Aplicação e integração do SCRUM e CMMI/ MPS.BR A ... · 2 Roteiro Apresentação ¾Sobre a Powerlogic ¾Métodos Ágeis e Scrum ¾CMMI e MPS.Br ¾Powerlogic jALM Estudo de Caso:

1

Aplicação e integração do SCRUM e CMMI/ MPS.BRA experiência prática da Powerlogic.

30 de outubro de 2007

Paulo Alvim ([email protected])

Processos Ágeis CertificadosAplicando Scrum e Powerlogic jALM para Certificações CMMI/MPS.Br

Outubro 2007

2

RoteiroApresentação

Sobre a PowerlogicMétodos Ágeis e ScrumCMMI e MPS.BrPowerlogic jALM

Estudo de Caso: Certificação PowerlogicPolíticas Organizacionais Ágeis ExplicadasGerência de Projetos Ágil CertificadaGerência de Requisitos Ágil CertificadaGarantia da Qualidade de ProdutoGarantia da Qualidade de ProcessoMedição e Análise

Apresentação Prática - FerramentasDo requisito ao código com Powerlogic jALM

Perguntas & Debate


Sobre a Powerlogic

3

Powerlogic - Timeline1994: Fundação, em Minas Gerais1995-1998: Cliente/Servidor e Downsizing1998: Início de Atuação com Java App Servers1999: eCompany Portal/Project 1.02000-2001: Maturidade em eBusiness2002: 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 “ExtremmeProgramming 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.

4

Powerlogic - CrescimentoAnálise de Crescimento - Powerlogic S.A

1.738,000

2.391,000

2.996,0002.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,0003.594,000

4.038,000

4.668,000

5.307,0005.811,000

6.042,0006.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)

Powerlogic – Solution Providers

5

Projetos Nacionais

Sudeste e Centro Oeste

6



7

Norte e Nordeste

Sul

8

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

9

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ãode “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: Origens

10

O Manifesto da Agilidade: Super-ênfase em Iteratividade!

O framework do Processo Unificado é“Iterativo” em sua concepção, mastende 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

Scrum Básico – Abordagem Empírica

11

Requirement

Technology

Instable

Stable

Known Unknown

Anarchy

ComplexComplicated

ComplicatedSimple

Scrum Básico – Teoria do Caos

Processes States:

• Ideal: Inputs, Outputs and Process Variables StablesSoftware 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. Predictiveand Planning almost ineffective.Continuous observation can delivery convergent products!

Software Development usually is in this state!

• Chaos! Process not producing conforming products and is notcontrollable.

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!

12

• 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

Scrum Básico – Processo Iterativo

13

Most projects deliver software every 6 to 18 months. Scrumreduces this to many 1 month deliveries to increase controlvia inspect/adapt.

This puts stress on the team and organization, exposingunderlying problems and limitations.

The Scrum Master’s job is to prioritize these problemsand help the organization overcome them to get betterat software development, managing softwareinvestments, 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

- QA Team

14

Scrum Básico – Comunicação

Scrum Básico – Agile Radiator

15



16



Adicionais Powerlogic:

- Retrospective Boxes

- www (what went well)

- wcbi (what can be improved)

- Indicadores do Processo e Release Plan

17



18


Scrum Básico – Comunicação

19

Scrum Básico – Comunicação Tácita

• Sprint Planning 1 (Pre-Planning)

• Sprint Planning 2• Daily Scrum• Sprint Review• Sprint Retrospective

Scrum Básico – Reuniões Formais

Adicionais Powerlogic:- Release Planning (Pre-Game)

- Release Review (Post-Game)

20


CMMI & MPS.Br

Compatibilidade Scrum & CMMI

Level Key Practice Area Rating2 Requirements management2 Software project planning2 Software project tracking and oversight

2 Software subcontract management

2 Software quality assurance2 Software configuration management

3 Organization process focus3 Organization process definition

3 Training program3 Integrated software management

3 Software product engineering

3 Intergroup coordination3 Peer review

21

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

22

SeguranSeguranççaa e e MonitoriaMonitoriaemem ProduProduççãoão

Java EEJava EEOpenOpen--Source Source

ControleControle de de QualidadeQualidadeJava EE Java EE

