Avaliação Experimental de Técnicas Ágeis de Desenvolvimento

Lucas dos Santos LimaAndrés Ignácio Martínez Menéndez (orientador)

Universidade Federal de SergipeDezembro de 2011

Plano de Apresentação• Introdução• Referencial Teórico

– PPDSI– Scrum

• Problemática• Análise PPDSI x Scrum

– Cenário– Itens de comparação– Desafios– Resultado

• Conclusão

Introdução• Motivação

Introdução• Motivação

Introdução• Objetivo– Levantar questionamentos– Comparativo prático– Análise de resultados

Introdução• Estrutura do trabalho:

1. Introdução2. Processo de Software3. Metodologias Tradicionais4. Metodologias Ágeis5. Análise comparativa entre PPDSI e Scrum6. Conclusão

Referencial Teórico• Processo Padrão de Desenvolvimento de

Software Infox– Orientado à documentação– Fases seqüenciais– Grandes projetos

Referencial Teórico

Referencial Teórico• Papéis– Gestor de Projeto– Coordenador de Atividades– Analista– Desenvolvedor– Web Designer– DBA– AD– Testator e Documentador– Suporte ao usuário

Referencial Teórico• Scrum

Referencial Teórico• Por que Scrum?

Pesquisa “State of Agile Development Survey” da VersionOne e conduzida pela Analysis.Net Research.

Problemática• Infox Tecnologia da Informação LTDA– Sistema de Defesa Agropecuária (Sidagro)• Momento crítico• Busca por novas soluções

Análise PPDSI x Scrum• Cenário da análise

Análise PPDSI x Scrum• Itens de Comparação– Tempo e Esforço– Artefatos– Atividades– Disciplinas– Papéis

Análise PPDSI x Scrum• Alocação de Tempo e Esforço• PPDSI– Horas de trabalho– Experiência passada– Hierárquico– Redmine

Análise PPDSI x Scrum• Alocação de Tempo e Esforço• Scrum– Planning Poker– Estimativa da Equipe– IceScrum

Análise PPDSI x Scrum• E quando não conseguimos estimar?

Análise PPDSI x Scrum• Alocação de Tempo e Esforço– Prazo inicial acordado e documentado• 30/11/2011

– Julho• Reanálise de escopo e prazo• 59/132 casos de uso implementados• Momento crítico• Novas diretivas• Projeto Piloto

Análise PPDSI x Scrum• Alocação de Tempo e Esforço– De Agosto à meados de Novembro• 85 estórias• 73 casos de uso• 11 Sprints (2 semanas)

Análise PPDSI x Scrum• Artefatos– PPDSI• Burocracia• +40 documentos

– Com o Scrum alguns artefatos deixaram de existir

• Retrospectiva Scrum

Análise PPDSI x Scrum

Análise PPDSI x Scrum• Artefatos– Scrum• Livre dessas críticas• Documentos só quando necessário (Manifesto Ágil)

– Alguns artefatos fazem parte do dia-a-dia

Análise PPDSI x Scrum• Product Backlog

Análise PPDSI x Scrum• Sprint Backlog

Análise PPDSI x Scrum• Burnup

PPDSI x Scrum• Artefatos– Por que o Scrum não precisa de todos esses

documentos?

Análise PPDSI x Scrum• Atividades– PPSDI• Tarefas desempenhadas por um papel.• Trabalhar os artefatos• Custo x Tempo

Análise PPDSI x Scrum• Redmine

Análise PPDSI x Scrum• Atividades– Scrum• Ciclo de vida curto.• Não há indicação de tarefas.

Análise PPDSI x Scrum• Atividades

Análise PPDSI x Scrum• Atividades

Análise PPDSI x Scrum• Atividades

Análise PPDSI x Scrum• Disciplinas– PPDSI• 5 workflows• Pouca Abrangência

– Scrum• Poucos processos de controle• Cerimônias

Análise PPDSI x Scrum• Disciplinas– Cerimônias• Reunião de Abertura de Projeto -> Release Planning• Daily Meeting• Sprint Review

Análise PPDSI x Scrum• Papéis– PPDSI• Indivíduos x Papéis• Equipe grande e cara• Ociosidade imposta

– Scrum• Indivíduos x Papéis• Multidisciplinaridade

Análise PPDSI x Scrum• Papéis– Coordenador -> Scrum Master– Gestor do Projeto -> “Meta” Scrum Master– Analista de Negócios -> Product Owner– AD, DBA, Analista, Desenvolvedor... -> Equipe (time)

Análise PPDSI x Scrum• Desafios Encontrados– Necessidade de um “Meta-Scrum Master”– Preparar a empresa para o Scrum– Fazer Scrum estritamente e “apenas” à risca– Inexperiência da Equipe em Scrum

Análise PPDSI x Scrum

Análise PPDSI x Scrum• Resultado– Ambas tem qualidades e defeitos– PPDSI• 59 casos de uso produzidos em 6 meses• Uma única entrega• Insatisfação e desconfiança do cliente• Pausa pra reflexão e ordem

