Gerenciamento de Projetos de Software

Transcrição

1 Gerenciamento de Projetos de Software Framework Ágil, Scrum Prof. Júlio Cesar da Silva Msc.

2 Ementa & Atividades Aula 1: Fundamentos do Gerenciamento de Projetos (p. 4) 30/abr Aula 2: Métodos Ágeis (p.21) 30/abr Caso: Airbus A3XX Aula 3: Lean, KanBan e extreme Programming (p.35) 07/mai Aula 4: Test Driven Development - TDD e Scrum (p.47), 07/mai Caso: Turner Construction Co. Aula 5: Framework Scrum (p.64) 21/mai Aula 6: Reuniões Reuniões Retrospectivas (p.76) 21/mai Pedras no Caminho ( Veja edição 2358 Pg. 84) Aula 7: Planejamento Orientado a Valor (p. 86) 04/jun. As ameaças à Copa (Veja edição 2364 Pg. 50)

3

4

5

6

7 Controle o tempo e o historico

8 Controle bem o Taskboard

9 Quadro de Retrospectiva

10 Artefato - Taskboard

11 Artefato - Taskboard

12 Scrum x Estrategia

13 Cerimônias - Reuniões

14 Cerimônias - Sprints & Release

15 Trabalhando com histórias As histórias utilizam os conceitos conhecidos com INVEST: Independente: A histórias são mais fáceis de trabalhar quando são independentes, isto é, não dependem de outras histórias para acontecerem. Negociável: A história não é um contrato com definição de funcionalidades, ela é negociável para melhor atender as necessidades do negócio.

16 Trabalhando com histórias As histórias utilizam os conceitos conhecidos com INVEST: Valiosa para usuários e clientes: A história precisa estar associada a um valor para o usuário ou clientes, sem isso, não existe razão para ela existir. Estimável: A história precisa ser estimável, precisamos dimensionar o esforço para implementá-la.

17 Trabalhando com histórias As histórias utilizam os conceitos conhecidos com INVEST: Small (pequena): Histórias representam situações simples. Testável: Toda história precisa ser testável. O cliente deve identificar quais seriam as condições de testes da história escrita. As condições de teste definidas pelo cliente ajudam o time a entender se a meta.

18 Trabalhando com histórias Uma boa história deve responder: QUEM? COMO? POR QUÊ? Como um PERFIL eu posso /gostaria/devo FUNÇÃO para VALOR AO NEGÓCIO Ou POR QUÊ? QUEM? COMO? Com o propósito de VALOR AO NEGÓCIO, como um PERFIL, eu posso/gostaria/devo FUNÇÃO

19 Trabalhando com histórias uma história para criar uma panela específica: Como um Cozinheiro (Usuário); Quero panela de inox, com fundo oval e antiaderente (Funcionalidade); Para cozinhar um salmão (Valor de Negócio).

20 Trabalhando com histórias Outro exemplo: Como comprador que não tem cartão de crédito; Quero que o sistema suporte pagamento em boleto bancário.

21 Cerimônias Historias, PB e Sprint

22 Desafios: Historias

23 Cerimônias - Sprints & Backlog

24 Planning Poker

25 Planning Poker O Planning Poker é uma prática de estimativa de tarefas bem simples e inclusive divertida, mas muito eficiente. Muito utilizada no SCRUM, esta prática funciona da seguinte forma: Ao invés de estimar horas exatas estima-se em pontos;

26 Planning Poker Os pontos utilizados no jogo são parecidos com a sequencia do Fibonacci, ou seja, o próximo número é a soma dos dois números anteriores: 0, 1, 2, 3, 5, Para simplificar é muito utilizada esta sequencia: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100.

27 Planning Poker O time do projeto se reúne com o responsável pelas regras de negócio e cada um recebe as cartas do Planning Poker. Mas que isso não seja um impedimento! Se não tem cartas, improvise com os dedos; As funcionalidades/tarefas são apresentadas, uma a uma e as dúvidas do time são sanadas;

28 Planning Poker Atribui-se o peso 2 para a menor tarefa, para que esta sirva de comparativo para as demais (ex: uma laranja é maior que um morango? E que uma manga? E assim as tarefas são comparadas tendo essa de peso 2 como parâmetro); Inicia-se com uma atividade (pode ser por ordem de prioridade), e todos jogam a carta ao mesmo tempo;

29 Planning Poker A ideia é discutir a variação de estimativa; porque Fulano estimou X e Ciclano estimou Y A discussão que é gerada em torno das estimativas e diferentes concepções é extremamente importante!

30 Planning Poker Porque números tão distante entre si? Porque quanto maior uma tarefa, mais difícil de prever com precisão quantos pontos a mesma terá (e muito menos horas). Isso significa que uma estimativa de 13 pode estar entre 8 e 21