OpenOpen--SourceSource

DesenvolvimentoDesenvolvimentoJava EEJava EE

OpenOpen--SourceSource

ComunicaComunicaççãoão e e ColaboraColaboraççãoão

ProcessosProcessos CorporativosCorporativos e e GerênciaGerência de de ProjetosProjetos

Powerlogic jALM

Powerlogic jALM

23

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áticasAveriguadas, ...

Pré-Produção

eCompany Portal Produção

jCompany Monitor

Aplicação Contextualizada Para Usuários,

Apoiada por UtilitáriosDe Colaboração, ...

Monitoria

eCompany Contact-Center

Aplicação Monitorada: Contabilização de Uso,Auditoria, Estatísticas,

Disponibilidade, ...

Suporte

eCompany ProcessProcesso, Produtos,

Componentes,Projetos, Requisitos

PlanejamentoGestor

AplicaçãoAveriguada 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.

24


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).

25



26



27


Informalidade não ésinônimo de Agilidade

Formalidade não é sinônimo de Conformidade

GPR – Gerência de Projetos ÁgilPolí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);

g) Os colaboradores (Scrum Team) trabalham em regime de 40 horas semanais, sem horas extras e com custo fixo. (...)

28

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 requisitosevolucioná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 "planode 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 suaopinião deve soberana. Para dimensionar tamanho, o Scrum Team deve seguir técnicas ágeis e unidade emIdeal Days. A ordenação das lista de requisitos pode sofrer ajustes pelo Scrum Team, para refletirdependê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), quepodem 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), parasolucionamento 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á quetendem a se manter os mesmos ao longo de vários projetos. Em cada projeto, deve-se definiros registros de versão de cada item e atualizações eventuais. Para cada projetosubsequente, deve-se definir somente alterações em versões de itens anteriores, destemodo a evitar redundância desnecessaria;

c) Deve-se possuir um conceito de "Configuração Global", que reuna um único número de versãoque consolide os demais números gerados pelos diversos repositórios que se façamnecessários (Subversion para fontes e documentos, Continuum para executáveis, eCompanyProcess 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.

GCO – Gerência de Configuração Ágil

29

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 todosos 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 garantirsolução de automação para execução de "testes de regressão" continuamente (integraçãocontí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 identificarproblemas, deve apresentar proposições de soluções e melhorias, e acompanhar suasdeliberaçõ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-CodeRepository

Subversion(SVN)

Subversion(SVN)

Customer.java v1. Customer.java v2. Customer.java v3Product.java v1. Product.java v2Invoice.java v1

ComponentRepository

(Maven)

sales.jar v3.0 (Customer.java v2, Product.java v1, ...). sales.jar v3.01. sales.jar v3.02. sales.jar v.4salesutils.war v1.0. salesutils.war v1.1hibernate.jar v3.2

ApplicationRepository

AdvancedContinuumAdvancedContinuum

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

MavenMaven

Repositórios de Gerência

de Configuração dojCompany QA Suite

Developer 1 Developer 2 Developer N Tester

MavenProxy

MavenProxy

30

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 queauxiliem a Diretoria de Tecnologia da Powerlogic a acompanhar, de forma quantificada, osresultados esperados do processo, observando e enfatizando as questões estabelecidasnas 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çãodurante reuniões de retrospectivas (Retrospective Meeting), e possam ser analisados pelasequipes coletivamente;

d) Os indicadores devem ficar visíveis junto aos radiadores ágeis, e também em relatórioconsolidado de GQA, para a Diretoria Técnica;

e) Os indicadores, sempre que possível, e ao longo do tempo, devem ser automatizados pelosprodutos Powerlogic.

MED – Medição e Análise Ágil


Apresentação Prática: Ferramentas

31

Objetivo:

Simular um Projeto Scrum incluindoGestão, Levantamento, Especificação, Construção e QA para uma aplicaçãode 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.

32


Perguntas & Debate


Fim

Documents

Aplicação e integração do SCRUM e CMMI/ MPS.BR A ... · 2 Roteiro Apresentação ¾Sobre a Powerlogic ¾Métodos Ágeis e Scrum ¾CMMI e MPS.Br ¾Powerlogic jALM Estudo de Caso: