Aplicação e integração do SCRUM e CMMI/ MPS.BR A experiência prática da Powerlogic. 30 de outubro de 2007 Processos Ágeis Certificados Aplicando Scrum e Powerlogic jalm para Certificações CMMI/MPS.Br Outubro 2007 Paulo Alvim (alvim@powerlogic.com.br) 1
Roteiro Apresentação Sobre a Powerlogic Métodos Ágeis e Scrum CMMI e MPS.Br Powerlogic jalm Estudo de Caso: Certificação Powerlogic Políticas Organizacionais Ágeis Explicadas Gerência de Projetos Ágil Certificada Gerência de Requisitos Ágil Certificada Garantia da Qualidade de Produto Garantia da Qualidade de Processo Medição e Análise Apresentação Prática - Ferramentas Do requisito ao código com Powerlogic jalm Perguntas & Debate Sobre a Powerlogic Paulo Alvim (alvim@powerlogic.com.br) 2
Powerlogic - Timeline 1994: Fundação, em Minas Gerais 1995-1998: Cliente/Servidor e Downsizing 1998: Início de Atuação com Java App Servers 1999: ecompany Portal/Project 1.0 2000-2001: Maturidade em ebusiness 2002: Início em J2EE Open-Source. 2003: jcompany Developer 1.0. Foco em Produtos. 2004: Powerlogic SA (BNDES Pró-Soft). 2004-2006: Atuação Nacional. Crescimento. 2007 (Junho): Certificação MPS.Br Nivel F. 2007 (Dezembro): Powerlogic ALM Powerlogic - Timeline (Processos) 1988-1993: Quadro diretor com expertise em MDS e ferramentas CASE (Projeto de Ferramentas CASE, OO, Análise Essencial, Engenharia da Informação) 1994-2001: Uso do Processo Unificado e MDS diversas em Projetos de Clientes 2002: Uso esporádico de SCRUM e técnicas ágeis durante a formação da área de Produtos da Powerlogic. 2003: Palestra Gestão Ágil de Projetos SCRUM na prática, no congresso Extremme Programming Brasil. 2004: Suporte ao SCRUM pelo ecompany Process. Expansão do uso de SCRUM. 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. 2006: Formalização e expansão do processo, segundo MPSbr. 2007 (Junho): Certificação MPS.Br Nivel F 2007 (Dezembro): Início Evolução para MPS.Br Nivel C. 3
Powerlogic - Crescimento 10.000,000 Análise de Crescimento - Powerlogic S.A Faturamento Anual Powerlogic (MIL) Crescimento Vol. Investimentos TI Serviços (BI) Crescimento Brasil PIB (TRI) 9.544,000 9.000,000 9.000,000 8.000,000 8.370,000 7.000,000 7.330,000 6.000,000 5.000,000 5.178,000 5.843,000 5.370,000 5.450,000 4.668,000 6.300,000 5.811,000 5.307,000 4.508,000 6.042,000 6.282,000 5.847,000 160 Colaboradores (30 Área de Produto) 4.000,000 3.000,000 3.303,000 3.594,000 4.038,000 2.996,000 2.791,000 3.207,000 2.391,000 2.000,000 1.738,000 1.000,000 2000 2001 2002 2003 2004 2005 2006 2007 Powerlogic Solution Providers 4
Projetos Nacionais Sudeste e Centro Oeste 5
Sudeste e Centro Oeste Sudeste e Centro Oeste 6
Norte e Nordeste Sul 7
Powerlogic Casos de Sucesso Mais de 400 sistemas em produção: Aplicações Internacionalizadas: Alemanha, Kuala Lumpur, México, Bolívia, França. Foco corporativo de Missão Crítica: Segurança, Disponibilidade (24 x7), Performance e Escalabilidade. Verticais Diversas: Indústria, Educação, Governo Executivo (Municipal, Estadual e Federal), Governo Judiciário, Financeira, Comércio, Cooperativa, Saúde, etc. Mais de uma centena de aplicações em tecnologias ebusiness Java EE Open-Source. Métodos Ágeis e Scrum Paulo Alvim (alvim@powerlogic.com.br) 8
O Manifesto da Agilidade: Valores www.agilealliance.org Values of Agile Alliance individuals and interactions over processes and tools working software over comprehensive documentation customer collaboration over contract negotiation responding to change over following a plan While there is value in the items on the right, we value the items on the left more. Uma questão de ênfase não de ruptura! O Manifesto da Agilidade: Origens The New, New Product Development Game* Lean Mngt Iterative, Incremental Development Smalltalk Engineering Tools Scrum, XP * Harvard Business Review, Jan. 1986, Takeuchi and Nonaka 9
O Manifesto da Agilidade: Super-ênfase em Iteratividade! O framework do Processo Unificado é Iterativo em sua concepção, mas tende a produzir implantações em Cascata, na prática! Scrum Básico Abordagem Empírica It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice. Process Dynamics, Modeling, and Control, Ogunnaike and Ray, Oxford University Press, 1992 10
Scrum Básico Teoria do Caos Requirement Instable Anarchy Complicated Complex Stable Simple Complicated Known Technology Unknown Scrum Básico Teoria do Caos Processes States: Ideal: Inputs, Outputs and Process Variables Stables Software Development is never in this state! Threshold: Process Reasonably Statistically Controllable. Number of Variances small, predictable and manageble. Software Development is eventually in this state! Edge of Chaos! Severe noises. Out of acceptable tolerances. Predictive and Planning almost ineffective. Continuous observation can delivery convergent products! Software Development usually is in this state! Chaos! Process not producing conforming products and is not controllable. O Scrum é realístico quanto às This may sound familiar to many software expectativas developers! por isto evidencia problemas mais cedo! 11
Scrum Básico Definição Empirical management and control process Inspect and adapt feedback loops Used to manage complex projects since 1990 Delivers business functionality in 30 days Scalable to distributed, large and long projects CMMI Level 3 and ISO 9001 compliant Extreme simple but very hard Scrum Básico Processo Iterativo 12
Scrum Básico Processo Iterativo Most projects deliver software every 6 to 18 months. Scrum reduces this to many 1 month deliveries to increase control via inspect/adapt. This puts stress on the team and organization, exposing underlying problems and limitations. The Scrum Master s job is to prioritize these problems and help the organization overcome them to get better at software development, managing software investments, and becoming a community to work in. Scrum Básico - Papéis Activity Owner Responsibilities Manage the vision Manage the ROI Manage the development iteration Manage the process Manage the release Product Owner Product Owner Team Scrum Master Product Owner The Product Owner establishes, nurtures and communicates the product vision. He achieves initial and on-going funding for the project by creating initial release plans and the initial Product Backlog. The Product Owner monitors the project against its ROI goals and an investment vision. He updates and prioritizes the Product Backlog to ensure that the most valuable functionality is produced first and built upon. He prioritizes and refines the Product Backlog and measures success against expenses. During an iteration the team selects and develops the highest-priority features on the Product Backlog. Collectively, the team expands Product Backlog items into more explicit tasks on a Sprint Backlog and then manages its own work and self-organizes around how it desires to complete the iteration. The team manages itself to its commitments. The Scrum Master is responsible for setting the team up for success by ensuring the project and organizational culture are optimized for meeting the ROI goals of the project. This involves organizing a Sprint Planning Meeting (during Adicionais which the team expands Powerlogic: Product Backlog into Sprint Backlog), a Sprint Review Meeting (during which the newly developed functionality is demonstrated), shielding the team from outside disturbances, - Stackholder holding brief Daily Scrum meetings, and removing obstacles to progress. - QA Master The Product Owner makes decisions about when to create an official release. For a variety of reasons it may not be desirable to release at the conclusion of every increment. Similarly, if an official release is planned for after the fifth - increment QA Team it may be released (with fewer features) after the fourth increment in order to respond to competitive moves or capture early market share. The Product Owner makes these decisions in a manner consistent with the investment vision that has been established for the project. 13
Scrum Básico Comunicação Scrum Básico Agile Radiator 14
Scrum Básico Agile Radiator Scrum Básico Agile Radiator 15
Scrum Básico Agile Radiator Scrum Básico Agile Radiator Adicionais Powerlogic: - Retrospective Boxes - www (what went well) - wcbi (what can be improved) - Indicadores do Processo e Release Plan 16
Scrum Básico Agile Radiator Scrum Básico Agile Radiator 17
Scrum Básico Agile Radiator Scrum Básico Comunicação 18
Scrum Básico Comunicação Tácita Scrum Básico Reuniões Formais Sprint Planning 1 (Pre-Planning) Sprint Planning 2 Daily Scrum Sprint Review Sprint Retrospective Adicionais Powerlogic: - Release Planning (Pre-Game) - Release Review (Post-Game) 19
CMMI & MPS.Br Paulo Alvim (alvim@powerlogic.com.br) Compatibilidade Scrum & CMMI Level Key Practice Area Rating 2 Requirements management 2 Software project planning 2 Software project tracking and oversight 2 Software subcontract management 2 Software quality assurance 2 Software configuration management 3 Organization process focus 3 Organization process definition 3 Training program 3 Integrated software management 3 Software product engineering 3 Intergroup coordination 3 Peer review 20
Compatibilidade Scrum & CMMI Os 5 (cinco) desafios maiores: GPR: Como gerenciar com base em planejamento contínuo (planning) em lugar do grande plano inicial (big-bang plan)? GPR: Como abraçar a mudança e controlá-la ao mesmo tempo? GRE: Como estimar requisitos que são parcialmente conhecidos? GQA: Como averiguar qualidade de produto em um processo iterativo com tempo fechado (time-boxed)? MED: O que são indicadores importantes em um processo ágil? Obs.: A Gerência de Configuração (GCO) é complexa, mas não é conflitante com princípios ágeis. Deve ser automatizada, e o conceito de Integração Contínua apoia decisivamente. Powerlogic jalm Paulo Alvim (alvim@powerlogic.com.br) 21
Powerlogic jalm Comunicação e Colaboração Processos Corporativos e Gerência de Projetos Desenvolvimento Java EE Open-Source Controle de Qualidade Java EE Open-Source Segurança e Monitoria em Produção Java EE Open-Source Powerlogic jalm 22
Powerlogic jalm Gestor Processo, Produtos, Componentes, Projetos, Requisitos Feecback: Erros (bugs), Dúvidas, Sugestões de Melhorias, Novos Requisitos,... Planejamento ecompany Process Elaboração CASE Requisitos,... ecompany Contact-Center Suporte Java, Modelos,... Aplicação Monitorada: Contabilização de Uso, Auditoria, Estatísticas, Disponibilidade,... Aplicação Contextualizada Para Usuários, Apoiada por Utilitários De Colaboração,... jcompany Monitor Monitoria Construção Qualidade jcompany Developer jcompany QA Aplicação Executável, Códigos Fontes,... Aplicação e Práticas Averiguadas,... ecompany Portal Produção jcompany Security Pré-Produção Cliente Aplicação Averiguada e Segura (Curva de Retorno do Investimento) Powerlogic jalm Segundo Scott Ambler, o Manifesto da Agilidade, em 2001, não previu que ferramentas (automação) seriam tão importantes para o sucesso de métodos ágeis. 23
Estudo de Caso: Certificação Powerlogic Paulo Alvim (alvim@powerlogic.com.br) Políticas Organizacionais Ágeis São motivos para a aderência a métodos ágeis, que sigam o Manifesto da Agilidade (http://agilemanifesto.org) com ênfase principal no Scrum (www.controlchaos.com): O altíssimo índice de incorporação de tecnologia de ponta dos produtos Powerlogic, implicando em um aumento importante da Imprevisibilidade; Exigências de criatividade em granularidade fina, para diferenciação com a concorrência, exigindo construção com base em Exploração e Adaptação (planejamento constante e evolucionário, e não antecipado e prescritivo); Exigências de liberação para o mercado (time-to-market) agressivas, com filosofia de entrega em "prazo fixo", via desenvolvimento iterativo com tempo definido (Time-Boxed); Monitoramento e adaptação ágil a mudanças estratégias que gerem benefícios, em taxas notadamente altas (Embrace Change); Presença do cliente (Product Owner) em constante contato com a equipe (Scrum Team), já que na área de produtos os requisitos são definidos e priorizados pela Powerlogic, em última instância. (Colaboração com o cliente). 24
Políticas Organizacionais Ágeis Políticas Organizacionais Ágeis 25
Políticas Organizacionais Ágeis Políticas Organizacionais Ágeis 26
Políticas Organizacionais Ágeis Formalidade não é sinônimo de Conformidade Informalidade não é sinônimo de Agilidade Políticas Ágeis para a Área GPR - Gerência de Projetos GPR Gerência de Projetos Ágil a) As práticas de Gerência de Projetos devem prever e garantir que se esteja trabalhando de forma verdadeiramente iterativa, (...); b) As iterações de desenvolvimento devem ter durações fixas de 30 dias, com restrição principal em tempo (Time-Boxed). As iterações subsequentes de Garantia da Qualidade (QA) devem durar 15 dias, também com restrição principal em tempo (Time-Boxed); c) As datas dos projetos e iterações da família jcompany devem ser defasadas em 15 dias das datas dos projetos e iterações da família ecompany, (...); d) O processo deve privilegiar e estimular, com primeira técnica de acompanhamento do andamento dos projetos, a inspeção frequente do produto de software em si, pelo líder das equipes (Scrum Master) e entre os membros da equipe, eventualmente utilizando-se programação em pares. Como segunda técnica, o processo deve prever e garantir que reuniões diárias de 15 minutos, conhecidas como Daily Scrum, estejam sendo feitas, garantindo feedback face-a-face (tácito), diário, inter-equipe. Como terceira prioridade, deve prever acompanhamento via indicadores indiretos de progresso (apropriações, percentual de andamento, etc.); e) O processo deve prover espaço para que o Scrum Master e o Scrum Team possam realizar adaptações em granularidade fina durante um ciclo, sem entraves formais neste nível (micro-gestão), implementando uma política de "solicitação de mudança formal" leve (lightweight change request). Ainda assim, deve garantir rastreamento de todas as modificações que ocorram após o "compromisso" (commitment), e formalização em situações críticas (ameaça a objetivos fundamentais, alteração de versão de item de configuração, etc.); f) O processo deve prover reunião formal de reflexão das equipes (Retrospective Meeting), com frequencia de uma ou duas vezes por iteração, de modo a apontar "o que foi bem" (WWW - What Went Well) e "o que pode ser melhorado" (WCBI - What Could Be Improved); g) Os colaboradores (Scrum Team) trabalham em regime de 40 horas semanais, sem horas extras e com custo fixo. (...) 27
GRE Gerência de Requisitos Ágil Políticas Ágeis para a Área GRE - Gerência de Requisitos a) As práticas de Gerência de Requisitos devem prover e garantir técnicas de elicitação de requisitos evolucionárias (planejamento contínuo), evitando um longo plano inicial, conforme preconizado por práticas ágeis. Ainda assim, devem garantir uma previsão razoável de escopo e prazo que seja factível para um "plano de projeto" (release plan) inicial, como consenso entre o Product Owner (representante do cliente) e o Scrum Team (Equipe). b) Requisitos devem ser mantidos em listas textuais, descritas em linguagem do usúario (bom português), seguindo os preceitos de Estórias de Usuários (User Stories) do XP e também de Product Backlog do Scrum. Estas listas devem ser priorizadas por "valor para o negócio" (business value), pelo Product Owner. c) Requisitos devem ser refinados em reuniões de planejamento coletivas, incluindo o Product Owner e o Scrum Team. Somente o Scrum Team deve ter habilitação para fazer previsões de tamanho, e sua opinião deve soberana. Para dimensionar tamanho, o Scrum Team deve seguir técnicas ágeis e unidade em Ideal Days. A ordenação das lista de requisitos pode sofrer ajustes pelo Scrum Team, para refletir dependências técnicas e ajustes de custo/benefício, uma vez que o "tamanho" do requisito for definido. O objetivo da priorização deve ser maximizar o "business value" liberado, em cada iteração. d) Para facilitar a consolidação de interesses de clientes, prospects e interesses estratégicos da Powerlogic, o processo deve prover facilidades de coleta de lista de requisitos do mercado (Product Backlog), que podem receber contribuições de qualquer Stackholder. e) Para o sucesso do processo de planejamento contínuo e para a agilidade em remoção de impedimentos, o processo deve considerar a presença forte do representante do Cliente (Product Owner), para solucionamento de dúvidas microscópicas em requisitos, além de tomadas rápidas de decisão. GCO Gerência de Configuração Ágil Políticas Ágeis para a Área GCO - Gerência de Configuração a) As práticas de Gerência de Configuração para a área de produtos da Powerlogic devem ser especialmente rigorosas e completas, por se tratarem de produtos de mercado, com grande diversidade de empresas usuárias e exigências especiais de controle de versão. Estas práticas devem utilizar automação e controles presentes nos produtos da Powerlogic, sempre que possível, de modo a serem implementadas de forma produtiva; b) Os itens de configuração devem ser definidos em nível de Produto, e não Projeto, já que tendem a se manter os mesmos ao longo de vários projetos. Em cada projeto, deve-se definir os registros de versão de cada item e atualizações eventuais. Para cada projeto subsequente, deve-se definir somente alterações em versões de itens anteriores, deste modo a evitar redundância desnecessaria; c) Deve-se possuir um conceito de "Configuração Global", que reuna um único número de versão que consolide os demais números gerados pelos diversos repositórios que se façam necessários (Subversion para fontes e documentos, Continuum para executáveis, ecompany Process para Planos e Processos, etc.); d) Alterações de versões de itens de configuração devem ser realizadas formalmente, via "Solicitação de Mudança" a ser analisada e aprovada por Comitê, de modo a se evitar falta de sincronismo e integridade provocada por modificações não controladas. 28
GQA Gerência de Qualidade Ágil Políticas Ágeis para a Área GQA Gerência de Qualidade de Produto e Processo a) As práticas de Gerência de Qualidade para Produto devem prever ciclos de averiguação de 15 dias, após a interação padrão de 30 dias, e serem realizadas também em filosofia de restrição de tempo (Timed-Boxed); b) O processo deve prever o uso do QA Team de forma compartilhada (em pool) para todos os projetos. Este deve testar de forma priorizada e limitado ao tempo disponível; c) O processo deve prever uso dos produtos de automação da Powerlogic, e garantir solução de automação para execução de "testes de regressão" continuamente (integração contínua); d) As práticas de Gerência de Qualidade para Processo devem auditar o desempenho do processo, os produtos de trabalho e atividades previstas em todas as áreas. Ao identificar problemas, deve apresentar proposições de soluções e melhorias, e acompanhar suas deliberações até o despacho final pela empresa; e) Deve garantir que os radiadores ágeis estão sendo utilizados, além de promover a visibilidade adequada de suas próprias averiguações, dando retorno ao Scrum Master, Scrum Team e QA Team (de Produto); f) Deve fornecer relatório à Diretoria Técnica da Powerlogic, contendo os resultados das revisões e auditorias, atráves do Relatório de GQA. Customer.java v1. Customer.java v2. Customer.java v3 Product.java v1. Product.java v2 Invoice.java v1 Source-Code Repository sales.jar v3.0 (Customer.java v2, Product.java v1,...). sales.jar v3.01. sales.jar v3.02. sales.jar v.4 salesutils.war v1.0. salesutils.war v1.1 hibernate.jar v3.2 Maven Maven Proxy Proxy Component Repository (Maven) salesapp.ear v5.0 (sales.jar v3.0, salesutil.war v1.0, hibernate.jar 3.2,...). salesapp v5.1. salesapp v6.0 Application Repository Subversion Subversion (SVN) (SVN) Repositórios de Gerência de Configuração do jcompany QA Suite Maven Maven Advanced Advanced Continuum Continuum... Maven Maven Maven Maven Maven Maven Maven Maven Developer 1 Developer 2 Developer N Tester 29
MED Medição e Análise Ágil Políticas Ágeis para a Área MED Medição e Análise a) As práticas de Medição e Análise do processo devem coletar e armazenar informações que auxiliem a Diretoria de Tecnologia da Powerlogic a acompanhar, de forma quantificada, os resultados esperados do processo, observando e enfatizando as questões estabelecidas nas presentes Políticas Organizacionais para o Processo; b) Os indicadores obtidos pela medição devem contemplar prioritariamente a performance de equipes com um todo, e não somente indicadores individuais, dentro do espírito do Scrum; c) Os indicadores devem ser coletados de modo que estejam disponíveis para divulgação durante reuniões de retrospectivas (Retrospective Meeting), e possam ser analisados pelas equipes coletivamente; d) Os indicadores devem ficar visíveis junto aos radiadores ágeis, e também em relatório consolidado de GQA, para a Diretoria Técnica; e) Os indicadores, sempre que possível, e ao longo do tempo, devem ser automatizados pelos produtos Powerlogic. Apresentação Prática: Ferramentas Paulo Alvim (alvim@powerlogic.com.br) 30
Objetivo: Simular um Projeto Scrum incluindo Gestão, Levantamento, Especificação, Construção e QA para uma aplicação de ebusiness (MVC Java EE 5, Design Patterns, Mapeamento OO x SGBD-R, performance, segurança e GUIs sofisticadas, etc.), do zero absoluto, utilizando o processo da Powerlogic. 31
Perguntas & Debate Paulo Alvim (alvim@powerlogic.com.br) Fim Paulo Alvim (alvim@powerlogic.com.br) 32