Por que os projetos falham?
Em um documento (mais precisamente um relatório) formulado por grupo chamado Stanches Group mostra uma realidade preocupante e que não mudou em nada (apenas piorou) nos ultimos anos:
Porcentagem de projetos concluidos, que tiveram mudanças e os que falharam.
Como podemos ver nos dados acima, tivemos:
32% Sucesso (no prazo, dentro do orçamento e com escopo completo).
44% Mudaram (atrasaram, estourou o orçamento, e/ou reduziram escopo).
24% Falharam (cancelados ou nunca usados)
Segundo o Gartner, 70% dos projetos falham no cumprimento de cronograma, custos e metas de qualidade e 50% são executados acima do orçamento. Já o CHAOS divulgou que 50% dos projetos de TI são cancelados, 82% são entregues com atraso e as pesquisas da KPMG destacam que menos de 40% desses projetos alcançaram os objetivos de negócios um ano depois.
O que estamos fazendo de errado?
Na minha opinião um dos principais erros que todos cometem é usar um modelo de gerenciamento desenvolvido a meados do século XVIII.
Durante aquela época era muito difícil encontrar mão de obra capacitada, então quem tinha certo nível de conhecimento era colocado como chefe para ensinar aos menos capacitados como executar uma parte do processo, e os chefes ficavam verificando se a execução foi feita corretamente.
Hoje em dia muitos colaboradores têm mais conhecimentos técnicos que seus respectivos chefes, deixando o modelo mencionado acima defasado.
Outro erro é uma herança da engenharia civil, vamos à outra historinha:
Na engenharia civil as coisas são pouco complexas, por exemplo:
Vamos projetar um prédio:
Vai ter 10 andares, cada andar com quatro apartamentos, porcelana da marca fulana ou similar, cor branca, etc.
Alguém já viu um cliente do engenheiro civil chegar quando está construindo o oitavo andar e falar:
Não era isso que eu queria, mudou as minhas necessidades, vai ter que ser dois quartos por andar! E agora?
Muitas vezes o plano pode nos deixar cegos
Ou seja, a engenharia usa o planning driver manager e funciona perfeitamente! Se tiver mudanças será a troca da porcelana da marca fulana para a marca ciclano.
E agora eu pergunto: isso acontece no planejamento de software?
Hora de mudar de planning driver manager para value driver manager!
Gerenciar um projeto é um empreendimento, por sua natureza, cheio de incertezas
e mudanças então por que continuamos apenas focado no plano.
?Entregar algo de valor para o cliente é mais importante que seguir o plano.?
?O plano não paga seu salário, quem paga e seu cliente.?
?O que adianta cumprir o escopo do seu planejamento e não cumprir a necessidade de seu cliente.?
O que torna a forma atual de gerenciamento de projetos questionável?
1- Requisitos não são completamente compreendidos no inicio do projeto.
2- Usuários só sabem exatamente o que querem após ver uma versão inicial do software.
3- Requisitos mudam durante o processo de desenvolvimento.
4- Novas ferramentas e tecnologias tornam a estratégia de desenvolvimento imprevisível.
Se você não conhece o problema completamente para poder especificar como acontece na engenharia civil vou ensinar uma técnica que funciona:
- Calculo Hipotético Utilizando Técnicas Estatísticas. (CHUTE)
O que é Scrum?
Uma definição simples de Scrum: consiste em um conjunto de papéis e práticas simples orientados para o processo de gerenciamento de projetos, especialmente de software.
Uma definição que eu gosto muito é a seguinte: Scrum é um processo iterativo e incremental para desenvolvimento de produtos e gerenciamento de projetos.
Alguns autores dizem que o Scrum seria um framework para gerenciamento de projetos, outros insistem em que Scrum é uma metodologia então nada melhor que uma citação do próprio criador:
?Ken Schwaber disse; Scrum não é uma metodologia, é um framework. O que significa que Scrum não vai te dizer exatamente o que fazer?.
Como escolher uma metodologia/framework para usar na minha empresa?
Para esta escolha observe a complexidade dos seus processos.
Pilares do Scrum
Transparência
Inspeção
Adaptação
Scrum
Transparência:
Aspectos que afetam os resultados do projeto devem ser visíveis para os que gerenciam estes resultados.
O que é visto deve ser compreendido: se quem inspeciona o processo acredita que está pronto, isso deve corresponder à definição de pronto utilizada.
Inspeção:
Os vários aspectos do processo devem ser inspecionados com uma frequência suficiente para que a variâncias inaceitáveis no processo possam ser detectadas
Adaptação:
Se a inspeção determinar que um ou mais aspectos do processo esta fora dos limites aceitáveis e que o produto que resultara será inaceitáveis, ele deve ajustar o processo ou o material sendo construído, este ajuste deve ser feito o mais rápido possível para evitar outros desvios.
Manifesto para o desenvolvimento ágil de software.
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:
-
Indivíduos e interação entre eles mais que processos e ferramentas -
Software em funcionamento mais que documentação abrangente -
Colaboração com o cliente mais que negociação de contratos -
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Fonte: Manifesto Ágil.
O Scrum é composto pelo seguinte:
Responsabilidades dos papéis definidas pelo Scrum.
Responsabilidades do Scrum Master:
· Permitir que o time seja auto gerenciável.
· Garantir que os caminhos para a comunicação do time estejam abertos permanentemente.
· Garantir e auxiliar o time a seguir corretamente as práticas do Scrum.
· Remover qualquer impedimento que o time encontre.
· Proteger o time de interferências externas para garantir que sua produtividade não seja afetada.
· Facilitar as reuniões do projeto (Planning Meeting, Daily Meeting, Review e Retrospectiva).
Responsabilidades do Product Owner:
· Definir visão do produto.
· Gerenciar retorno sobre investimento (ROI).
· Apresentar ao time os requisitos necessários para entrega do produto.
· Priorizar cada requisito de acordo com seu valor para o negocio/cliente.
· Gerenciar a entrada de novos requisitos e sua priorização.
· Planejar entregas.
· Atuar como facilitador quando mais de um cliente estiver envolvido no projeto.
· Colaborar com o time.
Responsabilidades do Time:
· Auto-organizáveis.
· Multidisciplinares.
· Possuem de 5 a 9 membros.
· Comprometidos com o trabalho.
· Focado em metas.
· Responsável por fazer o necessário para atingir essas metas.
· Comunicativos.
· Organizados em um espaço físico apropriado para o trabalho.
· Responsável para a resolução de conflitos.
A visão.
Projetos sem visão é suicídio.
Procurando na internet por imagem que mostram o fluxo do Scrum vejo que a maioria começa pelo product backlog, porem todo projeto Scrum deve iniciar pela visão.
Lembre-se:
· A visão deve ter no mínimo o tamanho de um release.
· Qualquer priorização sem visão é apenas ideia do P.O.
· Visão fixa, product backlog variável.
A visão é um parâmetro que representa o que deve ser satisfeito no final do projeto.
Para a definição da visão o Product Owner colhe informações junto aos usuários finais, clientes, time, executivos, stakeholders, envolvidos no projeto, etc.
O plano mínimo necessário para iniciar um projeto Scrum consiste de um documento de visão e um product backlog. A visão descreve porque o projeto esta sendo implementado e o que se deseja no final.
Uma visão efetiva deve responder os seguintes questionamentos:
· Quem irá comprar o produto?
· Quais os clientes que o produto foca em atender?
· Quais são os usuários alvos?
· Quem são os usuários alvos?
· Quais necessidades do cliente e dos usuários o produto pretende satisfazer?
· Quais atributos o produto deve possuir para satisfazer as necessidades do usuário?
· Quais os atributos do produto garantirão o sucesso do mesmo?
· Quais são os diferenciais do produto em vista dos concorrentes?
O tamanho das Sprints.
O tamanho recomendado pelo Scrum é de sprints com duração de 2 a 4 semanas, porem não devemos nos deixar cegar seguindo a risca a ?receita? do Scrum e ferindo um dos seus princípios de Agilidade:
A Adaptação.
Leve em consideração as seguintes situações para escolher o tamanho de sua Sprint:
· Mudanças constantes no topo do Product backlog e equipes com síndrome de estudante devem preferentemente trabalhar com sprints curtos.
· Quando existe uma dificuldade em entregar valores aos interessados devem ser usado sprints curtos.
· Times e/ou clientes cansados de sprints curtos devem aumentar a duração das mesmas.
· O cliente não sabe o que quer? Sprints curtos.
· Sprints muito curto podem ser estressantes.
A síndrome de Estudante:
É a atitude que muitos estudantes têm de começar a se dedicar inteiramente a uma tarefa logo antes do prazo final.
Dica:
Para saber se o time tem síndrome de estudante observe os dois primeiros e os dois últimos dias de uma sprints, caso o primeiro dia for tranquilo e o ultimo um caos, sua equipe sofre deste problema.
Para descobrir se você tem síndrome de estudante pense em quantas vezes usa a opção soneca do celular logo pela manha.
Lembre-se:
· O objetivo da Sprint é definido pelo tamanho da mesma, e não o objetivo que define o tamanho dela.
· Após definir o tamanho da Sprint o mantenha por um largo tempo.
Definindo o estado ?Done? (Pronto).
Definição de Done é uma premissa que visa garantir o que está sendo entregue REALMENTE atende as necessidades do projeto, do cliente ou do mercado, levando em consideração as limitações da tecnologia.
Exemplo:
- Implementações com boas práticas de engenharia (ex. testes automatizados).
- Implantações no ambiente de produção.
- Com documentação técnica e de usuário.
Sobre o Done.
· Configurável de estória para estória, projeto para projeto de empresa para empresa.
· É um compromisso entre o time e o product owner referente aos itens do product backlog.
· A qualidade não é negociável na composição do estado Done.
· O pronto deve ser definido apenas para coisas imprescindíveis.
Definindo o estado ?Ready? (Preparado).
Uma definição que gosto muito é a Ready (esta não descrita no Scrum) e a ready, que nada mais é que um compromisso do Product Owner com o time sobre os requisitos dos itens do product backlog.
Exemplos:
· Para quem é importante a user history.
· O que deve ser atendido na user history.
· Porque da user history estar no backlog.
· Protótipo de tela.
Estes são exemplos para que entendam a definição de ?ready? que nada mais é que uma especificação mínima necessária para que o time possa desenvolver seus trabalhos.
O Product Backlog.
O Product Backlog é uma lista contendo todas as funcionalidades desejadas para que a visão do produto seja alcançada.
Esta lista é definida pelo Product Owner e não precisa estar completa no início do projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.
Com a lista de itens do product backlog feita, o time prioriza e determinam quais destes itens poderão ser concluídos durante a execução da Sprint.
Após a priorização tais itens são transferidos do Product Backlog para o Sprint backlog. Ao fazer isso, a equipe quebra cada item da Sprint Backlog em uma ou mais tarefas, isso ajuda a dividir o trabalho entre os membros da equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamente relacionadas às funcionalidades solicitadas.
User Stories (procedente do XP).
É uma técnica para representar requisitos em um product backlog. Ela descreve uma funcionalidade que deve fornecer valor para o usuário ou cliente de um projeto de software.
Story ? Writing Workshop.
São reuniões em que desenvolvedores, usuários, clientes, stakeholders, Product Owner e qualquer pessoa que deseja contribuir e/ou estejam envolvidas no projeto com o objetivo de descobrir estórias.
O que é necessário para fazer um Story ? Writing Workshop?
· Folha de rascunhos.
· Post-it.
· Um quadro branco
· Canetas para o quadro (varias cores).
· Canetas e lápis.
· E o principal, as pessoas.
Dicas:
· Focar na quantidade, ao invés de qualidade (estamos em busca de ideias).
· Não perca tempo com detalhes.
· Não julgue as idéias.
· Não se preocupe com as prioridades.
A estrutura de User Story pode ser:
UM [ator]
PODE [fazer algo]
ou o modelo tradicional
COMO [ATOR],
QUERO/DEVO/POSSO[FAZER]
ALGO/PARA[GERAR VALOR]
Cuidado:
· Usuário não deve ser mencionado como perfil.
· Detalhes, preferentemente os técnicos não entram nas user stories.
· Pense sempre pela ótica do usuário.
Lembre-se:
· Se quiser requisitos bem definidos não use user stories.
· User stories são ótimas para comunicar uma idéia.
· Responda essas perguntas tendo em mente a visão do produto.