Sobre o 5CQualiBr Documentos Técnicos Blog Fórum Chat Publicações e Artigos Pesquisa Home Portal do Software Público Brasileiro :
5CQualiBr :
Iniciativas, programas, conteúdo multimídia e materiais de referência
Prestadores de Serviço Iniciativas, programas, conteúdo multimídia e materiais de referência
Outras Estruturas de Qualidade
O planejamento é uma atividade de suma importância no desenvolvimento de software. Há um mal-entendido comum sobre o agilismo de que neste não há planejamento ou de que o planejamento lhe seja algo periférico ou até mesmo incômodo. Nada mais enganoso. As abordagens ágeis para desenvolvimento de software conferem tamanha relevância ao planejamento que estimulam que o mesmo seja feito continuamente, ou seja, ao longo de todo o projeto.
A diferença em relação às abordagens tradicionais é que se espera que um plano ágil evolua e melhore iterativamente no decorrer do projeto. O planejamento é entendido não como o processo de produção de um plano, um documento com regras e expectativas a serem ferreamente cumpridas, mas como a busca por geração de valor. O planejamento produz um plano, mas este não é definitivo, devendo ser sempre melhorado. Deve ficar claro que para o agilismo, o planejamento é uma atividade, não um documento. O planejamento ágil balanceia o esforço e o investimento no planejamento com o conhecimento de que o plano será revisado e evoluído durante o curso do projeto. Assim, não há a necessidade de um alto investimento em um plano ultradetalhado no início do projeto. De acordo com Cohn (2006), o planejamento ágil possui 4 características principais: (1) é mais focado na atividade de planejar que no seu resultado, o plano; (2) não tenta evitar mudanças; ao contrário, as encoraja; (3) deve resultar em planos que são facilmente modificáveis e (4) é uma atividade disseminada por todo o ciclo de vida do projeto.
Duas frases extraídas de Cohn (2006) resumem o pensamento ágil a respeito do planejamento (tradução nossa):
"Se eu tiver que definir o que é um projeto fracassado, um de meus critérios certamente seria 'um projeto no qual ninguém veio com nenhuma ideia melhor do que aquelas que estavam na lista inicial de requisitos'" (p. 6)
"Um plano ágil é aquele que nós não somente iremos, mas estamos ansiosos para mudar. Nós não queremos mudar o plano simplesmente pela mudança; nós queremos mudar porque uma mudança de planos significa que nós aprendemos algo novo ou que evitamos um equívoco" (p. 9)
Como funciona o planejamento ágil
Na abordagem ágil para planejamento, um projeto não é visto como a execução de um conjunto de passos, mas como a geração contínua de um fluxo de novas capacidades e novo conhecimento. As novas capacidades são incorporadas ao produto; o novo conhecimento possibilita fazer do produto o melhor que ele pode ser. O conhecimento gerado pode ser sobre o produto (o que o produto deve ser) ou sobre o projeto (equipe, tecnologias utilizadas, riscos). Falhas em reconhecer estes novos conhecimentos levam a estratégias que tentam obter todo o conhecimento no início do projeto.
Cohn (2006) apresenta uma interessante analogia para se entender a diferença entre os modos de pensar do planejamento ágil e do tradicional. Na visão tradicional, se um projeto fosse uma corrida de 10 quilômetros onde a linha de chegada é conhecida e a meta é chegar a ela o mais rápido possível. Em um projeto ágil, a linha de chegada é um ponto no tempo. Neste sentido se parece mais com uma corrida baseada em tempo: chegar o mais distante possível em 60 minutos. Quando se reconhece que o resultado final é desconhecido – e mesmo impossível de ser conhecido – o planejamento se torna um processo de definição e revisão de metas que leva a um objetivo maior de longo prazo.
Como a consideração de que o resultado final em um projeto de software é desconhecido em seus detalhes contraria um dos mais arraigados preceitos da engenharia de software tradicional, o planejamento e levantamento de requisitos exaustivos no início do projeto, cabe uma melhor explanação a respeito.
Sob um ponto de vista ágil, o planejamento é um "constante processo de reavaliação e correção de curso durante todo o ciclo de vida do projeto" (tradução nossa) (BECK; FOWLER, 2000). Desenvolvimento significa um processo de aprendizagem, um exercício de descoberta (POPPENDIECK; POPPENDIECK, 2003). E um planejamento constante constitui, justamente, o ponto chave para se atingir um processo que acomode o aprendizado. Contudo, é impossível se produzir conhecimento, e por consequência, aprendizado, durante um projeto se a equipe de desenvolvimento tem pouco ou nenhum contato com os clientes, que são, em última análise, os produtores das especificações que o software precisa cumprir. De fato, os métodos ágeis preconizam que os desenvolvedores e os clientes construam um relacionamento de cooperação estreita, para que as atividades de desenvolvimento sejam baseadas em feedback concreto e não em especulações sobre o futuro, o que é comum nas abordagens tradicionais.
Brooks (1995) afirmou ser impossível para os clientes especificar, de um modo completo e preciso, os requisitos exatos de um projeto de software relativamente complexo antes de efetivamente utilizar algumas versões deste software. Isto significa que software em funcionamento é uma valiosa ferramenta de levantamento de requisitos, o que vai frontalmente contra o ciclo de vida baseado em fases das abordagens tradicionais, nas quais a programação (a atividade que gera software) somente é realizada em um momento tardio no projeto, quando os requisitos supostamente já estão levantados e estabilizados. Para obter um aprendizado efetivo durante o projeto, o software entregue aos usuários para auxiliar o levantamento de requisitos deve ter qualidade de produção e ser uma versão plenamente funcional, e não apenas um protótipo.
Os métodos ágeis atacam esta questão com o uso de iterações curtas. Em curtos períodos de tempo, software funcional é liberado para que os clientes possam verificar se o software implementado é exatamente aquele de que necessitam e que lhes gerará valor. Para cada iteração é alocado um pequeno número de funcionalidades, que serão implementadas pela equipe de desenvolvimento durante a iteração. As iterações devem ser tão curtas quanto possível, o que significa que o software é liberado em incrementos pequenos e freqüentes. Deste modo, é possível tanto para os desenvolvedores quanto para os usuários explorarem incrementalmente os requisitos e a maneira como o software vai sendo construído, permitindo uma melhor conformidade com as demandas do negócio. Além disto, quanto menores os incrementos e quanto mais curta é a iteração, mais rápido é o ciclo de feedback, levando a um controle de granularidade extremamente fina sobre o projeto e permitindo rápida correção quando o software começa a divergir das necessidades do negócio (MARTIN, 1999).
Do mesmo modo, o processo de levantamento de requisitos também é incremental. As funcionalidades não são detalhadas no início do projeto, apenas uma lista de funcionalidades é extraída inicialmente. Neste contexto, cada item desta lista não é um requisito, mas apenas um registro de sua existência, um compromisso de detalhamento futuro, um convite ao diálogo (JEFFRIES et al, 2001). Os detalhes acerca de uma funcionalidade são apenas analisados em profundidade na iteração na qual a funcionalidade é alocada.
No decorrer de um projeto, a lista de funcionalidades pode ser alterada diversas vezes pelos clientes, refletindo seu aprendizado sobre o software sendo criado e sobre suas próprias necessidades. A lista de funcionalidades, por sua vez, é priorizada em termos de valor de negócio: as funcionalidades consideradas mais importantes são implementadas primeiro. Isto constitui uma poderosa ferramenta para minimizar desperdícios e promover a simplicidade no desenvolvimento de software, uma vez que a decisão sobre o que será o escopo global do software não é tomada de uma só vez no início do projeto, mas iterativamente em seu decorrer. Assim, apenas as funcionalidades realmente necessárias são implementadas.
Outro ponto importante para os métodos ágeis é a busca por melhoria contínua: em intervalos regulares, equipes ágeis devem refletir acerca de suas práticas e pensar modos de ser mais eficiente, ajustando seu comportamento para esta meta (BECK et al., 2001; DERBY; LARSEN, 2006).
Para alcançar a forma de trabalho descrita nesta seção, é preciso traçar estratégias eficientes de planejamento.
Estratégias de planejamento ágil
O planejamento para além do horizonte visível sempre terá uma forte dose de especulação. Como se trata aqui de um produto intangível (software) e cujas interfaces são pessoas e mercados, a especulação sempre será altamente propensa a erros. Assim, o planejamento ágil procura estabelecer marcos dentro do projeto, a partir dos quais se pode vislumbrar o novo horizonte e fazer os ajustes necessários ao plano para que se possa alcançá-lo [muitos "se ..."].
A estratégia utilizada em planejamento ágil é uma estratégia em mútiplos níveis. No desenvolvimento de software, 3 níveis de planejamento são utilizados: diário, iteração e release.
BECK, K.; FOWLER, M. Planning Extreme Programming. New York: Addison-Wesley, 2000.
BECK, K. et al. Manifesto for Agile Software Development. 2001. Disponível em http://agilemanifesto.org, acesso em 06/06/2010.
BROOKS, F. The Mythical Man-Month. New York: Addison-Wesley, 1995.
COHN, M. Agile Estimating and Planning. New York: Addison-Wesley, 2006.
DERBY, E.; LARSEN, D. Agile Retrospectives: Making Good Teams Great. Dallas: The Pragmatic Bookshelf, 2006.
JEFFRIES, R. et al. Extreme Programming Installed. New York: Addison-Wesley, 2001.
MARTIN, R. Iterative and Incremental Development. 1999. Disponível em http://www.objectmentor.com/resources/articles/IIDII.pdf, acesso em 07/05/2010.
POPPENDIECK, M.; POPPENDIECK, T. Lean Software Development: An Agile Toolkit. New York: Addison-Wesley, 2003.ConteúdoGestão de RiscoHistórias do UsuárioMétricasPlanejamento da IteraçãoPlanejamento do ReleaseTécnicas de EstimativaVisão Índice