Modelos de Governação de TI

Não há uma definição que sirva todos os modelos para a governação de TI.

Os três modelos comuns são baseados nos três estilos de tomada de decisão das organizações. Estes são: centralizada, federada ou descentralizada.

No modelo centralizado é enfatizada a eficiência e o controlo de custos relativamente à responsabilidade das unidades de negócio. Há um interesse grande nos standards, sinergias e economias de escala.

No modelo descentralizado há uma grande propriedade do negócio da unidade e responsabilidade, mas a integração e as sinergias sofrem o que resulta em prováveis custos mais altos.

O modelo federado tenta combinar as melhores funcionalidades dos dois anteriores. As aplicações comuns e os recursos de infra-estrutura são partilhados, enquanto as unidades de negócio controlam as respectivas aplicações específicas.

Características de uma boa Governação de TI

¶ Os investimentos e as decisões de TI são avaliados de forma similar aos investimentos de negócio e as TI são geridas como um activo estratégico. Isto significa que há a participação da gestão de topo nas decisões chave de TI. Existe uma orientação do board para os investimentos de TI e executivos que são responsáveis e prestam as contas da realização dos benefícios.

¶ As TI são uma parte essencial do planeamento corporativo e do planeamento estratégico. As TI compreendem as dinâmicas de negócio e contribuem para o desenvolvimento da estratégia do negócio, que está interligada com a estratégia de TI. As TI e o negócio trabalham em conjunto para identificar oportunidades.

¶ Os principais riscos de TI são considerados de forma integrada dentro da estrutura de gestão de risco corporativa. Os riscos como os de protecção de dados, segurança de TI e continuidade de negócio merecem uma revisão periódica por parte do board.

¶ A performance das TI é medida regularmente e comparada com os seus pares e as boas práticas do mercado.

¶ Como e porque são tomadas as decisões é claramente entendido e os resultados são clara e formalmente comunicadas aos stakeholders. Os processos de excepção formal estão estabelecidos e promovem a transparência bem como permitem a aprendizagem organizacional.

As 4 Perguntas da Governação

Conforme as organizações do sector público e privado estão cada vez mais dependentes das TI, também começa a existir um crescente reconhecimento da necessidade de governação das TI como uma parte essencial da mais ampla governação das organizações. A Governação é tudo acerca de quem toma as decisões, como são estas decisões formadas e quem tem de prestar contas delas.

Muitos dos executivos de topo ainda consideram as TI como muito complexas, técnicas e difíceis de governar. A governação de TI continua, muitas vezes só nas grandes organizações, a ser percebida comi uma coisa do CIO (Chief Information Officer) e desta forma a governação do negócio continua a ser fraca.

As 4 perguntas da governação

A governação das TI visa garantir que os recursos da organização são usados da forma certa para criarem valor enquanto gerem os riscos das TI. A framework Val-IT do IT Governance Institute trata destes desafios. Esta é uma sólida estrutura de conhecimentos que ajuda que os esforços das organizações sejam alinhados e que as TI continuem a entregar valor para o negócio.

1. Será que estamos a fazer coisas certas? Peter Drucker disse “Não há nada tão inútil como fazer eficientemente as coisas que não deveriam nunca ser feitas”. Esta é a pergunta sobre se deveríamos fazer de todo tal coisa. Garante assim o alinhamento estratégico entre o negócio e as TI. Aquilo que estamos a pretender fazer encaixa dentro da visão e estratégia da organização? Será que é consistente com os princípios de negócio?

2. Estaremos a fazê-lo da forma correcta? Esta é a pergunta que trata da arquitectura e dos standards. O que estamos a fazer está conforme com a arquitectura e os processos?

3. Estamos a realizá-lo bem? Esta é a questão sobre a execução. Será que possuímos processos para a realização disciplinada e para a gestão da mudança? Possuímos os recursos com as capacidades especializadas correctas e estaremos a geri-los adequadamente? Como medimos a nossa performance relativamente a outros? Estamos a gerir com efectividade os riscos?

4. Estamos a obter os benefícios? Esta é a pergunta da realização do valor dos investimentos / projectos de TI. Temos um claro consenso acerca deles? Possuímos as métricas para os avaliar? A Responsabilidade pelos benefícios está claramente definida?

