Gerência, Planejamento e XP

Apresentação em tema: "Gerência, Planejamento e XP"— Transcrição da apresentação:

1 Gerência, Planejamento e XP
Parte 1 Nossa apresentação pretende relatar como ocorre planejamento e gerenciamento de projetos num projeto XP na empresa júnior do centro de informática, o CITi.

2 Para que planejar? [BECK01] para garantir que estamos sempre fazendo a coisa mais importante que se tem a fazer Para coordenar a interação das pessoas Para responder rapidamente a mudanças

3 Planejamento no XP Baseia-se na separação dos papéis
Cliente decide escopo e prioridade Desenvolvedor estima o tempo e declara velocity Baseia-se no Yesterday’s Weather

4 Overview Releases com poucos meses,
Divididas em iterações de uma semana divididas em tarefas de poucos dias O planejamento irá alocar stories às releases e iterações

5 Stories Representam características do sistema
Funcionalidades ou restrições Ora de alto nível, ora de baixo nível Escritas em cartões com poucas palavras e pelo cliente “Estórias são promessas de conversa”

6 Modelo de estória

7 Modelo de estória

8 Concepção do projeto Estórias em altíssimo nível
Estimativas aproximadas de tempo e custo Restrições fornecidas por um conhecedor do negócio

9 Planejando a Release O cliente: Os Programadores
Define as estórias da iteração Define o valor das estórias (prioridade) Os Programadores Estimam a duração das estórias Alertam sobre riscos técnicos Declaram o velocity

10 Planejando a iteração Revisão das estórias
Lista de tarefas para cada estória Estimativa das tarefas Revisão de Prioridade Escolha das estórias a serem implementadas Especificação dos Testes de Aceitação

11 Planning Game [WAKE02] A fase de Exploração tem como meta definir o que o sistema irá fazer tão bem que se possa estimar a partir da definição. Para isso, O Cliente deve escrever estórias, que conterão descrições de requisitos do sistema; O Programador deve estimar as histórias. Caso a estimativa de uma história exceda a duração de uma iteração, o cliente deve quebrar a estória de forma que ela possa ser melhor estimada e caber numa iteração. Caso os programadores não saibam tenham capacidade de estimar, devem realizar “spike solutions”, implementar um pouco do que deve ser realizado, para se ter uma idéia e se familiarizar com a tecnologia envolvida na solução o suficiente para que se possa fazer uma boa estimativa. Ao final da fase de exploração haverão estórias e custos/estimativas associados a elas. A fase de planejamento consiste de elaborar um plano de ação para a release que se inicia. Para isso, as estórias estimadas devem ser ordenadas pelo cliente de acordo com a necessidade do negócio. Classificações como essencial, importante e desejável são aceitas. Depois os programadores declaram qual sua velocidade: inicialmente pode-se considerar 1/3 das horas ideais um programador como sua velocidade. No nosso projeto, a equipe contava com 5 desenvolvedores, trabalhando 12 horas semanais. Portanto, nossa velocidade era 4 horas semanais por programador. Depois da velocidade declarada, o escopo da iteração é definido, pela ordem definida pelo cliente e pela capacidade dos programadores. Sabendo que a iteração duraria 1 semana, teríamos 20 horas ideais por iteração. A partir das estimativas feitas para cada tarefa pudemos preencher todas as iterações com estórias. Semanalmente, o jogo era refeito na reunião de iteração, o cliente voltava a falar sobre cada estória, propunha mudanças (novas estórias), e repriorizava o trabalho. É importante dizer que (passa o slide)

12 Em XP o gerente... Não define prioridades; o cliente faz isto.
[WAKE02] Não define prioridades; o cliente faz isto. Não delega tarefas; os programadores fazem isto; Não estima a duração das tarefas; programadores fazem isto. Não define cronogramas; cliente e programadores negociam isto. É importante dizer que o gerente Não define prioridades, o cliente faz isto. Não delega tarefas, os programadores fazem isto; Não estima a duração das tarefas, programadores fazem isto. Não define cronogramas; cliente e programadores negociam isto.