31 Planning Poker Por isso que quanto menor as tarefas, melhor para serem estimadas e a variação de pontos é melhor administrada. Sempre procure chegar no menor nível de granularidade, evitando tarefas muito grandes;

32 Desafios: estimativas

33 Backlog do Produto Priorização de backlog A p r i o r i z a ç ã o d o B a c k l o g é d e responsabilidade do Product Owner e está diretamente associada à melhoria do retorno sob investimento (ROI), pois quanto antes as funcionalidades mais importantes forem entregues, mais cedo gerarão retorno para o negócio.

34 Backlog do Produto Em geral, a priorização do backlog do produto segue uma sequência lógica, conforme apresentada: Valor: Qual a importância deste item para que o produto seja lançado? Quanto mais importante, mais no topo ele deverá estar. Riscos: Qual o nosso grau de conhecimento sobre o item? Quais as incertezas? Identificamos os riscos associados?

35 Backlog do Produto Em geral, quanto menos conhecemos ou de maior riscos devem ser priorizados. Quanto mais cedo falharmos, mais cedo corrigimos e obtemos sucesso. Releasability ( C a p a c i d a d e p a r a lançamento):itens que permitam lançar mais rapidamente o produto devem ser priorizados (Minimum Marketable Feature - MMF).

36 Backlog do Produto "Dependência : Temas e "dependências" devem ser considerados na priorização.

37 Backlog do Produto

38 Negociações do Sprint

39 Negociações do Sprint

40 Negociações do Sprint

41 Burndown O gráfico Burndown é a principal ferramenta de gerenciamento do processo de desenvolvimento de software. Ele representa o trabalho restante sobre tempo, ou seja, permite visualizar o progresso e/ou a evolução do trabalho executado pela a equipe e a quantidade trabalho x tempo (pontos) que ainda faltam para completar a Sprint.

42 Burndown Atualização do Burndown deve ser diária, isto facilita a tomada de decisão, pois, poderemos decidir em melhorar a produtividade da equipe e/ou para mitigar risco da Sprint.

43 Burndown Através da leitura do Burndown poderemos decidir, que devemos adicionar novas tarefas na Sprint (velocidade da equipe está acima do planejado, melhorando sua produtividade) ou retirar tarefas (a velocidade da equipe está abaixo do planejado, caso não seja feita uma redução de tarefas a meta da Sprint estará comprometida).

44 Artefato: Burndown

45 Artefato: Burndown

46 Olhos atentos ao Burndown

47 Alerta: Impedimento

48 Desafio: O Cliente

49 Refletindo

50 Desafios da Implantação Nenhum aprendizado organizacional Isso acontece quando o feedback das restropectivas é perdido e não incorporado na melhoria do processo. Idealmente, todo feedback deveria resultar em itens de ação. Estes itens de ação deveriam ser escolhidos pelo time se eles impactarem o projeto e pelo scrum master se eles impactarem a organização.

51 Desafios da Implantação Falta de um ambiente de confiança Freqüentemente, tal ambiente resulta em pessoas escondendo seus erros, não compartilhando suas opiniões e atrasando o processo de tomada de decisão. A solução é criar um ambiente que prospera em cima de feedback positivo e transparência.

52 Desafios da Implantação Fazer agile estritamente e apenas à risca - Scrum é um processo simples com um comportamento complexo. O que funciona para uma organização pode não funcionar para outra. Seguir apenas à risca pode não ajudar em todos os cenários. Scrum precisa ser customizado para as necessidades organizacionais.

53 Planejamento Orientado a Valor Em projetos ágeis, o planejamento de versões e a priorização do que será desenvolvido (backlog) é estratégia para melhorar o ROI (Return Over Investiment). É necessário ter uma boa visão de produto.

54 Planejamento Orientado a Valor Veja que não é interessante antecipar todo o planejamento já que, como temos muitas incertezas, teremos grandes probabilidades de mudanças caso a antecipação seja feita. Ao invés disso, fazemos um planejamento de alto nível para identificar e planejar as releases, e posteriormente planejamos mais detalhadamente cada interação.

55 Planejamento Orientado a Valor Visão é uma clara imagem que gera uma atração emocional entre pessoas e produto. Por exemplo: quando se fala, a visão de quem escuta deve ser capaz de imaginar como será o produto.

56 Planejamento Orientado a Valor A visão deve responder às seguintes perguntas: Quem irá comprar este produto? Quem é o cliente-alvo? Quem irá usar o produto? Quem são os usuários-alvo?

57 Planejamento Orientado a Valor Quais problemas do cliente (ou usuários) o produto pretende resolver? Qual valor o produto adicionará? Quais atributos o produto deve possuir para resolver estes problemas e quais garantirão o sucesso do produto?

58 Planejamento Orientado a Valor

59 Estimativas de Produtividade Um dos maiores desafios dos profissionais da área de desenvolvimento de software é estimar o esforço para a criação de novas funcionalidades, tarefas ou histórias. Sabemos que estimar é fundamental, porém, grande parte do esforço empreendido em estimar com precisão acaba sendo perdida.

