Scrum: Afinal o que significa ser empírico, iterativo e incremental?

De acordo com o Guia Scrum, o framework Scrum é fundamentado no empiricismo e emprega uma estratégia iterativa (e não interativa) e incremental. Mas a final o que significa cada uma dessas palavras?

Independente de seus significados no dicionário, para o Scrum, seus significados são:

* Empiricismo: o conhecimento provém de experiências e toda decisão é embasada no que se conhece e que se tem como verdade, até o momento de sua tomada. 

Na prática, isso significa evitar adotar premissas como verdades, sem sua efetiva comprovação. Adotar premissas é uma técnica muito comum, em projetos waterfall. No começo do projeto, quando estamos na fase de levantamento de requisitos, não temos maneiras eficientes de garantir aquilo que definimos. Então, criamos premissas que, caso não se comprovem, serão tratadas como mudanças de requisito (change request). 

O problema em se trabalhar assim é que, o momento de se testar a premissa é, geralmente, tardio; na fase de testes - após um longo período de design e desenvolvimento. Caso algo tenha que ser alterado, seu custo será alto, tanto em prazo, quanto financeiro. Ex: imagina que existe um projeto de um site e assumimos a premissa de que todos nossos clientes utilizam o navegador Internet Explorer 9.0. 

Então, todo desenvolvimento e testes são feitos, com base nesta premissa. Porém, no momento dos testes finais, nas máquinas dos clientes, identificamos que 40% utilizam o navegador Chrome. Imaginem o custo, de termos que alterar TODAS as funções desenvolvidas e que funcionam apenas no Internet Explorer.

Para evitar tal situação, o Scrum adota a prática de só decidir - e assim trabalhar - com fatos concretos. Caso não se tenha experiência anterior, ou fatos que embases uma premissa, o time trabalha para "comprar" o conhecimento. POC (provas de conteito), são uma técnica comum, para se adquirir um conhecimento importante e que ainda não temos. 

No exemplo acima, em vez de assumir uma verdade, o time faria um trabalho de campo, para verificar, exatamente, quais navegadores são utilizados pelos clientes. Isso evitará a necessidade de alteração futura, com menos custo e maior assertividade.

* Iterativo: iteração significa repetição. Assim, o conceito de iterativo, segundo o Scrum, significa realizar ciclos constantes (Sprints) repetidas vezes. Ciclos constantes - em duração, rotina de eventos, pessoas envolvidas (time) e ferramentas (tecnologia, linguagem de desenvolvimento, etc.) - elevam o conhecimento, velocidade de entrega e qualidade.

Independente do contexto (pessoal, profissional, entretenimento, etc.), toda vez que refazemos algo, o fazemos melhor. É aquele ditado: "a prática leva a perfeição". Logo, quanto mais praticamos, melhor nos tornamos no que fazemos.

Este conceito parece óbvio e simplório de mais. Mas, se olharmos sob outra ótica, veremos um risco que precisa ser gerenciado. Se toda vez que fazemos algo, o fazemos melhor; então aquilo que fizemos ano passado, certamente poderia ser melhorado - afinal, desde o ano passado, praticamos mais e, certamente, hoje fazemos melhor!

Sob esta perspectiva - e com foco no âmbito profissional -, a cada vez que desenvolvemos um entregável - seja uma funcionalidade de sistema, uma planilha Excel, um relatório, ou qualquer outro tipo de entregável - deixamos ali um débito técnico. Este débito é inevitável, uma vez que com o passar do tempo, a forma como fizemos o entregável fica desatualizada. 

Desta maneira precisamos, de tempos em tempos, revisitar aquilo que fizemos no passado - desde que ainda utilizado, lógico - para verificar se não poderíamos aprimorar algum ponto importante. Caso não revisitemos nossas entregas, corremos o risco de ficarmos tão desatualizados, que qualquer nova melhoria se torne complexa de mais, a ponto de não ser implementada - ou ter um custo mais caro, de implementação.

* Incremental: Este é o ponto mais difundido, para àqueles que já ouviram falar de Scrum. Incremental significa entregar partes de um todo, a cada final de ciclo (Sprint).

O benefício de se utilizar esta técnica, é que o cliente não precisa esperar todo desenvolvimento, para usufruir de benefícios do produto / entrega. 

Ao mesmo tempo, ao ter acesso constantemente às entregas (final de cada Sprint) - e mesmo que parciais - o cliente pode nortear o time de desenvolvimento, através de feedbacks contantes, sobre o que gostou ou não, do produto entregue.

