Lista de Práticas Ágeis•   Pós Engenharia de Software Ágil•   Prof. Edgard Davidson•   Aluno: Julio Cezar da Silva•   UNA
Product Vision
Product Backlog
User Stories
Uses Cases
Usage Scenario
Personas
Planning Poker
Requirement Prioritization
User Story Mapping
Lean Canvas
Spike Solutions
Domain Driven Development
Design Evolutivo
CRC
DbCpublic class Cor{  public int Vermelho { get; private set; }    public Cor(int pVermelho, int pVerde, int pAzul)   {   ...
Metáfora• “Para facilitar a criação de um design simples,  a equipe de desenvolvimento utiliza  metáforas, já que elas têm...
Coding Standard“Para que todos os desenvolvedores possam manipular qualquerparte do software de forma rápida, a equipe est...
TDD
BDD•   “Uma técnica de desenvolvimento ágil que visa integrar regras de negócios com    linguagem de programação”public cl...
Pair-Programming
Refactoring
Código coletivo
Build Automático
Integração Contínua• “Integração Contínua é uma pratica de  desenvolvimento de software onde os membros de um  time integr...
Peer Reviews• Na utilização da programação em par do XP a  técnica de revisão é aplicada todo o tempo da  programação já q...
Controle de Versão
Entregas Frequentes•  Ágeis “nossa maior prioridade é satisfazer o cliente  através da entrega contínua e desde cedo de  s...
Clean Code
Teste Unitário
Teste Fumaça• O Termo originou-se de testes de hardware quando  uma parte era corrigida ou atualizada simplesmente  ligava...
Testes de Sistemas
Teste Exploratório• Segundo o livro "Base de Conhecimento de Teste de  Software", Teste Exploratório "é indicado quando ex...
Testes de aceitação
Fixed Sprints
Release Planning•   O Release Plan deverá abordar:•   A quantidade e a duração dos Sprints•   Quantas pessoas ou times dev...
Iteration Planning• A meta do planejamento da iteração é estabelecer  objetivos de alto nível do que será realizado durant...
Sprint backlog
Task Board
WIP Limits• No Kanban, as tarefas em execução devem ser  explicitamente limitadas de modo a não haver  muitas tarefas send...
Class of Service
Lead Time• lead time is the time between the initiation and  delivery of a work item.
Definition of done
Daily Stand-up Meeting
Velocity
Sprint Review• Ao final de cada Sprint, uma Reunião Sprint Review  é realizada. Durante esta reunião, o Scrum Team  aprese...
Mapa de Cadeia de Valor• Os mapas da cadeia de valor são uma forma  popular de detectar desperdícios nos processos de  uma...
Root Cause Analysis• A Análise de Causa Raiz, também conhecida como  RCA (Root Cause Analysis) é uma maneira de  identific...
Burn Down Chart• A burn down chart is a graphical representation of  work left to do versus time.
Cumulative Flow Chart• Um Diagrama de fluxo cumulativo (CFD) é uma  área gráfica que mostra o progresso do trabalho de  um...
Gestão a Vista•   A gestão à vista tem como objetivo disponibilizar as informações    necessárias de uma forma simples e d...
Retrospectiva•   Retrospectivas ágeis são sem dúvida, uma grande oportunidade para que equipes de    desenvolvimento de so...
Retrospectiva
Backlog de melhorias• O Backlog é nada mais nada menos do que os  requisitos do produto que precisa ser entregue, bem  com...
Small Team
Cross-Functional Team• Times podem ser funcionais (ex: um tipo somente  de sys admins) ou cross-funcionais (um time formad...
Equipes Auto Organizadas•   Essas equipes caracterizam-se por 3 condições:•   Autonomia: após receberem uma missão com obj...
Common Workspace
Product Owner
Scrum Master•   A missão do Scrum Master é facilitar o dia-a-dia do Time,    removendo tudo aquilo que está atrapalhando o...
Sustainable pace• Trabalhar com qualidade, buscando ter ritmo de  trabalho saudável (40 horas/semana, 8 horas/dia),  sem h...
Move People Around• A ideia é não deixa a pessoa fazendo sempre a  mesma coisa ou sempre a mesma dupla, o ideal é  que o c...
Scrum Escalado
Communities of Practices
Coding Dojo
Clube do Livro
Palestra da Equipe            para a Equipe• A ideia é a própria equipe repassar o que está  aprendendo, no blog abaixo el...
Biblioteca a Disposição
Participação em EventosO Agile Brazil 2012 acontecerá em São Paulo de 3 a 7 de setembro.
Contratação com participação do             time• O time deve participar da contratação de novos  colaboradores.
Feedback 360º• Consiste na equipe avaliando a equipe frente a  frente.
One-on-ones meetings• É uma reunião do gerente com cada um dos  colaboradores, individualmente.
Índice da Felicidade• A tendência, que põe a praticidade dos resultados  financeiros em segundo plano e a complexa  subjet...
Definição de Metas• A definição de metas é essencial no processo  dentro das empresas nos dias de hoje. É através  deste p...
Gemba Walks• Já teve a ligeira impressão de que os engenheiros  que projetam os ônibus parecem que nunca  andaram de ônibu...
Delegation Poker
Authority Board
ROTI• Is a quick and easy method to gauge the time spent  on meetings or workshops, and to improve their  effectiveness.
Resolução de Problemas com A3
Hackathon•   Hackathon é uma maratona de programação, onde os    colaboradores da empresa tiram o dia (ou viram uma noite)...
SlackTime• É uma prática de incluir em cada plano uma série  de tarefas ou histórias de usuários que podem ser  descartado...
Impedimentos Visíveis• Impedimento é qualquer coisa que atrapalhe um  membro da equipe de executar o trabalho. Os  impedim...
Upcoming SlideShare
Loading in …5
×

Lista de Práticas Ágeis

779 views
682 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
779
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Lista de Práticas Ágeis

  1. 1. Lista de Práticas Ágeis• Pós Engenharia de Software Ágil• Prof. Edgard Davidson• Aluno: Julio Cezar da Silva• UNA
  2. 2. Product Vision
  3. 3. Product Backlog
  4. 4. User Stories
  5. 5. Uses Cases
  6. 6. Usage Scenario
  7. 7. Personas
  8. 8. Planning Poker
  9. 9. Requirement Prioritization
  10. 10. User Story Mapping
  11. 11. Lean Canvas
  12. 12. Spike Solutions
  13. 13. Domain Driven Development
  14. 14. Design Evolutivo
  15. 15. CRC
  16. 16. DbCpublic class Cor{ public int Vermelho { get; private set; } public Cor(int pVermelho, int pVerde, int pAzul) { this.Vermelho = pVermelho; // Configurar as outras propriedades... } public void AdicionarVermelho(int pValor) {// Aqui estamos garantindo que ao final da execução desse método, a//propriedade Vermelho deverá respeitar o limite de 255; Contract.Ensures(this.Vermelho <= 255); this.Vermelho += pValor; }}
  17. 17. Metáfora• “Para facilitar a criação de um design simples, a equipe de desenvolvimento utiliza metáforas, já que elas têm o poder de transmitir ideias complexas de forma simples, através de uma linguagem comum que é estabelecida entre a equipe de desenvolvimento e o cliente.”• Fonte: Extreme Programming – Vinícius Manhães Teles
  18. 18. Coding Standard“Para que todos os desenvolvedores possam manipular qualquerparte do software de forma rápida, a equipe estabelece padrões decodificação, que servem também para tornar o sistema maishomogêneo e permitir que qualquer manutenção futura sejaefetuada mais rápidamente.”Fonte: Extreme Programming – Vinícius Manhães Teles
  19. 19. TDD
  20. 20. BDD• “Uma técnica de desenvolvimento ágil que visa integrar regras de negócios com linguagem de programação”public class ComportamentoDoControladorDeJanela { @Test public void deveFecharJanelas() { // Dado que ControladorDeJanela controlador = new ControladorDeJanela("Meu Quadro"); Quadro quadro = new Quadro(); //Quando controlador.fecharJanelas(); // Então garantirQue(!frame.estaAparecendo()); } }
  21. 21. Pair-Programming
  22. 22. Refactoring
  23. 23. Código coletivo
  24. 24. Build Automático
  25. 25. Integração Contínua• “Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver multiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.”  Martin Fowler
  26. 26. Peer Reviews• Na utilização da programação em par do XP a técnica de revisão é aplicada todo o tempo da programação já que enquanto um digita o outro vai verificando o código, em ambientes burocráticos que não têm a programação em par, poderia ser utilizado os testes unitários e ao ser alterado o código ser verificado através dos testes se nenhum bug foi introduzido.
  27. 27. Controle de Versão
  28. 28. Entregas Frequentes•  Ágeis “nossa maior prioridade é satisfazer o cliente através da entrega contínua e desde cedo de software com valor” e “entregar frequentemente software em funcionamento, desde a cada duas semanas até a cada dois meses, com uma preferência por prazos mais curtos” (FOWLER & HIGHSMITH, 2001)
  29. 29. Clean Code
  30. 30. Teste Unitário
  31. 31. Teste Fumaça• O Termo originou-se de testes de hardware quando uma parte era corrigida ou atualizada simplesmente ligava o hardware e se o mesmo não der fumaça significa que passou nos testes. Em software consiste em um teste rápido, executando as principais funcionalidades do sistema, sem se preocupar com as condições de erro.
  32. 32. Testes de Sistemas
  33. 33. Teste Exploratório• Segundo o livro "Base de Conhecimento de Teste de Software", Teste Exploratório "é indicado quando existe pouca documentação para orientar os testes ou quando o prazo é tão curto que não é possível preparar um teste mais formal. É um teste executado a partir da experiência e da intuição do testador"
  34. 34. Testes de aceitação
  35. 35. Fixed Sprints
  36. 36. Release Planning• O Release Plan deverá abordar:• A quantidade e a duração dos Sprints• Quantas pessoas ou times deverão participar do projeto• O número de Releases• O valor a ser entregue em cada Release• A data de liberação do(s) Release(s)• As principais informações para o Release Planning são:• A priorização dos Product Backlogs• A estimativa da velocidade• O Product Owner deve atender as datas importantes (time-to-market) impostas pelo mercado.
  37. 37. Iteration Planning• A meta do planejamento da iteração é estabelecer objetivos de alto nível do que será realizado durante uma iteração, produzir um plano suficientemente detalhado, indicando quem deve fazer o que para realizar os objetivos e definir como avaliar se o que deveria ser realizado foi feito.
  38. 38. Sprint backlog
  39. 39. Task Board
  40. 40. WIP Limits• No Kanban, as tarefas em execução devem ser explicitamente limitadas de modo a não haver muitas tarefas sendo executadas ao mesmo tempo, no Scrum não existe explicitamente esse limite, mas o mesmo é implícito quando é limitada a quantidade de pontos que a equipe consegue entregar por sprint.
  41. 41. Class of Service
  42. 42. Lead Time• lead time is the time between the initiation and delivery of a work item.
  43. 43. Definition of done
  44. 44. Daily Stand-up Meeting
  45. 45. Velocity
  46. 46. Sprint Review• Ao final de cada Sprint, uma Reunião Sprint Review é realizada. Durante esta reunião, o Scrum Team apresenta o que foi realizado durante o Sprint. Tipicamente, esta apresentação é feita na forma de uma demonstração das novas funcionalidades.Fonte: http://epf.eclipse.org/wikis/scrumpt/Scrum/tasks/sprint_review_meeting_8735340C.html
  47. 47. Mapa de Cadeia de Valor• Os mapas da cadeia de valor são uma forma popular de detectar desperdícios nos processos de uma empresa — passos que não adicionam valor ao produto final.Fonte: http://office.microsoft.com/pt-pt/visio-help/criar-um-mapa-da-cadeia-de-valor- HA010113024.aspx
  48. 48. Root Cause Analysis• A Análise de Causa Raiz, também conhecida como RCA (Root Cause Analysis) é uma maneira de identificar as causas de um problema, afinal os problemas são melhores resolvidos ao tentar corrigir ou eliminar as suas causas.
  49. 49. Burn Down Chart• A burn down chart is a graphical representation of work left to do versus time.
  50. 50. Cumulative Flow Chart• Um Diagrama de fluxo cumulativo (CFD) é uma área gráfica que mostra o progresso do trabalho de um produto, versão ou Sprint. O eixo horizontal em um CFD indica o tempo, e o eixo vertical indica os cards (tarefas). Cada área colorida equivale o gráfico para o status do workflow.
  51. 51. Gestão a Vista• A gestão à vista tem como objetivo disponibilizar as informações necessárias de uma forma simples e de fácil assimilação, buscando tornar mais fácil o trabalho diário e também a busca pela melhoria da qualidade. Ela torna possível a divulgação de informações para um maior número de pessoas simultaneamente e ajuda a estabelecer a prática de compartilhamento do conhecimento como parte da cultura organizacional.
  52. 52. Retrospectiva• Retrospectivas ágeis são sem dúvida, uma grande oportunidade para que equipes de desenvolvimento de software parem para pensar no trabalho que vem realizando e questionem o que pode se melhorado. É uma excelente ferramenta para que o famoso ciclo PDCA (Plan / Do / Check/ Act) possa ser aplicado. O método ágil Scrum sugere que as reuniões de retrospectiva aconteçam no final da iteração (sprint) e que a equipe se faça duas perguntas básicas: o O que está indo bem? o O que pode ser melhorado?• Alguns preferem perguntar:• O que devemos parar de fazer? o O que devemos continuar fazendo? o O que devemos começar a fazer?• No fim das contas o que realmente importa é que a reunião tenha como resultado ações a serem tomadas pela equipe para que a melhoria continua seja aplicada, e que na próxima retrospectiva, a equipe seja melhor do que era na última.
  53. 53. Retrospectiva
  54. 54. Backlog de melhorias• O Backlog é nada mais nada menos do que os requisitos do produto que precisa ser entregue, bem como todo o entendimento necessário para se atender aos requisitos, produzir funcionalidades e por fim entregar um produto.• Em resumo é uma lista de todas as características, funções, tecnologias, melhorias e correções que constituem a versão futura do produto.
  55. 55. Small Team
  56. 56. Cross-Functional Team• Times podem ser funcionais (ex: um tipo somente de sys admins) ou cross-funcionais (um time formado por desenvolvedores, designers e testadores)
  57. 57. Equipes Auto Organizadas• Essas equipes caracterizam-se por 3 condições:• Autonomia: após receberem uma missão com objetivos claramente definidos, o time está livre para definir sua própria direção. A alta gerência limita-se a dar orientação, recursos e apoio moral;• Auto-transcedência: a equipe busca continuamente estender seus limites. Partem da diretriz recebida da alta gerência, estabelecem objetivos iniciais, elevando-os constantemente durante o processo de desenvolvimento. Ao perseguir objetivos aparentemente contraditórios a equipe supera seu "status quo" e faz descobertas incríveis; e• Fertilização cruzada: uma equipe multidisciplinar, com variados padrões de comportamento, processos conhecidos e especialização funcional conduz o desenvolvimento do novo produto. A referida fertilização acontece na iteração entre essas pessoas. Ao compartilharem um mesmo ambiente de trabalho o processo de transferência de conhecimento entre seus membros acontece naturalmente, caracterizando o termo fertilização cruzada.
  58. 58. Common Workspace
  59. 59. Product Owner
  60. 60. Scrum Master• A missão do Scrum Master é facilitar o dia-a-dia do Time, removendo tudo aquilo que está atrapalhando o seu progresso. É garantir que o time siga os valores e práticas do Scrum, protegendo para que ele não se comprometa excessivamente com aquilo que é capaz de executar dentro de um Sprint. É aprimorar a produtividade do time da melhor maneira possível. !=
  61. 61. Sustainable pace• Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.
  62. 62. Move People Around• A ideia é não deixa a pessoa fazendo sempre a mesma coisa ou sempre a mesma dupla, o ideal é que o código seja coletivo e todos mexam em tudo de modo que na necessidade não tenha somente um responsável por determinada funcionalidade.
  63. 63. Scrum Escalado
  64. 64. Communities of Practices
  65. 65. Coding Dojo
  66. 66. Clube do Livro
  67. 67. Palestra da Equipe para a Equipe• A ideia é a própria equipe repassar o que está aprendendo, no blog abaixo eles foram além, gravam as apresentações e disponibilizam para a comunidade.• http://blog.bluesoft.com.br/
  68. 68. Biblioteca a Disposição
  69. 69. Participação em EventosO Agile Brazil 2012 acontecerá em São Paulo de 3 a 7 de setembro.
  70. 70. Contratação com participação do time• O time deve participar da contratação de novos colaboradores.
  71. 71. Feedback 360º• Consiste na equipe avaliando a equipe frente a frente.
  72. 72. One-on-ones meetings• É uma reunião do gerente com cada um dos colaboradores, individualmente.
  73. 73. Índice da Felicidade• A tendência, que põe a praticidade dos resultados financeiros em segundo plano e a complexa subjetividade do bem-estar social em primeiro.
  74. 74. Definição de Metas• A definição de metas é essencial no processo dentro das empresas nos dias de hoje. É através deste posicionamento que se estabelece o esforço para implementação das condições necessárias para o resultado dentro de um prazo estipulado.
  75. 75. Gemba Walks• Já teve a ligeira impressão de que os engenheiros que projetam os ônibus parecem que nunca andaram de ônibus? Então, Gemba Walks é o processo de imersão naquilo que se está disposto a fazer ou mudar, seria “o cliente estar dentro do taxi quando do engarrafamento.” a visão é diferente dependendo de como se vê.
  76. 76. Delegation Poker
  77. 77. Authority Board
  78. 78. ROTI• Is a quick and easy method to gauge the time spent on meetings or workshops, and to improve their effectiveness.
  79. 79. Resolução de Problemas com A3
  80. 80. Hackathon• Hackathon é uma maratona de programação, onde os colaboradores da empresa tiram o dia (ou viram uma noite), para trabalharem em suas próprias ideias que possam vir a agregar valor ao produto da empresa.• É o dia que você deixa de lado o seu trabalho do dia-a-dia para colocar em prática algo novo ou algo que você sempre pensou que podia ser legal adicionar ao produto.• O objetivo é que ao final da maratona, todos apresentem algo implementado para que a equipe dê feedback e decida se vale a pena dar continuidade em sua ideia.
  81. 81. SlackTime• É uma prática de incluir em cada plano uma série de tarefas ou histórias de usuários que podem ser descartados se o time ficar sem tempo.
  82. 82. Impedimentos Visíveis• Impedimento é qualquer coisa que atrapalhe um membro da equipe de executar o trabalho. Os impedimentos podem ser identificados nas reuniões diárias, onde cada membro da equipe tem a oportunidade de comunicar o Scrum Master do impedimento existente. O Scrum Master é responsável pela solução dos impedimentos. 

×