13 O que faz o gerente então?
[WAKE02] Media interações externas Forma a equipe Obtém recursos: Reuniões, papel e pizza Gerencia o time Gerencia os problemas do time Resta ao gerente então: Mediar interações externas Formar a equipe Obter recursos: é papel do gerente marcar e garantir que tudo necessário para a reunião esteja pronto; obter o material de escritório, mesmo que delegue a tarefa a alguém; e pagar a pizza, no XP “o gerente sempre paga a pizza”; o gerente deve garantir celebração quando merecida. Gerenciar o time Gerenciar os problemas do time

14 Sit together Open workspace Fluxo de comunicação Privacidade
Pair programming Integração Área Privativa [WAKE02]

15 Contrato de escopo variável
[XPERS04] “É simplesmente um contrato de prestação de serviços, pago por desenvolvedor.hora” Klaus Wuestefeld

16 O que foi visto

17 Referências [PMBK00] PMBOK 2000
[BECK00] Beck, Kent Extreme Programming Explained. Boston: Addison-Wesley. [BECK01] Beck, Kent and Martin Fawler Planning Extreme Programming. Boston: Addison-Wesley. [CITi04] Soares, Allynson et. al Estruturação Organizacional Horizontalizada E Orientada A Projetos. Recife: CEPE 2004. [JEFF01] Jeffrien, Ron What is Extreme Programming? Em xprogramming.com [WAKE02] Wake, William C Extreme Programming Explored. Boston: Addison-Wesley [XpRecife] Grupo e lista de discussão XPRecife [XPERS04] Grupo e lista de discussão XPers [PMBK00] é a versão em português do PMBOK. [Beck00] é a bíblia do XP. O primeiro livro do criador do XP. [Beck01] é o segundo livro do XP, trata de planejamento. [CITi04] demonstra a estrutura organizacional do CITi. [JEFF01] é uma breve introdução ao XP. [WAKE02] é um livro para os que já viveram um pouco XP.

18 Referências [BECK00] Beck, Kent Extreme Programming Explained. Boston: Addison-Wesley. [BECK01] Beck, Kent and Martin Fawler Planning Extreme Programming. Boston: Addison-Wesley. [CITi04] Soares, Allynson et. al Estruturação Organizacional Horizontalizada E Orientada A Projetos. Recife: CEPE 2004. [JEFF01] Jeffrien, Ron What is Extreme Programming? Em xprogramming.com [WAKE02] Wake, William C Extreme Programming Explored. Boston: Addison-Wesley [XpRecife] Grupo e lista de discussão XPRecife [XPERS04] Grupo e lista de discussão XPers [PMBK00] é a versão em português do PMBOK. [Beck00] é a bíblia do XP. O primeiro livro do criador do XP. [Beck01] é o segundo livro do XP, trata de planejamento. [CITi04] demonstra a estrutura organizacional do CITi. [JEFF01] é uma breve introdução ao XP. [WAKE02] é um livro para os que já viveram um pouco XP.

19 Gerência, Planejamento e XP
Parte 2 Nossa apresentação pretende relatar como ocorre planejamento e gerenciamento de projetos num projeto XP na empresa júnior do centro de informática, o CITi.

20 Áreas de Conhecimento em PGP
Uma visão extrema

21 Integração Desenvolvimento, execução do plano de projeto e controle de mudanças Whole team = desenvolvedores + cliente Papel do gerente: MEDIADOR e TRACKER Calha à fiveleta ressaltar a importância da idéia de “Whole team” presente no XP. A presença do cliente com papel atuante e bem definido, como explicado anteriormente. Para desenvolver o plano de projeto, o gerente serve como um mediador da interação entre o cliente e o programador, durante a execução do plano ele funciona como um solucionador de problemas, tornando o ambiente de trabalho propício à realização do trabalho, mostrando o que deve ser feito, ao invés de delegar as tarefas, mesmo assim, o papel de Tracker, aquele que verifica o cumprimento das estimativas e o progresso da equipe, é presente. Da mesma forma no controle de mudanças: mediar é a palavra chave. Mudanças não representam riscos, mudanças representam rotina, por isso XP é baseado em feedback, coragem e simplicidade.