Outro benefício, é que o cliente pode decidir mudar os rumos do produto - ou até parar seu desenvolvimento - no momento que entender ser necessário. Isso reduz riscos e prejuízos, aumenta a confiança, entre negócios e time de desenvolvimento, e produz um produto mais próximo às necessidades reais do cliente final.

Enfim, para se ter um melhor resultado, na utilização do Scrum, é importante analisar o guia com um olhar mais profundo sobre seus pilares, valores e técnicas. Buscar entender cada uma das iniciativas ali apresentadas. 

Afinal, como Mike Cohn diz no prefácio do livro Scrum Essencial (Kennet S. Rubin, 2012), existem milhões de maneiras de se fazer um hambúrguer, assim como existem bilhões de maneiras de se implementar o Scrum. Enquanto não existe certo ou errado, existe uma maneira melhor e pior de se fazer um hambúrguer, ou implementar o Scrum.

Product Backlog e Scrum Master. Uma ligação mais próxima do que se pensa

De acordo com o framework Scrum, o Product Owner (P.O.) é o responsável pela criação, priorização e gestão, do Product Backlog (P.B.). Este é um fator importante, para uma boa gestão do produto. Entretanto, o mesmo framework diz que o Scrum Master "serve" o P.O. na busca por técnicas, que resultem numa gestão eficaz do Product Backlog e garantir que o P.O. entenda como maximizar seu valor. Mas o que este "servir" significa, então?!

Primeiro, não significa que o Scrum Master atuará na escrita dos Product Backlog Items (P.B.I.) - ou histórias -, na priorização de itens ou intercederá, nas conversas entre o P.O. e seus Stakeholders. Isto deve ser responsabilidade do P.O. 

Além disso, devemos lembrar que o time de desenvolvimento é responsivo ao P.O. Isto é, ele deve esperar que o P.O crie e priorize os itens, em que o time trabalhará - salvo exceções. E é neste ponto, que o Scrum Master torna-se importante, no processo.

O Scrum Master deve certificar-se, que o P.O. possui um backlog preparado e priorizado. Parece trivial, que isso ocorra; mas é impressionante o número de times que trabalham sem um backlog mínimo. Uma boa prática, é ter um backlog com itens para 2 Sprints. Assim, o time poderá antecipar dependências e bloqueios e, caso o projeto / produto tome uma nova direção, não haverá muito trabalho perdido. Vale lembrar que, ter um bom backlog significa que todos seus itens possuem o nível de informações necessárias, para que o time entenda o que deve ser feito - o que varia entre times e itens do backlog.

Porém, apenas ter um backlog não garante que este esteja apto à ser desenvolvido. Para tal, é importante que o time o conheça bem, assim como que estime o esforço necessário, para sua entrega. O framework Scrum sugere um evento chamado de Refinamento, como forma de preparar o backlog, para seu desenvolvimento. 

Refinamento, é um evento que deve ocorrer durante toda Sprint, com tempo máximo de 10% de todo seu tempo útil. Assim, se uma Sprint tem prazo de 2 semanas, o Refinamento deverá tomar, no máximo, 8 horas (10% de 80 horas). Nele, o P.O. apresenta o backlog para o time, para que este possa tirar dúvidas, validar que possui toda habilidade necessária, para entrega, e estimar seu esforço.

Portanto, novamente o Scrum Master deve garantir que os eventos de refinamento ocorram, durante a Sprint. Quanto mais cedo na Sprint este evento iniciar, mais rico será seu resultado; pois o time poderá ter mais tempo para entender os itens, do backlog, e estudá-los, antes da reunião de planejamento - ou Planning.

Há, ainda, outros pontos onde o Scrum Master apoia, ou "serve" o P.O, em relação ao Product Backlog. Através do acompanhamento da velocidade do time - ou capacidade de entregas, por Sprint - o P.O. pode avaliar o prazo necessário, para finalização de uma funcionalidade, MVP ou release.

Enfim, o Scrum Master não é o guardião do Product Backlog, tão pouco seu representante. Mas é certo que suas relações são bem próximas.

MVP Ágil para Melhorar a Gestão de Expectativas dos Clientes

