Introdução a Métodos Ágeis

Introdução a Métodos Ágeis

Insanidade, é repetir, interminavelmente, o mesmo processo, sempre à espera de um resultado diferente. Albert Einstein

Joshua Kerievski sugere uma abordagem humana : Trabalhar com foco na felicidade e não apenas na satisfação, devemos propiciar o equilíbrio na busca da felicidade, a todos os envolvidos no processo de desenvolvimento de SW. Conheça todo o seu ecossistema, entenda o que cada elemento da cadeia quer e avalie o que ele precisa para sentir-se feliz.

Joshua Kerievski sugere uma abordagem humana : Falhar é uma maneira muito forte de aprendizado, mas é preciso aprender sem apontar culpados

Manifesto Ágil

13/Novembro/2001 Wasatch mountains Utah 17 pessoas http://manifestoagil.com.br/index.html Jim Highsmith, for the Agile Alliance 2001 Jim Highsmith

SCRUM e outras técnicas ágeis NÃO são bala de prata* * Não mata vampiros & afins * Exige trabalho duro e comprometimento

Mas, quais os princípios por trás do manifesto ágil???

1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas. R2 - Novo resultado de busca e detalhe R3 - SuperBônus R4 - Bônus R5 - Nova Capa R6 - Nova Busca

3. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.

4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

7. Software funcional é a medida primária de progresso.

8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente passos constantes.

9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

11. As melhores arquiteturas, requisitos e designs emergem de times auto-organizados.

12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

RAP (RBS Agile Process) Revolução x Evolução :: Não vamos implodir tudo, a cultura vigente deve evoluir :: Não restringir ao que esta escrito no livro de Scrum :: O Porque? é mais importante que o O Que? Tópicos :: Trabalho em equipe de forma auto-organizada :: Cliente presente, participativo e transparente :: Boa engenharia e com melhorias contínuas :: Resultados rápidos, iterativos e de valor ao negócio Lembre-se :: Lean Thinking :: Baby Steps (faça o que é certo aos poucos) :: Kaizen (mudanças contínuas para melhor) :: Gemba (onde as coisas acontecem...)

Auto-Organização :: Saída da zona de conforto :: Produto + Arte + SEO + TI :: Retrospectiva e planos de ação :: Estancar dívida recursiva :: Responsabilidade :: Transparência :: Ambiente construtivo :: Cooperação em imersão :: Alçada e tomada de decisão

Embasamento Scrum Comando-ação x Auto-Organização Exercício número 1 : Equipe gerenciada por um chefe, que ordenará os comandos parar ou frente ou direita ou esquerda Cada integrante apenas pode cumprir as ordens do gerente, sem questioná-las Cada um que completar 20 passos levanta os braços e fica parado 5 minutos.

Embasamento Scrum Comando-ação x Auto-Organização Exercício número 1 : Equipe gerenciada por um chefe, que ordenará os comandos parar ou frente ou direita ou esquerda Cada integrante apenas pode cumprir as ordens do gerente, sem questioná-las Cada um que completar 20 passos levanta os braços e fica parado Exercício número 2 : Equipe auto-gerenciada, 2 minutos de Planejamento antes de executar, quando cada integrante fará o percurso com os mesmos comandos, mas decididos por si só 5 minutos.

Embasamento Scrum Scrum é um framework no qual pessoas podem endereçar problemas complexos, para produtiva e criativamente desenvolver produtos com o maior valor possível. Scrum esta fundamentado na teoria de controle de processos empíricos, empregando uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Três pilares sustentam a implementação de controle em processos empíricos : TRANSPARÊNCIA INSPEÇÃO ADAPTAÇÃO

TIME SCRUM Times de Scrum são projetados para otimizar flexibilidade e produtividade. Para esse fim, eles são auto-organizáveis, multidisciplinares e trabalham em iterações. Cada Time de Scrum possui três papéis: Equipe Product Owner Scrum Master

TIME SCRUM PRODUCT OWNER O Product Owner é uma única pessoa, e não um comitê Responsável pela rentabilidade (ROI) Define as funcionalidades do produto (gerencia o product backlog) Decide datas de lançamento e conteúdo Prioriza funcionalidades de acordo com o seu valor para o negócio Único que pode priorizar ou repriorizar os ítens do Product Backlog Focado em garantir o valor do trabalho realizado pelo Time Aceita ou rejeita o resultado dos trabalhos Deve ser assertivo e acessível, todos na organização respeitam suas decisões A alta responsabilidade e visibilidade requer que o Product Owner faça seu melhor, o que faz o papel de Product Owner exigente e recompensador.

TIME SCRUM EQUIPE Auto-organizável e Multi-funcional De 5 a 9 pessoas em tempo integral Melhor não ter títulos (programadores, testers, webdesigners, arquiteto, etc) As equipes são multidisciplinares e o conhecimento que devem compartilhar tendem a ser mais importantes do que aqueles que eles não dividem. As pessoas que se recusam a programar porque são arquitetas ou designers não se adaptam bem a Times Ágeis. Auto-organizáveis, descobrem a melhor forma de aplicação do método, processo e áreas de conhecimento por si só. Cada membro do Time aplica sua especialidade a todos os problemas. A sinergia que resulta disso melhora a eficácia geral como um todo.

TIME SCRUM SCRUM MASTER Representa a gerência para o time Responsável pela aplicação dos valores e práticas do Scrum Remove impedimentos e garante a plena produtividade da equipe Garante a colaboração entre os diversos papéis e funções Escudo para interferências externas O ScrumMaster é responsável por treinar e garantir que o Time de Scrum esteja adotando e aderindo aos valores do Scrum, às práticas e às regras, levando-o a ser mais produtivo e a desenvolver produtos de maior qualidade. O ScrumMaster ajuda o Time de Scrum a entender e usar auto-organização e multidisciplinaridade, propiciando fazerem o seu melhor em um ambiente organizacional que pode ainda não ser Ágil.

