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.

1. Utilizando Metodologias Ágeis paraatingir MPS.BR nível C na Powerlogic Nome do Instrutor

2. Apresentação Isabella 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.

4. Métodos Ágeis e Scrum

5. Estudo de Caso: Powerlogic MPS.BR

6. Políticas Organizacionais ÁgeisMelhorias Percebidas e Conclusão Perguntas & Debate

7. Sobre a Powerlogic Isabella Fonseca(isabella@powerlogic.com.br)

9. 1994-2001: Uso do Processo Unificado e MDS diversas em Projetos de Clientes

10. 2002: Uso esporá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: Suporte ao SCRUM pelo eCompany Process. Expansão do uso de SCRUM.

13. 2005: Processo empírico estabelecido, 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ção e expansão do processo, segundo MPS.BR.

15. 2007 (Junho): Certificação MPS.BR Nível F.

17. O Problema Crônico Por que projetos de informática continuam fracassando em preços, prazos e resultados, em níveis impressionantes?

18. Previsibilidade? Os primeiros “ruídos de 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 (para Piorar) “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 Mercados Economiaem Rede ForncedoresParceirosCliente CorporaçãoEstendida AutomaçãoCorporativa Internet Intranet/Extranet Novos Desafios - Web Funcionários Cliente/Servidor

22. Método “Cascata”: Um Engano Colossal Gráfico de Complexidade/Sucesso – Métodos “em Cascata” 0,9 0,5 0,1 Inflexibilidade para responder a imprevisibilidades (internas e externas) causa queda acentuada em PS na medida em que a Complexidade aumenta Probabilidade de Sucesso (PS) Baixa Média Alta Complexidade (C)

23. Método “Cascata”: Um Engano Colossal “Processos em Cascata (Preditivos) não são adequados para o desenvolvimento de softwares complexos…” Instáveis Anarquia Complicado Complexo Requisitos Complicado Simples Estáveis Conhecidas Desconhecidas Tecnologias

24. Método “Cascata”: Um Engano Colossal “… e a maior parte dos projetos corporativos na atualidade caem nesta categoria” Instáveis Anarquia (6%) Complicado(15%) Complexo (63%) Requisitos Complicado(10%) Simples (6%) Estáveis Conhecidas Desconhecidas Tecnologias

25. Desenvolvimento Iterativo e Incremental (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 e Incremental (IID) PDCAs: Múltiplos Plan - Do – Check – Act O 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ão Realí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 estado Beira 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. Conexões Inesperadas

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 Scrum Nonaka e 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)

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 Tradicional 1900 Trabalhadores devem 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 Tradicional 1900 Experts devem definir 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 System 1950 Assimilação da 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 evidenciou pela primeira vez o modelo Toyota como largamente superior ao modelo Ford/Taylor …

38. Toyota Production System “Apenas depois 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 de inventá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 da Agilidade “Não é a mais forte das espécies que sobrevive, nem a mais inteligente, mas aquela que melhor se adapta à mudança” Charles Darwin

44. Software funcionando mais que documentação compreensiva

45. Colaboração do cliente mais que negociação de contrato

46. Responder à mudança mais que seguir um planoIsto é, muito embora valorizemos os itens da direita, valorizamos mais os da esquerda!” 1o Semestre de 2001.

48. Software funcionando mais que documentação compreensiva

49. Colaboração do cliente mais que negociação de contrato

50. Responder à mudança mais 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 da Agilidade - Autores 17 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 da Agilidade: Os 12 princípios Diretrizes Gerais Para um Projeto de Sucesso!

53. Princípio 1 A mais alta prioridade é a satisfação do cliente através da liberação mais rápida e contínua de software de valor!

54. Princípio 2 Receba bem as 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 3 Libere software com 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 4 Mantenha as pessoas dos negócios e os desenvolvedores trabalhando juntos a maior parte do tempo do projeto.

57. Princípio 5 Construa projetos com indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado.

58. Princípio 6 O método mais eficiente e efetivo de repassar informação entre uma equipe de desenvolvimento é através de conversação cara-a-cara.

59. Princípio 7 Software funcionando é a principal medida de progresso.

60. Princípio 8 Processos ágeis promovem desenvolvimento sustentado. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica indefinidamente.

61. Princípio 9 A atenção contínua para a excelência técnica e um bom projeto aprimora a agilidade.

62. Princípio 10 Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essencial.

63. Princípio 11 As melhores arquiteturas, requerimentos e projetos emergem de equipes auto-organizadas.

64. Princípio 12 Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas, e então refinarem e ajustarem seu comportamento de acordo.