Como utilizar as Metodologias Ágeis de Desenvolvimento de projetos, em contratos firmados entre consultorias de sistema – que buscam estabilidade no escopo, para melhor gestão do contrato – e empresas que não possuem tempo em acompanhar, de perto, o projeto. Esta é uma pergunta que ouço frequentemente em conversas com executivos de vendas, de consultorias de sistema, ou de clientes, durante projetos que participei.

A resposta parece simples, mas a maneira de torná-la prática, nem tanto. Para resolver tal questão, eu utilizo o conceito de MVP (Minimum Viable Product, ou Mínimo Produto Viável), amplamente utilizado por algumas metodologias ágeis de desenvolvimento de projetos.

O conceito de MVP define que um produto deve ter o mínimo de funcionalidades, que viabilizem sua entrega. De maneira que o cliente possa começar a utilizar o produto mais cedo, com menos custo e, através desta utilização, gerar feedbacks que farão o produto amadurecer.

Apenas como exemplo, vamos admitir que um cliente precisasse se deslocar entre sua casa e trabalho. Então, o cliente contrata uma consultoria para desenvolver uma solução para este problema. Uma solução seria o desenvolvimento de um carro, que será caro e demandará muito tempo para ser entregue. O cliente, nesta condição precisará de muito tempo, e esforço, até que tenha sua necessidade atendida.

Outra solução é a consultoria desenvolver um Skate, para que o cliente possa ir e vir do trabalho. O produto entregue não tem o mesmo conforto que um carro, mas custou menos e precisou de menos tempo para ser entregue. O cliente começa, de maneira mais rápida, a ver sua necessidade atendida. E, Enquanto pode desfrutar do produto, o cliente pode planejar uma nova versão, até que tenha seu carro. Por outro lado, o cliente pode entender, ao utilizar o produto, que não era um carro que ele queria. Assim, ele pode aprimorar as versões do produto, enquanto o utiliza; o que o tornará o valor agregado do produto ainda maior.

Ainda resta o desafio de administrar a expectativa do cliente. Visto que, em um primeiro momento, tem-se a impressão de que demandará mais tempo e custo para o cliente atingir seu objetivo final. No nosso exemplo, ter o carro.

Metodologias Ágeis, como Scrum e Kanban utilizam uma técnica chamada Inception, para resolver este desafio. Nesta técnica, o cliente (neste caso principais envolvidos no projeto) são chamados para atender uma seção que dura entre 2 dias e uma semana.

Durante este tempo, questões serão abordadas, para que sejam definidos os objetivos que a solução atenderá, assim como aqueles que a solução não atenderá. E outros pontos, como características da solução, grupo de funcionalidades e grau de importância para cada um deles.

Através do grau de importância, que o grupo de funcionalidades possui, serão definidas as versões, que o produto terá até que se atinjam todos os objetivos da solução. O prazo médio, de duração das versões, também será acordado, mas geralmente duram entre 1 e 6 meses. Quanto menor for o prazo das versões, mais rápido termos o retorno do cliente, quanto o grau de sua satisfação. Isso diminui o risco de o produto, em desenvolvimento, não atender ás expectativas do cliente.

Algumas métricas podem ser utilizadas, para avaliar o andamento do projeto e verificar seu valor agregado, para validar se o projeto atende ás expectativas do cliente, bem como se deve ser mantido para próxima versão. Dentre elas, podemos destacar:

• O tempo médio despendido, entre a definição de uma funcionalidade e sua entrega;
• Quantidade de erros gerados por entrega – erros podem ser problemas de funcionalidades do produto, ou requisitos negados pelo cliente na entrega;
• Porcentagem de código escrito e que tenha testes automatizados – para facilitar a alteração de funcionalidades no futuro.

Ao utilizar o conceito de MVP, para contratação de um projeto, a consultoria fornecedora mitiga os riscos de gestão de escopo, visto que a quantidade de requisitos do projeto será menor – pois o projeto poderá ser contratado por versões –, enquanto que o cliente poderá dar mais atenção ao projeto, visto que suas entregas serão mais rápidas e o produto utilizado durante o desenrolar do próprio projeto.

Inteligências Múltiplas: O que São e Como Tirar Proveito

Na década de 1980, pesquisadores de Harvard, liderados pelo psicólogo Howard Gardner, desenvolveram uma nova teoria para descrever o conceito da inteligência. Eles acreditavam que o QI, modelo utilizado na época, não era capaz de descrever a diversidade de capacidades cognitivas do ser humano. Em outras palavras, uma pessoa não é mais esperta que outra apenas porquê aprende matemática mais facilmente.

