[Uff]qualidade agilidade

Qualidade e Agilidade

[email protected]

mailto:[email protected]

Analia Irigoyen Ferreiro Ferreira

2 | © ProMove – Business Intelligence Solutions

Sócia-Diretora da ProMove

Mestre em Eng. de Sistemas e Computação pela UFRJ (2009), Pós-graduação em

Análise, Projeto e Gerência de Sistemas PUC (1999) e graduado em Informática pela

UFF (1996).

Implementadora credenciada do modelo MPS, participou em implementações dos

modelos CMMI e MPS.

Avaliadora líder inicial credenciado do modelo MPS.

Mais de 10 anos de experiência em Gerência de Projetos, certificada Scrum-

Master e PMP.

Público Alvo


Grupos de processo de organizações que adotaram os modelos CMMI ou MPS e

querem adotar práticas ágeis .

Empresas que tenham interesse em realizar avaliações no CMMI com práticas ágeis

nos próximos anos.

Implementadores que desejam compreender o que o CMMI na versão 1.3 discute

sobre a Agilidade.

Para Refletir ...


“Use professional judgment and common sense to interpret the model for your

organization. That is, although the process areas described in this model depict

behaviors considered best practices for most users, process areas and practices

should be interpreted using an in-depth knowledge of CMMI-DEV, your

organizational constraints, and your business environment.”

Qual o julgamento profissional e senso comum em organizações que adotam

métodos ágeis?

CMMI or Agile: Why Not Embrace Both! [Glazer 2008].

CMMi não diz como implementar as práticas.

CMMi V1.3: notas auxiliam na interpretação.

CMMi - Versão 1.3 e Agilidade

Lista de pré-requisitos do CMMi V1.3

Aderente Manifesto for Agile Development [Beck 2001].

Envolvimento do PO



Múltiplas interações para conhecer e evoluir o produto



Cliente comprometido em compartilhar decisões e riscos

Agilidade


Agilidade x SCRUM

SCRUM é uma pequena parte do mundo ágil

Princípios Ágeis

Notas do CMMI Versão 1.3 sobre agilidade


5 Causal Analysis and Resolution (CAR) Organizational Performance Management (OPM)

4 Organizational Process Performance (OPP) Quantitative Project Management (QPM)

3 Decision Analysis and Resolution (DAR) Integrated Project Management (IPM) Organizational Process Definition (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Risk Management (RSKM)

Product Integration (PI) Requirements Development (RD) Technical Solution (TS) Validation (VAL) Verification (VER)

2 Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP)

Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM)

Gerência de Configuração (CM)


Responsável por GC no Time:

Garantindo que Estratégia de GC seja cumprida

Estratégia de GC+ Complexa

Integração do Produto (PI)


Integração Contínua



A Estratégia de Integração Contínua deve (1/2):

1)Ser elaborada no início do projeto e revista para refletir a evolução dos componentes existentes e os novos.

2) Conter regras para incorporar produtos de terceiros.

3) Como será a solução para as interface entre as aplicações.

4) Informações enviadas e recebidas



A Estratégia de Integração Contínua deve (2/2):

5) Quando realizar refactoring.

Monitoração e Controle (PMC)


Monitoração do envolvimento dos Stakeholders

- É crucial garantir que o PO e os usuários finais estejam envolvidos nas atividades de desenvolvimento.

Planejamento do Projeto (PP)


Por desconhecimento do todo (o software é evoluído conforme o conhecimento adquirido) (1/3):

1)Planejamento inicial de Alto Nível.

-> Os maiores riscos e marcos são conhecidos.

-> Restrições e premissas também são conhecidas.

2) O time faz o planejamento/Replanejamento mais frequentes e com maiores detalhes.




-> Refletem como realizar uma iteração e o perfil do time envolvido e alguns fatores como: esforço, recursos e riscos.

-> O planejamento é revisado/refinado durante as reuniões diárias e ao final das iterações.

-> O comprometimento é obtido ao “pegar a tarefa” (time, durante o sprint)




3) Estimativas

-> Estórias são elaboradas ou estimadas e as iterações são realizadas por meio de um conjunto de tarefas.