65. Métodos Ágeis Gráfico de Complexidade/Sucesso – Métodos “em Cascata” 0,9 0,5 0,1 Métodos Ágeis Flexíveis para Lidar Com a Complexidade Inflexibilidade para responder a imprevisibilidades (internas e externas) causa queda acentuada em PS na medida em que a Complexidade aumenta Probabilidade de Sucesso (PS) Baixa Média Alta Complexidade (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 Scrum A Metáfora com o Rugby:

69. O que é o Scrum? Framework de Processo de Gerenciamento e Controle Empírico Ciclos de Feedback para "Inspeção e Adaptação" Usado para Gerenciar Projetos Complexos de Software desde 1990 Libera funcionalidade a cada 30 dias Escalável para projetos longos, grandes e distribuídos Compatível com ISO 9001 e CMMI-3 (MPS.BR C!) Bastante Simples de Entender, mas Difícil de Aplicar

70. Papéis - Scrum

72. Publisher – parte do Scrum Team

73. QC Team / QC Master

74. Gerente de Qualidade de Processos

75. Grupo de Configuração

76. Grupo de Medição e Análise

77. Grupo de Gerência de Reutilização

78. Grupo de Gestão do Conhecimento

79. Gerente de RH

80. Expedição de Produtos

81. Alta GestãoProduct Owner (representante do cliente) Gerenciar a visão (goal) Gerenciar o ROI Scrum Master Garantir o andamento de acordo com o processo Gerenciar a Release e Sprints Remover impedimentos Scrum Team Garantir o desenvolvimento da iteração Estimar tamanho das atividades e se comprometer com os goals estabelecidos.

82. Porcos e Galinhas Durante um 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. Reuniões - Scrum

84. Entendendo o Scrum - Reuniões

85. Sprint Goal O Sprint Goal é 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. Artefatos - Scrum

88. Entendendo o Scrum - Artefatos

89. Entendendo o Scrum - Artefatos

90. Entendendo o Scrum - Artefatos

91. Entendendo o Scrum - Artefatos

92. Sprint Burndown HH Restantes Dias

93. Entendendo o Scrum - Artefatos

94. Release Burndown Fonte: http://www.mountaingoatsoftware.com/

95. Scrum – Agile Radiator

96. Scrum – Agile Radiator

97. Scrum – Agile Radiator

98. Scrum – Agile Radiator

100. www (what went well)

101. wcbi (what can be improved)

102. Indicadores do Processo e Release Plan

103. Disponibilidade da Equipe

105. Scrum – Agile Radiator

106. Scrum – Agile Radiator

107. Scrum – Agile Radiator

108. Scrum – Agile Radiator

109. Scrum – Agile Radiator

110. Comunicação

111. Principais problemas Segundo PMI Brasil, 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ção Fonte: 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. Planejamento e Gerenciamento

118. Gerenciamento em projetos ágeis

119. Gerenciamento em projetos ágeis FOCO no OUTPUT e não no INPUT Planejamento preditivos: Criação de um plano com atividades definidas O gerenciamento/acompanhamento de atividades conforme o plano Planejamento ágil: Criação de entregas com conjunto de itens priorizados Gerencimanto via feedback e constante adaptação

120. Teoria das Restrições - TOC Uma 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 - TOC Variáveis de controle requerem cuidado: Recursos Pessoas Infra-estrutura Tempo Escopo Custo Qualidade (deve ser intrínseca) Não é “inteligente”estabelecer todos estas variáveis como prioritárias em um projeto simultaneamente.

122. TOC em Software - Restrições Agile Management for Software Enginnering David J. Anderson

123. TOC em Software - Soluções Enfileiramentopriorizado: "deveter", "deveriater", "seriabomter" Margem no Prazo Certeza -> Margem 100% -> 15% 90% -> 25-30% 80% -> 50% 50-70% -> 100% <50% -> 200% Reserva de Dinheiro Reservas de equipamento, lugares de trabalho, sistemas de backup, suporte a infra-estrutura Reserva de Produtividade(Ex.: 5,5 horas/dia) Reserva de PessoasAptas* (Brook's Law) Agile Management for Software Enginnering David J. Anderson

124. TOC Comercial - Realístico Projeto Urgente Projeto Crítico Sem Orçamento

125. TOC Comercial - Arriscados Urgente e Crítico Crítico Sem Orçamento "Marcha para a Morte"

126. TOC - Variável Recursos Recursos 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ável Recursos - Scrum

128. TOC - Variável Recursos - Scrum Desenvolvimento heróico enfatiza indivíduos. As atividades são designadas individualmente Projeto fica altamente dependente da performance dos indivíduos envolvidos Desenvolvimento colaborativo enfatiza o time -> Scrum Um time alto-organizado define as atividades para se atingir as metas estabelecidas O time possui habilidades diversas (generalizing specialist – Scott Ambler)

131. Melhoria na flexibilidade

133. TOC - Processos ágeis Com 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ção de Backlogs

136. Estimativas Ágeis Medidas de Tamanho Ágeis Story Points e Ideal Day, por exemplo

137. Estimativas Ágeis – Ideal Day Um 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

140. 60% das funcionalidades entregues em projetos de sucesso são raramente ou nunca utilizadas.

141. Priorização do Product Backlog Fonte: http://www.softhouse.se/

142. Scrum - Business Value Itens 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ção do Backlog Plano Ágil Sprint 1 48 SP - 400 BV 20% Sprint 2 52 SP - 250 BV 20% Sprint 3 55 SP - 150 BV Sprint 4 40 SP - 100 BV 60% Sprint 5 50 SP - 100 BV Plano de Projeto (Release Plan): Total de 245 SP e 1.000 BV

144. Estudo de Caso: Powerlogic – Nível C

145. Processo Powerlogic O cará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/ AMP DFP/AMP: Métodos Ágeis podem e devem ser formalizados (Ex: Scrum Methodology)

147. Métodos Ágeis Estendidos DFP/AMP: Métodos Ágeis podem e devem ser formalizados (Ex: Scrum Methodology)

148. Timeline de um Produto DRE/PCP: Conceito Aprimorado de PO Team & Pre-Sprint; VAL: Conceito Aprimorado de QC Team & Post-Sprint

149. Timeline de uma Release GCO/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 um projeto As 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

152. Planejamento via Release Planning, Sprint Planning 1 e Sprint Planning 2

153. Acompanhamento contínuo via inspeção direta (Scrum Master)

154. Acompanhamento “formal” diário via Daily Scrum, e mensal via Sprint Review e Release Review

155. Agile Radiator com 3 bandas principais (Pendentes, Em Desenvolvimento e Finalizados), duas bandas para WWW e WCBI e uma banda para impedimentos.

156. Reservas de “tempo para impedimentos” no planejamento de cada ciclo, revisada em cada Sprint Planning

157. Isolamento da equipe

160. Uso de Pocker Planning para Backlogs acima de 1 ID ou polêmicos

161. Quebra de Product Backlog em Atividades que possam ser completadas por cada membro de equipe em 1 dia real.

162. Captura contínua na forma 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”)

165. GRE – Gerência de Requisitos

167. Testes funcionais automatizados.

168. Erros capturados pelo QA Team contam pontos contra o Scrum Team. Erros capturados pelo mercado contam pontos contra o QA Team.

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. Aspectos de Testes

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)

178. PCP/ DRU – Projeto e Construção de Produto e Desenvolvimento para Reuso PCP/DRU: Arquitetura, desenho ágil e desenvolvimento para reuso já eram intensivos na empresa, porém o processo trouxe melhoria e maior disseminação

180. Rastreabilidade do Requisito (Backlog) ao Código

183. Indicadores “Clássicos”: Produtividade (Velocidade*Qualidade), Metas (Goals), Previsto x Realizado, …

184. Resultados tangíveis são vistos positivamente pelo Scrum Team (produtividade da Scrum Team, do QA, etc.)

185. Gerente de Processo como apoio ao Scrum Master no incentivo e catequese de práticas ágeis.

188. Maior importância no uso 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 espectro de “agilidade” para cada projeto (Escala de Cockburn + Matriz de Restrições)

190. Expansão em áreas de 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. Gerência de Reutilização

193. Gerência de Conhecimento

195. Melhorias percebidas - Planejamento Planejar 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

197. Inspeção continua através das reuniões

198. Feedback real e imediato

199. Também ocorre planejamento, pois a mudança é aceita e ocorre todo o tempo

200. Integração contínua (commit associado ao requisito propiciando rastreabilidade)

201. Menos interrupções para o time

202. Criação do conceito Impediment Backlogs proporcionando identificação e apropriação correta nestes itens.

204. Retrabalhos mediante aprovação

205. Testes de aceitação e integração feitos pelo QA

206. Reestimating e FollowUp Meetings

207. Indicadores apóiam a tomada de decisão e criam atmosfera de busca de melhoria contínua

208. Integração de equipe: conceito de pilha/prioridade

209. Conceito de “Component Owner”, mas o código é compartilhado.

211. Scrum – Conclusão Por tudo 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ão O 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 é a mais forte das espécies que sobrevive, nem a mais inteligente, mas aquela que melhor se adapta à mudança” Charles Darwin Isabella Fonseca(isabella@powerlogic.com.br)