A teoria de Gardner divide a capacidade humana em 9 áreas diferentes:

• Lógico-matemática: capacidade de solucionar problemas matemáticos, habilidade de raciocínio dedutivo e noção lógica apurada.
• Linguística: domínio e apreço pela comunicação, idiomas e o desejo de explorar.
• Musical: habilidade de compor e e execução de padrões musicais, além de ouvido apurado, apreço por ritmos e sons.
• Espacial: capacidade de compreensão visual apurada, com a capacidade de transformar e recriar experiências visuais sem estímulos físicos.
• Corporal-cinestésica: domínio do corpo, de seus movimentos e sua interação com o ambiente onde se encontra.
• Intrapessoal: a capacidade de se conhecer, entender suas próprias atitudes e sentimentos.
• Interpessoal: capacidade de se comunicar, entender o próximo e se fazer entender, criar relacionamentos e confiança.
• Naturalista: sensibilidade para compreender e organizar os objetos, fenômenos e padrões da natureza.
• Existencial: capacidade de refletir e ponderar sobre questões espirituais, filosóficas e históricas.

Diferente dos modelos mais tradicionais, a teoria desenvolvida por Gardner não aponta meios para avaliar cada uma das áreas da inteligência. Ao invés disso, a teoria indica que as áreas são componentes que podem ou não ser ativados e desenvolvidos, de acordo com a cultura, meio, educação e necessidades de cada pessoa.

Porém, mesmo sem serem quantificados, podemos avaliar quais das inteligências citadas são mais presentes em nós mesmos. Esta auto-avaliação é o ponto inicial para compreendermos como podemos tirar proveito dos pontos mais fortes, assim como evoluir pontos menos desenvolvidos.

Para pessoas que atuam em posições de liderança, é fundamental entender quais as áreas de inteligência mais presentes em nossos liderados, para que possamos aproveitar seus diferencias e até mesmo para oferecer Coaching em áreas menos produtivas. Isto é, se precisamos ensinar uma atividade lógica à uma pessoa com menos habilidades lógico-matemáticas, mas com habilidades corporais-cinestésica, a melhor maneira talvez seja emular o problema como em uma peça de teatro, ou história fictícia, para que a pessoa se sinta parte do problema e entenda melhor como solucioná-lo.

Por fim, a utilização da teoria das inteligências múltiplas não se restringe apenas ao mundo profissional. Pelo contrário, em nossa vida pessoal, em nosso cotidiano, podemos aprimorar todas as áreas de inteligência o quanto quisermos, através de atividades que estimulem nosso cérebro e que apontem para o desenvolvimento da área requerida.

Relatório do Caos - Por quê os Projetos Falham?

O Relatório do Caos é criado, anualmente, pelo Standish Group, e tem como objetivo apresentar um estudo sobre o cenário de projetos de TI. Para o estudo, o relatório apresenta uma comparação entre projetos para contrução de pontes e projetos de sistemas. O motivo do relatório escolher tal comparação, deve-se ao fato de serem projetos com características opostas. Enquanto um projeto de contrução de ponte tem pouquíssimia possibilidade de mudança de escopo, projeto de sistemas tem muita necessidade de mudança, devido ao dinamismo de seu mercado.

Para o relatório, projetos de contrução de pontes são, mundialmente, vistos como projetos de sucesso. E, quando fracassam, as causas do fracasso são investigadas profundamente, o que impede, ou mitiga, a possibilidade de repetição. Nos casos de projetos de sistemas, em caso de fracasso, suas causas não são investigadas e tratadas de forma correta, o que direciona para sua repetição.

O relatório aponta números impressionantes sobre os valores desperdiçados, por grandes empresas, devido a projetos que são cancelados antes mesmo de serem concluídos. Apenas nos Estados Unidos, 31% dos projetos são cancelados em fase de construção, o que implica em mais de 81 bilhões de dólares em prejuízos. E quando o projeto é concluídos, apenas 16% são entregues no prazo e custo estimados e com cerca de apenas 42% dos requisitos originais.

Mas por quê isto acontece? Por que os projetos de TI possuem números tão assustadores? 

Acredito que a maior causa dos problemas esteja relacionado justamente com a comparação realizada pelo instituto para criação do relatório. Os projetos de TI nasceram com os conceitos da construção civil, como a fase de planejamento, a engenharia, arquitetura e contrução. Muitas metodologias de gestão colocam  projetos de TI no mesmo patamar de outros projetos. Porém o dinamismo do mundo corporativo, não permite tal inclusão.

