Programa de Pós-Graduação Stricto Sensu em Gestão do Conhecimento e da Tecnologia da Informação da Universidade Católica de Brasília
Pesquisadora: Elizabete Proença Strauhs
Projeto: Limitadores e Soluções de Contorno na Adoção de Práticas Ágeis do Método Scrum em Projetos de Desenvolvimento de Software
Protocolo de Pesquisa 1. Procedimentos de campo
1 Obtenção formal de acesso à empresa e às informações de interesse da pesquisa. 2 Providenciar notebook, gravador e bloco de anotações.
3 Confirmação dos Scrum Masters a serem entrevistados. 4 Agendamento das entrevistas.
5 Realizar entrevistas com base no instrumento de pesquisa (ver Apêndice J)
6 Identificação de documentos relacionados a dificuldade de adoção de práticas Scrum no desenvolvimento de software. 7 Registro em banco de dados das informações obtidas nos entrevistas e documentos.
2. Questões específicas para coleta de dados Fontes
1
Quando uma prática não foi adotada por algum aspecto organizacional, investigar se esse aspecto foi modificado ou ainda persiste na empresa.
Entrevistados e Documentos da empresa.
2 Investigar a existência de registros da não adoção de alguma prática ágil nas lições aprendidas dos projetos. Documentos dos projetos.
3 Se alguma prática nunca foi adotada, confirmar o motivo. Entrevistados e gerência da empresa.
3. Análise de dados
Será utilizada a análise de conteúdo temática com os procedimentos de "caixa" para as categorias de limitadores já identificados na literatura, e o procedimento por "milhas" para as categorias encontradas durante a análise.
4. Avaliação do Resultado
Avaliar resultado da análise de dados junto com Scrum Masters e com gerente de desenvolvimento da área de TI.
5. Guia para elaboração do relatório
1 Resultados e Análise 2 Considerações Finais
APÊNDICE J – INSTRUMENTO DE PESQUISA
Programa de Pós-Graduação Stricto Sensu em Gestão do Conhecimento e da Tecnologia da Informação da Universidade Católica de Brasília
Pesquisadora: Elizabete Proença Strauhs
Projeto: Limitadores e Soluções de Contorno na Adoção de Práticas Ágeis do Método Scrum em Projetos de Desenvolvimento de Software
Instrumento: Entrevista, formato Focus Group
Informações sobre os entrevistados
Quantidade de Scrum Master: _____ Experiência média:_____
Dados da entrevista
Data: ___/___/_____ Início: ________ Fim:________
Componentes
Scrum Práticas Scrum
Sempre adotou
(s/n)
Por que não adotou ?
Equipe Scrum Composto pela equipe de desenvolvedores,
Product Owner e Scrum Master
Equipe de desenvolvedores
Autogerenciada
Todos são desenvolvedores sem criar especializações dentro do time
Composto por mais de 2 pessoas e menos de 7
Multidisciplinar
Focado nas tarefas do Sprint
Pouca rotatividade
Equipe motivada
Equipe no mesmo ambiente Treinamento técnico apropriado para equipe Membros da equipe com alta competência e
experiência
Bom relacionamento com o cliente
Product Owner
Desempenhado apenas por uma pessoa Único responsável pela gestão do Product
Backlog
Possui autoridade para decidir Suficientemente claro na explicação dos itens do
Product Backlog
Forte compromisso e presença no projeto
Scrum Master
Protege a equipe de interferências externas Guia da equipe nas práticas do scrum Orienta equipe para o desenvolvimento de
competências
Auxilia na remoção de obstáculos Garante o entendimento de todos em relação ao
significado de pronto
Componentes
Scrum Práticas Scrum
Sempre adotou
(s/n) Por que não adotou ?
Bom relacionamento com o cliente
Sprint Planning
Duração do evento compatível com duração do Sprint. Ex: Sprint de 4 semanas, então Sprint Planning de 8 horas
Equipe de desenvolvedores define as entregas com base na capacidade da equipe, na complexidade dos itens e na velocidade do Sprint anterior
Tarefa escolhida pelo membro da equipe proporciona aprendizado
Entrega primeiramente das funcionalidades mais importantes
Sprint
Duração máxima de 4 semanas Correto mecanismos de testes e integração
Modelagem mínima
Aprendizado
Daily Meeting
Duração de 15 minutos
Participantes permanecem em pé Presente apenas o time scrum Registro dos impedimentos Definição de adaptações e correções para atingir
objetivo do Sprint
Sprint Review
Duração do evento compatível com duração do Sprint. Ex: Sprint de 4 semanas, então Sprint Review de 4 horas
Entregas regulares de software Execução dos itens prontos Cumprimento regular do cronograma Todos interessados podem participar da Sprint
Review
Sprint Retrospective
Duração do evento compatível com duração do Sprint. Ex: Sprint de 4 semanas, então Sprint Review de 3 horas
Identificação do que funcionou bem Identificação do que precisa melhorar Definição de melhorias para o próximo Sprint Todos desenvolvedores e Scrum Master
participam
Aprendizado
Product Backlog
Lista ordenada de tudo que é necessário no produto
Origem única dos requisitos Atualizado pelo Product Owner Atualização não pode consumir mais que 10%
do esforço da equipe em um Sprint
Estimativa realizada somente pela equipe de desenvolvimento
Requisições no formato de estórias
Entendimento coletivo
Componentes
Scrum Práticas Scrum
Sempre adotou
(s/n) Por que não adotou ?
Sprint Backlog
Não pode receber inclusões de novos itens ou alterações nos itens escolhidos
Desenvolvido durante Sprint Planning Atualização diária em relação à evolução do
trabalho
Sprint Burndown Chart
Atualizado diariamente
Acompanhamento visual de progresso
Visível para todos
Product Burndown Chart
Atualizado ao final da Sprint Review Acompanhamento visual de progresso
Visível para todos
Questões abertas:
1 – A Infoglobo adota alguma prática além das encontradas na teoria? 2 – Em que situação, organizacional ou de projeto, o Scrum não é adotado? 3 – Que situação organizacional ou de projeto favorece a adoção do Scrum?
APÊNDICE K – DETALHAMENTO SCRUM MASTERS
Scrum Master Tempo de Experiencia Certificações
A 4 anos e meio Certified ScrumMaster (CSM) e Certified Scrum Product Owner (CSPO)
B 5 anos CSM e CSPO
C 5 anos CSM e CSPO
D 4 anos CSM e CSPO
APÊNDICE L – TRANSCRIÇÃO DAS ENTREVISTAS
Programa de Pós-Graduação Stricto Sensu em Gestão do Conhecimento e da Tecnologia da Informação da Universidade Católica de Brasília
Pesquisadora: Elizabete Proença Strauhs
Projeto: Limitadores e Soluções de Contorno na Adoção de Práticas Ágeis do Método Scrum em Projetos de Desenvolvimento de Software
Instrumento: Entrevista, formato Focus Group
Componentes
Scrum Categoria Práticas Scrum É critica? adotou (s/n) Sempre Por que não adotou ? adota ? Hoje
Equipe Scrum Composição Composto pela equipe de desenvolvedores,
Product Owner e Scrum Master S S
Equipe de desenvolvedores
Multifuncional Todos são desenvolvedores sem criar especializações dentro do time N N Existe especialização em função das tecnologias adotadas. Ex: Escenic, Asp, criação.
N Experiência Membros do time com alta competência e experiência N N Os projetos, normalmente possuem mais Plenos e Juniors do que seniors. N Autogerenciamento Autogerenciada S S Porém existem regras e procedimentos a serem cumpridos.
Ambiente de
Trabalho Equipe no mesmo ambiente S S Facilita a comunicação
Multidisciplinar Equipe multidisciplinar S N
No projeto do Clube do Assinante se iniciou com os profissionais de criação fora da célula e não funcionou. Hoje os projetos incluem esses profissionais dentro da célula.
S
Tamanho Composto por mais de 2 pessoas e menos de 7 S N
Já tiveram experiência com times com mais de 9 pessoas e a comunicação ficou prejudicada porque nem todos conseguiam falar na Daily e no planning.
S Cont.
Componentes
Scrum Categoria Práticas Scrum É critica?
Sempre
adotou (s/n) Por que não adotou ?
Hoje adota ?
Motivação Equipe motivada S N
Existe uma grande preocupação em manter a equipe motivada mas houve um momento em que mudanças organizacionais acabaram por desmotivar a equipe.
S
Foco Focado nas tarefas do Sprint S N
Algumas células adotam estórias reservadas para incidentes e imprevistos, outras negociam com PO que o objetivo do Sprint não será atingido. Porém só são realizadas tarefas relacionadas com o produto.
N
Rotatividade Pouca rotatividade S N Dificil adotar porque as pessoas pedem para sair ou são desligadas por mal desempenho ou problemas de relacionamento. N Capacitação Treinamento técnico apropriado para equipe S N Afeta a performance pois membros da célula têm que treinar os que não possuem
treinamento adequado.
N Relacionamento Bom relacionamento com o cliente S N Nem sempre acontece pois é dificil atender suas expectativas. Não adotam o método.
Demoram para decidir. N
Product Owner
Perfil de atuação Desempenhado apenas por uma pessoa S S
Poder de decisão Único responsável pela gestão do product
backlog S S
Embora em um projeto o profissional de Soluções execute tarefas operacionais do PO Poder de decisão Possui autoridade para decidir S N Precisa negociar. N
Habilidade Suficientemente claro na explicação dos itens do
product backlog S N
Na maior parte das vezes são, mas nem
sempre. N
Atitude Forte compromisso e presença no projeto S N As tarefas paralelas prejudicam a dedicação. N
Scrum Master
Proteção Protege a equipe de interferências externas S S
Orientação Guia da equipe nas práticas do scrum S S
Orientação Orienta equipe para o desenvolvimento de competências S S Com o apoio da Academia da Infoglobo e verba do projeto
Facilitador Auxilia na remoção de obstáculos S S
Relacionamento Bom relacionamento com o cliente S S
Componentes
Scrum Categoria Práticas Scrum É critica?
Sempre
adotou (s/n) Por que não adotou ?
Hoje adota ?
Sprint Planning
Duração Duração do evento compatível com duração do Sprint. Ex: Sprint de 4 semanas, então Sprint Planning de 8 horas
S S Se não for cumprido, sobra menos tempo para o desenvolvimento. Capacidade de
trabalho
Equipe de desenvolvedores define as entregas com base na capacidade da equipe, na complexidade dos itens e na velocidade do Sprint anterior
S S
Aprendizagem Tarefa escolhida pelo membro da equipe proporciona aprendizado S S Estratégia de entrega Entrega primeiramente das funcionalidades mais importantes S S Definido pelo PO.
Sprint
Modelagem Modelagem mínima N S Não tem modelagem de dados
Duração Duração máxima de 4 semanas S S
Aprendizagem Aprendizado S S Aumentar o conhecimento para novos desafios. Teste e Integração Correto mecanismos de testes e integração S N Data de entrega do produto arrojada. Atividade monótona. N
Daily Meeting
Duração Duração de 15 minutos S S No Globo já foi maior, mas corrigiu.
Estratégia de reunião Participantes permanecem em pé S S
Público Presente apenas o time scrum S S
Impedimentos Registro dos impedimentos S S
Mudança Definição de adaptações e correções para atingir objetivo do Sprint S S É o momento de chamar apoio de fora se for necessário.
Sprint Review
Homologação Execução dos itens prontos S S Nem sempre o processo é mostrado na íntegra ( O Globo).
Frequência de
entregas Entregas regulares de software S S
Sprint 1 e 2 com baixo nivel de entrega. Lançamento de produto (go live) é a entrega
em produção.
Público Todos interessados podem participar da Sprint
Review S S
Duração Duração do evento compatível com duração do Sprint. Ex: Sprint de 4 semanas, então Sprint
Review de 4 horas
S N 2hs. Critico porque PO participa. Projeto Extra, um dos primeiros utilizando Scrum, até do diretor de TI participava.
S Cont.
Componentes
Scrum Categoria Práticas Scrum É critica?
Sempre
adotou (s/n) Por que não adotou ?
Hoje adota ?
Cumprimento de
Prazos Cumprimento regular do cronograma S N Data de entrega é definida pelo PO. O escopo é negociado para caber no prazo. N
Sprint Retrospective
Duração Duração do evento compatível com duração do Sprint. Ex: Sprint de 4 semanas, então Sprint Retrospective de 3 horas
S S
1,5h em média. Grupo grande prejudica a comunicação. Duração pode ser maior se
time precisar.
Avaliação Identificação do que funcionou bem S S
Avaliação Identificação do que precisa melhorar S S
Mudança Definição de melhorias para o próximo Sprint S S As vezes não se consegue colocar em prática.
Público Todos desenvolvedores e Scrum Master participam S S
Aprendizagem Aprendizado S S Nem que seja só para o Scrum Master entender como tratar um problema
recorrente.
Product Backlog
Repositório Origem única dos requisitos S S
Capacidade de
trabalho Atualização não pode consumir mais que 10% do esforço da equipe em um Sprint S S
Requisitos Requisições no formato de estórias S S
Visão comum Entendimento coletivo S S
Documentação Correta quantidade de documentação S S
Poder de decisão Atualizado pelo Product Owner S N A atualização acontece porque existe pressão do Scrum Master e PO de Soluções. S Requisitos Lista ordenada de tudo que é necessário no produto S N Backlog com desejos mas sem definição (épicos e temas) sem valor para o negócio.
PO sem maturidade. N
Estimativa de esforço Estimativa realizada somente pela equipe de desenvolvimento S N PO Técnico do Globo estima. N
Sprint Backlog
Monitoração Atualização diária em relação à evolução do trabalho S S
Componentes
Scrum Categoria Práticas Scrum É critica?
Sempre
adotou (s/n) Por que não adotou ?
Hoje adota ?
Atualização Desenvolvido durante Sprint Planning S N
Pre-planning é realizado no meio do Sprint, estórias são priorizada e é identificado a necessidade de ajuda externa. Participam o PO, o Scrum Master e um desenvolvedor.
N
Sprint Burndown Chart
Atualização Atualizado diariamente S S
Monitoração Acompanhamento visual de progresso S S
Visibilidade Visível para todos S S Na sala ou no site
Product Burndown Chart
Atualização Atualizado ao final da Sprint Review S S
Monitoração Acompanhamento visual de progresso S S
Visibilidade Visível para todos S S Indicadores de progresso no site
Questões abertas:
1 - A Infoglobo adota alguma prática além das encontradas na teoria?
Strategic Planning: Primeira reunião do projeto onde são elaborados o Roadmap do produto (roteiro previsto de grandes entregas), o Product Backlog, o conceito de pronto e o Burndown Product Backlog.
Retrospectiva Técnica: Reunião criada para discussão da qualidade técnica do que foi entregue. Um analista de QA analisa com os desenvolvedores o que foi bom e o que precisa melhorar.
Pre-planning: Reunião realizada antes do Sprint Planning onde o ScrumMaster, o PO e um desenvolvedor elaboram uma versão do Sprint Backlog sem envolver toda a equipe. Todos serão envolvidos no Sprint Planning.
Product Owner Técnico: analista da área de Soluções que auxilia o PO na elaboração e manutenção do Product Backlog.
2 – Em que situação, organizacional ou de projeto, o Scrum não é adotado?
- A internalização do DBM foi Scrum, mas não deveria ter sido. Não havia como fazer entregas a cada 15 dias. Os processos eram demorados. - Na implantação de pacotes não existe uma equipe de desenvolvedores em tempo integral e isso inviabiliza a utilização do Scrum.
- Quando existe uma data de entrega pré-definida, como por exemplo, o inicio do recolhimento de uma obrigação legal. Nesse caso, não da para garantir que o produto ficará totalmente pronto, porque as tarefas não são definidas em detalhes para se saber o tempo necessário de desenvolvimento.
- Quando o orçamento do projeto envolve um valor muito grande de dinheiro, o cliente quer saber desde o início, como o dinheiro será gasto. 3 – Que situação organizacional ou de projeto favorece a adoção do Scrum?
APÊNDICE M – LIMITADORES E SOLUÇÕES DE CONTORNO REVISADOS Limitadores na adoção de práticas ágeis Situação do limitador na
Infoglobo Fonte do limitador Práticas do Scrum afetadas Solução de contorno
Fonte da solução de contorno
Tecnologia
Inadequada Confirmado Nerur, Mahapatra e Mangalaraj (2005). Correto mecanismos de testes e integração.
Aquisição de ferramentas específicas para testes e integração.
Infoglobo Rotatividade dos
Integrantes Confirmado Dyba e Dingsoyr (2008).
Equipes de desenvolvedores com pouca
rotatividade. Não encontrada
Cultura Organizacional Confirmado Soares (2011); Nerur, Mahapatra e Mangalaraj (2005); Tolfo e Wazlawick (2008).
Equipe de desenvolvedores autogerenciada; motivada; focada; bem relacionada com o cliente; Product Owner possui autoridade para decidir; forte compromisso e presença no projeto; Duração da Sprint Review e Sprint Backlog sem mudanças.
Estórias para manutenções corretivas e Retrospectiva Técnica.
Infoglobo
Indisponibilidade
do Cliente Confirmado Dyba e Dingsoyr (2008).
Product Owner com forte compromisso e presença no projeto; estimativa de esforço do Product Backlog; e atualização do Product Backlog.
Criação do papel Product Owner Técnico; adoção do Pre-Planning.
Infoglobo
Equipe Distribuída Ausente
Paasivaara, Durasiewicz e Lassenius (2008); Ganis, Surdek e Woodward (2009); Pries-Heje e Pries-Heje (2011).
Equipe de desenvolvedores no mesmo ambiente.
Teleconferência,
videoconferência, e-mail, mensagem instantânea e Wiki.
Paasivaara, Durasiewicz e Lassenius (2008); Ganis, Surdek E Woodward (2009); Pries-Heje e Pries- Heje (2011) Criticidade do
Projeto Ausente Hansson et al. (2006); Cockburn (2000). Modelagem mínima; correta quantidade de documentação. Não encontrada Manutenção
Limitadores na adoção de práticas ágeis
Situação do limitador na
Infoglobo Fonte do limitador Práticas do Scrum afetadas Solução de contorno
Fonte da solução de contorno
Equipes Grandes Confirmado
Dyba e Dingsoyr (2008); Cockburn (2000); Boehm (2002).
Equipes de desenvolvedores composta por mais de duas pessoas e menos de sete; Duração dos eventos Daily Meeting, Sprint Planning, Sprint Review e Sprint
Retrospective. Scrum-of-scrums Paasivaara, Durasiewicz e Lassenius (2008) Falta de
competências Descoberto Infoglobo Equipe de desenvolvedores multidisciplinar Não encontrada Restrição