Estas 4 questões cobrem o cerne da governação, que é constituído por: Alinhamento Estratégico, Realização de Valor das TI, Gestão de Risco das TI, Gestão da Performance e Gestão de Recursos de TI. Quando os gestores em todos os níveis tratarem destas questões será quando a Governação de TI fará parte da cultura.

Desenhar Objectivos SMART

A cultura anglo-saxónica habituou-nos à utilização de acrónimos e frases que funcionam como mnemónicas mentais para fazer as coisas da forma entendida como a mais adequada. Um desses é o SMART.

O acrónimo SMART é uma ferramenta para nos assegurarmos que os nossos objectivos e instruções são Específicos (S). Mensuráveis (M), Atingíveis (A), Relevantes (R) e em Tempo (T). Ajuda na clarificação do que pretendemos alcançar e estabelecer os prazos para ficarmos certos que iremos produzir os resultados que queremos dentro da escala de tempo que necessitamos.

1º Passo – Avalie as suas intenções

Antes de começar a afinar os seus objectivos, lembre-se de reverificar a sua intenção para querer alcançar este objectivo. Pergunte-se a si próprio:

• Qual é o resultado final que quero alcançar?
• Porque é que isto é tão importante para mim e para a minha organização?
• Se não alcançar este objectivo ou o fizer deficientemente, como é que isso irá afectar a minha carreira / planos de vida, auto-estima ou realização no trabalho?
  

2º Passo – Torne-os Específicos

Se a sua descrição de objectivos é inequivocamente clara para aqueles que a lêem, está à procura de confusão e de uma desculpa. Depois de ter escrito o objectivo pergunte-se a si próprio:

• Se alguém ler este objectivo, será que conseguirá executá-lo sem me ter a mim para o explicar?
• Será que o objectivo fornece as respostas ao Quem? Quê? Quando? e Onde?
• Está curto e conciso?
  

3º Passo – Torne-o Mensurável?

Já ouviu dizer, provavelmente, que «O que pode ser medido, pode ser feito.» Quando se desenham declarações de objectivos que são mensuráveis, estamos muito mais perto de as fazer e sabemos que as alcançámos porque produzem resultados claros. Para se assegurar que os seus objectivos obtém resultados, pergunte-se:

• Como saberei se este objectivo ou milestone foi alcançado e até que ponto?
• Como é que o irei medir e com que frequência?
• É totalmente claro para os que são parte da realização deste objectivo quais são os resultados mensuráveis?
  

4º Passo – Tornar os Objectivos Alcançáveis

Até pode querer, na próxima semana, ter uma promoção no trabalho ou até começar uma viagem à volt do mundo por um ano. Embora estes objectivos sejam excitantes e possíveis, eles podem não ser atingíveis para já. Pergunte-se:

• Pode este objectivo ser atingido (mesmo com algum esforço) dentro da escala de tempo indicada? Se não, divida o objectivo em partes mais pequenas e escreva de novo a declaração de objectivo.
• Se não consigo alcançar este objectivo dentro da escala de tempo indicada, quais são as mudanças que devo fazer para o conseguir?
  

5º Passo – Torne-o Relevante

Se os objectivos não parecem relevantes temos a tendência de os pôr na estufa. De facto, há sempre demasiadas outras coisas em que nos focarmos e para fazermos. Para garantir que os objectivos são relevantes, pergunte-se:

• Como é que este objectivo de alinha com a imagem total?
• Que problemas poderão surgir se não conseguir concluir este objectivo?
• É mesmo neste ano ou mês que este objectivo deve ser concretizado?
  

6º Passo – Fazer em Tempo

Muitos objectivos falham porque não identificamos a linha de tempo dentro da qual os queremos realizar. Para aqueles de nós que somos recorrentes em não fornecer escalas de tempo mensuráveis, parece-nos que os mesmos objectivos aparecem vezes e vezes repetidas nas nossas folhas de planeamento: para prevenir quer isto aconteça, pergunte-se:

• Será que estabeleci um prazo final global para a realização deste objectivo?
• Indiquei as milestones ou outros prazos para as actividades que contribuem para o progresso?
• Quando é que quero isto concretizado?