Análise PPDSI x Scrum• Resultado– Scrum• 85/95 estórias em 4 meses• 73 casos de uso em 10 entregas• Estimativa: 11 Sprints de 2 semanas (5 meses e meio)

– Toda mudança impõe riscos!• Resistência• Desconfiança

Análise PPDSI x Scrum• Lições Aprendidas– Constante transição– É muito fácil começar a fazer Scrum, o difícil é

vencer a resistência das pessoas– Se o foco das pessoas for “fazer telas”, “testar” ou

“escrever software”, o projeto está comprometido– Boas práticas de Engenharia de Software são

fundamentais

Conclusão• Objetivos– Infox X Monografia

• Base para outras pesquisas– Metodologia Híbrida– Customização do Scrum para licitações

Referências• AGILE MANIFESTO. Agile Manifesto. Agile Manifesto, 2001. Disponivel em:

<http://agilemanifesto.org/iso/ptbr/>. Acesso em: 10 jul. 2011.• AMBLER, S. Modelagem ágil: práticas eficazes para a Programação

Extrema e o Processo Unificado. Porto Alegre: Bookman, 2004.• BECK, K. Extreme Programming Explained: EmbraceChange. 1. ed. [S.l.]:

Addison Wesley, 1999.• DIJKSTRA, E. The Humble Programmer. Commun. ACM 15.

en:Communications of theACM, Nova York, 1972.• FOWLER, M. . B. K. Manifesto for Agile Software Development, 2001.

Disponivel em: <http://www.agilemanifesto.org>.• HAMMOND, D. W. A. J. S. The Forrester Wave™: Agile Development

Management Tools, Q2 2010, 05 055 2010.• KNIBERG, H. Scrum e XP Direto das Trincheiras. [S.l.]: [s.n.], v. 1, 2007. 147

p.

Referências• KOSCIANSKI, A. Qualidade de software. 2. ed. [S.l.]: [s.n.], 2007.• KRUCHTEN, P. The Rational Unified Process, An Introduc-tion. 2. ed. [S.l.]:

Addison Wesley, 2000.• MINISTÉRIO DA DEFESA. Programa de Excelência Gerencial. Elaboração e

Gerenciamento de Projetos. 33.• OLIVEIRA, S. R. B. R. T. A. Adequação de Processos. Simpósio Internacional

de Melhoria de. São Paulo: [s.n.]. 2004.• ONE, V. Version One. Version One, 2010. Disponivel em:

<http://www.versionone.com>. Acesso em: 16 nov. 2011.• PRESSMAN, R. S. Engenharia de Software. 5. ed. [S.l.]: Makron Books,

2002.• Processo Padrão de Desenvolvimento de Software Infox. Infox Tecnologia

da Informação LTDA. Aracaju, p. 121. 2011.

Referências• R.A. FALBO, C. S. M. A. R. R. Integração de Conhecimento sobre Processos

de Software em um Ambiente de Desenvolvimento. IX Conferência Internacional de Tecnologia de Software. Curitiba: [s.n.]. 1998.

• REIS, D. F. Conceitos básicos sobre Metodologias Ágeis para Desenvolvimento de Software. devmedia, 2008. Disponivel em: <http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=10596>. Acesso em: 28 maio 2011.

• REIS, D. F. DevMedia. DevMedia, 2008. Disponivel em: <http://www.devmedia.com.br/post-10596-Conceitos-basicos-sobre-Metodologias-Ageis-para-Desenvolvimento-de-Software--Metodologias-Classicas-x-Extreme-Programming.html>. Acesso em: 12 jun. 2011.

• SCHWABER, K. Agile Software Development with Scrum. 1. ed. [S.l.]: Prentice Hall , 2001.

• SCHWABER, K. Agile Project Management With Scrum. [S.l.]: Microsoft, 2004.

Referências• SCHWABER, K. Agile Project Management With Scrum. 1. ed. [S.l.]:

Microsoft Pr, 2004.• SCHWABER, K. The Enterprise and Scrum. 1. ed. [S.l.]: Microsoft Press,

2007.• SOMMERVILLE, I. Software Engineering (International Computer Science

Series). 5. ed. [S.l.]: Addison-Wesley, 1995.• SOMMERVILLE, I. Software Engineering. 6. ed. [S.l.]: Addison Wesley,

2000.• SOMMERVILLE, I. Engenharia de Software. 6. ed. [S.l.]: Addison Wesley,

2003.• THE STANDISH GROUP INTERNATIONAL. Extreme Chaos. The Standish

Group International. [S.l.]. 2004.• WELLS, D. Manifesto for Agile Software Development, 2004. Disponivel

em: <http://www.extremeprogramming.org>.

Dúvidas?

“O único jeito de evitar erros é adquirindo experiência, mas a única maneira de adquirir experiência é cometendo erros” (Elbert Hubbard)