CONTEXTUALIZAÇÃO Agilidade X CMMI

Transcrição

1 Uso do SCRUM em Ambiente CMMI Teresa M. de Medeiros Maciel Ana Sofia C. Maçal Felipe Furtado Bruno Freitas Mariana Xavier CONTEXTUALIZAÇÃO Agilidade X CMMI 1

2 Em Over <> Instead of ABORDAGEM ÁGIL Um estado mental, não um conjunto de passos, técnicas... Iterações curtas de 2 a 6 semanas. Priorizações dinâmicas (ao final de cada iteração) Foco em produzir valor ao negócio de forma rápida e contínua. Rápida adaptação a mudanças. Proximidade e intensa interação entre a equipe. Feedback constante. Pessoas como principais direcionadores do sucesso do projeto. 2

3 MÉTODOS ÁGEIS podem ser considerados uma coletânea de diferentes técnicas e métodos que compartilham os mesmos valores e princípios básicos, alguns dos quais remontam técnicas introduzidas em meados dos anos 70, como os desenvolvimentos e melhorias interativos (COHEN et al, 2003). MÉTODOS ÁGEIS 3

4 CMMI O que realmente é requerido? Only the statement of the specific or generic goal is a required model component CMMI SE/SW V1.2 ÁREAS DE PROCESSO OBJETIVOS PRÁTICAS SUB-PRÁTICAS PRODUTOS TÍPICOS DE TRABALHO Requeridos Desejáveis Informativos CMMI X AGILIDADE Alguns Mitos Nenhuma documentação é requerida Just Code Man! Design on the fly resulta em um melhor produto Clientes estão sempre tomando decisões juntamente com o time. Não precisamos de registro. Apenas fazemos a reunião CMMI é incompatível com Ágil Avaliações e auditorias não agregam valor Nós apenas conseguimos o CMMI se focarmos em evidências, documentos e relatórios. CMMI é algo que você implementa. CMMI é aplicável apenas a grandes corporações. O CMMI irá duplicar nosso trabalho e nos deixar mais lentos. O CMMI é projetado para trabalhar bem com projetos cascata. Fonte: Process Innovation at the Speed of Life, J. R Dalton, SEPG

5 AGILE PROJECT MANAGEMENT surge como uma nova plataforma de gerenciamento de projetos aplicável a ambientes voláteis e desafiadores, sujeitos a mudanças freqüentes. Plataforma sólida, capaz de dar suporte a vários tipos de projetos Relacionamento entre as plataformas de gerenciamento clássico e ágil de projetos FONTE: CHIN, Garry A cada iteração é feito um novo planejamento do escopo, prazo, custo e qualidade, visando a entrega do produto e possibilitando incrementos de funcionalidades. Fluxo do gerenciamento ágil de projetos 5

6 SCRUM Cada funcionalidade selecionada deve ser quebrada em tarefas. O cliente explica cada funcionalidade O cliente atribui valorde negócio Equipe estima a complexidade para desenvolver cada funcionalidade. Equipe prioriza funcionalidades de acordo com seu valor de negócio e a complexidade. Equipe seleciona quais funcionalidades serão construídas no próximo sprint. Lista de produtos Premissas Restrições etc Cliente pode ver O quê uma andou versão bemdemo O quê do deve produto ser com as melhorado funcionalidades Últimos 30 dias. desenvolvidas. Equipe deve completar cada tarefa Daily meeting: O que você tinha que ter feito desde a última daily meeting? O que você irá fazer antes da próxima daily meeting? O que está no seu caminho? Impedimentos devem ser resolvidos ASAP. PAPÉIS SCRUM Product Owner Determina as funcionalidades do Product Backlog Prioriza o Product Backlog Scrum Master Garante que a equipe de desenvolvimento utilize os valores e as práticas do Scrum Escuta relatos, mas não deve interferir nas decisões da equipe a menos que seja solicitado Retira os impedimentos do projeto Scrum Team Tipicamente i 5-10 pessoas Todos devem trabalhar coletivamente para completar o ciclo da Sprint Engenharia, Designer, QA não estão em times separados, todos estão no mesmo time O time é auto-gerenciável, não existe mais o papel do gerente dizendo o que eles tem que fazer 6

7 CMMI e SCRUM Análise das PAs de Gerenciamento de Projetos Falta de um gerenciamento de riscos mais efetivo Falta de práticas organizacionais Uso não sistemático de bases históricas Fonte: Mapping CMMI Project Management Process Areas to Scrum SEW 2007, IEEE CMMI e SCRUM Análise das PAs de Gerenciamento de Projetos Grande parte de conflitos entre o CMMI e o SCRUM se encontram nas práticas organizacionais, as quais podem ser adicionadas. Fonte: Mapping CMMI Project Management Process Areas to Scrum SEW 2007, IEEE 7