O que é o PRINCE2?

“Projects in Controlled Environments” ou, em breve, PRINCE2 está a tornar-se um dos métodos mais populares e amplamente utilizado para a gestão de projecto. Pouco utilizado no nosso país, onde é quase desconhecido, é usado no sector privado e público e tornou-se o standard de facto para gestão de projectos no reino Unido.

Continuando o sucesso obtido no Reino Unido, o interesse por este método começou a espalhar-se pelo mundo. Os países em que se tornou mais usado são a Holanda, Bélgica, Alemanha, África do Sul, Austrália e mesmo nos EUA.

A que se refere o 2 em PRINCE?

O PRINCE” nasceu em 1975, a partir da metodologia PROMPTII. Esta foi substituída pela PRICE em 1989, passando a ser o standard para todos os projectos de sistemas de informação do governo do Reino Unido. Em 1996, a metodologia foi relançada como uma metodologia genérica de gestão de projecto para todos os projectos do governo britânico.

Porque foi introduzido o PRINCE?

Podemos dizer que o sector público de qualquer país não pode dizer com fundamento que a forma como faz a gestão dos seus projectos seja exemplar. Antes pelo contrário! O PRINCE e o PRINCE2, posteriormente, foram introduzidos para enfrentar as causas comuns de fracasso nos projectos, muito em especial no sector público.

Como actua o PRINCE2?

PRINCE” é uma estrutura de boas práticas que apoia os gestores a realizar projectos em tempo e dentro do orçamento. Divide os projectos em etapas claramente definidas com um princípio, meio e fim. Concentra-se na realização de produtos em vez de realizar actividades. Todos os projectos devem ter um business case e um plano que são periodicamente revistos para verificar se continuam viáveis.

Um projecto PRINCE” tem as seguintes características:

¶ Um ciclo de vida definido e finito

¶ Produtos de negócio definidos e mensuráveis

¶ Um conjunto correspondente de actividades para realizar produtos de negócio.

¶ Uma quantidade definida de recursos

¶ Uma estrutura de organização, com responsabilidades definidas, para gerir o projecto.

Como é estruturado um projecto PRINCE2?

No centro da metodologia está o Board do Projecto, constituído pelo cliente, representantes do utilizador e do fornecedor. O Gestor de Projecto reporta a este board, com regularidade, o progresso, os problemas e o board decide como deve o projecto proceder.

Quais são os benefícios do PRINCE2?

PRINCE2 dedica-se realizar os projectos certos, no tempo certo pelas razões certas. Fornece sistemas comuns, procedimentos e linguagem para os projectos. Oferece ainda:

¶ Melhor controlo e uso dos recursos

¶ Meios de gerir riscos e questões

¶ Pontos de decisão flexíveis

¶ Revisões regulares do progresso em relação ao plano de projecto e ao business case.

¶ Garantia de que o projecto continua a ter uma justificação de negócio

¶ Visibilidade antecipada dos problemas

¶ Boas comunicações entre a equipa de projecto e os outros stakeholders

¶ Um mecanismo para gerir desvios ao plano do projecto

¶ Um processo para capturar as lições aprendidas.

Com isto tudo PRINCE” permitirá poupar tempo e dinheiro ao mesmo tempo que se realizam com mais efectividade os projectos.

Gestão de Projecto e Impacto no Sucesso dos Projectos

Na próxima semana, inicio uma acção de formação em Gestão de Projecto para uma empresa de desenvolvimento de software portuguesa. As 3 palavras desenvolvimento, software e portuguesa parecem que se contradizem. Mas não! É uma empresa com sucesso, especializada no software e portuguesa.

A pergunta que me coloquei foi: como posso contribuir para com a Gestão de Projecto melhorar o seu sucesso?

Ao lidar com projectos de TI,  a utilização de técnicas de gestão especializada de projecto poderá ser muito benéfica para o progresso dos projectos em curso e, sobretudo, para o crescimento da taxa de sucesso no longo prazo. O planeamento e a gestão de Projectos pode ser complicado por muitas razões e isso faz com que a capacidade de concluir com sucesso se torne um activo de muito valor.