REUNIÃO DIÁRIA Em 15 minutos, todos os membros da equipe devem responder às três perguntas e não podem desviar o foco para discussões de problemas, discussões ou divagações. O Scrum Master é responsável por organizar a agilidade, fazendo com que todos falem. Cada membro da equipe deve responder à três perguntas sobre o projeto: O que você fez ontem? O que você fará hoje? Há algum impedimento? Durante a reunião somente uma pessoa fala por vez. Reunião? Quando alguém apresenta algo excepcional ou precise da assistência de outros, agenda-se um encontro das partes interessadas logo após a reunião diária.

QUADRO SCRUM (~ KANBAN) O quadro de tarefas Scrum é uma ferramenta com forte apelo a comunicação organizacional e visual, pois transmite a mensagem muitas vezes sem a necessidade de conversas, somente com a utilização de Post-Its, símbolos e cores, de modo que todos recebem a mensagem, as vezes de forma lúdica. Tem como objetivo disponibilizar as informações necessárias de uma forma simples, visual, transparente e de fácil assimilação, buscando tornar mais fácil o trabalho diário e também a busca pela melhoria da qualidade. Com estes quadros, fica visível e transparente o trabalho do time, impedimentos, quantidade de tempo restante e progresso do time em relação a meta da Sprint. Desenvolvimto Testes Homologação Produção TO DO DOING TO DO DOING TO DO DOING DONE READY Produto: Impedimentos:

QUADRO SCRUM (~ KANBAN) Cada integrante da Equipe tem a responsabilidade de ir movendo os seus Post-Its no ritmo que suas tarefas vão evoluindo, em tempo real, antes da reunião diária. Questões como tarefas extras, bugs, rejeição, responsável, alertas, etc podem ser representados por selos, post-its de outras cores, etc, desde que seja claro a todos.

USER STORY - Definição Funcionalidade no mundo do software, estória no mundo SCRUM e XP; O termo em inglês é story (estória conto) e não history (história relato de fatos); Estórias são equivalentes a requisitos, um produto de software é um conjunto de estórias; É basicamente uma lista de requisitos, funções que o dono do negócio solicita e que espera que elas sejam entregues, descrita em linguagem coloquial. Independent : Estórias devem ser independentes uma das outras; Negotiable : Estórias não são contratos, mas lembretes para discussões; Valuable : Estórias devem agregar valor para o cliente; Estimatable : Os desenvolvedores devem ser capazes de estimar o seu tamanho; Medium : Mantenha suas estórias simples e concisas - nem grandes, nem pequenas; Testable : Estórias devem ser possíveis de serem testadas; Card : Escreva em um cartão ou PostIt, coloque em um local visível a todos.

USER STORY - Definição A história deve ser compreensível para clientes e desenvolvedores, testável, valiosa para o cliente, e suficientemente pequena para que os programadores possam criar meia dúzia em uma iteração. Planning Extreme Programming de Kent Beck e Martin Fowler Escrever as estórias é um trabalho inicialmente executado pelo Product Owner, entretanto, a partir do momento que a equipe começa a trabalhar nela, passa a ser um trabalho cooperativo e colaborativo. Exemplos: Como um <Cliente> eu posso <pesquisar produtos> para <agilizar as minhas compras>; Como um <gerente comercial> eu devo <dar opções de pagamento> para <facilitar a compra dos meus clientes>; Como um <Cliente de Negócios> eu posso <pesquisar recurso de divulgação de produto> para <aumentar as minhas vendas>;

Retrospectiva O livro do "Scrum and XP from the trenches (disponível na nossa wiki) sugere trabalhar retrospectiva após cada Sprint e focar em três colunas, a primeira e segunda ligada ao passado e a terceira em planos de ação para o futuro : "O que foi bom - "O que poderia ter sido melhor - "Melhorias É feita uma dinâmica, com tempos pré-estabelecidos, em que cada um terá a oportunidade de falar sua visão ou escrever sua opinião sobre cada coluna. Há diversas técnicas, simples ou complexas Obs1: Há uma relação direta nas melhorias com o que poderia ter sido melhor. Exemplo: Porque tivemos tantas estórias com bugs, algumas com 2 ou 3? Melhorias: As estórias estão mal escritas, faltam critérios de aceitação, não estamos montando casos de testes? Plano de Ação: Rosangela vai treinar a equipe em casos de testes. Obs2: O livro sugere que cada pessoa utilize três sinais, em imãs ou post-its pequenos, para esta indicação e assim definir uma escala de prioridade nos planos de ações. Ele diz que cada pessoa pode votar como quiser.

Perguntas???

Referências teóricas e práticas Material na wiki da RBS Manual do curso de Professional Scrum Master da Scrum.Org Manual do curso de Scrum da Stefanini Scrum Guide em Português da http://www.scrum.org http://blogdoabu.blogspot.com http://infoq.com/br/minibooks/scrum-xp-fromthe-trenches http://pt.scribd.com/doc/54614765/30/quadro-scrum-vs-quadro-kanban-%e2%80%93-um-exemplo-menos-trivial Alguns nomes a serem seguidos por quem quer saber o que esta rolando? Em Porto Alegre Luiz Parzianello (RBS), Daniel Wild (Trevisan), Rafael Prikladnicki (PUC), Paulo Caroli (TW) No Brasil Rodrigo de Toledo, Allison Vale, Giovanni Bassi, Rodrigo Yoshima No Mundo Ken Schwaber, Jeff Sutherland, Jim Highsmith, Mary Poppendieck