8 O C.ES.A.R Contexto Organizacional SEDE Recife PE Brasília - DF São Paulo - SP Onde estamos 8

9 QUALIDADE NO C.E.S.A.R ProSCes 1.0 SW-CMM2 ISO Pitang SCRUM na Pitang CMMI3 Pitang SQA E SCM nos Projetos ISO Incubação SCRUM no CESAR C.E.S.A.R CMMI3 C.E.S.A.R Qualidade Prioridade C.E.S.A.R CONTEXTO ORGANIZACIONAL Busca do CMMI3 em processo de institucionalização Processo de software padrão publicado e aderente ao CMMI3 Grande diversidade de projetos Motivação de alguns gerentes a aderirem a APM CMMI3 na Pitang em fase de definição do processo da organização Projetos de inovação, requerendo flexibilidade vesus projetos de desenvolvimento de aplicativos críticos demandando disciplina e formalidade 9

10 ProSCes SCRUM + CMMI Processo de Software C.E.S.A.R Estratégia de inserção de APM no C.E.S.A.R. Necessidades do negócio,. Objetivos estratégicos. Prioridades do Processo Definição e Melhoria do ProSCes Adaptação do Processo Critérios de Adaptação Repositório do Processo PROSCES PDP Projeto A PDP Projeto B PDP Projeto C Verificações, feedback, lições aprendidas Arquitetura Pré-definida Gerência de Configuração Controle de Mudanças Disponibilizado em Intranet Identificação de Melhorias ProSCes Ambiente 10

11 ADAPTAÇÃO DO PROCESSO PADRÃO Processo de Software CESAR - PROSCES Subprocesso Subprocesso 2... Subprocesso n Propósito Público Alvo Fluxo de Atividades Atividade 1 Atividade 2 Atividade n Objetivos Critérios de entrada Responsabilidades Ações Critérios de Saída Artefatos de entrada Artefatos de Saída Templates Forte adaptação Flexibilização Procedimento Detalhado Técnicas ou Guias Ferramentas Pequenos ajustes ESTRATÉGIA DE INCORPORAÇÃO DO SCRUM NO C.E.S.A.R Foruns institucionais de discussões, coleta de LAs pelo SQA FORMAÇÃO DE MULTIPLICADORES PROJETOS PILOTOS SCRUM ANÁLISE DE LAS 30 colaboradores formados em SCRUM Master (GPs, líderes, SQEs, CMs) Motivação pessoal de equipes e do cliente Projetos não inseridos no escopo CMMI3 Adoção e validação formal (SCAMPI) do SCRUM+CMMI3 na Pitang VALIDAÇÃO FORMAL DO USO CONJUNTO SCRUM E CMMI EXTENSÃO DO SCRUM+CMMI PARA TODOS OS PROJETOS CESAR/PITANG Inserção de práticas SCRUM no processo padrão do C.E.S.A.R APM Estratégia 11

12 EXPERIÊNCIA NO USO DO SCRUM NO C.E.S.A.R PROJETOS PILOTOS SCRUM Nível de Experiência da Equipe 13% 11% Duração do Projeto 45% 25% 62% 44% Baixo Médio Alto Longa Média Curta Custo do Projeto 11% 0% 33% Tamanho da Equipe 89% Médio Baixo Alto Pequena Média Grande 67% 12

13 PROJETOS PILOTOS Abordagens Adotadas Papéis Product Owner: Gerente de Projeto do Cliente ou Gerente de Projeto C.E.S.A.R (quando o cliente não quer se envolver). Em um dos projetos, um consultor interno assumiu o papel. ScrumMaster (SM)- Cenários Gerente de Projeto do C.E.S.A.R assumindo totalmente o papel. Gerente de Projeto (GP)+Líder de Equipe C.E.S.A.R (TL). O GP resolve os impedimentos sobre os quais o TL não tem autonomia e o TL resolve os impedimentos mais técnicos. Em geral, o TL conduz as reuniões de daily meeting e, algumas vezes, o sprint burndown. O GP fica mais com atividades administrativas. Gerente de Projeto C.E.S.A.R + Engenheiro de Qualidade Como uma das responsabilidades do SM é garantir que a equipe execute o Scrum da forma correta, isso passa a ser uma vantagem. Por outro lado, os impedimentos foram tratados pelo GP. PROJETOS PILOTOS Abordagens Adotadas Uso do Sprint Burndown para acompanhamento das tarefas. Uso de Story Points para derivar esforço a partir da complexidade das tarefas da sprint. Testes formais executados no final de cada sprint. Os produtos de trabalho formalmente aceitos pelo cliente ao final de cada sprint. Itens de backlog registrados como solicitações de mudança registradas. 13

