Aplicação e integração do
SCRUM e CMMI/ MPS.BR
A experiência prática da
Powerlogic.
30 de outubro de 2007Paulo Alvim
Processos Ágeis Certificados
Aplicando Scrum e Powerlogic jALM para Certificações CMMI/MPS.Br
Outubro 2007
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
Paulo Alvim
(alvim@powerlogic.com.br)
Sobre a Powerlogic
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
Powerlogic - Crescimento
Análise de Crescimento - P owerlogic S.A
1.738,000 2.391,000 2.996,000 2.791,000 3.207,000 4.508,000 5.847,000 9.000,000 5.178,000 5.843,000 5.370,000 5.450,000 6.300,000 7.330,000 8.370,000 9.544,000 3.303,000 3.594,000 4.038,000 4.668,000 5.307,000 5.811,000 6.042,000 6.282,000 1.000,000 2.000,000 3.000,000 4.000,000 5.000,000 6.000,000 7.000,000 8.000,000 9.000,000 10.000,000 2000 2001 2002 2003 2004 2005 2006 2007
Faturamento Anual Powerlogic (MIL) Crescimento Vol. Investimentos TI Serviços (BI) Crescimento Brasil PIB (TRI)
160 Colaboradores
(30 Área de Produto)
Projetos Nacionais
Sudeste e Centro Oeste
Norte e Nordeste
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.
Paulo Alvim
(alvim@powerlogic.com.br)
Métodos Ágeis e Scrum
O Manifesto da Agilidade: Valores
• www.agilealliance.org
• Values of Agile Alliance
• While there is value in the items on the right,
• we value the items on the left more.
individuals and interactions over processes and tools
working software over comprehensive documentation
customer collaboration over contract negotiation
responding to change over following a plan
Uma questão de
“ênfase” – não
de “ruptura”!
The New, New Product
Development Game* Lean Mngt Iterative, Incremental Development
Smalltalk Engineering Tools
Scrum, XP
* Harvard Business Review, Jan. 1986, Takeuchi and Nonaka
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!
“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
Requirement
Technology
Instable Stable Known Unknown Anarchy Complex Complicated Complicated SimpleScrum 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.
Î This may sound familiar to many software developers!
Scrum Básico – Teoria do Caos
O Scrum é realístico quanto às
expectativas – por isto
evidencia problemas mais
cedo!
•
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 – Definição
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 – Processo Iterativo
Activity Owner Responsibilities
Manage the
vision 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.
Manage the ROI
Product Owner
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.
Manage the development iteration
Team 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.
Manage the
process ScrumMaster
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 which the team expands Product Backlog into Sprint Backlog), a Sprint Review Meeting (during which the newly developed functionality is demonstrated), shielding the team from outside disturbances, holding brief Daily Scrum meetings, and removing obstacles to progress.
Manage the release
Product Owner
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 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.
Scrum Básico - Papéis
Adicionais Powerlogic:
-
Stackholder
-
QA Master
Scrum Básico – Comunicação
Scrum Básico – Agile Radiator
Scrum Básico – Agile Radiator
Scrum Básico – Agile Radiator
Adicionais Powerlogic:
-Retrospective Boxes
-
www (what went well)
-
wcbi (what can be improved)
Scrum Básico – Agile Radiator
Scrum Básico – Agile Radiator
Scrum Básico – Comunicação Tácita
• Sprint Planning 1 (Pre-Planning) • Sprint Planning 2 • Daily Scrum • Sprint Review • Sprint RetrospectiveScrum Básico – Reuniões Formais
Adicionais Powerlogic:
-
Release Planning (Pre-Game)
Paulo Alvim
(alvim@powerlogic.com.br)
CMMI & MPS.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
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.
Paulo Alvim
Powerlogic jALM
Seguran
Seguran
ç
ç
a
a
e
e
Monitoria
Monitoria
em
em
Produ
Produ
ç
ç
ão
ão
Java EE
Java EE
Open
Open
-
-
Source
Source
Controle
Controle
de
de
Qualidade
Qualidade
Java EE
Java EE
Open
Open
-
-
Source
Source
Desenvolvimento
Desenvolvimento
Java EE
Java EE
Open
Open
-
-
Source
Source
Comunica
Comunica
ç
ç
ão
ão
e
e
Colabora
Colabora
ç
ç
ão
ão
Processos
Processos
Corporativos
Corporativos
e
e
Gerência
Gerência
de
de
Projetos
Projetos
Powerlogic jALM
Feecback: Erros (bugs), Dúvidas,
Sugestões de Melhorias,
Novos Requisitos, ... CASE
Requisitos, ... Elaboração jCompany Developer Java, Modelos, ... Construção jCompany QA Aplicação Executável, Códigos Fontes, ... Qualidade jCompany Security Aplicação e Práticas Averiguadas, ... Pré-Produção
eCompany Portal Produção
jCompany Monitor
Aplicação Contextualizada Para Usuários, Apoiada por Utilitários
De Colaboração, ... Monitoria eCompany Contact-Center Aplicação Monitorada: Contabilização de Uso, Auditoria, Estatísticas, Disponibilidade, ... Suporte eCompany Process Processo, Produtos, Componentes, Projetos, Requisitos Planejamento Gestor Aplicação Averiguada e Segura (Curva de Retorno do Investimento) Cliente
Powerlogic jALM
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.
Paulo Alvim
(alvim@powerlogic.com.br)
Estudo de Caso:
Certificação Powerlogic
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).
Políticas Organizacionais Ágeis
Políticas Organizacionais Ágeis
Políticas Organizacionais Ágeis
Informalidade não é
sinônimo de Agilidade
Formalidade não é sinônimo
de Conformidade
GPR – Gerência de Projetos Ágil
Políticas Ágeis para a Área GPR - Gerência de Projetos
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);
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.
GRE – Gerência de Requisitos Á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.
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çãode 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.
GQA – Gerência de Qualidade Ágil
Source-Code Repository Subversion (SVN) Subversion (SVN) Customer.java v1 . Customer.java v2 . Customer.java v3 Product.java v1 . Product.java v2 Invoice.java v1 Component Repository (Maven)
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 Application Repository Advanced Continuum Advanced Continuum salesapp.ear v5.0
(sales.jar v3.0, salesutil.war v1.0, hibernate.jar 3.2, ...)
. salesapp v5.1 . salesapp v6.0
...
MavenMaven MavenMaven MavenMaven MavenMaven
Maven Maven
Repositórios de
Gerência
de Configuração do
jCompany QA Suite
Developer 1 Developer 2 Developer N Tester
Maven Proxy
Maven Proxy
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.
