O documento discute as vantagens do desenvolvimento ágil de software e apresenta várias metodologias ágeis como Scrum, Kanban, XP e FDD. Ele destaca que pesquisas mostram que projetos ágeis têm maior taxa de sucesso do que projetos tradicionais e que a adoção de práticas ágeis pode ajudar equipes a entregar software funcionando com mais frequência e a se adaptar melhor às mudanças.
8. Você se prende a paradigmas?
Não desenvolva apego a nenhuma
arma ou escola de combate.
Miyamoto Musashi
(famoso samurai do século 17, se destacava por sua técnica de luta
das espadas gêmeas)
9. Seu processo não é tão flexível?
Mais prescritivo Mais adaptativo
11. Sua equipe só está apagando fogo?
Esse fenômeno da engenharia de
software é conhecido como
Síndrome do Estudante
Eu devia ter estudado antes…
Executado
Planejamento
13. Manifesto Ágil
Indivíduos e interações entre eles
mais que processos e ferramentas
Software em funcionamento
mais que documentação abrangente
Colaboração com o cliente
mais que negociação de contratos
Responder a mudanças
mais que seguir um plano
14. SCRUM
Scrum é uma metodologia ágil para gestão
e planejamento de projetos de software.
15. FDD (Feature Driven Development)
FDD é uma metodologia ágil para gestão e
desenvolvimento de software.
A empresa americana chamada Standish Group , há pouco mais de uma década, vem produzindo um relatório chamado The Chaos Report que pesquisou 280 mil projetos de software nos EUA e revelou: 72% deles falham por algum motivo. 17% desse fracassaram tão vigorosamente que foram cancelados .
Os atrasos normalmente representam 63% mais tempo que o estimado. Os gastos normalmente são 45% maiores que o orçado. No geral apenas 67% das funcionalidades prometidas são efetivamente entregues .
Concluiu-se com a pesquisa que o Princípio de Pareto também se aplica ao desenvolvimento de software, onde 20% das funcionalidades costumam gerar 80% ou mais do benefício esperado . Não há priorização no desenvolvimento de funcionalidades. Os programadores priorizam da forma que acharem melhor e normalmente preferem desenvolver as funcionalidades mais simples primeiro. Resultado entrega de parte do sistema que o cliente não irá utilizar .
Muitas pessoas e empresas acreditam que UML é documentação . UML é uma linguagem universal entre analistas, desenvolvedores e stakeholders e deve ser usada de forma a ser útil, não um fardo. Uma das soluções para diminuir o volume de documentos gerados é a utilização de boas práticas, na codificação. código simples , padronizado , organizado e bem comentado muitas vezes tem mais valor. Outro recurso que pode ser utilizado é automatizar o processo de documentação , a fim de evitar as prováveis defasagens.
Uma das principais diferenças entre Metodologias Ágeis e RUP é que no RUP você recebe coisas demais, e você supostamente remove o material que não precisa. Nas Metodologias Ágeis você recebe muito pouco, e supostamente adiciona o material que lhe falta.
Fenômeno onde pessoas começam a se esforçar para finalizar uma tarefa no último momento possível, ou seja antes do final do prazo. Isso leva a perda de qualquer buffer (gordura) reservado para comprimento de outras tarefas. Na hora da implementação, o desenvolvedor acaba usando todo o tempo reservado para a tarefa na melhor das hipoteses. Devido a isso, quando uma tarefa apresenta maior complexidade do que o esperado, todos os buffers individuais que foram reservados para as tarefas anteriores já foram usados, fazendo com que o tempo para todas as tarefas seja maior do que o previsto
Nos dias 11 a 13 de fevereiro de 2001, em uma estação de ski nas montanhas Wasatch de Utah, 17 pessoas se encontraram para conversar, esquiar, relaxar, e tentar encontrar um lugar comum e claro, para comer. O que emergiu foi o Manifesto para Desenvolvimetno Ágil de Software. Representantes da Extremme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, e outros simpatizaram com a necessidade de uma alternativa aos pesados processos de desenvolvimetno de software orientados a documentação Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas
Conta com a experiência dos desenvolvedores. Utilização de seqüência fibonaci : 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100. Depois de esclarecidas todas as dúvidas em relação a história, todos pontuam . As menores e as maiores pontuações devem ser justificadas . A re-pontuação é feita até que se entre em um consenso . Se a pontuação for 40 ou 100 , a história deve ser revisada , verificando se a mesma esta bem coesa . Conforme a equipe se familiariza com o sistema, a duração passa a ser baseada na complexidade: Tamanho ≠ Duração , com base no histórico de pontuações.
Conta com a experiência dos desenvolvedores. Utilização de seqüência fibonaci : 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100. Depois de esclarecidas todas as dúvidas em relação a história, todos pontuam . As menores e as maiores pontuações devem ser justificadas . A re-pontuação é feita até que se entre em um consenso . Se a pontuação for 40 ou 100 , a história deve ser revisada , verificando se a mesma esta bem coesa . Conforme a equipe se familiariza com o sistema, a duração passa a ser baseada na complexidade: Tamanho ≠ Duração , com base no histórico de pontuações.
Conta com a experiência dos desenvolvedores. Utilização de seqüência fibonaci : 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100. Depois de esclarecidas todas as dúvidas em relação a história, todos pontuam . As menores e as maiores pontuações devem ser justificadas . A re-pontuação é feita até que se entre em um consenso . Se a pontuação for 40 ou 100 , a história deve ser revisada , verificando se a mesma esta bem coesa . Conforme a equipe se familiariza com o sistema, a duração passa a ser baseada na complexidade: Tamanho ≠ Duração , com base no histórico de pontuações.
Reunião em pé (15 minutos) Deve ser respondido: O que foi feito? Qual o próximo passo? Há algum impedimento? Comemoração a cada história finalizada ( sinergia ). Depois da reunião: Atualização dos indicadores .
Com ciclos menores, tomadas de decisão podem ser feitas, a tempo de resolver problemas a curto prazo.
O acompanhamento das da evolução dos Sprints, é necessário para controlar a saúde do projeto e tomar decisões de médio e longo prazo.
O acompanhamento das da evolução dos Sprints, é necessário para controlar a saúde do projeto e tomar decisões de médio e longo prazo.
O termo lean foi cunhado ao final da década de 80 em um projeto de pesquisa do Massachusetts Institute of Technology (MIT) sobre a indústria automobilística mundial. A pesquisa revelou que a Toyota havia desenvolvido um novo e superior paradigma de gestão nas principais dimensões dos negócios. Naquela época, a montadora japonesa não estava nem entre as dez maiores do mundo. Em 2009, a Toyota tornou-se a maior em volume de vendas, acumulando vitória após vitória ao longo destas décadas, mostrando as vantagens e benefícios do sistema que desenvolveu. Os 3 Pilares: Eliminar o desperdício , Melhorar continuamente e Respeitar as pessoas . Reduzir o desperdício ou otimizar qualquer processo de trabalho é um grande desafio , pois não basta apenas eliminar tarefas julgadas como desnecessárias, mas sim, trata-se de uma grande mudança na mentalidade das pessoas . É disso que trata o Pensamento Lean (Lean Thinking).