Ocorre que diante de um projeto para desenvolver software, gerentes ou responsaveis se esforcam para estimar precisamente tarefas, tempos e recursos necessarios para a producao do bem.A producao do software visa gerar um bem que sera entregue ao final do projeto para o cliente.A producao de servicos e, necessariamente, uma operacao na qual o cliente e agente dentro do processo, pois servicos sao de consumo imediato, nao se pode estoca-los ou entrega-los a posterior.O desenvolvimento agil, no qual se aluga a forca de trabalho para o cliente, e uma prestacao de servico com bens associados. A equipe fica alocada ao cliente durante o tempo necessario a prestacao do servico. O cliente participa do trabalho, recebendo os beneficios como o aprendizado, sua garantia de qualidade pela certeza da adequacao do produto e o bem produzido.Explicar o planejamento para um predio costuma ser o exemplo utilizado para se explicar o porque se faz planejamento exaustivo e adiantado para o desenvolvimento de software.Entretanto, o desenvolvimento de software, em funcao de ser um servico exploratorio, que envolve a descoberta de conhecimentos tacitos, entrevista com os especialistas, possibilidade de atualizacao on-the-fly destes mesmos conhecimentos, sugere a utilizacao de metodos ainda mais poderosos de planejamento, do que o planejamento estatico, feito no inicio do processo de desenvolvimento, sem conhecimento suficiente e prevendo um intervalo de tempo normalmente muito grande.O planejamento agil e feito de forma incremental, prevendo escopo e horizontes de tempo de cada iteracao, portanto muito menores e com probabilidade de acerto muito maior.O risco ao longo deste processo fica diluido pelo escopo simplificado e prazo menores, sendo a probabilidade de sinistros tambem menor. Qual e o planejamento mais seguro?Qual o planejamento mais preciso? Numericamente o planejamento incremental e mais eficiente.A duvida deveria ser se esta forma de planejamento e viavel para o processo de desenvolvimento de software, entretanto as criticas ou a auxencia delas, segue no espaco do desconhecimento e desconsideracao de sua existencia e forma.Segundo Jeff Patton (2008), conhecer o problema mas nao saber desde o inicio o que se quer, e comum, e normal, e o suficiente.Eu humildimente complementaria que e inclusive melhor sob o ponto de vista de obter algo de qualidade. Lean Software Development: An Agile ToolkitBy Mary Poppendieck, Tom PoppendieckImplementing Lean Software Development From Concept to Cashby Mary Poppendieck; Tom PoppendieckAgile Estimating and Planningby Mike CohnAgile Project Management with Scrumby Ken SchwaberUser Stories Applied: For Agile Software Developmentby Mike CohnAgile Project Management with Scrumby Ken SchwaberUser Stories Applied: For Agile Software Developmentby Mike CohnAgile Estimating and Planningby Mike CohnAgile Testing: A Practical Guide for Testers and Agile Teamsby Lisa Crispin; Janet GregoryThe Art of Agile Development, 1st Editionby James Shore; Shane Warden Lendo o livro de David Anderson (2010 - Kanban), percebi um detalhe interessante que estava passando desapercebido por mim.Ele diz que descobriu e ficou curioso sobre teoria das restricoes, e aprendeu os conceitos iniciais desta tecnica. Sao cinco passos para melhorar o desempenho do sistema a partir da identificacao do elo mais fraco da corrente. Muito simples, muito interessante, dizem que roubado dos japoneses que nao tinha tradicao de