Algumas complicações comuns

A dificuldade na gestão de projectos de TI reflecte-se na elevada taxa de insucesso dos mesmos. De facto, um relatório de 2009 publicado pelo The Standish Group indica que apenas 32% dos projectos de tecnologia da informação desenvolvidos pelas empresas foram considerados bem-sucedidos.

Quase um quarto de todos os projectos de TI falharam, enquanto 44% foram considerados «comprometidos», ou seja, foram considerados atrasados, a gastar mais que o orçamento ou não indo ao encontro de todos os requisitos do projecto. Com esta taxa de fracasso, é fácil perceber por que são especiais as competências e conhecimento de gestão de projectos em TI (e, muito especialmente, em software) e a sua necessidade para manter os projectos na linha.

Em geral, os projectos falham por um conjunto de razões. Por exemplo, um projecto pode falhar devido a planeamento pobre ou insuficiente, a um âmbito mal verificado ou a uma escala de tempo irrealista. Embora estes sejam problemas comuns em todos os tipos de fracasso em projecto, a natureza tecnológica dos projectos torna este tipo particular de situações mais provável de se desenvolverem.

Entre os factores que contribuem para o fracasso dos projectos estão:

· A falta de profissionais com experiência especializada em gestão de projecto;

· As complicações derivadas da utilização de tecnologia incompatível ou insuficientemente madura;

· A falta de compreensão geral acerca dos desafios específicos dos projectos de tecnologia de informação por parte daqueles responsáveis pelo seu planeamento, execução e controlo

A formação e as boas práticas em Gestão de Projecto

Apesar de existirem desafios específicos para superar quando se trata gestão de projectos de, a realização de alguma formação neste campo pode conduzir a uma maior compreensão de como abordar as questões e contornar os problemas. Ao participar em cursos de gestão de projecto com formação especificamente para tecnologia da informação, você pode aprender como aplicar estratégias comprovadas para projectos de TI, a fim de melhorar os resultados e gerar processos mais eficientes.

Técnicas como a criação de métricas para medir o desempenho uniforme do projecto e padronizar a linguagem utilizada para descrevê-las, Sistemas de controlo de projecto aceites e utilizados pela equipa e processos de colaboração durante a execução, são alguns conceitos básicos de gestão de projectos que podem melhorar muito os resultados do projecto quando envolve tecnologia de informação. Manter monitorização estreita de prazos e custos do projecto e âmbito do projecto de gestão são vitais quando está a tentar garantir um projecto de tecnologia da informação se mantem no caminho certo.

Luís Quintino

Análise de Negócio numa Equipa Agile

Os processos, produtos e relações alteram-se numa equipa Agile.

Como planeamos o trabalho, entregamos o produto, representamos os requisitos, partilhamos o conhecimento, interagimos com a equipa e cliente, gerimos os requisitos em mudança e documentamos os requisitos será completamente diferente dos projectos tradicionais em Waterfall.

De facto, pass a fazer parte de uma equipa de colegas altamente colaborativos com um foco furioso em realizar valor, negociando a realização de valor em ciclos curtos e apoiando os parceiros de negócio para compreenderem o que realmente necessitam, não só no imediato, mas também conforme o produto vai aparecendo em pequenos pedaços utilizáveis.

Que muda

Os analistas de negócio devem ceder o controlo dos requisitos, a relação com o cliente e a documentação usual de requisitos. Porquê? Só porque na equipa Agile você entrega software valioso a trabalhar numas poucas semanas. E você (a sua equipa e o seu cliente) não sabem qual será exactamente o produto final mesmo até ao momento em que se começa a construí-lo, entrega-lo e obter, então, feedback sobre ele. Só então apreendemos qual é a real necessidade.

Um projecto Agile é tudo acerca de suspender o controlo durante tanto tempo quanto o possível.

Até as funções da equipa podem ser ambíguas: As especificidades podem variar, mas uma equipa Agile colabora para entregar um conjunto de requisitos a que se comprometeu. Cada membro da equipe está pronto, mesmo ansioso a fazer o que for preciso para que isso aconteça, não importa o que ditarem as responsabilidades oficiais do trabalho .