60 Estimativas de Produtividade A comunidade adepta aos métodos e frameworks ágeis geralmente procura utilizar estimativas que levam em consideração apenas o esforço para a realização de determinada tarefa (histórias), onde todos os envolvidos no desenvolvimento medem as diversas tarefas e assim definem estimativas comparativas (com margens de erro) entre todo o trabalho que precisa ser realizado.

61 Estimativas de Produtividade O Planning Poker funciona porque utiliza opinião de diversos especialistas (que irão realmente realizar a tarefa) e promove o diálogo que permite maior acuracidade das estimativas, principalmente em itens com maior incerteza. Além de ser uma técnica de estimar considerando a experiência de todos da equipe, proporciona um conhecimento do negócio mais homogêneo e é mais atraente (e divertida) que as demais técnicas.

62 Estimativas de Produtividade Técnica PMG Outra forma de estimativa muito utilizada no mundo ágil é a técnica PMG, uma analogia as medidas de roupas, onde cada item é classificado como P para pequeno, M para médio e G para grande, de acordo com a percepção de esforço do time para entregá-la.

63 Estimativas de Produtividade Técnica PMG Os pontos definidos em cada história devem envolver todo o esforço para entregá-la pronta para funcionar no ambiente real. Significa que devemos considerar a complexidade devido ao desconhecimento ou incertezas, o esforço do trabalho e os riscos associados em nossas estimativas.

64 Inteligência emocional Inteligência emocional é a nossa capacidade de identificar, avaliar e influenciar nossas próprias emoções, de outros indivíduos e de grupos. No Slide a seguir identificamos os diferentes aspectos da inteligência emocional. Veja:

65 Inteligência emocional Autogerenciamento Autocontrole Consciência; Adaptabilidade; Direcionamento e motivação.

66 Inteligência emocional Habilidades Sociais Autocontrole; Liderança inspiradora; Desenvolvimento dos demais; Trabalho em equipe e colaboração.

67 Inteligência emocional Autoconhecimento; Autoconfiança; Autoconhecimento emocional; Precisa autoavaliação.

68 Inteligência emocional Consciência Social Empatia; Consciência organizacional; Compreender o ambiente.

69 Comunicação Segundo o Project Management Institute (PMI) existe uma correlação direta entre a capacidade de comunicação e o desempenho do projeto, isto é, um bom gerenciamento de comunicações é fator determinante de sucesso ou fracasso em projetos. Scrum: sente o time junto!!!!!!

70 Comunicação Um conceito básico é que as comunicações devem ser eficientes (fornecendo apenas as informações necessárias) e eficazes (informações nos formatos certos e no momento certo): Quem deve receber quais informações Quais são as reais necessidades de informação?

71 Comunicação Qual informação é necessária, de que tipo Em que formato e meio deve ser transmitida a informação? Com que frequência? Qual é o fluxo de informações? Scrum: Reuniões Diarias como foco!

72 Comunicação Para facilitar a comunicação cara a cara e o compartilhamento de conhecimentos, é recomendado que os times sejam de tamanho reduzido, geralmente com até 12 membros ou menos (Lembre-se de que o aumento da complexidade da comunicação é diretamente proporcional ao número de pessoas envolvidas). Quando os projetos são maiores, o recomendado é trabalhar com diversos times, utilizando técnicas como o Scrum sob Scrum.

73 Comunicação

74 Cumulative Flow Diagram (CFD) O CFD é uma ótima ferramenta para monitoramento do trabalho de desenvolvimento. Com ele podemos acompanhar o trabalho que falta, o trabalho em progresso (WIP) e o trabalho pronto.

75 Cumulative Flow Diagram (CFD) Seu funcionamento é simples, no eixo vertical temos o trabalho estimado em pontos, horas ou outra métrica predefinida pelo time, no eixo horizontal, o tempo (em dias, semanas ou sprints). Uma grande diferença entre o CFD e o Burndown Chart é que podemos visualizar o trabalho em progresso.

76 Cumulative Flow Diagram (CFD) Veja na imagem que a área em cor amarela apresenta o trabalho que está pendente, isto é, trabalho não iniciado, a área laranja representa o trabalho em progresso e a azul o trabalho pronto.

77 Cumulative Flow Diagram (CFD)

78 Cumulative Flow Diagram (CFD) Quando o gráfico de seu time apresenta grande distância do pronto para o não iniciado significa que seu time está com muitos trabalhos em progresso, é possível (e aconselhável) determinar um limitador para atividades em andamento, por exemplo, só 2 histórias em paralelo, para evitar o acúmulo do trabalho em andamento e o atraso nas entregas.

79 Cumulative Flow Diagram (CFD)

80 Dúvidas? Obrigado!