14 PROJETOS PILOTOS Abordagens Adotadas Em alguns projetos, um período entre o planning 1 e 2 foi adicionado para possibilitar a decisão de abordagens a serem adotadas para os IBLs mais complexos e indefinidos (não dura mais de 3 dias e é usado apenas para os estudos e tomadas de decisão). A duração das sprints variaram entre: 2 semanas pequenas aplicações,apresentando facilidade de eestimativa. 3 semanas maior parte dos projetos. 4 semanas normalmente quando houve atraso. LIÇÕES APRENDIDAS Aspectos Positivos Observados O uso de Story Points possibilita iniciar a estimativa sem necessidade de grande informação. Precisa-se apenas de uma referência o item de backlog com menor complexidade, ponto de comparação para a estimativa dos demais itens. A estimativa por Story Points ajuda a priorizar os itens do Product Backlog, e a selecionar os itens que devem compor o Selected Product Backlog. Nítido comprometimento da equipe quanto ao cumprimento dos prazos estimados, uma vez que os mesmos são definidos colaborativamente. 14

15 PROJETOS PILOTOS Aspectos Positivos Observados O uso do burndown permite maior visibilidade da completude das tarefas desde o início do projeto. Atrasos são detectados com mais antecedência. Evita surpresas. Todos os membros da equipe conhecem as atividades dos demais membros. Isso permite uma maior cooperação entre o time. Uns ajudam os outros. Dependências são mais visíveis. Post-it X Planilha O Post-it permite uma maior visibilidade A planilha é usada para coleta de indicadores (percentual de distribuição de esforço por subprocesso, variação de esforço). Além disso é útil para o acompanhamento a distância. LIÇÕES APRENDIDAS Aspectos Positivos Observados A equipe interpreta os requisitos em conjunto com o cliente nas reuniões de sprint planning, facilitando o entendimento e interação com o cliente. 15

16 LIÇÕES APRENDIDAS Dificuldades Encontradas A estimativa por Story Points baseia-se em uma referência para o projeto, que provavelmente não será a mesma para um outro projeto. A comparação efetiva das estimativas entre projetos, desta forma, pode ser comprometida. Estimativas das primeiras sprints foram pouco precisas ocasionando em horas adicionais de trabalho. À medida que a equipe foi se integrando e adquirindo conhecimento no domínio da aplicação e na tecnologia, as estimativas tornaram-se mais precisas. LIÇÕES APRENDIDAS Dificuldades Encontradas O Story Points recomenda a participação de toda a equipe nas estimativas, diferente das demais técnicas (UCP, FPA, Delphi) que normalmente os especialistas é que tendem a participar. A inexperiência de parte da equipe pode, então, comprometer seriamente as estimativas. 16

17 MOMENTO ATUAL Cerca de 10 projetos executando SCRUM no C.E.S.A.R e Pitang. Grupos de estudos criados, com listas e chats de discussões específicos sobre APM e agilidade em outras disciplinas (PPQA, SCM ). Projeto de melhoria em andamento para inserção de práticas SCRUM no processo padrão (aderente ao CMMI3 foco no atendimento a goals e não a practices. Adoção do CMMI e APM como referências fundamentais do ProSCes. CMMI3 + SCRUM iniciado na Pitang. CONSIDERAÇÕES FINAIS A adoção do SCRUM tem sido considerada positiva considerando as lições aprendidas. A experiência e entrosamento da equipe é fundamental em equipes SCRUM. O uso do SCRUM em ambiente CMMI é possível e pode ser uma boa estratégia para projetos de software. A abordagem de uso conjunto de SCRUM e CMMI, pode ocasionar em riscos com relação à aderência ao modelo, mas práticas alternativas podem ser consideradas sem comprometer o atendimento dos goals. 17

18 CENAS DO SCRUM EM EXECUÇÃO 18

19 19

20 20

21 Referências 21

22 Referências AGILE ALLIANCE. Manifesto for Agile Software Development. Available: [jan. 2005]. CHIN, Gary L. Agile Project Management: How to Succeed in the Face of Changing Project Requirements. Amacon, HIGHSMITH, Jim. Agile Project Management: Creating Inovative Products. Boston: Addison-Wesley, HIGHSMITH, Jim. Agile Software Development Ecosystems. Boston: Addison-Wes ley, PMBOK, 3 ed, Project Management Institute Inc., THOMSETT, E. Extreme Project Management. E-Project Management Advisory Service Executive Report, THOMSETT, E. Radical Project Management. Prentice Hall PTR, UDO, N., KOPPENSTEINER, S. Will Agile change the way we manage software projects? Agile from a PMBoK guide perspective. Projectway, 2003 POPPENDIECK M.e T., Lean Software Development An Agile Toolkit, Addison Wesley, DALTON, J.R., Process Innovation at the Speed of Life, SEPG 2006, Referências

23 Teresa Maci CESAR/Qualida Consulto 23