É provável que não seja o único a elicitar, analisar e especificar requisitos. A equipa está focada em entregar um software «utilizável» em ciclos curtos (iterações), assim as suas actividades podem cruzar sobre outras actividades que entusiasmam as suas competências, capacidades e interesse.

Por exemplo, é pouco provável que você se identifique ou mesmo crie e execute testes de aceitação do utilizador: a validação em cima do produto. As suas competências soft e a compreensão das dependências dos requisitos tornam-no um bom candidato para realizar o planeamento de workshops de definição do mapa de trabalhos do produto e planos de release.

Como Analista de Negócio Agile você deixou de estar preso à grande e complexa documentação de requisitos e modelos. Em vez disso, vai influenciar os seus parceiros de negócio e equipas a repensar que tipo de (e quanta) documentação é necessário. Você pode entregar a documentação em pequenos pedaços, juntamente com os pequenos e úteis pedaços de requisitos que a sua equipa de entrega em cada iteração (muitas vezes sob a forma de user stories). Você pode passar a desenvolver uma documentação leve de produto, de utilizador ou de suporte.

Novo tipo de trabalho

O seu trabalho é, ao mesmo tempo, táctico e estratégico: você tem de entender o ponto de vista global (o mapa de visão do produto e os planos de release), mantendo ao mesmo tempo uma mão firme no agora (a iteração corrente). Tem de ter a disciplina e a flexibilidade para operar em modos múltiplos (o «agora» da iteração corrente e o «depois» das próximas iterações.

O seu trabalho será transparente. Você obterá melhores estimativas e ao trabalhar com seus companheiros da equipa multifuncional pode prever com segurança quanto o software a sua equipa pode entregar em cada iteração. A visibilidade de planeamento da iteração, as demonstrações de final de iteração, e as retrospectivas não permitem permitir nenhum esconso. Você vai sentir-se mais em controlo, já que vai ser abertamente responsável perante seu cliente, a equipe, e você próprio.

Luís Quintino

Cinco competências de Comunicação

Liderar Pessoas – a parte prática da gestão de projecto – é tão importante como as competências para as actividades.

A comunicação é uma competência crítica para o sucesso do projecto porque mantém os membros da equipa actualizados e porque ganha o apoio dos stakeholders chave.

Mas quais as competências que fazem a diferença? Eis a opinião de muitos dos gestores de projecto.

1. Escuta activa

Esta é a nossa capacidade para ouvir e compreender os outros. Ouvir as palavras e o significado por detrás das palavras, não interromper ou deixar a nossa mente vaguear, colocar perguntas para garantir a compreensão, observar os sinais não-verbais.

2. Construir relações com base no respeito e confiança

A confiança e o respeito são as pedras angulares das relações pessoais. São conquistadas e não são um direito, decorrem da experiência com a sua honestidade, integridade e competência.

Entre as características que as pessoas usam para determinar a nossa credibilidade estão a honestidade, transparência, vontade de compartilhar ideias e informações livremente, a consistência, confiabilidade, lealdade, capacidade e competência.

3. Definir prioridades claras

Em terceiro lugar, está a capacidade de um gestor de projecto de transmitir a estratégia à sua equipa – através do estabelecimento de metas, planeamento e priorização. Isto é o quê, o quem, o quando, o onde, o porquê e o como do projecto. Os membros da equipa devem compreender quer o plano geral como as prioridades técnicas de baixo nível.

4. Favorecer a colaboração

Num ambiente colaborativo os membros da equipa apoiam e encorajam-se uns aos outros em vez de se focarem unicamente nas suas actividades e responsabilidades.

Eles estão dispostos a cooperar e partilhar informações, ideias e recursos para ajudarem-se uns aos outros. O resultado, assim, pode ser maior que a soma de suas partes.

5. Liderar a visão da organização

Clarificar o plano geral ajuda os membros da equipa a compreender onde se encaixa o projecto os propósitos globais da unidade de negócio e da organização. Os executivos seniores estão focados nos três pontos – finanças, ambiente, reputação – que é onde eles esperam que o seu projecto marque pela diferença.

O SCRUM essencial

O termo Desenvolvimento Iterativo e Incremental descreve uma categoria de metodologias para desenvolvimento de software em que o sistema cresce incrementalmente através de ciclos completos de desenvolvimento.

Os métodos de desenvolvimento agile de software são um grupo de metodologias iterativas específicas que combinam interacções relativamente curtas com refinação evolucionária dos requisitos, planos e metas ao longo de cada interacção subsequente.

Aparentemente as metodologias agile e iterativas tem mais baixo risco que os métodos com o estilo Waterfall, em que todo o planeamento e o desenho é feito antes do desenvolvimento.

Scrum

O SCRUM é uma das mais simples metodologias agile e provou já ser altamente efectivo para quer o desenvolvimento de software quer o desenvolvimento de produtos mais genéricos. O SCRUM é muitas vezes utilizado no desenvolvimento de produtos financeiros.

Baseia-se na ideia que durante um projecto os clientes irão com a maior das certezas mudar de ideias acerca do que querem e necessitam. Para enfrentar isto, um projecto Scrum avança numa série de interacções curtas cada uma das quais realiza um conjunto incremental de melhorias ao produto.

Scrum faz a mediação entre resultados e funcionalidades operáveis. Isto permite ao cliente receber um produto operável mais cedo e permite que o projecto mude os seus requisitos de acordo com as necessidades em mudança.

A metodologia oferece um conjunto de práticas e funções pré-definidas que são adoptadas pela equipa para maximizar as capacidades da equipa para entregar com rapidez e responder aos requisitos mudados e emergentes.

A Equipa Scrum

Uma equipa Scrum é normalmente Transfuncional e consiste em cerca de 5 a 9 pessoas, mas pode ser muito maior. A equipa tem a responsabilidade de entregar o produto. O Scrum encoraja a localização de todos os membros da equipa e a comunicação verbal entre todos.

Existem algumas funções específicas no Scrum:

O ScrumMaster

Os projectos Scrum são geridos com um estilo de gestão muito flexível e requerem gestores de projecto com experiência específica na gestão de projectos agile. A função de gestão de projecto é não tradicional, já que o ScrumMaster é, em primeiro lugar, um facilitador que institui regras acordadas, remove impedimentos ao progresso e garante que a equipa se mantém focada.

As equipas Scrum são auto-organizadas. O ScrumMaster não é o líder da equipa e actua como um buffer entre a equipa e quaisquer influências que a distraem

Proprietário do Produto

O Proprietário do Produto representa o cliente e assegura que a Equipa Scrum trabalha nas «coisas certas» numa perspectiva de negócio. O Proprietário do Produto escrever «estórias» centradas no cliente que são uma ou duas frases que em linguagem de negócio descrevem uma funcionalidade específica do produto. Estas são então implementadas pela equipa Scrum.

Stakeholders

Estas são as pessoas para quem o projecto irá produzir os resultados acordados. Eles só estão envolvidos directamente no processo durante as revisões do progresso realizado.

"Sprints" e "Backlogs"

O trabalho é compartimentado em pequenas parcelas de cerca de duas semanas de duração. Denominadas «Sprints». Durante cada Sprint, a equipa cria um incremento completo do produto tendo como resultado um produto potencialmente entregável.

O conjunto de funcionalidades que são incluídas em cada Sprint decorre de um conjunto de requisitos de alto nível do trabalho a ser feito, conhecido como «backlog do produto». Este contém descrições genéricas de todas as funcionalidades desejadas para o produto novo ou actualizado, priorizadas em termos do seu valor projectado para o negócio, bem como com estimativas do esforço necessário para as realizar.

Quais os itens específicos do backlog que são incluídos no Sprint é determinado durante uma reunião de planeamento anterior ao Sprint. Durante esta reunião, o Proprietário do Produto informa a equipa sobre os itens do Backlog do Produto que querem que sejam completados. A equipa determina então a quanto se pode comprometer durante o próximo Sprint, o que passa a ser o «backlog do Sprint» do próximo Sprint.

Durante o curso do Sprint, não é permitido a ninguém alterar o backlog do Sprint, o que significa que os requisitos estão congelados para aquele Sprint. Depois do Sprint ser concluído, a equipa demonstra o produto para o Proprietário do Produto. A equipa pode cancelar um sprint se sentir que não são capazes de alcançar os objectivos do Sprint e stakeholders externos podem também cancelar o Sprint se se manifestarem circunstâncias externas que negam o valor para proceder com este. Se um Sprint termina anormalmente, o próximo passo será conduzir uma reunião de planeamento para um novo Sprint, onde é revista a razão da terminação.

Um quadro apresentado publicamente é usado para mostrar o trabalho remanescente para o Sprint corrente. Isto é denominado um gráfico de Sprint burndown e deve ser actualizado todos os dias para oferecer visibilidade ao progresso realizado.

Transitar para o Scrum

A transição dos métodos tradicionais de trabalho para o Scrum é relativamente transparente. Pode haver benefícios em envolver um formador experimentado em Scrum para assistir na formação e implementação.

O Scrum trabalha muito bem à sua maneira é também é um excelente primeiro passo se se pretender introduzir conceitos agile na organização visto ser simples e focar-se numa gestão de projecto a alto nível.

Tradução e adaptação de artigo de Chris Young

Waterfall ou Agile: Como escolher a abordagem do desenvolvimento de Software?

Os projectos de desenvolvimento de software são normalmente abordados com a utilização alternativa de dois métodos, o Waterfall ou o Agile. Ambos têm prós e contras e cada um tem defensores que salientam o valor da sua abordagem preferida. \

Vamos analisar ambos os métodos e tentar compreender qual é o melhor e sob que circunstâncias respondem à questão: Como escolher a abordagem do meu desenvolvimento de Software?

O método de Waterfall (ou de Cascata)

O método de Waterfall já é usado desde 1970 e continua a ser o mais comum. Afirma que deve ser seguido um conjunto distinto de passos através do ciclo de vida do projecto. Os passos são usualmente similares a estes:

• · Análise de Requisitos
• · Desenho
• · Implementação
• · Teste
• · Instalação
• · Manutenção

A razão pela qual é denominado o método de Waterfall (cascata) é por que cada etapa decorre a partir da prévia quando esta se conclui, descendo como uma cascata. Como uma casta flui para baixo e nunca para cima. Este método é muitas vezes considerado como «mais seguro».

O método funciona bem em ambientes comerciais em que os contratos são assinados e o dinheiro é pago. Contudo. Quando se trabalha para clientes internos, é mais difícil fazer má cara a mudanças de última hora quando são as pessoas da organização que as pedem e muitas vezes com o apoio da gestão de topo.

Prós	Contras
Documentação detalhada	Início lento.
Requisitos acordados e assinados.	Requisitos fixos difíceis de mudar.
Pode ser desenvolvido com programadores com conjunto de competências mais baixo.	Não há visibilidade do software para o cliente até que o desenvolvimento esteja concluído.
Número reduzido de defeitos através de um planeamento do desenho.	Falta de flexibilidade tornando difícil mudar de direcção.
Pontos de início e de fim definidos para cada fase, permitindo que o progresso possa ser facilmente medido	Os Clientes não estão inicialmente conscientes dos requisitos.

Método Agile

O método Agile refere-se a uma abordagem iterativa a projectos, em que os requisitos e soluções evoluem através da colaboração entre clientes e equipas de desenvolvimento. O termo está ligado a 2001 quando foi lançado o «Agile Manifesto».

Se o gestor do projecto está receoso de cometer erros frente ao cliente este não é o melhor método a adoptar. O método Agile significa que criamos resultados o mais cedo possível e vamos refinando-os através diversas iterações com o cliente. Contudo, verifica-se que alguns stakeholders encaram negativamente esta abordagem.

Assim, será que o método Agile conduz a uma mais rápida entrega de resultados? Só porque conseguimos começar a programar mais cedo não significa necessariamente que iremos terminar mais cedo. Mas, garante que o resultado final vai de encontro às expectativas e necessidades do cliente, por que , principalmente, ele consegue oferecer válidos inputs durante toda a fase desenvolvimento.

Prós	Contras
Início rápido, releases incrementais e revisões regulares e feedback do cliente.	Pode ser mal interpretado como não planeado ou indisciplinado.
Evolução dos requisitos ao longo do tempo.	Exige uma equipa de alta qualidade que possa enfrentar o cliente.
Capacidade de resposta rápida à mudança.	Necessita de um envolvimento de alto nível por parte do cliente.
Menor trabalho repetido alcançado através de teste continue envolvimento do cliente.	Falta de planos detalhados de longo prazo.
Comunicação em tempo real entre o desenvolvimento e o cliente.	Produz documentação de baixo nível.

Conclusão

Então qual é o melhor método, Waterfall ou Agile?

Nenhum…

O método que usamos depende de vários factores, tais como:

Tipo de trabalho: há um resultado claramente definido? O desenvolvimento de sites da web é criativo e adere com facilidade ao método Agile. Já o desenvolvimento de sistemas de transacções, onde existe um resultado claramente definido adapta-se melhor ao método Waterfall.

Tipo de cliente: será que o cliente está disposto a trabalhar de forma iterativa, terão tempo suficiente para rever e comentar as iterações regulares?

Ponto de vista do gestor: Será que ele favorece um método relativamente ao outro. Até que ponto é ele adaptável?

Apreciação das TI na organização: as TI são vistas como um parceiro valioso ou um mal necessário? Se o ponto de vista é o último, então utilize o método de Waterfall.

Cliente externo ou interno: o seu cliente é externo ou interno? O método Waterfall funciona bem com clientes externos para os quais é normal existir um contrato assinado, pelo contrário com os clientes internos podem forçar mudanças com base no suporte da gestão de topo.

O gestor de projecto deve seleccionar o método que melhor satisfaça as necessidades dos utilizadores. O problema surge quando existem diferenças de opinião. Neste caso, escolha o método que irá realizar o melhor resultado e faça a gestão dos desacordos.

No fim ambos os métodos podem realizar o projecto. O segredo está na gestão das expectativas do cliente e na realização de um produto de qualidade. A realidade é que quando se chega ao fim da viagem, já ninguém se importa como é que lá se chegou.

LQ

Conhecer os custos de um projecto não é suficiente!

Para se poder compreender o verdadeiro valor de um projecto e decidir se o levamos a cabo ou não (ou mesmo até, em primeiro lugar, iniciá-lo) não é muito útil considerar unicamente os custos. Se os benefícios excedem os custos então não há razão porque os custos não podem aumentar. O que é importante é que os benefícios continuem a exceder os custos.

Quando a organização pretende verificar se estes componentes se mantêm em desequilíbrio é porque pretende validar a realização.

Quando analisamos os custos torna-se vital que também verifiquemos os benefícios. Nós temos coisas chamadas centros de custo onde todos os custos relevantes são acumulados e mantidos e inevitavelmente debruçamo-nos sobre eles, analisamo-los e revemo-los, etc. E então o que fazemos com os benefícios? Quando foi a última vez que ouvimos falar de um centro de benefícios?

O que precisa então ser conhecido acerca destes benefícios que podem vir a ocorrer num futuro incerto? A próxima vez que estiver num projecto pense acerca do que pode ser necessário registar destes benefícios, para garantir que são compreendidos de forma adequada a poderem ser reconciliados com os custos. Sugeria o seguinte:

• Descrição do Benefício – uma narrativa que nos ajude a compreender o âmbito daquilo que esperamos obter.
• Quando é expectável ocorrer o benefício e qual o período durante o qual se realizará – os benefícios são raramente óbvios de forma imediata. Taxa Interna de Retorno, Valor Líquido Presente, Payback e outros indicadores financeiros trabalham tão bem com benefícios como com custos.
• Medir a realização do benefício e como será obtida – como iremos medir o verdadeiro valor e particularmente como é que o poderemos medir. Não se esqueça de fazer uma avaliação do «estado actual» já que todas as melhorias devem ser medidas em relação com alguma coisa.
• Que custos estão directamente associados com os benefícios em questão.
• Qual o projecto que irá realizar os outputs que permitirão obter os benefícios.
• Que riscos podem estar associados com o caminho de obtenção do benefício.
• Quem irá ser responsável e proprietário da realização dos benefícios.

Se registamos os benefícios desde o início estaremos em boa posição para validarmos as razões para o projecto e aptos a demonstrar a sua viabilidade.