Eu costumo fazer uma alusão entre projetos de TI e seriados de TV, que acredito serem muito mais parecidos. Requisitos de projeto são como personagens do seriado; crescem de importância ou são excluídos de acordo com o andamento do projeto, ou seriado. E a comunicação entre a equipe técnica com seu cliente, é parecida com o retorno dado pelo público, durante a temporada de um seriado.

Outro ponto que difere projetos de TI dos demais projetos, é o fato de sistemas serem menos visíveis e tangíveis durante seu desenvolvimento. Em uma casa, ou ponte, podemos ver o que é contruído a cada etapa, sentir e tocar. Projetos de TI, por vezes, impedem tal percepção.

Por isso precisamos fazer com que o cliente esteja próximo da equipe técnica durante toda a fase de desenvolvimento de sistemas. Apresentar cada item desenvolvido e receber feedbacks sobre o andamento do projeto. E, para isso, precisamos mudar conceitos e buscar, no mercado, metodologias que embasem projetos de TI como algo singular, seja ágil ou não. Porém, o mesmo relatório aponta que projetos de TI, embasados por metodologias ágeis, apresentam melhores resultados. 

Até o próximo post.

AMDD e TDD - Arquitetura, Modelagem e Desenvolvimento Ágil

Os princípios, mencionados no artigo Ciclo de Vida de Desenvolvimento de Sistemas Ágil, podem ser utilizados junto à outras metodologias, ou conceitos, para se criar um processo de desenvolvimento de sistemas. Um desses conceitos é a Modelagem de Desenvolvimento Dirigira (MDD em inglês). Esse conceito guia como agrupar os requisitos do projeto, como modelá-los e como arquitetar a solução para atender aos requisitos. Assim, ao ser utilizada sob o foco ágil nasce a Modelagem Ágil de Desenvolvimento de Sistemas (AMDD em inglês).

Esse conceito pode ser utilizado juntamente com diversas metodologias ágeis para completar o Ciclo de Vida do Desenvolvimento de Sistemas. Isto é, a metodologia escolhida suportará o planejamento do projeto bem como suas alterações, como criar o fluxo de comunicação e etc. E o AMDD proverá como realizar estas tarefas, do ponto de vista da equipe técnica. Isto é, como dividir o desenvolvimento em iterações, como criar e manter os documentos necessários para o projeto.

Agile Model Driven Development

A Figura acima - http://www.ambysoft.com/essays/agileLifecycle.html - apresenta as tarefas realizadas em cada iteração do projeto, a partir da iteração 0 – início do projeto. A caixa verde mostra as atividades da iteração 0. Nesta fase, os requerimentos iniciais são modelados assim como a arquitetura inicial do projeto, ambos em caráter de macro-visão.

O modelo, dos Requisitos Iniciais representa a lista de requerimentos que os clientes necessitam que o sistema possua ou execute. Esta lista é chamada de Product Backlog, e contém os requisitos, ordenados por prioridade – as prioridades representam quais requisitos retornam mais valor ao negócio –, e nortearão a equipe técnica a desenvolver e entregar os requisitos mais importantes primeiro, assim como a estimar a duração do projeto de maneira mais eficiente.

É importante ressaltar que esta lista pode ser alterada durante o projeto pelos clientes, com a inclusão, mudança ou retirada de algum requisito. Porém tais alterações são realizadas em momentos específicos, como veremos a seguir.

O modelo da Arquitetura Inicial representa a arquitetura que será utilizada pela solução em uma visão macro. Isto é, o modelo proverá qual tecnologia será utilizada, qual a linguagem de programação, banco de dados, se será Web ou Cliente-Servidor e etc. O detalhamento da arquitetura como componentes, seqüência ou classes serão modelado no início de casa iteração de Construção.

As caixas azuis representam as iterações de Construção, seguintes à iteração 0. Cada iteração de Construção possui a mesma estrutura. Isto é, cada uma das iterações começa, se desenvolve e termina através do mesmo processo.

Ao dividir o Product Backlog, criado na iteração 0, em sub-listas, uma nova lista será criada. Esta nova sub-lista chama-se Sprint Backlog.