22 Escopo Planejamento do escopo Gerenciamento do escopo Planning Game
Mudanças + Verificação  Client on-site + Testes de Aceitação Como se pode perceber, o escopo é definido pelo cliente na fase de exploração do Planning Game. É papel do cliente também priorizar e planejar/negociar com os programadores o escopo dos releases e das iterações. Durante o gerenciamento do escopo, feedback constante garantido pela presença do cliente e verificação garantida pelos testes de aceitação.

23 Tempo Definição e estimativa das atividades
Fase de exploração do Planning Game Seqüenciamento e desenvolvimento do cronograma Fase de Planejamento do jogo Os processos relativos ao gerenciamento do tempo no PMBOK são garantidos pelo XP no planning game. Em suas duas fazes, como pudemos ver temos definição e estimativa das atividades, durante a exploração; e seqüenciamento e desenvolvimento do cronograma, no planejamento. Documentos de cronograma ou gráficos de rede não se fazem necessários devido à rapidez do feedback. XP é como dirigir um carro: “você não mira e trava a direção, você vê a meta e vai ajustando até chegar.” [BECK01]

24 Custo Contrato de escopo variável
[XPERS04] Contrato de escopo variável “É simplesmente um contrato de prestação de serviços, pago por desenvolvedor.hora” Klaus Wuestefeld XP baseia-se numa coisa chamada de contrato de escopo variável: ao invés de definir o escopo e a duração no início do projeto, já que todos sabem que os requisitos fatalmente mudam, é mais honesto mostrar ao cliente isto (que a mudança de requisitos é inevitável). O cliente paga por mês e recebe por release. A cada release ele pode resolver o contrato sem ônus para ele. Se em 2 meses (nossa release) perceber que a equipe não é boa, pode cancelar. Da maneira tradicional, ele precisaria esperar o fim do contrato. A garantia que o cliente tem é que a equipe trabalhará sempre a todo vapor, e ele pode averiguar isto estando presente. Além disso, também é garantido que ao final da release será entregue aquilo de maior valor para o cliente, afinal, ele mesmo priorizou!

25 Recursos humanos Montagem da equipe Desenvolvimento da equipe
Primeira reunião: o que é XP? Desenvolvimento da equipe Move people around Pair programming Aumentando o “truck number” Como já foi dito, montar a equipe é papel do gerente. Se a equipe vai trabalhar com XP, os programadores precisam saber disto! É papel do gerente informar à equipe como será desenvolvido o trabalho. Em nosso projeto por exemplo, a primeira reunião entre gerente e desenvolvedores foi sobre XP. O desenvolvimento da equipe é garantido pelas práticas como pair programming e Move People Around. O pair programming funciona em mão dupla: enquanto o código sofre constante revisão e piloto do par é requisitado para fazer testes e refactoring pelo parceiro, ambos crescem em conhecimento. Por exemplo: um par formado pelo expert em Java web e o expert em Banco de dados promove um aumento fantástico da qualidade e disposição em camadas do código, enquanto o web expert aprende mais sobre BD e vice-versa. De forma semelhante, pares são desfeitos e refeitos toda hora, “moving people around” garante um nivelamento no conhecimento do sistema e o aumento do “truck number”. Truck number é o tamanho do menor conjunto de pessoas em um projeto tais que, se elas forem atropeladas por um caminhão o projeto estará em problemas. Distribuir conhecimento dentro por entre os membros de um projeto e um grande problema. Portanto, um baixo Truck Number é ruim (1 seria o pior) enquanto um número alto é bom (melhor seria se fosse igual ao número de integrantes do projeto)

