planejamento ágil de projeto
Publicado: 04/07/2009 Filed under: principal 7 comentáriosUma das perguntas recorrentes nas listas de discussão é como se planeja um projeto sob a ótica da filosofia ágil. Não há uma diferença gritante do ponto de vista de técnicas em relação ao que tradicionalmente se faz. Mas há uma diferença substancial na forma como se encara esse planejamento e na forma de estimar seu prazo. Além disso, há outra grande diferença na forma em que o planejamento é acompanhado. Mas isso é vinho de outra pipa.
É preciso deixar claro que o que vou falar daqui pra frente é um entendimento bastante generalista. Há várias nuances válidas e detalhes não explorados no texto. Mas acho que o post responde à dúvida habitual a respeito de planejamento ágil de projetos. Além do mais, planejamento tem relação com uma série de questões, como gestão da comunicação, de recursos humanos, de aquisições, etc. O texto se limita apenas a estimativas de prazo – e custo, por tabela – e a elaboração de cronograma, que acho que é a dúvida corriqueira.
Como se faz tradicionalmente? De forma geral: levantam-se primeiramente as funcionalidades esperadas. Depois classifica-se cada uma em pequeno, médio ou grande (APCU e APF, habitualmente). Cada classificação dessas representa uma quantidade de pontos. Soma-se então os pontos de cada funcionalidade chegando-se a um subtotal. Ajusta-se esse subtotal de acordo com algumas complexidades do projeto e chega-se ao total de pontos do projeto. Depois calcula-se o tempo total do projeto de acordo com a velocidade histórica da equipe. Ex.: se o sistema tem 180 pontos e se e equipe produz em média 10 pontos por mês, isso quer dizer que o projeto deve durar 18 meses. Se vai durar 18 meses, e se a equipe custa $50.000 por mês, isso quer dizer que o projeto vai custar $900.000.
Em geral, em projetos ágeis a coisa funciona mais ou menos do mesmo jeito, com pequenas diferenças. Não há por exemplo essa classificação em pequeno, médio e grande para cada funcionalidade. Também não há esse ajuste em relação às complexidades do projeto. Elas são consideradas, mas de outra forma.
O planejamento começa apresentando-se as tais complexidades (normalmente requisitos não-funcionais, como nível de usabilidade, portabilidade, tolerância a falhas, escalabilidade, etc.) do projeto, para que a equipe tenha noção do buraco em que está se metendo e para que elas influam nas estimativas. Depois levantam-se as funcionalidades (em geral, histórias) esperadas. Depois, a equipe estima cada funcionalidade em pontos (aqui na Fortes utilizamos horas-ideais). Somam-se então os pontos das funcionalidades achando o total de pontos do projeto. O resto é igual: divide-se o total de pontos pela velocidade achando o tempo total do projeto, derivando igualmente seu custo.
É na elaboração do cronograma que o bicho pega, que denota a enorme diferença entre o que se faz tradicionalmente e o que se faz no mundo ágil.
Um cronograma tradicional estabelece uma série de fases para cada funcionalidade, realizadas por pessoas diferentes, em que cada fase representa a produção de um documento que é transmitido para a fase seguinte. Um exemplo de cronograma tradicional:
De novo: fui simplista. Faltaram por exemplo as correções de cada funcionalidade e os testes de integração e correções de cada release. Mas a ideia é dar uma visão geral.
Esse mesmo projeto sendo ágil:
Release #1 [00/00/0000]
Funcionalidade #1
Funcionalidade #2
Funcionalidade #3
Funcionalidade #4
Release #2 [00/00/0000]
Funcionalidade #5
Funcionalidade #6
Funcionalidade #7
Funcionalidade #8
Nesse caso, cada funcionalidade é desenvolvida idealmente de forma geral por toda a equipe, uma após a outra. Quando se termina uma funcionalidade, termina mesmo, coberta por testes automatizados, unitários, de integração, de aceitação, exploratórios, de estresse. De fato, quanto a esses dois últimos tipos de teste, há equipes ágeis que os realizam por release. Aqui na Fortes, realizamos os testes exploratórios por funcionalidade. Quanto aos de estresse, ainda não os temos.
O planejamento do projeto, apesar de relevante, não é aquilo que evidencia peremptoriamente as diferenças entre os mundos tradicional e ágil, apesar de dar algumas pistas, como podemos observar nas questões das fases e na existência do papel separado de projetista. E olhe que, no caso do exemplo tradicional, expus um exemplo de projeto de certa forma iterativo-incremental. Imagine se apresentasse um cascata. Agora perceba que, no exemplo tradicional, as funcionalidades são desenvolvidas paralelamente. Imagine uma mudança de requisitos nesse cenário. Como reconstruir o cronograma? Como atualizar todos os documentos? Aqui na Fortes, já fomos por um breve período “tradicionais”. O que acontecia quando de uma mudança de requisitos? Abondonávamos o planejamento e íamos no peito e na raça.
Um dos mitos a respeito de desenvolvimento ágil é ausência de planejamento. Uma pena. E de certa forma, curioso. XP foi a metodologia que “popularizou” o desenvolvimento ágil, e há um livro, escrito por Kent Beck e Martin Fowler, só sobre planejamento em XP.
Clavius Tales 
Esses mitos de XP são bem curiosos mesmo, considerando a larga bibliografia já lançada nos últimos 10 anos, creio que XP tem maturidade sufiente para planejar adequadamente um projeto de software, mas é aquela coisa, não tem o charme “Project Management” que o Scrum atraiu. vai entender.
Sobre as métricas, Tales, temos que considerar que nas “horas ideais” variam de projeto a projeto e essa variação no final de contas é um chute mesmo. Muitos atribuem 30% para a variação, outros preferem até 50%.
Qualquer dia escrevo um post sobre homem/hora e porque o tempo é ralativo 😀
Blogue mais, tá muito parado aqui e estamos ansiosos pelos seus textos… 🙂
Oi, Milfont.
Não entendi esse esquema de que horas-ideais variam de projeto para projeto, mas concordo que é um chute mesmo, mas com um certo controle, com uma certa técnica. É só uma forma de dar uma macroestimativa do projeto, de ter uma noção de grandeza. Aí entra o que citei sobre o acompanhamento, como o planejamento é encarado pelos agilistas. Quando uma gravadora dá um ano para uma banda produzir um disco, não quer dizer que a coisa é feita da seguinte forma: serão quinze canções, então vocês devem me entregar uma canção a cada 24 dias.
Tales, a hora ideal de programação que considero tem que se levar em conta se a empresa já passou pelo knowhow de ter desenvolvido um sistema com características semelhantes entre outros aspectos.
Agora o principal, complexidade de um algoritmo nem sempre é a complexidade do que é necessário para dominar esse algoritmo e sim knowhow das pessoas envolvidas no processo, exemplifico:
Imagine um algoritmo que necessite calcular a rotação de uma matriz, tome um programador que saiba algebra linear e é muito bom em matemática, essa operação que é trivial para ele vai ser calculada com um esforço grande por todo o time [provavelmente] e uma atividade que foi calculada como um esforço pequeno como por exemplo um CRUD com muitos relacionamentos que precisava de um bom conhecimento em ORM se mostrou levar mais tempo do que o necessário.
Claro que em um processo ágil que haja realmente boa comunicação, isso pode e vai ser minimizado porque o desenvolvedor deverá convencer a todos que a tarefa não é tão cabulosa como todos imaginam.
Isso já aconteceu muito comigo, lembro de uma tarefa que era fazer busca textual e foi considerada de alta complexidade pelo time mas como eu já tinha feito isso antes e sabia o caminho das pedras eu calculei um tempo muito pequeno e foi cumprida no prazo acordado.
Então, esses pontos modificam a ordem de grandeza da velocidade do time e deve ser ajustada de projeto a projeto de acordo com o KnowHow dos envolvidos, eu acredito muito no conselho do Kent Beck para contratar consultores especialistas para facilitar esse andamento.
Aproveitando esse parágrafo e já mudando de assunto:
Eu estou vendo isso na prática hoje em um cliente [que até já falei para você], como um especialista inserido no time conseguiu dar uma agilidade e fazer ultrapassar a concorrência com menor esforço e menos recursos.
Olá Tales,
Cheguei a este post através da lista scrum-brasil. Muito legal a tua explicação sobre o assunto.
Pelo que eu entendi, da mesma forma que a maneira tradicional, tu estimas o projeto todo de uma vez, provavelmente no começo do projeto. É isso?
Oi, André.
Estimamos no começo sim, o projeto todo. Mas como disse, em geral os agilistas têm uma percepção diferente em relação a essa estimativa. Está mais para uma noção de grandeza do que para um dado preciso. Ou então encara-se como um orçamento, do tipo: “Faça o melhor possível com esse orçamento.” Além disso, quanto maior o projeto, maior o grau de incerteza. Isso tudo precisa ser levado em conta. Outra coisa que os agilistas costumam fazer é um ajuste constante do planejamento (aqui na Fortes por exemplo monitoramos semanalmente). Assim, se a estimativa original estiver fugindo demais da realidade, podemos renegociar e reestimar.
Oi, Milfont.
Imagino que as estimativas já absorvam esse tipo de questão. Ou seja, as pessoas vão naturalmente estimar “tempos” maiores se o domínio não é tão conhecido.
Cheguei a esse post através de busca sobre iniciar um planejamento de atividades na criação de projetos de software. Muito interessante, gostei muito do nível dos participantes, e da forma como os assuntos são tratados e esclarecidos.