O Sprint Backlog proverá ao time de desenvolvimento quais requisitos serão desenvolvidos durante a iteração atual. Ainda que o Sprint Backlog possa ser alterado pelos clientes, é primordial que este seja congelado, no início da iteração, de modo a estabilizar o trabalho da equipe técnica. Assim, se algum requisito, pertencente ao Sprint Backlog, necessitar de alterações, um novo requisito deve ser criado e priorizado para próxima iteração. Se esta alteração é realmente importante, os clientes devem escolher um outro requisito para ser substituído, ou projetado para uma próxima versão do produto.

A primeira atividade de cada umas das iterações de Construção é avaliar e validar o Sprint Backlog. Esta atividade está incluída na tarefa de Modelagem da Iteração. Esta atividade é muito importante, pois através dela é possível certificar que o prazo da iteração é viável e que seus requisitos são possíveis de serem desenvolvidos. Outro ponto é que este é o momento em que os clientes podem sugerir mudanças do escopo de maneira mais eficaz e com menos riscos para a qualidade do projeto.

Além disso, nesta atividade, o modelo da arquitetura é revisto e detalhado para incluir os itens necessários para o desenvolvimento da iteração atual.

A melhor maneira de se criar o Modelo de Tomada (Model Storming) é se reunir com a equipe técnica, por cerca de 30 minutos em média, e analisar todas as possibilidades de risco para o item e apontar a melhor estratégia de desenvolvimento. Esta tarefa é feita para cada item a ser desenvolvido na iteração atual.

A tarefa de Desenvolvimento Dirigido à Teste (TDD em inglês) adiciona a documentação e o desenvolvimento efetivo dos itens. TDD é um conceito que suporta estratégias de desenvolvimento de sistemas, onde o desenvolvedor primeiro constrói o teste que deve ser feito para validar o item desenvolvido e, em seguida, constrói o código fonte para atender os testes com sucesso.

De acordo com este conceito, o desenvolvedor cria o teste necessário para validar alguma funcionalidade e, em seguida, começa a desenvolver o fonte para implementar a funcionalidade. A idéia é criar o código fonte passo a passo – cerca de 10 linhas – sempre testando o código. A funcionalidade está criada com sucesso, quando os testes rodam com cucesso. A figura abaixo apresenta como o TDD funciona.

Test Driven Development

Se o TDD for bem implementado, os testes criados serão utilizados como a documentação técnica e o código certamente será bem executado. Entretanto, nem todas as funcionalidades do sistema deve ter um teste implementado. Somente códigos críticos ou complexos deveriam ter testes implementados. O desenvolvedor deve pensar se a funcionalidade é complexa o suficiente para requerer uma estratégia TDD.

Assim, no final de cada iteração, depois de todos os itens pertencentes ao Sprint Backlog serem desenvolvidos, o sistema estará pronto para ser entregue à equipe de Testadores para certificarem-se que o produto não possui problemas. Se tudo estiver bem, os clientes podem iniciar seus testes. Estes testes proverão um parecer se os requerimentos foram desenvolvidos como necessário e se eles estão satisfeitos com o sistema.

Se tudo estiver de acordo, o projeto segue paras as próximas iterações. Caso contrário, as mudanças necessárias são implementadas e testadas, conforme o ciclo de vida do projeto. 

Até o próximo post.

Ciclo de Vida de Desenvolvimento de Sistemas Ágil

Todo projeto de desenvolvimento de sistemas possui o mesmo fluxo, não importa o tamanho ou propósito. Começam devido alguma necessidade e terminam com a entrega de um produto. Este fluxo é chamado de Ciclo de Vida de Desenvolvimento de Sistemas (SDLC em inglês). Tanto as metodologias tradicionais quanto ágeis possuem um tipo de SDLC.