26 Comunicação Open workspace Stand up meeting Client On-Site
Pair programming Integração Open workspace Stand up meeting Client On-Site Pair programming A Comunicação, já inclusa como valor do XP, rege as práticas como os demais valores. Notadamente podemos destacar as práticas de Pair Programming e cliente presente como promotores da comunicação. Além disso, a organização do espaço de trabalho deve propiciar a comunicação. XP dá preferência à conversa face a face ao . O espaço de trabalho não deve conter baias separando os programadores e deve ser repleto de quadros brancos contendo modelagem, cartões de estórias e gráficos que informem o progresso da equipe. Dessa forma o espaço de trabalho garante a distribuição uniforme da informação. No Cin não há uma sala para a equipe de desenvolvimento do projeto, entretanto a organização dos laboratórios facilita a comunicação dos membros da equipe. O stand-up meeting consiste de uma reunião rápida de 10 minutos, não necessária mente em pé, mas obrigatoriamente rápida, para informar o que será feito hoje, o que foi feito, que problemas ocorreram (mas não como solucioná-los), etc. O cliente presente proporcionando feedback também ajuda na comunicação. Área Privativa [WAKE02]

27 Qualidade, Risco e Aquisições
TRACKER e COACH: gerentes de qualidade Risco: papel do gerente informá-los Aquisições: apoio da diretoria de qualidade do CITi, problemas com a infra-estrutura do CIn São 3 os papéis gerenciais no XP: o de gerente, já falado, o tracker e o coach. O tracker é responsável por medir o progresso do time, quantas estórias são implementadas por iteração, como andam os testes de aceitação, como anda cada programador e se ele está cumprindo o estimado. A figura do coach representa aquele que coloca a equipe nos trilhos quando necessário, ele é o maior conhecedor de XP da equipe, e deve garantir que as disciplinas do processo estão sendo realizadas da melhor forma possível. Se os stand-up meetings estão demorando 2 horas, o coach deve entrar em ação. Estes são os gestores de qualidade do projeto. Além deles, os programadores, enquanto executores de design simples, test driven develeopment e refactoring são operadores de qualidade, por assim dizer. No XP não há de fato uma disciplina relativa aos riscos, mas é papel do gerente mostrar a equipe os riscos para que todos fiquem a par do que pode vir a ocorrer. Em nosso caso, o gerenciamento das aquisições foi apoiado pela diretoria, especialmente a diretoria de qualidade, que ajudou a sanar problemas com a infra-estrutura. Atualmente, o CITi utiliza a infra-estrutura do CIn para desenvolver seus projetos.

28 Conclusões Valores do XP guiam as atividades da equipe
Adaptação é a palavra chave. Adaptamos o XP às nossas necessidades; PMBOK com roupa de XP(?) Satisfação do cliente Os valores do XP guiam as atividades da equipe e são compatíveis com os valores do CITi. Nossas atividades foram e continuam a ser guiadas pelos valores. Mesmo que não possamos implementar XP em sua totalidade de práticas, podemos adaptá-lo às nossas necessidades. Adaptação é uma tônica do XP, que se baseia em simplicidade para possibilitar a mudança, feedback e comunicação para guiá-la e coragem para abraçar a mudança e respeito para realizá-la. Da mesma forma, não tentamos adaptar PMBOK ao contexto do XP, apenas, como já dito, nos utilizamos dele para não sair da linha de Planejamento e Gerenciamento de Projetos. O mais importante, para nós, sem dúvida é a satisfação do cliente. Sobre isso podemos dizer que o novo contrato para novos releases está fechado.

29 Referências [PMBK00] PMBOK 2000
[BECK00] Beck, Kent Extreme Programming Explained. Boston: Addison-Wesley. [BECK01] Beck, Kent and Martin Fawler Planning Extreme Programming. Boston: Addison-Wesley. [JEFF01] Jeffrien, Ron What is Extreme Programming? Em xprogramming.com [WAKE02] Wake, William C Extreme Programming Explored. Boston: Addison-Wesley [XpRecife] Grupo e lista de discussão XPRecife [XPERS04] Grupo e lista de discussão XPers [PMBK00] é a versão em português do PMBOK. [Beck00] é a bíblia do XP. O primeiro livro do criador do XP. [Beck01] é o segundo livro do XP, trata de planejamento. [JEFF01] é uma breve introdução ao XP. [WAKE02] é um livro para os que já viveram um pouco XP.