Carregado porPowerlogic Consultoria e Sistemas
Palestra Gerenciamento de Projetos com Scrum e MPS.Br
O documento discute a jornada da Powerlogic em alcançar certificações MPS.BR utilizando metodologias ágeis como Scrum. Apresenta a história da empresa com o uso de métodos tradicionais e ágeis ao longo dos anos, culminando na certificação nível C em 2010 utilizando Scrum.
Palestra Gerenciamento de Projetos com Scrum e MPS.Br
- 1. Utilizando Metodologias Ágeisparaatingir MPS.BR nível C na PowerlogicNome do Instrutor
- 2. ApresentaçãoIsabella Fonseca éCertified Scrum Master (CSM) com 5 anos de prática de Scrum e 13 anos de experiência em TI, tendo sido líder no SEPG que conduziu a Powerlogic à certificação MPS.BR Nível F com Scrum, em junho/2007.Atuou como Scrum Master por 2,5 anos e atualmente exerce o papel de Product Owner para a família de produtos eCompany da Powerlogic, continuando como líder do SEPG para certificação MPS.BR Nível C, finalizada em março/2010.Formada em Ciência da Computação pela PUC-MG com especialização em Redes de Telecomunicações pela UFMG, lecionou ainda disciplinas de Engenharia de Software e Análise de Sistemas na UNA Centro Universitário.
- 3.
- 4. Métodos Ágeis eScrum
- 5. Estudo de Caso:Powerlogic MPS.BR
- 6. Políticas Organizacionais ÁgeisMelhoriasPercebidas e ConclusãoPerguntas & Debate
- 7. Sobre a PowerlogicIsabellaFonseca(isabella@powerlogic.com.br)
- 8. Powerlogic - Timelinede Processos 1988-1993: Quadro diretor com expertise em MDS e ferramentas CASE (Projeto de Ferramentas CASE, OO, Análise Essencial, Engenharia da Informação)
- 9. 1994-2001: Usodo Processo Unificado e MDS diversas em Projetos de Clientes
- 10. 2002: Usoesporádico de SCRUM e técnicas ágeis durante a formação da área de Produtos da Powerlogic.
- 11. 2003: Palestra“Gestão Ágil de Projetos – SCRUM na prática”, no congresso “Extremme Programming Brasil”.
- 12. 2004: Suporteao SCRUM pelo eCompany Process. Expansão do uso de SCRUM.
- 13. 2005: Processo empíricoestabelecido, com incorporação de Disciplinas PMBOK complementares. jCompany QA suportando Integração Contínua. Automação e Gerência de Configuração.
- 14. 2006: Formalizaçãoe expansão do processo, segundo MPS.BR.
- 15. 2007 (Junho):Certificação MPS.BR Nível F.
- 16. 2010 (Março): CertificaçãoMPS.BR Nível C.Métodos Ágeis e ScrumIsabella Fonseca(isabella@powerlogic.com.br)
- 17. O Problema CrônicoPorque projetos de informática continuam fracassando em preços, prazos e resultados, em níveis impressionantes?
- 18. Previsibilidade?Os primeiros “ruídosde comunicação” ocorrem na contratação… Com qual margem de segurança é realmente possível prevermos os tempos de análise, implementação e implantação de um grande sistema corporativo, nos tempos atuais?
- 19. …em seguida o“ruído” é potencializado por abordagens de projeto inapropriadas…Quem usa métodos formais recaem na “Paralisia da Análise” ou confiam excessivamente em processos e documentações como “notas promissórias” (métodos monumentais).Abordagem?
- 20. Novos Desafios (paraPiorar)“A Gestão Clássica de Projetos de Tecnologia da Informação nunca foi trivial, e nestes tempos de Internet mais do que nunca!”
- 21. Novos Clientese MercadosEconomiaem RedeForncedoresParceirosClienteCorporaçãoEstendidaAutomaçãoCorporativaInternetIntranet/ExtranetNovos Desafios - WebFuncionáriosCliente/Servidor
- 22. Método “Cascata”: UmEngano ColossalGráfico de Complexidade/Sucesso – Métodos “em Cascata”0,90,50,1Inflexibilidade para responder a imprevisibilidades (internas e externas) causa queda acentuada em PS na medida em que a Complexidade aumentaProbabilidade de Sucesso (PS)Baixa Média AltaComplexidade (C)
- 23. Método “Cascata”: UmEngano Colossal“Processos em Cascata (Preditivos) não são adequados para o desenvolvimento de softwares complexos…”InstáveisAnarquiaComplicadoComplexoRequisitosComplicadoSimplesEstáveisConhecidasDesconhecidasTecnologias
- 24. Método “Cascata”: UmEngano Colossal“… e a maior parte dos projetos corporativos na atualidade caem nesta categoria”InstáveisAnarquia (6%)Complicado(15%)Complexo (63%)RequisitosComplicado(10%)Simples (6%)EstáveisConhecidasDesconhecidasTecnologias
- 25. Desenvolvimento Iterativo eIncremental (IID)O desenvolvimento iterativo e incremental paraleliza disciplinas em ciclos de entrega de (parcelas de) software funcionando ao cliente. Com isso, acelera o aprendizado de clientes e técnicos via feedback constante (exploração e adaptação), melhora a percepção do progresso (“onde estou?”), diminui riscos e acelera o retorno do investimento (ROI).Craig Larman – Agile & Iterative Development
- 26. Desenvolvimento Iterativo eIncremental (IID)PDCAs: Múltiplos Plan - Do – Check – ActO ciclo de Deming tem por princípio tornar mais claros e ágeis os processos envolvidos na execução -> Melhoria Contínua
- 27. Métodos Ágeis SãoRealísticos“Projetos de Software estão usualmente em um estado quase caótico – e por isso são melhor gerenciados por Processos Empíricos eIterativos.”Estados Possíveis de um Processo (Teoria do Caos):Ideal: Entradas, Saídas e Variáveis de Processo Estáveis Desenvolvimento de Software nunca está neste estado!Limítrofe: Processos Controláveis Estatisticamente de Forma Razoável. Variâncias em número pequeno, previsíveis e gerenciáveis. Desenvolvimento de Software está eventualmente neste estadoBeira do Caos! Ruídos severos. Tolerâncias fora das aceitáveis. Previsibilidade e planos quase ineficazes. Observação contínua pode liberar produtos convergentes! Desenvolvimento de Software está usualmente neste estado!Caos! Processos sem controle, que não resulta em produtos convergentes (em conformidade com o esperado). Isto pode soar familiar para muitos desenvolvedores de software!Cascata (Waterfall)Ágeis (Agile)
- 28. Sistemas Adaptativos Complexos(CAS)“Um Complex Adaptive System (CAS) é um sistema formado por uma rede dinâmica de agentes (os quais podem ser células, espécies, indivíduos, firmas, nações, etc.) atuando em paralelo, agindo e reagindo constantemente ao que os outros agentes estão fazendo. O controle de um CAS tende a ser altamente disperso e descentralizado. Se há alguma coerência no comportamento do sistema, ele emerge da competição e cooperação dos agentes. O comportamento geral do sistema é resultado de um grande número de decisões tomadas a cada momento por cada indivíduo”John H. Holland
- 29.
- 30. O que éo Scrum?“É um conjunto de “melhoresidéias” que um grupo de pessoasexperientesemnossaprofissãoevidenciou com o passar do anos. (...)Suaurgência, talcomo no XP e Agile emgeral, foireagir à ascenção de gurus de processo e metodologias e àsorganizações de gerência de projetos ‘emcascata’, através de umacoalisão de boas idéias”Ken Schwaber
- 31. Origem do ScrumNonakae Takeuchi – “The New New Product Development Game” – Janeiro/Fevereiro 1986 (Harvard Business Review)Estudo das práticas de gestão (do conhecimento) quediferenciavam as empresas Fuji Film, Toyota, 3M e Xerox, Epson, Brother, NEC e Honda.Identificamdiferençaschave entre empresasjaponesasinovadoras e ocidentais: - Ênfasenaimportância do ‘conhecimentotácito’- Processos de gerenciamento ‘do-meio-para-cima-e-para-baixo’ (middle-up-down process management)
- 32. Origem do ScrumNonakae Takeuchi Velho Modelo: Corrida de Revezamento
- 33. Novo Modelo: Rugby(AproximaçãoemConjunto)Origem do ScrumFatores de SucessosegundoNonaka e Takeuchi:InstabilidadeIntrínseca Times Auto-OrganizadosFases de DesenvolvimentoSobrepostas Multi-Aprendizado (Multi-Nível e Multi-Funcional)ControleSutilTransferência de ConhecimentoOrganizacional“Cada elemento deste por si não traz velocidade e flexibilidade. Mas tomados como um todo, formam características que podem produzir um poderoso conjunto de dinâmicas que fazem a diferença”Nonaka e Takeuchi
- 34. O que éo Scrum?“É um conjunto de “melhoresidéias” que um grupo de pessoasexperientesemnossaprofissãoevidenciou com o passar do anos. (...)Suaurgência, talcomo no XP e Agile emgeral, foireagir à ascenção de gurus de processo e metodologias e àsorganizações de gerência de projetos ‘emcascata’, através de umacoalisão de boas idéias”Ken Schwaber
- 35. Manufatura Tradicional1900 Trabalhadoresdevem realizar “o mínimo possível” Trabalhadores não devem se preocupar com a qualidade Trabalhadores não são inteligentes o suficiente para saber a melhor maneira de fazer seu trabalho.
- 36. Manufatura Tradicional1900Experts devemdefinir a melhor maneira (“the one best way”) de se fazer o produto, quebrando seu processo em pequenas atividades simples Foco em “substituição de pessoas” Primeiros problemas: Dificuldade extrema de adaptação - a Ford começou a enfrentar problemas quando a GM introduziu o conceito de “variedade”
- 37. Toyota Production System1950Assimilaçãoda importância da "Qualidade Total" (TQM) com o estatístico americano Edwards Deming. Aprimoramento com a cultura de qualidade “Stop-the-Line”: Parada automática quando ocorre algum defeito (Otimização Holística).Melhoria contínua e implacável do processo: Aprendizado e revisão pelos trabalhadores, inteligentes e adaptativos. Fluxo Just-In-Time (JIT), com obsessão por eliminação de desperdício: “Elimine tudo que não agregue valor ao produto final”. Em 1973, a crise do petróleo evidencioupela primeira vez o modelo Toyota como largamente superior ao modelo Ford/Taylor …
- 38. Toyota Production System“Apenasdepois que os fabricantes de automóveis americanos exauriram todas as outras explicações possíveis para o sucesso da Toyota como ‘Yen desvalorizado’, ‘força de trabalho dócil’, ‘cultura japonesa’ e ‘automação superior’, eles passaram a admitir que sua vantagem real estava na sua habilidade de usar o intelecto de seus empregados comuns”Gary Hamel – HBR 2006 – “Inovação do Gerenciamento”
- 39. Just-in-Time Eliminação deinventário (estoques intermediários) criados em nome da “economia de escala” de Taylor. Otimização holística do processo e não de suas partes. Trabalhadores aptos no processo como um todo (e não em sub-processos ou atividades) – adaptação rápida da linha de produção para cada nova situação ou problema.
- 40. Just-in-Time Cultura “Stop-the-Line”(Parada Automática de toda a Produção, por Qualquer Problema). Acertos de qualidade feitos o mais cedo possível, ao longo do processo: “fazer certo da primeira vez”. “Gerenciando o Inesperado”Preocupação com as Falhas Análise de Risco; Preparação para Falhas Possíveis.Relutância em Simplificar Motivos de FalhasSe a linha de produção é complexa, logo as falhas são complexas.Sensibilidade com as OperaçõesGerentes Trabalhando na produção em part-time.Compromisso em Aprender com os ErrosMesmo pequenos acidentes analisados para determinar como eliminá-los.Reverência à Expertise TécnicaTodo gerente reconhece que quem faz o trabalho é o que melhor o conhece
- 41. O que éo Scrum?“É um conjunto de “melhoresidéias” que um grupo de pessoasexperientesemnossaprofissãoevidenciou com o passar do anos. (...)Suaurgência, talcomo no XP e Agile emgeral, foireagir à ascenção de gurus de processo e metodologias e àsorganizações de gerência de projetos ‘emcascata’, através de umacoalisão de boas idéias”Ken Schwaber
- 42. O Manifesto daAgilidade“Não é a mais forte das espécies que sobrevive, nem a mais inteligente, mas aquela que melhor se adapta à mudança”Charles Darwin
- 43. O Manifesto daAgilidadeOs Quatro Valores“Nós estamos descobrindo novas maneiras de desenvolver software fazendo e ajudando outros a fazê-lo. Através deste trabalho nós valorizamos:Indivíduos e interações mais queprocessos e ferramentas
- 44. Software funcionando maisque documentação compreensiva
- 45. Colaboração do clientemais que negociação de contrato
- 46. Responder à mudançamais que seguir um planoIsto é, muito embora valorizemos os itens da direita, valorizamos mais os da esquerda!”1o Semestre de 2001.
- 47. O Manifesto daAgilidade“Nós estamos descobrindo novas maneiras de desenvolver software fazendo e ajudando outros a fazê-lo. Através deste trabalho nós valorizamos:Indivíduos e interações mais queprocessos e ferramentas
- 48. Software funcionando maisque documentação compreensiva
- 49. Colaboração do clientemais que negociação de contrato
- 50. Responder à mudançamais que seguir um planoIsto é, muito embora valorizemos os itens da direita, valorizamos mais os da esquerda!”Note que o manifesto pregamudança de ênfase - e nãoruptura...
- 51. O Manifesto daAgilidade - Autores17 Autores Gurus (11 a 13 de fevereiro de 2001)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, Dave Thomas
- 52. O Manifesto daAgilidade: Os 12 princípiosDiretrizes Gerais Para um Projeto de Sucesso!
- 53. Princípio 1A maisalta prioridade é a satisfação do cliente através da liberação mais rápida e contínua de software de valor!
- 54. Princípio 2Receba bemas mudanças de requerimentos, mesmo em estágios tardios do desenvolvimento. Processos ágeis devem admitir mudanças que trazem vantagens competitivas para o cliente.
- 55. Princípio 3Libere softwarecom a frequência de um par de semanas até um par de meses, com preferência para a escala de tempo maiscurta.
- 56. Princípio 4Mantenha aspessoas dos negócios e os desenvolvedores trabalhando juntos a maior parte do tempo do projeto.
- 57. Princípio 5Construa projetoscom indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado.
- 58. Princípio 6O métodomais eficiente e efetivo de repassar informação entre uma equipe de desenvolvimento é através de conversação cara-a-cara.
- 59. Princípio 7Software funcionandoé a principal medida de progresso.
- 60. Princípio 8Processos ágeispromovem desenvolvimento sustentado. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica indefinidamente.
- 61. Princípio 9A atençãocontínua para a excelência técnica e um bom projeto aprimora a agilidade.
- 62. Princípio 10Simplicidade –a arte de maximizar a quantidade de trabalho não feito – é essencial.
- 63. Princípio 11As melhoresarquiteturas, requerimentos e projetos emergem de equipes auto-organizadas.
- 64. Princípio 12Em intervalosregulares, as equipes devem refletir sobre como se tornarem mais efetivas, e então refinarem e ajustarem seu comportamento de acordo.
- 65. Métodos ÁgeisGráfico deComplexidade/Sucesso – Métodos “em Cascata”0,90,50,1Métodos ÁgeisFlexíveis para LidarCom a ComplexidadeInflexibilidade para responder a imprevisibilidades (internas e externas) causa queda acentuada em PS na medida em que a Complexidade aumentaProbabilidade de Sucesso (PS)Baixa Média AltaComplexidade (C)
- 66. O que éScrum?“Na abordagem em forma de rugby (jogo britânico parecido com o futebol americano), o processo de desenvolvimento do produto surge a partir de constante interação, como que de mãos dadas, onde um grupo extremamente disciplinado trabalha junto do início ao fim. ”Nonaka e Takeuchi - The New New Product Development Game
- 67. O que éo Scrum?Reagindo a Mudanças de Forma Ágil(Planejamento Mensal – Adaptabilidade e Comunicação Diárias)Em Rugby, Scrum é um time de oito integrantes que trabalham em conjunto para levar a bola adiante no campo. Ou seja: times trabalhando como uma unidade altamente integrada com cada membro desempenhando um papel bem definido e o time inteiro focando num único objetivo.Eliminas práticas de controle desnecessárias, inadequadas e burocráticas, se concentrando na essência do processo de confecção de sistemas de informação.Fonte: news.bbc.co.uk/sport1/hi/rugby_union/7048733.stm
- 68. Origem do ScrumAMetáfora com o Rugby:
- 69. O que éo Scrum?Framework de Processo de Gerenciamento e Controle EmpíricoCiclos de Feedback para "Inspeção e Adaptação"Usado para Gerenciar Projetos Complexos de Software desde 1990Libera funcionalidade a cada 30 diasEscalável para projetos longos, grandes e distribuídosCompatível com ISO 9001 e CMMI-3 (MPS.BR C!)Bastante Simples de Entender, mas Difícil de Aplicar
- 70.
- 71. Scrum - PapéisAdicionaisPowerlogic:QA Team – parte do Scrum Team (Scrum Team Tester)
- 72. Publisher – partedo Scrum Team
- 73. QC Team /QC Master
- 74. Gerente de Qualidadede Processos
- 75.
- 76. Grupo de Mediçãoe Análise
- 77. Grupo de Gerênciade Reutilização
- 78. Grupo de Gestãodo Conhecimento
- 79.
- 80.
- 81. Alta GestãoProduct Owner(representante do cliente)Gerenciar a visão (goal)Gerenciar o ROIScrum MasterGarantir o andamento de acordo com o processoGerenciar a Release e SprintsRemover impedimentosScrum TeamGarantir o desenvolvimento da iteraçãoEstimar tamanho das atividades e se comprometer com os goals estabelecidos.
- 82. Porcos e GalinhasDuranteum Sprint, o Scrum Team estácomprometido com a construção e liberação de software útil, queatendaao Sprint Goal. Todososdemaisestãoapenasenvolvidos. Portanto, durante um Sprint o Scrum Team é "porco" e todos os demais são "galinha"Esta metáfora valoriza que efetivamente "faz" o trabalho, evidenciando a necessidade de evitar interrupções externas durante um Sprint
- 83.
- 84. Entendendo o Scrum- Reuniões
- 85. Sprint GoalO SprintGoal é um objetivo "visionário" no escopo do Sprint, para orientar a adaptação do time, reforçando seu norte estratégicoÉ um parágrafo, preferencialmente de uma frase, estabelecido pelo Product Owner ao final do Sprint Planning 1É sempre verificado no Sprint Review, confrontado com a demonstração do Scrum Team
- 86. Entendendo o Scrum- Reuniões
- 87.
- 88. Entendendo o Scrum- Artefatos
- 89. Entendendo o Scrum- Artefatos
- 90. Entendendo o Scrum- Artefatos
- 91. Entendendo o Scrum- Artefatos
- 92.
- 93. Entendendo o Scrum- Artefatos
- 94.
- 95. Scrum – AgileRadiator
- 96. Scrum – AgileRadiator
- 97. Scrum – AgileRadiator
- 98. Scrum – AgileRadiator
- 99. Scrum – AgileRadiatorAdicionais Powerlogic:Retrospective Boxes
- 100. www (what wentwell)
- 101. wcbi (what canbe improved)
- 102. Indicadores do Processoe Release Plan
- 103.
- 104. Quadro de HabilidadesScrum– Agile Radiator
- 105. Scrum – AgileRadiator
- 106. Scrum – AgileRadiator
- 107. Scrum – AgileRadiator
- 108. Scrum – AgileRadiator
- 109. Scrum – AgileRadiator
- 110.
- 111. Principais problemasSegundo PMIBrasil, os problemas mais freqüentes em gerenciamento de projetos levantados são:Não cumprimento de prazos (72%)Problemas de comunicação (71%)Mudança de escopo (69%)Estimativa errada de prazo (66%)Fonte: Benchmarking em Gerenciamento de Projetos, 2006, chapters do PMI no Brasil
- 112. Principais problemas -Comunicação Analisando os problemas levantados, pode-se constatar que o cerne do problema reside principalmente na comunicação levando, como conseqüência, aos demais. Quando presente, mecanismos de comunicação ineficientes são utilizados contribuindo para a falta de compreensão e colaboração por parte dos envolvidos. Mecanismos que promovem e facilitam a comunicação são compostos por perguntas e respostas. Mais eficiente ainda é se utilizarmos mecanismos interativos (com perguntas e respostas) e ainda ter a presença física na mesma sala dos diversos envolvidos. Para completar, um quadro branco auxiliando na dinâmica das discussões, pode expandir em muito as possibilidades de se fazer entendido.
- 113. Principais problemas -Comunicação
- 114. Principais problemas -Comunicação
- 115. Principais problemas -ComunicaçãoFonte: Alistar Cockburn - Agile Software Development
- 116. Principais problemas -Comunicação“Todo time de projeto deve questionar sobre como reduzir o custo de energia total para detectar ou transferir idéias necessárias.”Alistair Cockburn Fonte: Alistar Cockburn - Agile Software Development
- 117.
- 118. Gerenciamento emprojetos ágeis
- 119. Gerenciamento emprojetos ágeisFOCO no OUTPUT e não no INPUTPlanejamento preditivos:Criação de um plano com atividades definidasO gerenciamento/acompanhamento de atividades conforme o planoPlanejamento ágil:Criação de entregas com conjunto de itens priorizadosGerencimanto via feedback e constante adaptação
- 120. Teoria das Restrições- TOCUma das grandes contribuições da TOC é o seu processo de otimização contínua. Esse processo de otimização contínua contém 5 etapas:1. Identificar a(s) restrição(ões) do sistema. 2. Decidir como explorar a(s) restrição(ões) do sistema. 3. Subordinar tudo o mais à decisão acima. 4. Elevar a(s) restrição(ões) do sistema. 5. Se num passo anterior uma restrição for quebrada, volte ao passo 1.“Usando esse processo podemos enfocar nossos esforços nos poucos pontos de um sistema que determinam seu desempenho (nas suas restrições), e assim podemos melhorar significativamente no curto prazo. “EliyahuGoldratt – A Meta
- 121. Gerenciando projetos ágeis- TOCVariáveis de controle requerem cuidado:RecursosPessoasInfra-estruturaTempoEscopoCustoQualidade (deve ser intrínseca)Não é “inteligente”estabelecer todos estas variáveis como prioritárias em um projeto simultaneamente.
- 122. TOC em Software- RestriçõesAgile Management for Software EnginneringDavid J. Anderson
- 123. TOC em Software- SoluçõesEnfileiramentopriorizado: "deveter", "deveriater", "seriabomter"Margem no PrazoCerteza -> Margem100% -> 15%90% -> 25-30%80% -> 50%50-70% -> 100%<50% -> 200%Reserva de DinheiroReservas de equipamento, lugares de trabalho, sistemas de backup, suporte a infra-estruturaReserva de Produtividade(Ex.: 5,5 horas/dia)Reserva de PessoasAptas* (Brook's Law)Agile Management for Software EnginneringDavid J. Anderson
- 124. TOC Comercial -RealísticoProjeto UrgenteProjeto CríticoSem Orçamento
- 125. TOC Comercial -ArriscadosUrgente e CríticoCrítico Sem Orçamento"Marcha para a Morte"
- 126. TOC - VariávelRecursosRecursos são geralmente a variável menos efetiva para se ajustar:The Mythical Man Month by Frederick Brooks, 1975.Quando um projeto está atrasado, adicionar pessoas ao projeto servirá apenas para atrasá-lo ainda mais.Devemos considerar o tempo que perdemos em gestão e comunicação quando temos pessoas demais trabalhando em um projeto.Ao calcular o tempo de desenvolvimento de qualquer coisa, temos que dobrá-lo. O programador precisa de "tempo para pensar" além do "tempo para programar“.Ênfase nas pessoas!Treinamentos, disseminação de conhecimento, boas condições de trabalho
- 127. TOC - VariávelRecursos - Scrum
- 128. TOC - VariávelRecursos - ScrumDesenvolvimento heróico enfatiza indivíduos.As atividades são designadas individualmenteProjeto fica altamente dependente da performance dos indivíduos envolvidosDesenvolvimento colaborativo enfatiza o time -> ScrumUm time alto-organizado define as atividades para se atingir as metas estabelecidasO time possui habilidades diversas (generalizing specialist – Scott Ambler)
- 129. TOC - VariávelRecursos - ScrumModo Tradicional Comunicação deteriorada
- 130. Pouca interação,etc...TOC - Variável Recursos - ScrumGeneralista/especialista – Agile Melhoria na comunicação e colaboração
- 131. Melhoria naflexibilidade
- 132. Menor riscoTOC- Variável EscopoPode ser a mais efetiva em ajustarEntregas parciais podem gerar retornos imediatos“É preferível se atingir uma data com um escopo parcial implementado do que com o escopo completo parcialmente terminado”
- 133. TOC -Processos ágeisCom relação à recursos:Times estáveis e trabalhando em equipe (real)À Tempo:Ciclos de desenvolvimento tempo-fechado (time-boxed)À Escopo:Ajustes de escopo feitos através de feedback constante
- 134. Gerenciamento ágil– mudanças
- 135. Estimativa e Priorizaçãode Backlogs
- 136. Estimativas ÁgeisMedidas deTamanho ÁgeisStory Points e Ideal Day, por exemplo
- 137. Estimativas Ágeis –Ideal DayUm Ideal Day corresponde à quantidade de trabalho que um profissional de nível sênior, com fluência nas tecnologias e ferramentas envolvidas (Ideal Developer) consegue realizar, em 08 (oito) horas de trabalho dedicadas (sem interrupções). É importante que se compreenda que o "Dia Ideal", com 08 (oito) horas de trabalho sem interrupções, de um "desenvolvedor ideal", raramente ocorrerá na prática, e, portanto, deve ser utilizado unicamente como "moeda" estável para quantificação de tamanho de referência e balizador ideal de produtividade. O tempo ideal quase nunca é igual ao tempo real
- 138. Estimativas Ágeis –Planning Poker
- 139. Priorização do ProductBacklogFonte: http://www.softhouse.se/Entrega de Valor é sempre maior nas primeiras iterações! 80% do valor de um software vem de 20% das funcionalidades - PARETO
- 140. 60% dasfuncionalidades entregues em projetos de sucesso são raramente ou nunca utilizadas.
- 141. Priorização do ProductBacklogFonte: http://www.softhouse.se/
- 142. Scrum - BusinessValueItens que se concentram no quadrante superior direito são os que devem ser priorizados e, seguramente, são os que mais representam a maximização do resultado. Priorização final da pilha = BV/ Tamanho do requisito Fonte: http://www.powerlogic.com.br
- 143. Exemplo de Priorizaçãodo BacklogPlano ÁgilSprint 148 SP - 400 BV20%Sprint 252 SP - 250 BV20%Sprint 355 SP - 150 BVSprint 440 SP - 100 BV60%Sprint 550 SP - 100 BVPlano de Projeto (Release Plan): Total de 245 SP e 1.000 BV
- 144. Estudo de Caso:Powerlogic – Nível C
- 145. Processo Powerlogic Ocaráter iterativo e colaborativo dos processos com relação às áreas de processo do MPS.BR podem ser vistos de forma gráfica através do padrão disseminado pelo Processo Unificado:
- 146. DFP/ AMPDFP/AMP: MétodosÁgeis podem e devem ser formalizados (Ex: Scrum Methodology)
- 147. Métodos Ágeis EstendidosDFP/AMP:Métodos Ágeis podem e devem ser formalizados (Ex: Scrum Methodology)
- 148. Timeline de umProdutoDRE/PCP: Conceito Aprimorado de PO Team & Pre-Sprint; VAL: Conceito Aprimorado de QC Team & Post-Sprint
- 149. Timeline de umaReleaseGCO/GQA: Iteratividade trazendo ritmo uniforme e maior simplicidade em Auditorias e Linhas de Base; por exemplo, se as entregas são iterativas a importância da gestão sobre itens de configuração ‘intermediários’ é reduzida dramaticamente.
- 150. Iterações de umprojetoAs iterações de Pre-Sprint (do PO Team), Sprint (do Scrum Team) e do Post-Sprint (do QC Team) se suporpõem de modo a preservar a aceleração de produtividade esperada pelo processo
- 151. GPR –Gerência de ProjetosAlguns pontos chave:Conceito de Release e Release Plan
- 152. Planejamento via ReleasePlanning, Sprint Planning 1 e Sprint Planning 2
- 153. Acompanhamento contínuo viainspeção direta (Scrum Master)
- 154. Acompanhamento “formal” diáriovia Daily Scrum, e mensal via Sprint Review e Release Review
- 155. Agile Radiator com3 bandas principais (Pendentes, Em Desenvolvimento e Finalizados), duas bandas para WWW e WCBI e uma banda para impedimentos.
- 156. Reservas de “tempopara impedimentos” no planejamento de cada ciclo, revisada em cada Sprint Planning
- 157.
- 158. Práticas “adicionais”: Registrono Powerlogic jALM (Release, Sprints, Goals, resultados,…); apropriação de horas diária; medição de produtividade em equipe, matriz de competências. GPR – Gerência de ProjetosMatriz de Competência
- 159. GRE –Gerência de RequisitosAlguns pontos chave:Uso de Ideal Day (considerando um “Ideal Man!”)
- 160. Uso de PockerPlanning para Backlogs acima de 1 ID ou polêmicos
- 161. Quebra de ProductBacklog em Atividades que possam ser completadas por cada membro de equipe em 1 dia real.
- 162. Captura contínua naforma de Product Backlog (eCompany Process Suite), com refinamento em três fases (Release Backlog -> Select Backlog -> Sprint Backlog)
- 163. Solicitação de Mudança“leve”: Mudanças ao final do Sprint ou dentro de um Sprint que não afetem o “Sprint Goal” não requerem “Solicitação de Mudança”. Somente são requeridas em situações críticas (Ex.: “não vamos cumprir o Goal”) ou para mudanças de configuração (Ex.: “alteração de versão de framework”)
- 164. Práticas “adicionais”: registrode Backlogs e métricas no eCompany Process Suite; rastreabilidade “do requisito ao código” (matriz de rastreabilidade) GRE – Gerência de Requisitos
- 165. GRE –Gerência de Requisitos
- 166. GQA, VERe VALAlguns pontos chave:Conceito de “confirmação do Goal” pelo QA
- 167.
- 168. Erros capturados peloQA Team contam pontos contra o Scrum Team. Erros capturados pelo mercado contam pontos contra o QA Team.
- 169. GQA: Nesta áreaestão definidas as atividades de auditoria de produtos e sub-produtos, sem entrar em sua composição interna. Ou seja, verifica que uma atividade foi executada como esperado e produziu o produto de trabalho no local correto conforme os atributos esperados definidos em artefatos do processo. GQA, VER e VALVerificação: Nesta área estão definidas as atividades de averiguações e testes de diversas naturezas/aspectos sobre os produtos e sub-produtos, entrando em sua composição interna para verificar se estão corretos conforme atributos esperados definidos em artefatos do projeto (requisitos e desenhos, tipicamente).
- 170. Cobertura de Documentação(Comentários de Código) Cobertura de Documentação de APIs (Comentários em Interfaces) Complexidade Ciclomática Violação de Regras Sumarizada (PMD, CheckStyle, FindBugs)
- 171.
- 172. Sistema - Funcional(testes em novas funcionalidades)
- 173. Sistema - Usabilidade(testes de ergonomia, beleza, mensagens)
- 174. Regressão - Funcional(para erros e manutenções evolutivas)
- 175. Integração - Funcional(ponta a ponta)
- 176. Sistema - Documentação,Sistema - Instalação (mídia) VER e ITP (Integração de Produtos)VER/ITP: Verificação ‘just-in-time’ é realizada diariamente e por automação: formulários eletrônicos para todos os ‘itens de ALM’ provêem verificação e rastreabilidade automatizados; verificação estática de código com Dashboard e regressão, dentre outros recursos, tornam a verificação e integração presentes diariamente e de forma natural ao longo do processo
- 177. GQA, VERe VALValidação: Nesta área estão definidas as atividades de aceitações finais de um produto já verificado, normalmente realizadas pelo cliente (PO) e usuários finais (programas de validação) em seus diversos ambientes operacionais, conforme atributos definidos em artefatos do projeto (critérios de aceitação, tipicamente).1) Contínua2) Sprint Review3) Validação Complementar do QC Team
- 178. PCP/ DRU –Projeto e Construção de Produto e Desenvolvimento para ReusoPCP/DRU: Arquitetura, desenho ágil e desenvolvimento para reuso já eram intensivos na empresa, porém o processo trouxe melhoria e maior disseminação
- 179. GCO –Gerência de ConfiguraçãoAlguns pontos chave:Integração Contínua (SVN, Maven e Continuum) com jCompany QA Suite
- 180. Rastreabilidade do Requisito(Backlog) ao Código
- 181. Controle de códigofonte, componente (JAR), executável (WAR), release plan (com linha de base), documentação e mídia de CD/DVD dos produtos. GCO – Gerência de ConfiguraçãoPara sua implementação, os requisitos devem ser obtidos do eCompany Process Suite através do plugin MyLyn. Antes de trabalhar em cada requisito o desenvolvedor deve ativá-lo para, deste modo, também obter rastreabilidade com os artefatos de implementação.
- 182. MED –Medição e AnáliseAlguns pontos chave:Indicadores “Ágeis”: Assiduidade do Daily Scrum, Remoção de Impedimentos, Frequência de Integração, Inspeção,...
- 183. Indicadores “Clássicos”: Produtividade(Velocidade*Qualidade), Metas (Goals), Previsto x Realizado, …
- 184. Resultados tangíveis sãovistos positivamente pelo Scrum Team (produtividade da Scrum Team, do QA, etc.)
- 185. Gerente de Processocomo apoio ao Scrum Master no incentivo e catequese de práticas ágeis.
- 186. Gerente de Processocomo assessor da Diretoria (Management) para garantia de resultados da implantação do processo.Métodos Ágeis EstendidosGRH: Times ‘auto-organizados’ precisam de ‘genérico-especialistas’ (Generalizing Specialists) . Obs.: Scrum Team Tester e Scrum Team Publisher tiveram seus papéis destacados – o que é pecado para alguns - mas julgamos necessário apenas para sistematizar a formação de especialista. O Scrum Team continua ‘cross-functional’ e operando com liberdade total para reorganização interna, inclusive com propriedade coletiva de código e medição do time com um todo.
- 187. MPS.Br NivelC & AgileAlguns pontos chave:Evidências na Área de Engenharia de Software obtidas de práticas de XP (TDD, Pair-Programming, Refactoring, Integração Contínua) e formalização de alguns diagramas arquiteturais mínimos (CASE UML)
- 188. Maior importância nouso de uma suíte de ALM para obtenção de evidências “por consequência do processo produtivo”, integrando ECM, Portal e CASE.
- 189. Caracterização do espectrode “agilidade” para cada projeto (Escala de Cockburn + Matriz de Restrições)
- 190. Expansão em áreasde gestão de RH (plano de treinamento, evolução individual, etc.), consoantes com os valores ágeis.
- 191. Gerência de Risco– integração com impedimentos
- 192.
- 193.
- 194. Verificação e ValidaçãoMelhoriasPercebidas e Conclusão
- 195. Melhorias percebidas -PlanejamentoPlanejar o planejamento:Planejar disponibilidade dos recursos, impedimentos já identificados, horas de retrabalho levantadas, etc;Identificar riscos;Traçar metas e planejar como não perde-las de vista.Algumas metas a serem cumpridas:Release e Sprint Goals (com o consenso de todos);Indicadores do time e individuais (produtividade, % de retrabalho, % de desvio previsto x real e índice de melhoria do produto). Estimativas reais e compartilhadas conquistando comprometimento do time
- 196. Melhorias percebidas -AcompanhamentoInstitucionalização do processo
- 197. Inspeção continua atravésdas reuniões
- 198. Feedback real eimediato
- 199. Também ocorre planejamento,pois a mudança é aceita e ocorre todo o tempo
- 200. Integração contínua (commitassociado ao requisito propiciando rastreabilidade)
- 201. Menos interrupções parao time
- 202. Criação do conceitoImpediment Backlogs proporcionando identificação e apropriação correta nestes itens.
- 203. Gestão a vista(Agile Radiator)Melhorias percebidas - ExecuçãoApropriação mais correta e associada a um projeto.
- 204.
- 205. Testes de aceitaçãoe integração feitos pelo QA
- 206. Reestimating e FollowUpMeetings
- 207. Indicadores apóiam atomada de decisão e criam atmosfera de busca de melhoria contínua
- 208. Integração de equipe:conceito de pilha/prioridade
- 209. Conceito de “ComponentOwner”, mas o código é compartilhado.
- 210. Sabe-se onde estáe onde quer chegarMelhorias percebidas - AvaliaçãoRetrospective Meeting: avalia o que deu certo e o que deu errado alimentando próximo Sprint. Retrospective Meeting 2: avalia se algo está sendo feito e também como o time se saiu com os retrabalhos. Reuniões de review com objetivos claros (sem segunda chance). APRENDIZADO CONSTANTE!
- 211. Scrum – ConclusãoPortudo isso, o Scrum não é milagreiro. Quem contribui, em muito, para o sucesso de um projeto, são as pessoas envolvidas: sejam desenvolvedores, gerentes, o corpo diretor ou clientes. Todos devem estar cientes do porquê utilizar as técnicas citadas neste curso: pair programming, peer review, comunicação tácita, compartilhamento de código, entrega de maior valor de negócio, planejamento contínuo, etc. Estas são somente algumas práticas que você pode aplicar para complementar seu dia-a-dia no gerenciamento de projetos.
- 212. MPS.BR - ConclusãoO modelo MPS.BR tem agregado valor às práticas ágeis da Powerlogic. Se uma empresa não necessita do certificado em si, tanto melhor: a evolução em áreas de processo de sua prioridade será certamente ainda mais eficaz! Percebemos que o modelo MPS.BR também estimulado de forma importante a ‘cultura da qualidade’ em empresas clientes da Powerlogic – e até em profissionais de TI em geral: Comunicar sobre processo tem ficado mais fácil entre as empresas/órgãos Funcionários públicos são respaldados para ‘adquirirem qualidade’. Percebemos, por exemplo, uma diminuição das licitações suicidas ‘somente menor preço’ (não necessariamente com exigência do certificado em si) Os subsídios governamentais para a certificação em grupo (Ex: Fumsoft, etc.) funcionam: os empresários (pequenos e até médios) muitas vezes precisam de estímulo para enfatizar a qualidade como necessário. As pequenas empresas de Minas já conversam MPS.BR conosco com certa fluência.
- 213. Fim“Não é amais forte das espécies que sobrevive, nem a mais inteligente, mas aquela que melhor se adapta à mudança”Charles DarwinIsabella Fonseca(isabella@powerlogic.com.br)