Métodos Ágeis
Valores:
Adaptação a mudança mais do que seguir um plano;
Software funcionando é mais importante que documentação completa e detalhada;
Indivíduos e iterações são mais importantes que processos e ferramentas;
- Colaboração do cliente mais do que negociação do contrato;
Princípios:
1: A mais alta prioridade é a satisfação do cliente através da libertação mais rápida e contínua de software de valor.
2: Receba bem as mudanças, mesmo em estágios tardios de desenvolvimento. Processos ágeis devem admitir mudanças que trazem vantagens competitivas para o cliente.
3: Libere software com frequência de um par de meses, com preferência para uma escala de tempo mais curta, 2 ou 3 semanas.
4: Mantenha as pessoas dos negócios e os desenvolvedores trabalhando juntos a maior parte do tempo do projeto.
5: Construa projetos com indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado.
6: O método mais eficiente e efetivo de passar informação entre uma equipe é através da conversação cara-a-cara, pessoalmente.
7: Software funcionando é a principal medida de progresso.
8: Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica indefinidamente.
9: A atenção contínua para a excelência técnica e um bom projeto aprimora a agilidade.
10: Simplicidade – a arte de maximizar a quantidade de trabalho não feito é essencial. Fazer apenas o necessário.
11: As melhores arquiteturas, requerimentos e projetos emergem de equipes auto organizadas.
12: Em intervalos regulares as equipes devem refletir sobre como se tornarem mais efetivas e então refinarem e ajustarem seu comportamento de acordo. Buscar aumento de produtividade.
SCRUM
Framework de gerenciamento de projetos e controle. Libera funcionalidades a cada 30 dias. Compatível com a ISO 9001, MPS.BR nível C, e CMMI nível 3. Simples de entender, porém difícil de aplicar.
Sistemas Adaptativos Complexos – CAS: É um sistema formado por uma rede dinâmica de agentes atuando em paralelo, agindo e reagindo constantemente ao que os outros agentes estão fazendo. O controle de um CAS tende a ser disperso e descentralizado. Os “agilistas” consideram o desenvolvimento de software como um CAS.
Uma metodologia pode ser considerada ágil quando é:
Incremental: liberar pequenas versões em iterações de curta duração;
Colaborativa: cliente e desenvolvedores trabalhando juntos em constante comunicação;
Direta: O método em si é simples de aprender e modificar;
Adaptativa: Capaz de responder as mudanças até último instante.
Elementos do SCRUM
… → Product Backlog → Reuniões de Planejamento → Sprint Backlog → Burndown → Impedimentos → Product backlog → ...
Papéis
Product Owner: Dono do Produto, conhece o negócio e representa demais stakeholders. Estabelece e comunica a visão do produto. Cria o release plan e o product backlog inicial. Monitora o projeto com metas de ROI. Responde e apóia o Scrum Team para sanear dúvidas sobre requisitos. Decide quando serão liberadas as versões do produto. Atualiza e prioriza continuamente o product backlog para assegurar que as funcionalidades mais valiosas são produzidas primeiro. É o Gerente de Produto assumindo parcelas do gerente de Projetos.
Scrum Master: Semelhante ao GP, responsável por liderar o time. Acompanha o progresso do trabalho, verifica se está sendo seguidos os padrões e inspeciona as implementações.
Scrum Team: Time multi-fucional que reúne todas especializações necessárias para implementar segmentos completos de software a cada sprint. Identifica impedimentos e reporta ao Scrum Master. Realiza a reunião diária de Daily Scrum para garantir comunicação plena do time e sincronismo de tarefas, de pé, no máximo 15 minutos. Pode lançar mão de quaisquer recursos disponíveis para se adaptarem a circunstancias não previstas.
Stakeholder: São todos os interessados no software em desenvolvimento a começar por clientes, usuários finais, equipe de marketing e vendas, scrum master, management e outros. São representados pelo dono do produto que deve conhecer o interesse e coletar ideias de todos para contruir o Product backlog.
Management: corrensponde ao grupo diretor, que provê fundos ($$) para o projeto ou responsável em última instância.
Detalhamento dos Elementos do SCRUM
→ Product Backlog
Este documento contém todos os itens que devem ser implementados no produto alvo. É atualizado sempre que houverem novas demandas para o produto alvo. Cada item deve ser estimado para determinar o tempo necessário para desenvolvê-lo.
→ Reuniões de Planejamento
Define-se os itens do Product Backlog que serão adicionados no sprint atual. Planeja-se o total de horas da equipe destinada ao sprint. A estimativa de cada item do Product Backlog diminui o total de horas planejada para o Sprint, o planejamento é encerrado quando acaba-se o total de horas que a equipe tem disponível, normalmente 40 horas. Não faz hora extra, planeja fazer apenas o possível para a semana ou dia.
→ Sprint Backlog
É a lista de itens adicionados no sprint atual, sprintpost-it grande e colado na coluna Backlog do quadro. Caso o item seja complexo para desenvolver deve-se detalhar em atividades menores através do post-it médio. Pode-se ainda ir classificando os post-it em execução, os feitos, os que faltam e os impedimentos.
→ Impedimentos
Tarefas não relacionadas com o desenvolvimento do sprint que devem ser descritas na coluna “BurnDown”. Exemplos: Reunião com clientes, suportes...
→ Burndown
Aqui cola-se os post-it com os impedimentos.
*** Sprint: um sprint é uma iteração de duas semanas a 30 dias. Quem atualiza os post-it no quadro são os próprios desenvolvedores, analistas... assim fica visível para todos o que cada um está fazendo e acredito que também motive as pessoas a trabalharem mais para terminarem logo os itens e irem tirando de “em execução” e “mostrar serviço”. No lado esquerdo do post-it marca-se a estimativa e no lado direito o tempo realizado. No verso do post-it pode-se citar os passos de testes. No final do projeto tirar foto e remover os post-it.
Críticas sobre métodos ágeis:
Falta estrutura e documentação realmente necessária.
Requer desenvolvedores experientes e disciplinados.
Costumam resultar em desenho insuficiente.
Requer mudança cultural muito grande.
Dificultam negociações contratuais.
Dificultam estimativas de esforços, custos e prazos para projetos maiores.
Mostram dificuldades de tratamento dos requisitos funcionais e não funcionais.
Método XP
O mais conhecido e radical dos métodos ágeis, Extreme Programming.
Jogo do Planejamento: Os desenvolvedores estimam esforço, o cliente define escopo e prazo.
Liberações pequenas: Iterações duram de 2 a 3 semanas.
Metáfora: A forma do produto é definida por uma metáfora.
Desenho Simples: O código resultante passe em todos os testes, comunique tudo que os programadores querem comunicar..
Desenvolvimento dirigido por testes: Testes de unidades são escritos o tempo todo.
Programação em pares: Todo o código é escrito conjuntamente por 2 programadores na mesma estação de trabalho com papéis de piloto e navegador.
Integração contínua: Sempre integrado.
Propriedade coletiva: Todo programador pode alterar qualquer código.
Cliente Local: representante do cliente disponível durante o tempo todo.
Semana de 40 horas: Horas extras são proibidas.
Espaço aberto: A equipe trabalha em baias em uma única sala.
Regras adaptáveis: A equipe se compromete com as regras anteriores, mas pode alterá-las sempre que necessário.
Medir a velocidade do projeto: Medir o progresso.
Trocar as pessoas com frequência: trocar entre as diversas partes do projeto.
Reunião diária de pé.
Plano de liberações: Plano detalhado de cada iteração.
Padrões de codificação.
Otimizações: Otimizar no final do projeto.
Protótipos: Desenvolvimento de protótipos.