A Figura abaixo apresenta um Cico de Vida de Desenvolvimento de Sistemas baseado no Scrum (extraída da página: http://www.ambysoft.com/essays/agileLifecycle.html). Segundo a figura, o projeto é dividido em fases subseqüentes e as fases de construção em sub-projetos.

A iteração -1 representa a pré-fase do projeto, quando os requerimentos são levantados e apurados. Esta iteração é de responsabilidade do cliente junto à área de negócios. Isto é, eles devem entender quais suas necessidades e listar o que gostariam que fosse desenvolvido. A responsabilidade da equipe técnica do projeto é garantir que é possível entregar o que os clientes esperam.

A iteração 0 determina o início do projeto. Após o projeto ser aprovado e iniciado, o escopo é fechado e os requisitos listados e priorizados. Os clientes, junto com a equipe técnica, irão priorizar os itens e dividi-los em sub-listas. A quantidade de sub-listas tornarão-se a quantidade de iterações da Fase de Construção. Nesta iteração o ambiente começa a ser planejado e configurado. Isto é, o número de estações de trabalho são listadas, as configurações dos servidores revistas, licenças de aplicativos revista – para garantir que a equipe terá condições de trabalhar – ou qualquer outra informação relevante para garantir não só o encaminhamento do projeto, mas como a operação deste em produção. E finalmente, a equipe do projeto é arquitetada, isto é, quantos desenvolvedores, testadores, arquitetos e demais estarão inclusos no projeto e por quanto tempo.

As iterações de Construção são todas as iterações necessárias para desenvolver o sistema. Cada uma possui as mesmas atividades. Isto é, todas possuem as tarefas de análise, desenvolvimento, teste e publicação dos pacotes, e devem possuir durações curtas, de 2 a 4 semanas. Devido à existência de todas essas tarefas, as iterações de Construção são consideradas sub-projetos.

No início dessas iterações, a equipe técnica define os itens que serão desenvolvidos. Então inicia-se a modelagem, desenvolvimento e teste destes itens (a maneira de como planejar as atividades foi comentado no artigo Planejamento Ágil).  Para criar um fluxo de comunicação, dentro da equipe técnica, claro e objetivo, o time deve realizar uma reunião curta toda manhã. O Scrum nomeia esta reunião como Stand Up Meeting, o que em português significa Reunião em Pé. Está reunião tem curta duração e deve ser realizada em pé (razão de seu nome) por volta de 15 minutos, onde o time discute o que foi feito desde a última reunião, o que será feito até a próxima e se existem impeditivos para tal. Sua realização proverá, à cada integrante da equipe, uma visão geral do andamento do projeto e prevenir que o time caminhe para um caminho errado.

Ao final do desenvolvimento de cada item, dentro da iteração, os desenvolvedores devem testar o que foi desenvolvido. O ideal seria que um outro desenvolvedor, ou o líder do desenvolvimento, testassem algo que foi desenvolvido, como uma revisão de código. Isto ajudaria a equipe a entregar sistemas com mais qualidade, pois os testes seriam realizados de uma maneira menos viciada. Além disso, esta ação podem aprimorar a confiança dos clientes, nos produtos e no time de desenvolvimento, pois eles terão produtos com menos problemas. Ao final de cada ciclo da iteração de Construção, a equipe de Qualidade testará o pacote entregue, para garantir a confiabilidade e qualidade do produto.

Em seguida aos testes da equipe de qualidade, os clientes podem realizar seus testes. Se os clientes avaliarem positivamente o produto apresentado, eles estarão mais confiantes e entusiasmados para investir no projeto. Entretanto, se eles não avaliarem positivamente, o projeto pode ser cancelado – diminuindo assim o prejuízo por antecipar seu fim – ou alterações podem ser feitas para garantir que o projeto entregue valor real ao negócio.

Ao final de cada ciclo da iteração de Construção, bem como no final do projeto, uma reunião de Lições Aprendidas deve ser realizada. Esta reunião tratará de como o projeto foi conduzido e apresentará o que cada integrante entende como boas práticas para um próximo projeto e o que deve ser reformulado. Estas reuniões alimentarão uma base de conhecimentos compartilhada por todos na empresa e serão base para próximos trabalhos.

A fase de Release é a fase onde o projeto e publicado no ambiente de Produção. Se todas as outras fases obtiveram sucesso, esta fase representará um intragável que atende às necessidades do negócio. E este é sempre o maior objetivo do projeto. Entretanto, se alguma das outras fases obteve fracasso, ou foi realizada com ressalvas, devido à falta de participação por parte dos clientes, ou problemas técnicos, a tendência é que produto entregue não atenda as necessidades reais do negócio. Ainda nesta fase, as documentações necessárias para o usuário, como manual ou itens para treinamento devem estar prontos.

A Produção é a fase onde apenas correções de erros e suporte são feitos. Além disso, esta fase proverá informações úteis sobre o que pode ser melhorado ou alterado no sistema, e que podem ser listados para uma próxima versão do produto. Assim, um novo projeto será iniciado.

A fase “Retirement”, ou Retirada em português, é a fase onde o produto é removido do ambiente de produção, seja devido à uma nova versão do sistema, ou devido o produto não ser mais necessário.

Até o próximo post.