-> Sprint Backlog é derivado de um Product Backlog.

Garantia da Qualidade (PPQA)


Times ágeis estão resolvendo necessidades imediatas da iteração!

1)Planejar no início do projeto: como as avaliações objetivas serão realizadas para garantir objetivos organizacionais.

2)Que processos e produtos serão avaliados;

3)Como o resultado das avaliações serão incorporados ao time (parte do daily meeting, checklists, peer reviews, tools, integração contínua, restrospectivas)

Gerência de Projeto Quantitativa (QPM)


Exemplos de objetivos de desempenho dos processos:

1)Aumentar a velocidade do time em X % em Y meses ou anos.

Desenvolvimento de Requisitos (RD)


1) Requisitos e idéias são elicitados,

desenvolvidos , elaborados e validados de

forma iterativa (1/2).

• São documentados em: User Stories,

Cenários, Casos de Uso, Product

Backlogs, Código.

• A priorização dos requisitos e análise

dos riscos é realizada ao selecionar o

“Sprint Backlog“ do “Product Backlog”.

Desenvolvimento de Requisitos (RD)


1. Requisitos e idéias são elicitados, desenvolvidos , elaborados e validados de forma iterativa (2/2).

• Quanto de detalhes dos requisitos a ser documentado é decidido pelo risco de perder o que foi aprendido.

• Quando o PO está no time, é necessário separar requisitos do cliente de requisitos do produto.

• Todas as tarefas e responsabilidades são distribuídas entre os times e a rastreabilidade é feita por meio do “Product Backlog”.

Gerência de Requisitos (REQM)


1) Requisitos são comunicados através dos quadros e comprometimentos são obtidos /revistos nas reuniões de planejamento e revisões (daily meeting,..) (1/3):



2) Rastreabilidade (2/3)

1) Product Backlog

2) Sprint Backlog

3) Tarefas

4) Código



3) Análise das Inconsistências (3/3)

Reuniões de Início de Sprint (SP 1), Retrospectiva e Review (Demo)

Gerência de Riscos (RISKM)


• A estratégia de riscos está “embutida” na própria metodologia ágil.

• Algumas técnicas de mitigação de riscos podem ser adotadas, como:

experimentação (early failures) ou spike (fora da iteração).

• Só que é necessário algo mais sistemático: Planejamento, Estimativa e

Aceite as tarefas.

Solução Técnica (TS)


1) Exploração de soluções técnicas o mais cedo possível. Ex.: tecnologia, Arquitetura, reutilização, requisitos funcionais e não funcionais.

2) É importante explicitar o custo x benefício e outros raciocínios quando existem altos (DAR)

3) Manuais de instalação, informações da release, logs de manutenção.

Verificação (VER) e Validação (VAL)


1) Com Envolvimento do PO, VER passa a ser VAL. (1/2)

2) Um defeito detectado em um Sprint , tanto pelos testes do time ou pelo PO contribuem para o alcance do objetivo.

3) Algo mais sistemático deve ser estabelecido no início do projeto: o que vai ser revisto e testado, métodos e ambiente (Ex.: Integração Contínua).

4) Garantir: Compatibilidade com a Solução e Requisitos e Consistência.

Verificação (VER) e Validação (VAL)


1) Exemplo: Integração Contínua

Relação MPS.BR e XP

• Auditoria independente (GQA)• A periodicidade ideal é a cada três meses.

• Assegurar a objetividade das auditorias (GQA e GC)• Avaliador independente do projeto.• Nível de hierarquia adequado.• Critérios de avaliação que garantam o

entendimento comum.

Papéis – Qualidade no Nível F

Scrum para Implantar Biblioteca de Ativos

Lições Aprendidas

Não busque o processo perfeito. Comece com:

Processo Iterativo com melhoria contínua

Faça:

Um bom planejamento inicial

Um excelente backlog

Uma excelente infraestrutura

Uma equipe comprometida e motivada

Contato


[email protected]

Tel/Fax: (21) 3283-8340

[Uff]qualidade agilidade

Documents

Transcript of [Uff]qualidade agilidade