Amigos,
estamos aqui no trabalho precisando de uma ferramenta para fazer as vezes de "intranet". Tentamos usar os wikis, que são poderosos, mas ao mesmo tempo não são tão intuitivos.
Encontrei essa ferramenta, já consideravelmente conhecida, chamada Zoho Projects (www.zoho.com). Criei um projeto para ver como funciona e gostei muito do que eu vi.
Pode ser adaptada pro SCRUM tranquilamente. É bem simples e bem funcional! Vale a pena e fica a minha sugestão. Algumas features que ela provê:
- Quatro tipos de usuários (admin, contractor, manager, employee) com visões e atribuições diferentes.
- Forum para discussões
- Visualização de o usuário está online ou não (faltou um chat integrado)
- Cadastro de horas trabalhadas (para empresas mais rígidas)
- Controle de arquivos (com versionamento)
- Agendamento de reuniões
- Criação de milestones que contem grupo de tarefas e que contem tarefas. Aqui, basta mudar para sprint (milestone), user story e impediment backlog (grupo de tarefas) e tarefas. As tarefas podem ficar sem atribuições de pessoas, podendo ser atualizada durante a daily meeting.
- Feed RSS para aviso de mudanças
- Log com mudanças que ocorram na página
- Possibilidade de inserir notas em tarefas, reuniões, etc.
Enfim, para quem procura uma ferramenta bem simples e gratuita para controlar o seu projeto, eu recomendo esta.
Fica a sugestão :)
Mostrando postagens com marcador implantação. Mostrar todas as postagens
Mostrando postagens com marcador implantação. Mostrar todas as postagens
Quinta-feira, 10 de Julho de 2008
Terça-feira, 1 de Julho de 2008
Palestra "Scrum in Hell - Implantando agilidade em ambientes difíceis"
Salve pessoal,
Ontem realizei a palestra a convite do pessoal do GUMA-RS (Grupo de Usuários de Métodos Ágeis) onde trouxe um caso prático da aplicação do SCRUM, no meu trabalho.
O link para download é este.
Utilizei a conotação "ambiente difícil" para ilustrar ambientes onde os processos são caóticos, a comunicação normalmente é ruim, a cultura é autocrática, etc. que normalmente remetem a empresas de pequeno porte - e no meu caso, em grupos de pesquisa acadêmicos.
A apresentação não foi muuuito bem conduzida. Muito porque eu não tive tempo suficiente para prepará-la. Então acredito que o material apresentado tenha sido bem interessante, porém não consegui conduzir muito bem (em alguns momentos eu nem lembrava ao certo o porque havia escrito aquilo). Mesmo assim, com algumas correções, essa apresentação ficará redonda e bem ilustrativa de como aplicar SCRUM em sua empresa :)
Na verdade acredito que vou mudar o contexto dessa apresentação. Ao invés de ser "Scrum in Hell" será algo do tipo "YES YOU CAN!", que remete a um bordão americano famoso - usado incessantemente por um daqueles apresentadores de programa estilo "Márcia Goldschimitt" nos Estados Unidos, nos anos 90.
No post anterior, o Jefferson comentou que achou muito interessante o processo que eu abordei. Pretendo trabalhar mais em cima disso, mostrando como é simples de aplicar o SCRUM em sua empresa, seja ela pequena, grande, autocrática ou democrática. Podem ser iniciativas que partem desde o modelo "top-down", ou seja, vendendo a idéia para a diretoria para então implantar no operacional, ou "bottom-up", fazendo o inverso.
Então esperem que a próxima palestra será sim bem melhor e bem mais focada :) Tenho certeza que irão gostar mais ainda.
Uma pena que haviam 50 inscritos para a palestra e apenas metade compareceu ao evento, no dia. Espero que estas pessoas não tenham tirado o lugar de outros que não puderam ir!
O link para download da apresentação é este.
Vou ver se consigo com o Daniel para publicar a apresentação dele, que possuia muitos links interessantes.
Um grande abraço
Ontem realizei a palestra a convite do pessoal do GUMA-RS (Grupo de Usuários de Métodos Ágeis) onde trouxe um caso prático da aplicação do SCRUM, no meu trabalho.
O link para download é este.
Utilizei a conotação "ambiente difícil" para ilustrar ambientes onde os processos são caóticos, a comunicação normalmente é ruim, a cultura é autocrática, etc. que normalmente remetem a empresas de pequeno porte - e no meu caso, em grupos de pesquisa acadêmicos.
A apresentação não foi muuuito bem conduzida. Muito porque eu não tive tempo suficiente para prepará-la. Então acredito que o material apresentado tenha sido bem interessante, porém não consegui conduzir muito bem (em alguns momentos eu nem lembrava ao certo o porque havia escrito aquilo). Mesmo assim, com algumas correções, essa apresentação ficará redonda e bem ilustrativa de como aplicar SCRUM em sua empresa :)
Na verdade acredito que vou mudar o contexto dessa apresentação. Ao invés de ser "Scrum in Hell" será algo do tipo "YES YOU CAN!", que remete a um bordão americano famoso - usado incessantemente por um daqueles apresentadores de programa estilo "Márcia Goldschimitt" nos Estados Unidos, nos anos 90.
No post anterior, o Jefferson comentou que achou muito interessante o processo que eu abordei. Pretendo trabalhar mais em cima disso, mostrando como é simples de aplicar o SCRUM em sua empresa, seja ela pequena, grande, autocrática ou democrática. Podem ser iniciativas que partem desde o modelo "top-down", ou seja, vendendo a idéia para a diretoria para então implantar no operacional, ou "bottom-up", fazendo o inverso.
Então esperem que a próxima palestra será sim bem melhor e bem mais focada :) Tenho certeza que irão gostar mais ainda.
Uma pena que haviam 50 inscritos para a palestra e apenas metade compareceu ao evento, no dia. Espero que estas pessoas não tenham tirado o lugar de outros que não puderam ir!
O link para download da apresentação é este.
Vou ver se consigo com o Daniel para publicar a apresentação dele, que possuia muitos links interessantes.
Um grande abraço
Segunda-feira, 30 de Junho de 2008
É hoje a palestra!
Hoje é a palestra que irei dar ao público aqui em Porto Alegre entitulada: "SCRUM IN HELL - Uma abordagem prática da aplicação do SCRUM em ambientes difíceis". O nome é mesmo para instigar :)
Irei conceituar o que eu chamo de ambientes difíceis (micro e pequenas empresas e, no meu caso, grupo de pesquisa universitário) e depois apresentarei o que eu fiz para iniciar a implantação do SCRUM no ambiente de trabalho. Não será uma palestra que fala sobre a metodologia do SCRUM, mas sim uma visão de como ela pode nos ajudar no dia-a-dia.
Espero que consiga passar a mensagem para o público e que pelo menos alguns, se animem a tentar mudar em suas empresas :)
Depois conto como foi.
---------------------------
Essa é a semana decisiva do projeto Agritec. Semana passada os guris acabaram queimando um pequeno circuito da placa, que já foi trocado (felizmente não foi nada grave). Essa semana faremos os testes e depois prepararemos a apresentação que será feita na outra segunda-feira.
Tomara que tudo corra nos conformes...
Irei conceituar o que eu chamo de ambientes difíceis (micro e pequenas empresas e, no meu caso, grupo de pesquisa universitário) e depois apresentarei o que eu fiz para iniciar a implantação do SCRUM no ambiente de trabalho. Não será uma palestra que fala sobre a metodologia do SCRUM, mas sim uma visão de como ela pode nos ajudar no dia-a-dia.
Espero que consiga passar a mensagem para o público e que pelo menos alguns, se animem a tentar mudar em suas empresas :)
Depois conto como foi.
---------------------------
Essa é a semana decisiva do projeto Agritec. Semana passada os guris acabaram queimando um pequeno circuito da placa, que já foi trocado (felizmente não foi nada grave). Essa semana faremos os testes e depois prepararemos a apresentação que será feita na outra segunda-feira.
Tomara que tudo corra nos conformes...
Segunda-feira, 23 de Junho de 2008
Implantando o SCRUM a conta-gotas.
Não existe dúvida que a implantação de qualquer metodologia (ou prática ou padrão) requer um pré-requisito principal para funcionar: o apoio da direção.
De nada adianta nossa boa vontade, nossa motivação, iniciativa e conhecimento técnico se os maiores patrocinadores da mudança não demonstrarem pelo menos metade disso.
Por isso, vou listar aqui algumas idéias para você implantar alguns conceitos de agile e SCRUM aos pouquinhos. De forma que, em pouco tempo, a implantação completa seja só um pequeno passo.
Observação importante: essa é a minha opinião :)
Vamos lá
1) DAILY MEETINGS. Nada mais simples do que isso. Reuna a sua equipe diariamente e comece a fazer as três famosas perguntas: "O que você fez ontem? O que fará hoje - ou o que pretende fazer para amanhã ? Quais seus impedimentos?". Essa é uma poderosa forma de maximizar a comunicação da sua equipe! E tem como bonus, a vantagem de que pelo menos uma vez por dia TODOS irão estar reunidos em um horário certo.
2) SPRINTS. Tente criar o conceito de sprints, mesmo sem seus chefes saberem. Defina "deadlines" a cada 2 semanas ou 1 mês e mantenha fixo.
3) PRODUCT BACKLOG. Defina o seu primeiro product backlog. Tente levantar as funcionalidades que precisam ser feitas, priorize e discuta cada uma, criando estimativas e definições de finalizado.
4) CRIE UM TASKBOARD. Um simples local onde você tem as suas tarefas em "todo", "doing" e "done" já é um bom começo para ter o seu termômetro do status do projeto. Agregue valor com o tempo (stories, burndown, impedimentos, tarefas não planejadas, etc).
5) RETROSPECTIVAS. Ao final de um sprint, use o taskboard como repositório e faça uma retrospectiva com sua equipe. Veja o que foi bom, o que poderia ser melhorado e no que vocês irão focar para melhorar. Detalhe: faça dessa reunião algo bem informal, compre uns salgadinhos e refrigerantes.
E lembre-se, você pode implantar o SCRUM na sua empresa de duas maneiras: pelo jeito "bottom-up" ou pelo jeito "top-down". Bottom-up seria você começando diretamente com a sua equipe e com isso mostrando ao seu chefe os resultados das práticas ágeis. Top-down é o inverso, ou seja, você vende a idéia para o seu chefe e depois tenta vender para sua equipe.
Ambas são eficientes, e dependem do seu ambiente de trabalho. Tenha isso em mente, quando for pôr em prática estas cinco preciosas práticas que eu deixo aqui :)
São as minhas cinco dicas para quem quiser tentar colocar um pouco de agilidade em seu ambiente :) Se você tem outras dicas, poste aí nos comentários!
Abraços
De nada adianta nossa boa vontade, nossa motivação, iniciativa e conhecimento técnico se os maiores patrocinadores da mudança não demonstrarem pelo menos metade disso.
Por isso, vou listar aqui algumas idéias para você implantar alguns conceitos de agile e SCRUM aos pouquinhos. De forma que, em pouco tempo, a implantação completa seja só um pequeno passo.
Observação importante: essa é a minha opinião :)
Vamos lá
1) DAILY MEETINGS. Nada mais simples do que isso. Reuna a sua equipe diariamente e comece a fazer as três famosas perguntas: "O que você fez ontem? O que fará hoje - ou o que pretende fazer para amanhã ? Quais seus impedimentos?". Essa é uma poderosa forma de maximizar a comunicação da sua equipe! E tem como bonus, a vantagem de que pelo menos uma vez por dia TODOS irão estar reunidos em um horário certo.
2) SPRINTS. Tente criar o conceito de sprints, mesmo sem seus chefes saberem. Defina "deadlines" a cada 2 semanas ou 1 mês e mantenha fixo.
3) PRODUCT BACKLOG. Defina o seu primeiro product backlog. Tente levantar as funcionalidades que precisam ser feitas, priorize e discuta cada uma, criando estimativas e definições de finalizado.
4) CRIE UM TASKBOARD. Um simples local onde você tem as suas tarefas em "todo", "doing" e "done" já é um bom começo para ter o seu termômetro do status do projeto. Agregue valor com o tempo (stories, burndown, impedimentos, tarefas não planejadas, etc).
5) RETROSPECTIVAS. Ao final de um sprint, use o taskboard como repositório e faça uma retrospectiva com sua equipe. Veja o que foi bom, o que poderia ser melhorado e no que vocês irão focar para melhorar. Detalhe: faça dessa reunião algo bem informal, compre uns salgadinhos e refrigerantes.
E lembre-se, você pode implantar o SCRUM na sua empresa de duas maneiras: pelo jeito "bottom-up" ou pelo jeito "top-down". Bottom-up seria você começando diretamente com a sua equipe e com isso mostrando ao seu chefe os resultados das práticas ágeis. Top-down é o inverso, ou seja, você vende a idéia para o seu chefe e depois tenta vender para sua equipe.
Ambas são eficientes, e dependem do seu ambiente de trabalho. Tenha isso em mente, quando for pôr em prática estas cinco preciosas práticas que eu deixo aqui :)
São as minhas cinco dicas para quem quiser tentar colocar um pouco de agilidade em seu ambiente :) Se você tem outras dicas, poste aí nos comentários!
Abraços
Terça-feira, 10 de Junho de 2008
SCRUM como cultura... e não superficial
É comum a gente encontrar artigos na internet criticando o Agile e até mesmo o próprio SCRUM, em particular. Até mesmo em discussões esse assunto é recorrente. Eu considero que quem critica o SCRUM, na maioria dos casos (vale ressaltar), tem uma visão MUITO superficial do que os processos ágeis sugerem.
Não vou entrar no mérito da discussão destas pessoas. O meu foco é, novamente, mostrar porque é tão difícil de implementar o SCRUM em um ambiente hostil (como eu costumo chamar), como é o caso de um grupo de pesquisa onde os projetos não são vistos como deveriam ser.
Uma das maiores pré-condições para que qualquer processo ágil funcione é: COMUNICAÇÃO. Eu costumo dizer que o SCRUM é mais do que um processo iterativo: é um processo interativo, antes de tudo!
Partindo disso, podemos dizer que o esforço da implantação de agilidade em um lugar onde as interações não acontecem como deveriam, o SCRUM não funcionará corretamente. E é exatamente isso que estou vivendo no meu grupo de pesquisa.
Já cansei de falar de situações onde os coordenadores pegam alguns funcionários, sem me avisar, e alocam em outros projetos. Isso é recorrente, mas é uma das primeiras coisas que pretendemos acabar. Porém, ontem aconteceu algo mais crítico ainda.
Temos que desenvolver um protótipo para logística de ônibus até o início de Junho. Havia sido definido que faríamos uma maquete e um simulador que faria tudo em cima dessa maquete. Dois recursos seriam utilizados, um para desenvolver o "core" do simulador, e outro para desenvolver as aplicações extras.
Estava tudo bem, estávamos avançados até no sistema, inclusive já pensando em questões finais... quando ontem um dos meus coordenadores comenta que iremos utilizar GPS ao invés de simular.
Como assim?! Pois é, fizeram uma mudança enorme de escopo e, claro, não nos consultaram para ver da possibilidade de realizar a mudança. É assim... temos um prazo de menos de um mês e as coisas mudam para uma complexidade x². O simulador morreu. Agora iremos fazer um caso com um ônibus real. Haverá mapeamento, cálculos complexos, recepção de sinais de GPS, envolvimento com hardwares...
Obviamente toda a parte de produção (e os gerentes) foram os últimos a saber. E, claro, cortaram um funcionário e colocaram outro no lugar, sem nos avisar. De novo.
Vendo isso acontecer, de novo, eu me lembro do email que um dos coordenadores me enviou (e que causou aquele meu momento de raiva, há algum tempo atrás) e pego um trecho do email que tem muito a ver com isso:
Coloquei em negrito alguns trechos mais "interessantes" para mostrar a realidade: os coordenadores NÃO percebem que são ELES os maiores culpados disso tudo. Eles realmente NÃO percebem.
SCRUM em ambientes hostis... é um desafio. Eu estou comprando esse desafio. Mas, se não houver um envolvimento e comprometimento de todos, se a visão for superficial e a cultura de agilidade (principalmente COMUNICAÇÃO e INTERAÇÃO) não for absorvida, realmente não me restará outra opção a não ser abandonar o barco. Mudar uma cultura é difícil, eu sei. Só que se eles sequer estiverem dispostos a mudar, daí não tem porque ficar gastando energia a toa.
Não vou entrar no mérito da discussão destas pessoas. O meu foco é, novamente, mostrar porque é tão difícil de implementar o SCRUM em um ambiente hostil (como eu costumo chamar), como é o caso de um grupo de pesquisa onde os projetos não são vistos como deveriam ser.
Uma das maiores pré-condições para que qualquer processo ágil funcione é: COMUNICAÇÃO. Eu costumo dizer que o SCRUM é mais do que um processo iterativo: é um processo interativo, antes de tudo!
Partindo disso, podemos dizer que o esforço da implantação de agilidade em um lugar onde as interações não acontecem como deveriam, o SCRUM não funcionará corretamente. E é exatamente isso que estou vivendo no meu grupo de pesquisa.
Já cansei de falar de situações onde os coordenadores pegam alguns funcionários, sem me avisar, e alocam em outros projetos. Isso é recorrente, mas é uma das primeiras coisas que pretendemos acabar. Porém, ontem aconteceu algo mais crítico ainda.
Temos que desenvolver um protótipo para logística de ônibus até o início de Junho. Havia sido definido que faríamos uma maquete e um simulador que faria tudo em cima dessa maquete. Dois recursos seriam utilizados, um para desenvolver o "core" do simulador, e outro para desenvolver as aplicações extras.
Estava tudo bem, estávamos avançados até no sistema, inclusive já pensando em questões finais... quando ontem um dos meus coordenadores comenta que iremos utilizar GPS ao invés de simular.
Como assim?! Pois é, fizeram uma mudança enorme de escopo e, claro, não nos consultaram para ver da possibilidade de realizar a mudança. É assim... temos um prazo de menos de um mês e as coisas mudam para uma complexidade x². O simulador morreu. Agora iremos fazer um caso com um ônibus real. Haverá mapeamento, cálculos complexos, recepção de sinais de GPS, envolvimento com hardwares...
Obviamente toda a parte de produção (e os gerentes) foram os últimos a saber. E, claro, cortaram um funcionário e colocaram outro no lugar, sem nos avisar. De novo.
Vendo isso acontecer, de novo, eu me lembro do email que um dos coordenadores me enviou (e que causou aquele meu momento de raiva, há algum tempo atrás) e pego um trecho do email que tem muito a ver com isso:
- Nao vi nenhum de voces acompanhando o desenvolvimento disto com o Beltrano e/ou Sicrano (os dois da equipe atual) na ultima semana. Nao adianta simplesmente passar as tarefas para eles e nao acompanhar o desenvolvimento diario delas, assim como as dificuldades que eles estao tendo. Onde esta o scrum?
- Voces como gerente de projetos devem saber como as coisas sao/foram implementadas, pois voces sao a memoria da equipe. Se desenvolvedores saem da equipe, isto, em principio, nao deveria afetar em nada o trabalho em relacao a parte tecnica.
- Sempre falei que qq sistema deveria ser modular e de facil re-adaptacao. O codigo objeto deve ser realizado segundo as metodologias de projeto adequadas para que isto nao ocorra mais. Nao podemos ficar sempre tendo que reaprender codigo de outros. Onde foram para as metodologias de projeto? engenharia de sw?
Coloquei em negrito alguns trechos mais "interessantes" para mostrar a realidade: os coordenadores NÃO percebem que são ELES os maiores culpados disso tudo. Eles realmente NÃO percebem.
SCRUM em ambientes hostis... é um desafio. Eu estou comprando esse desafio. Mas, se não houver um envolvimento e comprometimento de todos, se a visão for superficial e a cultura de agilidade (principalmente COMUNICAÇÃO e INTERAÇÃO) não for absorvida, realmente não me restará outra opção a não ser abandonar o barco. Mudar uma cultura é difícil, eu sei. Só que se eles sequer estiverem dispostos a mudar, daí não tem porque ficar gastando energia a toa.
Quarta-feira, 14 de Maio de 2008
Sobre cursos, palestras, blog...
Pelo visto, estou me tornando um "disseminador" de Agile. :)
Isso é muito bacana. Sempre é legal disseminar lições e experiências. Mas eu tenho os pés no chão.
Certa vez escutando um podcast do Ricardo Viana Vargas, um dos maiores nomes de gerenciamento de projetos no Brasil, ele falou uma coisa que eu sigo ao pé da letra: "Não tente vender aquilo que você não sabe".
Se formos ver, isso é corretíssimo. Uma pena que existam pessoas que fazem isso... uma pena para a própria pessoa, pois normalmente ela é desmascarada logo de cara.
Nas palestras e "workshops internos" que eu tenho feito, eu sempre deixo claro que estou apresentando a minha visão de agile, baseado nas minhas experiências e aprendizados (seja na prática, seja na teoria, seja nas discussões nas listas). Mas eu NUNCA tento me passar por "mago" ou o "bambambam" do SCRUM.
O meu próprio blog foi feito com o intuito de divulgar as minhas experiências, mostrar que ser gerente de projetos (iniciante - quando eu comecei o blog) e em ambientes "hostis" (pesquisa, micro e pequenas empresas) não é um bicho de sete cabeças. É difícil, sim. Mas a gente aprende... com erros e acertos.
Eu sigo essa filosofia. Exponho a minha vivência, a minha visão. Não pretendo nunca ser um xiita e dizer que "tenho a fórmula mágica para a solução dos seus problemas!".
Fico feliz em receber feedback de leitores, felizes com as experiências que eu exponho aqui. Mas tenham isso em mente: o que eu faço não é certo nem errado. É apenas a minha interpretação de agile, baseado no meu ambiente de trabalho.
Fuja de formulismos, e busque você também moldar o agile conforme as suas necessidades e situação.
Um abraço!
Isso é muito bacana. Sempre é legal disseminar lições e experiências. Mas eu tenho os pés no chão.
Certa vez escutando um podcast do Ricardo Viana Vargas, um dos maiores nomes de gerenciamento de projetos no Brasil, ele falou uma coisa que eu sigo ao pé da letra: "Não tente vender aquilo que você não sabe".
Se formos ver, isso é corretíssimo. Uma pena que existam pessoas que fazem isso... uma pena para a própria pessoa, pois normalmente ela é desmascarada logo de cara.
Nas palestras e "workshops internos" que eu tenho feito, eu sempre deixo claro que estou apresentando a minha visão de agile, baseado nas minhas experiências e aprendizados (seja na prática, seja na teoria, seja nas discussões nas listas). Mas eu NUNCA tento me passar por "mago" ou o "bambambam" do SCRUM.
O meu próprio blog foi feito com o intuito de divulgar as minhas experiências, mostrar que ser gerente de projetos (iniciante - quando eu comecei o blog) e em ambientes "hostis" (pesquisa, micro e pequenas empresas) não é um bicho de sete cabeças. É difícil, sim. Mas a gente aprende... com erros e acertos.
Eu sigo essa filosofia. Exponho a minha vivência, a minha visão. Não pretendo nunca ser um xiita e dizer que "tenho a fórmula mágica para a solução dos seus problemas!".
Fico feliz em receber feedback de leitores, felizes com as experiências que eu exponho aqui. Mas tenham isso em mente: o que eu faço não é certo nem errado. É apenas a minha interpretação de agile, baseado no meu ambiente de trabalho.
Fuja de formulismos, e busque você também moldar o agile conforme as suas necessidades e situação.
Um abraço!
Segunda-feira, 5 de Maio de 2008
Index Cards e Planning Poker para download
Caros amigos!
Estou disponibilizando (em formato PPT - powerpoint) o modelo de Index card que eu utilizei abaixo. Basta imprimir em folhas A4 que você terá 2 index cards por folha :)
O download é aqui.
E também estou disponibilizando uma versão da Planning Poker para download, em PPT. Ele é similar a esse:
A carta "1" indica que a user story é muito pequena, e portanto deve ser anexada a outra story.
As cartas "2, 3, 5, 8 e 13" são os valores para trabalhar com as estimativas.
A carta "21" indica que a user story é muito grande e deve ser quebrada em duas.
A carta do "alien" indica que a pessoa não faz a menor idéia de uma estimativa para aquela story (por exemplo, um cara de hardware estimando um módulo de software).
A carta da "taça" indica que a pessoa quer dar um tempo para descansar.
É bem simples de fazer. O slide 1 é a frente e o 2 é atrás. Leve em uma gráfica e peça para eles fazerem frente e verso. Use o espaço em branco ali para colocar o logo da sua empresa, se quiser. Mas atenção, quando for imprimir, exclua a marcação pontilhada do slide 2. Ele é apenas um guia para você colocar o seu logo. A impressão não ficará igual se você deixar a linha pontilhada.
Faça o download aqui.
Espero que gostem!
Abraços
Estou disponibilizando (em formato PPT - powerpoint) o modelo de Index card que eu utilizei abaixo. Basta imprimir em folhas A4 que você terá 2 index cards por folha :)
O download é aqui.
E também estou disponibilizando uma versão da Planning Poker para download, em PPT. Ele é similar a esse:
A carta "1" indica que a user story é muito pequena, e portanto deve ser anexada a outra story.
As cartas "2, 3, 5, 8 e 13" são os valores para trabalhar com as estimativas.
A carta "21" indica que a user story é muito grande e deve ser quebrada em duas.
A carta do "alien" indica que a pessoa não faz a menor idéia de uma estimativa para aquela story (por exemplo, um cara de hardware estimando um módulo de software).
A carta da "taça" indica que a pessoa quer dar um tempo para descansar.
É bem simples de fazer. O slide 1 é a frente e o 2 é atrás. Leve em uma gráfica e peça para eles fazerem frente e verso. Use o espaço em branco ali para colocar o logo da sua empresa, se quiser. Mas atenção, quando for imprimir, exclua a marcação pontilhada do slide 2. Ele é apenas um guia para você colocar o seu logo. A impressão não ficará igual se você deixar a linha pontilhada.
Faça o download aqui.
Espero que gostem!
Abraços
SCRUM para resgatar o projeto!
Hoje tivemos nossa reunião para começar o sprint. Não foi uma reunião oficial, daquelas em que passamos o dia planejando e tudo mais. Mesmo assim tivemos definições importantes.
Temos 7 semanas até o fim do projeto. Então decidimos fazer 3 sprints de 2 semanas, com mais 1 semana de "pulmão" para ajustes e afins. Temos inicialmente 11 stories para cumprir. No primeiro sprint 4 stories serão "atacadas".
Definimos como será o nosso taskboard. A princípio ele será conforme a figura abaixo:
(1) São as user stories em forma de index cards (veja mais adiante)
(2) Identifica a coluna que acrescentamos, a VERIFY
(3) Indica o nosso burndown chart
(4) As tarefas não planejadas, as famosas "tarefas rosas"
(5) São as informações da sprint, número, data de início e fim e o tamanho em pontos
(6) É o backlog de impedimentos
A coluna VERIFY eu acredito que seja a melhor mudança introduzida. Por quê? Pois ela "força" uma pessoa a dar o aval se a tarefa está pronta ou não. No caso, serei eu (scrum master) que validarei as tarefas para DONE. O processo é bem simples:
SE AS TAREFAS ESTIVEREM PRONTAS, VÃO PARA DONE
SE ALGO NÃO ESTIVER CONFORME, VOLTA PARA DOING
O legal é que todos da equipe aprovaram isso. O Scrum Master começa a se integrar mais com as atividade de fato, sem ficar na esperança de que os caras tenham feito as coisas mesmo.
O nosso gráfico de BURNDOWN seguirá o modelo que usamos anteriormente, o qual não é recomendado, mas devido ao nosso baixo tempo para estimar tarefas e também ao pedido da equipe pelo gráfico, ele será mensurado da seguinte forma:
X-AXIS : dias do sprint (5/5, 6/5, 7/5... 15/5, 16/5).
Y-AXIS : tarefas restantes (número de tarefas. Quando surgirem rosas, o gráfico sobe)
O pessoal recomenda usar horas ou pontos. Como eu disse, não tínhamos tempo (e sinceramente, nem saco) para estimar cada uma das tarefas. Então faremos assim... o gráfico dará apenas uma visão gráfica da taskboard. Servirá apenas como "motivador".
As tarefas não planejadas são todas aquelas que não foram levantadas durante a reunião de hoje (2a feira). Se uma atividade não planejada durar mais do que 1 hora, ela vira uma tarefa rosa. Portanto, "Resetar o computador" não é uma tarefa rosa. Mas "Reinstalar o Windows" já poderia ser considerada :)
O campo das informações do sprint são bem legais. Ali fica visual o dia de início e fim da sprint, o sprint goal (no nosso caso é "Finalizar o sistema de software") e também tem o número de pontos estimados para as 4 stories que colocamos no sprint. Uma de 13 pontos, duas de 8 pontos e uma de 5 pontos. Total 34 pontos.
O backlog de impedimentos será bem simples. Cada impedimento que ocorrer gera um post-it (no nosso caso, será aqueles "reciclados" cor cinza). Marcamos a data que surgiu e quem gerou o impedimento e quando ele for resolvido, será apenas "riscado".
As tarefas planejadas devem conter apenas o nome da pessoa que está realizando, como extra. Se forem 2 pessoas, ou se colocam os dois nomes ou alguém que responderá por ela.
Por fim, as INDEX CARDS. Finalmente usamos o conceito das index cards. Ela está exatamente como a figura abaixo mostra:
Temos o campo "ID" apenas para identificação rápida da story, o nome da story, a sua prioridade (na faixa de 1 a 150), algumas notas (que eu usei para descrever o objetivo e algumas informações extras sobre a story), a estimativa (usando planning poker ou apenas marcando Fibonacci ali 1-2-3-5-8-13-21) e o campo mais importante e útil de todos: o DoD (definition of done, ou definição de finalizado).
O DoD é tão importante e tão útil, que enquanto eu escrevia nele eu percebi o tamanho da ajuda que ele apresenta. Lembram na dinâmica do SCRUM que eu descrevi há algumas semanas atrás, quando mencionei que durante a sprint review eu não havia feito um DoD das stories, e assim eu não sabia o que avaliar nas apresentações? Pois é. Agora temos um "checklist" das coisas importantes que a story deve considerar.
Por exemplo, em uma story chamada "Manual do Usuário", um dos "DoD's" é:
- O documento identifica todas as funcionalidades do sistema
- O documento apresenta passo a passo os procedimentos para as funções
- Os pontos de interação com o usuário estão descritos no documento
E assim por diante. Na story chamada "Criação de uma placa de alimentação" temos alguns "DoD's" como:
- Todos os componentes necessários estão disponíveis
- Foi realizada uma medida de consumo do sistema e a placa atende a isso
Enfim, agora temos alguns critérios para avaliar se as stories estão realmente DONE ou não! Além disso, a utilização dos DoD's facilita (e facilitou mesmo) a definição das tarefas. Cada uma dessas DoD's vira no minimo uma tarefa... geralmente mais de uma até.
Os DoD's podem funcionar até mesmo como casos de teste. Se fosse uma story que descrevesse uma tela de login (usuário e senha), por exemplo. Os DoD's poderiam ser:
- O sistema não aceita menos de 5 caracteres nos campos de usuário e senha
- O sistema não aceita números sequenciais como senha (12345, 67890, etc)
E assim por diante. Eu posso dizer que o DoD realmente é uma das coisas mais importantes que sua story deve possuir. Sem dúvida nenhuma! :)
Pois então é isso. Temos 7 semanas para tocar o projeto. É a chance de recuperar um projeto que parecia morto e transformá-lo em um protótipo interessante e com uma documentação bem completa.
O que falta mudar agora é a atitude da equipe... eles estavam largados nesse meio tempo. Mas agora a pressão vai vir não só de mim... mas do taskboard também ;)
Um abraço!
Temos 7 semanas até o fim do projeto. Então decidimos fazer 3 sprints de 2 semanas, com mais 1 semana de "pulmão" para ajustes e afins. Temos inicialmente 11 stories para cumprir. No primeiro sprint 4 stories serão "atacadas".
Definimos como será o nosso taskboard. A princípio ele será conforme a figura abaixo:
(1) São as user stories em forma de index cards (veja mais adiante)
(2) Identifica a coluna que acrescentamos, a VERIFY
(3) Indica o nosso burndown chart
(4) As tarefas não planejadas, as famosas "tarefas rosas"
(5) São as informações da sprint, número, data de início e fim e o tamanho em pontos
(6) É o backlog de impedimentos
A coluna VERIFY eu acredito que seja a melhor mudança introduzida. Por quê? Pois ela "força" uma pessoa a dar o aval se a tarefa está pronta ou não. No caso, serei eu (scrum master) que validarei as tarefas para DONE. O processo é bem simples:
SE AS TAREFAS ESTIVEREM PRONTAS, VÃO PARA DONE
SE ALGO NÃO ESTIVER CONFORME, VOLTA PARA DOING
O legal é que todos da equipe aprovaram isso. O Scrum Master começa a se integrar mais com as atividade de fato, sem ficar na esperança de que os caras tenham feito as coisas mesmo.
O nosso gráfico de BURNDOWN seguirá o modelo que usamos anteriormente, o qual não é recomendado, mas devido ao nosso baixo tempo para estimar tarefas e também ao pedido da equipe pelo gráfico, ele será mensurado da seguinte forma:
X-AXIS : dias do sprint (5/5, 6/5, 7/5... 15/5, 16/5).
Y-AXIS : tarefas restantes (número de tarefas. Quando surgirem rosas, o gráfico sobe)
O pessoal recomenda usar horas ou pontos. Como eu disse, não tínhamos tempo (e sinceramente, nem saco) para estimar cada uma das tarefas. Então faremos assim... o gráfico dará apenas uma visão gráfica da taskboard. Servirá apenas como "motivador".
As tarefas não planejadas são todas aquelas que não foram levantadas durante a reunião de hoje (2a feira). Se uma atividade não planejada durar mais do que 1 hora, ela vira uma tarefa rosa. Portanto, "Resetar o computador" não é uma tarefa rosa. Mas "Reinstalar o Windows" já poderia ser considerada :)
O campo das informações do sprint são bem legais. Ali fica visual o dia de início e fim da sprint, o sprint goal (no nosso caso é "Finalizar o sistema de software") e também tem o número de pontos estimados para as 4 stories que colocamos no sprint. Uma de 13 pontos, duas de 8 pontos e uma de 5 pontos. Total 34 pontos.
O backlog de impedimentos será bem simples. Cada impedimento que ocorrer gera um post-it (no nosso caso, será aqueles "reciclados" cor cinza). Marcamos a data que surgiu e quem gerou o impedimento e quando ele for resolvido, será apenas "riscado".
As tarefas planejadas devem conter apenas o nome da pessoa que está realizando, como extra. Se forem 2 pessoas, ou se colocam os dois nomes ou alguém que responderá por ela.
Por fim, as INDEX CARDS. Finalmente usamos o conceito das index cards. Ela está exatamente como a figura abaixo mostra:
Temos o campo "ID" apenas para identificação rápida da story, o nome da story, a sua prioridade (na faixa de 1 a 150), algumas notas (que eu usei para descrever o objetivo e algumas informações extras sobre a story), a estimativa (usando planning poker ou apenas marcando Fibonacci ali 1-2-3-5-8-13-21) e o campo mais importante e útil de todos: o DoD (definition of done, ou definição de finalizado).
O DoD é tão importante e tão útil, que enquanto eu escrevia nele eu percebi o tamanho da ajuda que ele apresenta. Lembram na dinâmica do SCRUM que eu descrevi há algumas semanas atrás, quando mencionei que durante a sprint review eu não havia feito um DoD das stories, e assim eu não sabia o que avaliar nas apresentações? Pois é. Agora temos um "checklist" das coisas importantes que a story deve considerar.
Por exemplo, em uma story chamada "Manual do Usuário", um dos "DoD's" é:
- O documento identifica todas as funcionalidades do sistema
- O documento apresenta passo a passo os procedimentos para as funções
- Os pontos de interação com o usuário estão descritos no documento
E assim por diante. Na story chamada "Criação de uma placa de alimentação" temos alguns "DoD's" como:
- Todos os componentes necessários estão disponíveis
- Foi realizada uma medida de consumo do sistema e a placa atende a isso
Enfim, agora temos alguns critérios para avaliar se as stories estão realmente DONE ou não! Além disso, a utilização dos DoD's facilita (e facilitou mesmo) a definição das tarefas. Cada uma dessas DoD's vira no minimo uma tarefa... geralmente mais de uma até.
Os DoD's podem funcionar até mesmo como casos de teste. Se fosse uma story que descrevesse uma tela de login (usuário e senha), por exemplo. Os DoD's poderiam ser:
- O sistema não aceita menos de 5 caracteres nos campos de usuário e senha
- O sistema não aceita números sequenciais como senha (12345, 67890, etc)
E assim por diante. Eu posso dizer que o DoD realmente é uma das coisas mais importantes que sua story deve possuir. Sem dúvida nenhuma! :)
Pois então é isso. Temos 7 semanas para tocar o projeto. É a chance de recuperar um projeto que parecia morto e transformá-lo em um protótipo interessante e com uma documentação bem completa.
O que falta mudar agora é a atitude da equipe... eles estavam largados nesse meio tempo. Mas agora a pressão vai vir não só de mim... mas do taskboard também ;)
Um abraço!
Segunda-feira, 28 de Abril de 2008
Comunicação? Não... não é tão importante. E também: o guri de 18 anos.
Semana passada implantei a metodologia de SCRUM para atacar um dos principais problemas do laboratório: COMUNICAÇÃO. Pois não é que hoje eles conseguem me pregar mais uma peça?!
Fui para uma reunião de manhã, na empresa (para situar os novatos: trabalho em um laboratório de pesquisa E na empresa que é parceira de muitos projetos deste laboratório), para um projeto que a empresa fará em conjunto com uma empresa americana, para um portal coorportativo. Na saída, um dos sócios da empresa, que cuida da área comercial, comentou comigo:
- E ai, Flavio, amanhã vamos apresentar o sistema então?
- Hein? Qual sistema? (surpreso)
- O da administração da universidade, para o controle de ativos!
- Não estou sabendo de nada!!! (aflito)
- Não te avisaram então? Acho que um dos coordenadores deve falar contigo ainda hoje.
- Ah... tá bem, mas estou sabendo por ti agora. (resignado)
O sistema está pronto há 2 semanas. Ficamos todo esse tempo apenas mexendo aqui, ajeitando ali, nada de muito útil. Então, de um dia para o outro, resolvem fazer a apresentação sem nem ao menos nos consultar. Resultado? Boa parte da equipe não estava lá no laboratório, para fazer os testes finais e afins. Tivemos que passar o dia inteiro correndo atrás para deixar tudo pronto para amanhã e correndo atrás dessas pessoas responsáveis. Um deles chegou às 18h.
De tarde um dos coordenadores me falou da reunião. Não sei a visão que eles tem de implantar o sistema em um cliente, mas ao que parece, para eles é algo trivial e simples... por isso que 24h é mais do que o suficiente para nos avisar. Ainda mais no nosso ambiente atual de trabalho.
----------------------------------
Não foi um dia de SCRUM hoje. Não tive tempo de fazer nada do que pretendia (levantar o product backlog de pelo menos um projeto). Os incêndios vem e vão, é difícil de implantar agilidade em curto prazo...
Mas quero falar de um dos guris que trabalha lá. Ele tem 18 anos, é um dos mais novos. Eu mesmo o entrevistei para entrar em um projeto envolvendo PDA/PALM. Achei ele um guri novo, mas que pesava por ter sido o melhor dos entrevistados. Me pareceu com potencial.
O projeto acabou morrendo, embora ele cumpriu o que prometeu (desenvolveu uma aplicação em PDA). E agora está trabalhando fazendo os testes com RFID, para identificarmos casos de aplicabilidade e margem de leitura das antenas (melhores configurações para cada situação).
Inicialmente, nos passaram essa tarefa meio à bangu: "Tem que fazer testes, faz assim, assim e assim". Eu estava atarefado na época e montei uma planilha com as variáveis possíveis e passei para ele testar. Ele fez os testes, mas ficou muito dependente da pessoa que mexe com o software e as antenas.
Na apresentação disso a um dos coordenadores, ele foi bastante criticado, pois os testes não diziam nada. Assumi parte da culpa por não ter orientado ele e então com o meu colega fizemos um esboço de testes. Decidimos utilizar o conceito de cenários. Ou seja, para cada cenário específico, levantaríamos o que queríamos concluir com os testes e "setávamos" as variáveis envolvidas. Pedimos para o guri fazer o plano de testes baseado nisso.
Três dias, e ele continua na mesma. Hoje o meu colega deu um ultimato (de forma clara mas tranquila "Vamos virar essa página hoje?") mas eu senti que ele não havia novamente entendido o que seria o plano de testes. Ali pelas 17h30, sentei com ele e falei: "Ok me mostra o que tu tens". Ele estava fazendo planos de teste baseado novamente apenas nas variáveis... e isso estava gerando 300 casos de teste!!!
Questionei se ele faria tudo isso e ele achou graça. Então falei que ele iria acabar novamente gerando 300 casos de teste e não teria conclusão nenhuma. "O caso 195 foi o que garantiu 100% de leitura", ok, mas e aí? Onde seria aplicado? Como?
Então tive que, literalmente, ditar o documento para ele entender como queríamos. Estruturei o documento, onde eram explicados o cenário, o que queríamos testar, as condições, as variáveis e o objetivo do teste. E então, os planos de testes. Conseguimos queimar algumas variáveis dali, pois elas se sobrepunham (tag entrando do lado esquerdo e direito? Qual a diferença? Então colocamos tag entrando junto à antena). Não sei quantos casos de teste deu, deixei isso como tarefa para ele, mas acredito que não deve ter chegado a 30. E com um objetivo claro definido!
Além disso, com o pior caso possível poderemos propôr outro cenário de testes para tratá-lo. "O caso de teste 24 apresentou um aproveitamento de 30%. Para essa situação, iremos criar o cenário 2...".
Eu entendo que ele é um guri de 18 anos, entendo que a faculdade não ensina o pessoal a escrever, entendo que ele possa ter algumas dúvidas sobre os testes. Mas poxa, chegamos a essas conclusões do documento apenas pensando, imaginando a situação!! Reduzimos as variáveis apenas pensando!
Por que será que alguns dos meus funcionários teimam em não pensar um pouco nas tarefas que damos? A gente incentiva isso! Quando eu digo que as vezes fico desmotivado no trabalho, este é um dos principais motivos... as pessoas que nós gerenciamos parecem que não levam nada a sério.
Fui para uma reunião de manhã, na empresa (para situar os novatos: trabalho em um laboratório de pesquisa E na empresa que é parceira de muitos projetos deste laboratório), para um projeto que a empresa fará em conjunto com uma empresa americana, para um portal coorportativo. Na saída, um dos sócios da empresa, que cuida da área comercial, comentou comigo:
- E ai, Flavio, amanhã vamos apresentar o sistema então?
- Hein? Qual sistema? (surpreso)
- O da administração da universidade, para o controle de ativos!
- Não estou sabendo de nada!!! (aflito)
- Não te avisaram então? Acho que um dos coordenadores deve falar contigo ainda hoje.
- Ah... tá bem, mas estou sabendo por ti agora. (resignado)
O sistema está pronto há 2 semanas. Ficamos todo esse tempo apenas mexendo aqui, ajeitando ali, nada de muito útil. Então, de um dia para o outro, resolvem fazer a apresentação sem nem ao menos nos consultar. Resultado? Boa parte da equipe não estava lá no laboratório, para fazer os testes finais e afins. Tivemos que passar o dia inteiro correndo atrás para deixar tudo pronto para amanhã e correndo atrás dessas pessoas responsáveis. Um deles chegou às 18h.
De tarde um dos coordenadores me falou da reunião. Não sei a visão que eles tem de implantar o sistema em um cliente, mas ao que parece, para eles é algo trivial e simples... por isso que 24h é mais do que o suficiente para nos avisar. Ainda mais no nosso ambiente atual de trabalho.
----------------------------------
Não foi um dia de SCRUM hoje. Não tive tempo de fazer nada do que pretendia (levantar o product backlog de pelo menos um projeto). Os incêndios vem e vão, é difícil de implantar agilidade em curto prazo...
Mas quero falar de um dos guris que trabalha lá. Ele tem 18 anos, é um dos mais novos. Eu mesmo o entrevistei para entrar em um projeto envolvendo PDA/PALM. Achei ele um guri novo, mas que pesava por ter sido o melhor dos entrevistados. Me pareceu com potencial.
O projeto acabou morrendo, embora ele cumpriu o que prometeu (desenvolveu uma aplicação em PDA). E agora está trabalhando fazendo os testes com RFID, para identificarmos casos de aplicabilidade e margem de leitura das antenas (melhores configurações para cada situação).
Inicialmente, nos passaram essa tarefa meio à bangu: "Tem que fazer testes, faz assim, assim e assim". Eu estava atarefado na época e montei uma planilha com as variáveis possíveis e passei para ele testar. Ele fez os testes, mas ficou muito dependente da pessoa que mexe com o software e as antenas.
Na apresentação disso a um dos coordenadores, ele foi bastante criticado, pois os testes não diziam nada. Assumi parte da culpa por não ter orientado ele e então com o meu colega fizemos um esboço de testes. Decidimos utilizar o conceito de cenários. Ou seja, para cada cenário específico, levantaríamos o que queríamos concluir com os testes e "setávamos" as variáveis envolvidas. Pedimos para o guri fazer o plano de testes baseado nisso.
Três dias, e ele continua na mesma. Hoje o meu colega deu um ultimato (de forma clara mas tranquila "Vamos virar essa página hoje?") mas eu senti que ele não havia novamente entendido o que seria o plano de testes. Ali pelas 17h30, sentei com ele e falei: "Ok me mostra o que tu tens". Ele estava fazendo planos de teste baseado novamente apenas nas variáveis... e isso estava gerando 300 casos de teste!!!
Questionei se ele faria tudo isso e ele achou graça. Então falei que ele iria acabar novamente gerando 300 casos de teste e não teria conclusão nenhuma. "O caso 195 foi o que garantiu 100% de leitura", ok, mas e aí? Onde seria aplicado? Como?
Então tive que, literalmente, ditar o documento para ele entender como queríamos. Estruturei o documento, onde eram explicados o cenário, o que queríamos testar, as condições, as variáveis e o objetivo do teste. E então, os planos de testes. Conseguimos queimar algumas variáveis dali, pois elas se sobrepunham (tag entrando do lado esquerdo e direito? Qual a diferença? Então colocamos tag entrando junto à antena). Não sei quantos casos de teste deu, deixei isso como tarefa para ele, mas acredito que não deve ter chegado a 30. E com um objetivo claro definido!
Além disso, com o pior caso possível poderemos propôr outro cenário de testes para tratá-lo. "O caso de teste 24 apresentou um aproveitamento de 30%. Para essa situação, iremos criar o cenário 2...".
Eu entendo que ele é um guri de 18 anos, entendo que a faculdade não ensina o pessoal a escrever, entendo que ele possa ter algumas dúvidas sobre os testes. Mas poxa, chegamos a essas conclusões do documento apenas pensando, imaginando a situação!! Reduzimos as variáveis apenas pensando!
Por que será que alguns dos meus funcionários teimam em não pensar um pouco nas tarefas que damos? A gente incentiva isso! Quando eu digo que as vezes fico desmotivado no trabalho, este é um dos principais motivos... as pessoas que nós gerenciamos parecem que não levam nada a sério.
Sábado, 26 de Abril de 2008
Implantação do SCRUM no laboratório - Parte X
Sexta-feira foi o nosso último dia da dinâmica de uma semana de SCRUM.
Por algumas das pessoas terem provas e trabalhos, ficamos bastante desfalcados. Além disso, um dos grupos teve que deixar uma user story de lado, por solicitação do coordenador, para realizar outra mais crítica.
Nem todos acabaram suas user stories. Mesmo assim, tentei fazer algo parecido com um sprint review (demo), mas foi feito da forma mais precária possível... por quê? Como não utilizamos index cards para detalhar as user stories, não deixamos claro o que seria o DoD (definição de finalizado - Definition of Done). Ou seja, não havia como mensurar ou quantificar se aquelas coisas prometidas estavam feitas de acordo.
Ou seja, a sprint review foi apenas uma formalidade. Não funcionou para nada.
A retrospectiva, por falta de tempo, também tive que adaptar de uma forma mais ágil do que já é! Ou seja, não foi uma retrospectiva, mas quase um feedback.
Juntei todos na sala de reuniões, expliquei que aquela retrospectiva era uma das partes mais importantes do SCRUM e expliquei que teríamos aquela reunião em grupos, não com todos como estava sendo. Falei que são levantados os pontos positivos, negativos e as sugestões de melhorias para o próximo sprint. Então pedi para cada um falar.
De positivo, quase todos disseram que se tratava de uma metodologia legal. Concordaram que a comunicação melhorou bastante, além de todos saberem o que tem que ser feito. Dos comentários um foi bem interessante: um falou que achou o fato das tarefas terem responsáveis muito boa. Por quê? Pois assim as "mijadas" (broncas) seriam endereçadas às pessoas certas. Na hora eu não havia entendido que era isso que ele tinha dito, quem em avisou foi o meu colega, posteriormente.
De negativo, algumas coisas foram levantadas por desconhecimento do SCRUM e outra por falta de crença na mesma! Um falou que achava difícil levantar user stories até o fim do projeto, pois elas mudariam durante o projeto. Então eu expliquei que ele havia entendido errado, pois as mudanças são inerentes aos projetos, principalmente de TI. E mostrei que nós levantamos as user stories, mas só nos preocupamos em detalhar aquelas que iremos fazer. As outras podem sofrer as mudanças que quiserem! Outro comentário foi de que eu e o meu colega estávamos muito ocupados fazendo as reuniões, e isso tirou um pouco a nossa disponibilidade para conversar ou tomar decisões com eles. Expliquei, então, que essa semana foi anormal. Nós estávamos ocupados por estarmos coordenando a implantação e que depois, com os papéis definidos, isso acabaria e nós teríamos muito mais tempo.
O meu colega levantou a última questão que ele achou negativa, mas falou em "private" comigo, após a reunião. Ele disse que estava descrente quanto à reunião diária. Disse que muitas pessoas poderiam acabar "enchendo o saco" de ter que falar todo o dia. E sugeriu a idéia de termos as reuniões na 2a, 4a e 6a. Eu falei que posteriormente, se identificarmos esse descontentamento, podemos analisar isso. Mas, sinceramente, DUVIDO que alguém reclame... a não ser que ele próprio não tenha gostado :)
De melhorias, além de questões de infra-estrutura (um espaço maior para a taskboard e um armário para guardarmos o material dos projetos e também nossas coisas) eles deram duas sugestões para o SCRUM.
O primeiro foi para termos o chart burndown. Como eu esperava, a equipe que já tinha conhecimento do SCRUM, gostou de ter o gráfico representando o andamento. Eu defendo este gráfico, não tanto como informativo, mas mais como agente motivador. É realmente legal ver o nosso andamento graficamente!
E a segunda sugestão foi de termos uma coluna intermediária, após o "DOING", que se chamaria "VERIFY". Teríamos então:
TO DO --- DOING --- VERIFY --- DONE
O "verify" serviria para alguém, possivelmente o Scrum Master ou líder técnico, checar se a tarefa/user story estava finalizada de acordo com o esperado. É bem interessante e faz com que os SM se tornem mais presentes no dia-a-dia... mesmo que ele não tenha conhecimento técnico, pode dizer "ok" ou "não ok". Basta que as tarefas sejam explícitas no que irão produzir.
Então encerramos a reunião e demos fim à nossa dinâmica. Prometi para a semana que vem realizarmos as reuniões para levantarmos o product backlog e já começarmos os sprints. Principalmente porque a diretoria está ansiosa por resultados... mas isso é comum né?!
Muito saiu do meu planejamento durante essa semana. Não consegui praticar as coisas com as equipes como eu queria. Tivemos um review e retrospectiva muito aquém do que devíamos ter... mas no mundo de tecnologia, tempo é algo precioso. E eu tenho que considerar isso. Se não dá para usar o tempo como gostaríamos, temos que nos adaptar de alguma forma.
E com o décimo capítulo, encerro essa "Implantação de SCRUM no laboratório". A partir de agora, irei descrever o dia-a-dia, mas também voltarei a discutir outros assuntos.
Espero que estes posts possam servir como referência e até lições aprendidas para muitos que anseiam em implantar o SCRUM em suas empresas e organizações. Não temam! Se algo ocorrer errado, adaptem. Essa é a palavra-chave.
Abraços!
Por algumas das pessoas terem provas e trabalhos, ficamos bastante desfalcados. Além disso, um dos grupos teve que deixar uma user story de lado, por solicitação do coordenador, para realizar outra mais crítica.
Nem todos acabaram suas user stories. Mesmo assim, tentei fazer algo parecido com um sprint review (demo), mas foi feito da forma mais precária possível... por quê? Como não utilizamos index cards para detalhar as user stories, não deixamos claro o que seria o DoD (definição de finalizado - Definition of Done). Ou seja, não havia como mensurar ou quantificar se aquelas coisas prometidas estavam feitas de acordo.
Ou seja, a sprint review foi apenas uma formalidade. Não funcionou para nada.
A retrospectiva, por falta de tempo, também tive que adaptar de uma forma mais ágil do que já é! Ou seja, não foi uma retrospectiva, mas quase um feedback.
Juntei todos na sala de reuniões, expliquei que aquela retrospectiva era uma das partes mais importantes do SCRUM e expliquei que teríamos aquela reunião em grupos, não com todos como estava sendo. Falei que são levantados os pontos positivos, negativos e as sugestões de melhorias para o próximo sprint. Então pedi para cada um falar.
De positivo, quase todos disseram que se tratava de uma metodologia legal. Concordaram que a comunicação melhorou bastante, além de todos saberem o que tem que ser feito. Dos comentários um foi bem interessante: um falou que achou o fato das tarefas terem responsáveis muito boa. Por quê? Pois assim as "mijadas" (broncas) seriam endereçadas às pessoas certas. Na hora eu não havia entendido que era isso que ele tinha dito, quem em avisou foi o meu colega, posteriormente.
De negativo, algumas coisas foram levantadas por desconhecimento do SCRUM e outra por falta de crença na mesma! Um falou que achava difícil levantar user stories até o fim do projeto, pois elas mudariam durante o projeto. Então eu expliquei que ele havia entendido errado, pois as mudanças são inerentes aos projetos, principalmente de TI. E mostrei que nós levantamos as user stories, mas só nos preocupamos em detalhar aquelas que iremos fazer. As outras podem sofrer as mudanças que quiserem! Outro comentário foi de que eu e o meu colega estávamos muito ocupados fazendo as reuniões, e isso tirou um pouco a nossa disponibilidade para conversar ou tomar decisões com eles. Expliquei, então, que essa semana foi anormal. Nós estávamos ocupados por estarmos coordenando a implantação e que depois, com os papéis definidos, isso acabaria e nós teríamos muito mais tempo.
O meu colega levantou a última questão que ele achou negativa, mas falou em "private" comigo, após a reunião. Ele disse que estava descrente quanto à reunião diária. Disse que muitas pessoas poderiam acabar "enchendo o saco" de ter que falar todo o dia. E sugeriu a idéia de termos as reuniões na 2a, 4a e 6a. Eu falei que posteriormente, se identificarmos esse descontentamento, podemos analisar isso. Mas, sinceramente, DUVIDO que alguém reclame... a não ser que ele próprio não tenha gostado :)
De melhorias, além de questões de infra-estrutura (um espaço maior para a taskboard e um armário para guardarmos o material dos projetos e também nossas coisas) eles deram duas sugestões para o SCRUM.
O primeiro foi para termos o chart burndown. Como eu esperava, a equipe que já tinha conhecimento do SCRUM, gostou de ter o gráfico representando o andamento. Eu defendo este gráfico, não tanto como informativo, mas mais como agente motivador. É realmente legal ver o nosso andamento graficamente!
E a segunda sugestão foi de termos uma coluna intermediária, após o "DOING", que se chamaria "VERIFY". Teríamos então:
TO DO --- DOING --- VERIFY --- DONE
O "verify" serviria para alguém, possivelmente o Scrum Master ou líder técnico, checar se a tarefa/user story estava finalizada de acordo com o esperado. É bem interessante e faz com que os SM se tornem mais presentes no dia-a-dia... mesmo que ele não tenha conhecimento técnico, pode dizer "ok" ou "não ok". Basta que as tarefas sejam explícitas no que irão produzir.
Então encerramos a reunião e demos fim à nossa dinâmica. Prometi para a semana que vem realizarmos as reuniões para levantarmos o product backlog e já começarmos os sprints. Principalmente porque a diretoria está ansiosa por resultados... mas isso é comum né?!
Muito saiu do meu planejamento durante essa semana. Não consegui praticar as coisas com as equipes como eu queria. Tivemos um review e retrospectiva muito aquém do que devíamos ter... mas no mundo de tecnologia, tempo é algo precioso. E eu tenho que considerar isso. Se não dá para usar o tempo como gostaríamos, temos que nos adaptar de alguma forma.
E com o décimo capítulo, encerro essa "Implantação de SCRUM no laboratório". A partir de agora, irei descrever o dia-a-dia, mas também voltarei a discutir outros assuntos.
Espero que estes posts possam servir como referência e até lições aprendidas para muitos que anseiam em implantar o SCRUM em suas empresas e organizações. Não temam! Se algo ocorrer errado, adaptem. Essa é a palavra-chave.
Abraços!
Sexta-feira, 25 de Abril de 2008
Implantação do SCRUM no laboratório - Parte IX - a
Falei que ontem de noite eu havia enviado um email para os meus chefes explicando o porque eu preferia que eles não fossem os "clientes" dessa dinâmica, pois temia que eles não entendessem que utilizamos a semana para eles vivenciarem o SCRUM e desenvolverem pequenas partes dos projetos em que atuam.
Recebi essa resposta por email:
"(...) Como cliente ancioso, gostaria de ver o andamento dos projetos durante esta semana. Pois, acredito que a adocao da metodologia foi um plus no trabalho de cada projeto e entendi que os projetos continuariam fncionando a toda carga. (...)".
A dificil arte de agradar gregos e troianos.
PARTE X
Recebi essa resposta por email:
"(...) Como cliente ancioso, gostaria de ver o andamento dos projetos durante esta semana. Pois, acredito que a adocao da metodologia foi um plus no trabalho de cada projeto e entendi que os projetos continuariam fncionando a toda carga. (...)".
A dificil arte de agradar gregos e troianos.
PARTE X
Quinta-feira, 24 de Abril de 2008
Implantação do SCRUM no laboratório - Parte IX
Segundo dia de sprint. Hoje eu já tentei deixá-los mais "a vontade". Em praticamente todos os grupos surgiram impedimentos, mas só em um deles era um impedimento real. Nos demais eu deixei claro a diferença entre impedimento e pró-atividade, novamente.
O grupo em que já possuia um gerente, eu os deixei à vontade para conduzir a reunião como eles preferissem. E acho que o resultado foi bacana... parece o grupo mais empolgado e ativo no SCRUM. Infelizmente é o grupo que possui mais atividades não-planejadas... muito por culpa do "cliente" deles.
Com o projeto de testes, em que temos uma pessoa só trabalhando, hoje fiz algo bastante interessante. Como se trata de um "gurizão" (como chamamos aqui no Sul :), já que tem menos de 20 anos, ele ainda está naquela fase de insegurança... o meu colega me passou uma idéia para os testes e eu apenas conduzi para que o responsável pelos testes tomasse a decisão que ele achava mais conveniente. Ou seja, ao invés de chegar e dizer "Ok, tu tens que fazer isso, isso e aquilo" eu apresentei duas propostas e na conversa com ele deixei-o decidir pela melhor. E ao mesmo tempo questionei o motivo. O resultado foi que chegamos na mesma conclusão. Foi o primeiro passo para a pró-atividade dele, espero!
No mais, foi um dia corrido, com diversas tarefas para fazer em paralelo. Exatamente o tipo de dia que eu gosto :)
Aliás, estou fazendo jus aquela máxima que diz que "o gerente de projetos é sempre aquele que nunca está na sua mesa". Estou sempre em reunião, em contato com meus subordinados, colegas, chefes... ou seja, em total comunicação. Hoje eu posso dizer tranquilamente o que cada uma das pessoas está fazendo dentro do laboratório. Ou seja, aparentemente o problema de comunicação está quase resolvido!
------------------------------------------------
Amanhã é o dia da sprint review (demo) e retrospectiva. Ainda não me preparei para isso, mas já avisei a eles que EU serei o cliente, ao contrário dos nossos chefes. O motivo? Não quero inibí-los... tanto os chefes quanto as equipes. Será difícil para os chefes entenderem que tivemos uma dinâmica nessa uma semana e, portanto, os "entregáveis" são bem pequenos, quase nada. E isso pode fazer com que passe a imagem de que o SCRUM não trouxe benefício nenhum. De lambuja, ainda pode desmotivar as equipes.
Avisei a todos, porém, que eu serei um cliente fiel. Vou dar o feedback necessário, conforme o que foi prometido. Eles tem que sentir, mesmo que de forma teatral, como seria a reação com um cliente caso eles não entreguem ou entreguem sem qualidade.
Vou até preparar um "checklist" de perguntas que farei ;)
----------------------------------------------------
Para a semana que vem pretendo criar o product backlog real com todas as equipes. Talvez demore a semana toda... mas gostaria de que na 5a e 6a pudessemos iniciar as reuniões já. Tomara que dê tempo.
Abraços a todos!
PARTE IX - a
O grupo em que já possuia um gerente, eu os deixei à vontade para conduzir a reunião como eles preferissem. E acho que o resultado foi bacana... parece o grupo mais empolgado e ativo no SCRUM. Infelizmente é o grupo que possui mais atividades não-planejadas... muito por culpa do "cliente" deles.
Com o projeto de testes, em que temos uma pessoa só trabalhando, hoje fiz algo bastante interessante. Como se trata de um "gurizão" (como chamamos aqui no Sul :), já que tem menos de 20 anos, ele ainda está naquela fase de insegurança... o meu colega me passou uma idéia para os testes e eu apenas conduzi para que o responsável pelos testes tomasse a decisão que ele achava mais conveniente. Ou seja, ao invés de chegar e dizer "Ok, tu tens que fazer isso, isso e aquilo" eu apresentei duas propostas e na conversa com ele deixei-o decidir pela melhor. E ao mesmo tempo questionei o motivo. O resultado foi que chegamos na mesma conclusão. Foi o primeiro passo para a pró-atividade dele, espero!
No mais, foi um dia corrido, com diversas tarefas para fazer em paralelo. Exatamente o tipo de dia que eu gosto :)
Aliás, estou fazendo jus aquela máxima que diz que "o gerente de projetos é sempre aquele que nunca está na sua mesa". Estou sempre em reunião, em contato com meus subordinados, colegas, chefes... ou seja, em total comunicação. Hoje eu posso dizer tranquilamente o que cada uma das pessoas está fazendo dentro do laboratório. Ou seja, aparentemente o problema de comunicação está quase resolvido!
------------------------------------------------
Amanhã é o dia da sprint review (demo) e retrospectiva. Ainda não me preparei para isso, mas já avisei a eles que EU serei o cliente, ao contrário dos nossos chefes. O motivo? Não quero inibí-los... tanto os chefes quanto as equipes. Será difícil para os chefes entenderem que tivemos uma dinâmica nessa uma semana e, portanto, os "entregáveis" são bem pequenos, quase nada. E isso pode fazer com que passe a imagem de que o SCRUM não trouxe benefício nenhum. De lambuja, ainda pode desmotivar as equipes.
Avisei a todos, porém, que eu serei um cliente fiel. Vou dar o feedback necessário, conforme o que foi prometido. Eles tem que sentir, mesmo que de forma teatral, como seria a reação com um cliente caso eles não entreguem ou entreguem sem qualidade.
Vou até preparar um "checklist" de perguntas que farei ;)
----------------------------------------------------
Para a semana que vem pretendo criar o product backlog real com todas as equipes. Talvez demore a semana toda... mas gostaria de que na 5a e 6a pudessemos iniciar as reuniões já. Tomara que dê tempo.
Abraços a todos!
PARTE IX - a
Quarta-feira, 23 de Abril de 2008
Implantação do SCRUM no laboratório - Parte VIII
Primeiro dia oficial do sprint relâmpago. Algumas constatações:
- Para a equipe que já possui experiência em SCRUM, utilizamos o tempo para levantar as atividades, coisa que ficou faltando ontem. Feito isso, encerrou-se a reunião com eles. Não há muito o que falar ou explicar.
- Para a equipe da API, a função principal foi introduzí-los ao daily scrum, sendo eles liderados pelo meu colega. Foi um momento interessante, onde eu apenas assisti e escutei. Ao final, expressei ao meu colega que ele cometera dois erros: discutiu assuntos técnicos DURANTE a reunião (o que fez com que perdessemos tempo nisso) e não questionou a equipe sobre impedimentos, esperou que eles mencionassem alguma coisa. Além disso, notei que a equipe falou como se estivesse se reportando ao gerente e não à própria equipe. Essa é uma das coisas mais difíceis de mudar no pessoal, mas acredito que eles vão estar sentindo a reunião como um acerto de ponteiros e não como um "report" em breve.
- Para a equipe de um projeto de HW, no qual o scrum master é o gerente da própria equipe, eu apenas expliquei rapidamente o que se tratava a daily scrum e depois solicitei ao scrum master que conduzisse a reunião, sendo que eu apenas escutaria e não iria intervir. Foi uma reunião bem bacana, para a primeira vez de todos ali! Levantamos tarefas não-planejadas, todos disseram o que fizeram e o que pretendem fazer para a amanhã e também levantamos o primeiro impedimento. Um dos projetos de HW foi modificado por um dos "chickens" (cliente) e ainda não foi reenviado para a equipe. Agora o scrum master terá já um impedimento para atacar. Depois da reunião, eles trataram rapidamente de assuntos técnicos, sendo bem como eu estava planejando. No final, um dos guris da equipe veio falar que a reunião estava sendo bem legal pois ele estava começando a se sentir mais "dentro" do projeto. Ele reclamou que no projeto anterior ele recebia demandas de diversas pessoas diferentes e no final era cobrado por uma delas só (que nunca estava pronta). É o tipo de pessoa que eu sempre escutei que "ele só fica na internet, não trabalha", mas acho que agora começo a entender que era um funcionário que estava com a motivação a dois palmos abaixo do fundo do poço. E noto nele um foco de motivação com essa mudança. Felizmente! E fico feliz por ele dar este feedback.
- Por fim, para o outro projeto, de testes, estamos com mais dúvidas do que soluções. Não sabemos ao certo o que testar, pois para qualquer caso são muitas variáveis envolvidas. Então decidimos começar do básico... testar uma antena por completa para saber TUDO sobre ela: potencia, angulo de atuação, leitura, etc. Mas perdemos boa parte da tarde discutindo. Como é um projeto em que apenas UMA pessoa está trabalhando não seria justo exigir algo muito pesado. Então a "user story" deste projeto para esse sprint relâmpago será a criação do plano de testes documentado.
==========================================
Hoje o meu colega, que está atuando comigo, também falou que uma das coisas que desmotiva aqui no trabalho é a falta de pró-atividade das pessoas. Ele comentou como é chato ter que estar sempre tendo que apontar os caminhos para os funcionários... lembram daquela máxima: "Traga-me soluções e não problemas"? Pois é, isso não se aplica aqui.
Mas isso é algo que quero atacar DEPOIS. Primeiro, é a comunicação.
Abraços
PARTE IX
- Para a equipe que já possui experiência em SCRUM, utilizamos o tempo para levantar as atividades, coisa que ficou faltando ontem. Feito isso, encerrou-se a reunião com eles. Não há muito o que falar ou explicar.
- Para a equipe da API, a função principal foi introduzí-los ao daily scrum, sendo eles liderados pelo meu colega. Foi um momento interessante, onde eu apenas assisti e escutei. Ao final, expressei ao meu colega que ele cometera dois erros: discutiu assuntos técnicos DURANTE a reunião (o que fez com que perdessemos tempo nisso) e não questionou a equipe sobre impedimentos, esperou que eles mencionassem alguma coisa. Além disso, notei que a equipe falou como se estivesse se reportando ao gerente e não à própria equipe. Essa é uma das coisas mais difíceis de mudar no pessoal, mas acredito que eles vão estar sentindo a reunião como um acerto de ponteiros e não como um "report" em breve.
- Para a equipe de um projeto de HW, no qual o scrum master é o gerente da própria equipe, eu apenas expliquei rapidamente o que se tratava a daily scrum e depois solicitei ao scrum master que conduzisse a reunião, sendo que eu apenas escutaria e não iria intervir. Foi uma reunião bem bacana, para a primeira vez de todos ali! Levantamos tarefas não-planejadas, todos disseram o que fizeram e o que pretendem fazer para a amanhã e também levantamos o primeiro impedimento. Um dos projetos de HW foi modificado por um dos "chickens" (cliente) e ainda não foi reenviado para a equipe. Agora o scrum master terá já um impedimento para atacar. Depois da reunião, eles trataram rapidamente de assuntos técnicos, sendo bem como eu estava planejando. No final, um dos guris da equipe veio falar que a reunião estava sendo bem legal pois ele estava começando a se sentir mais "dentro" do projeto. Ele reclamou que no projeto anterior ele recebia demandas de diversas pessoas diferentes e no final era cobrado por uma delas só (que nunca estava pronta). É o tipo de pessoa que eu sempre escutei que "ele só fica na internet, não trabalha", mas acho que agora começo a entender que era um funcionário que estava com a motivação a dois palmos abaixo do fundo do poço. E noto nele um foco de motivação com essa mudança. Felizmente! E fico feliz por ele dar este feedback.
- Por fim, para o outro projeto, de testes, estamos com mais dúvidas do que soluções. Não sabemos ao certo o que testar, pois para qualquer caso são muitas variáveis envolvidas. Então decidimos começar do básico... testar uma antena por completa para saber TUDO sobre ela: potencia, angulo de atuação, leitura, etc. Mas perdemos boa parte da tarde discutindo. Como é um projeto em que apenas UMA pessoa está trabalhando não seria justo exigir algo muito pesado. Então a "user story" deste projeto para esse sprint relâmpago será a criação do plano de testes documentado.
==========================================
Hoje o meu colega, que está atuando comigo, também falou que uma das coisas que desmotiva aqui no trabalho é a falta de pró-atividade das pessoas. Ele comentou como é chato ter que estar sempre tendo que apontar os caminhos para os funcionários... lembram daquela máxima: "Traga-me soluções e não problemas"? Pois é, isso não se aplica aqui.
Mas isso é algo que quero atacar DEPOIS. Primeiro, é a comunicação.
Abraços
PARTE IX
Terça-feira, 22 de Abril de 2008
Implantação do SCRUM no laboratório - Parte VII
Hoje foi o primeiro dia da "dinâmica".
Primeiramente, me deparei com alguns problemas operacionais. Comprei post-its (rosa, amarelo, laranja e um reciclável) e três cartolinas. As cartolinas eram pequenas... só vi na hora em que coloquei os post-its. Nada que atrapalhe para ESSA semana, mas para as demais, teremos que rever algumas coisas.
Bom, eu havia marcado para a partir das 14h começar a fazer as reuniões. 15h30 começamos, pois foi a hora que pelo menos UM dos grupos estava totalmente presente.
Eu cheguei as 13h. Fiquei montando os cartazes (taskboards) e pensando em formas de usar o processo no resto da semana. Essa demora para o pessoal chegar já me desmotivou um pouco. Eu noto que eles estão bem interessados em aplicar o SCRUM, mas por ser um laboratório de pesquisa, eles também se sentem descompromissados. É a velha reclamação sobre comprometimento... é dose, não sei mais como usar argumentos e conversar a respeito.
Nessas 1h30 (+/-) que fiquei sozinho, refleti sobre a dificuldade que terei em atingir os objetivos que pretendo. Por um lado eu encaro isso como um baita desafio... é aquela coisa de que temos que superar os limites com os recursos que temos, de ser posteriormente reconhecido por isso. Porém, ao mesmo tempo bate o desânimo em contar com pessoas que faltam um pouco com suas responsabilidades.
Bom, a reunião acabou sendo prejudicada também pois não consegui imprimir as index cards e nem as cartas para o planning poker. Então foi tudo improvisado. O feriado me atrapalhou um pouco e hoje de manhã acabei não tendo tempo de fazer isso.
A agenda foi a seguinte, com cada grupo: homologar as user stories, estimá-las com planning poker (só para eles saberem como funciona), gerar as tarefas e depois agendar a daily scrum.
Definimos que os post-its terão as seguintes cores:
AMARELO (padrão) : tarefas planejadas (planned tasks)
LARANJA : user stories
ROSA : tarefas não planejadas (unplanned tasks)
RECICLADOS : impedimentos
Cada tarefa deve ter no máximo 1 dia de duração, com no mínimo meio-dia. Definimos também que cada tarefa deverá ter só o nome da pessoa que está a fazendo, ou que responderá por ela (caso seja feita por mais de uma pessoa).
Um dos grupos foi bem tranquilo isso, o problema é que é o único projeto em que eu não tenho a menor idéia do que se trata. hehe
Outro grupo também foi tranquilo, pois foi o meu projeto piloto quando fiz a experiência com SCRUM. Eles já conhecem o processo todo.
Porém, nos outros três projetos tivemos problemas.
Um deles, decidimos momentaneamente tirar da dinâmica. Motivo? É um projeto muito teórico que é a base de dois mestrados e alguns trabalhos de conclusão e doutorado. Não consigo ver a geração de valor nele, pois haverá pesquisa, pesquisa e mais pesquisa. Seriam artefatos na forma de relatórios... além disso, as duas pessoas responsáveis não estão mais no laboratório, mas nas baias que servem para os mestrandos/doutorandos. Não teriam a taskboard à vista. E eles não possuem um gerente de projetos... essa é a figura direta de um dos coordenadores. Enfim, um projeto bem difícil e bem complicado para aplicar SCRUM. Decidimos deixá-lo de lado no momento.
O outro projeto trata exclusivamente de testes com RFID. Notamos que a pessoa (é uma só) responsável por ele, estava gerando testes e mais testes mas só obtendo dados... sem ter muita informação. Decidimos então criar cenários de testes, para homologarmos qual será a melhor configuração para captar o máximo de tags para aquela situação específica. Assim teremos um objetivo bem claro e um resultado aparente. Este projeto deixamos em separado, pois como envolve uma pessoa apenas, iremos exigir na dinâmica apenas um "ante-projeto" destes testes. Nada mais.
E por fim, o outro projeto problemático. O SCRUM prevê user stories onde representam a interação do sistema com o usuário. Exemplos de user stories, que achamos por aí:
"O usuário pode depositar o dinheiro na conta"
"O usuário pode definir quais são as pessoas que podem visualizar seu perfil"
"O usuário pode buscar livros pelo autor, nome do livro e código"
São coisas bem específicas e fáceis de visualizar. Mas um dos "projetos" é a criação de uma API para a comunicação da leitora de RFID com a antena. E aí, não há como definir um usuário!! Ficamos quase 1 hora em reunião para conseguir achar duas míseras user stories para essa situação e acabamos definindo coisas técnicas: a geração da versão em Java e a modelagem e estrutura padrão para as API's.
Nessa hora eu percebi como o conceito de user story precisa ser aprofundado por mim e pelo meu colega que está me auxiliando. Ainda temos dúvidas nesse tipo de situação. Um sistema pode ser um ator? E no caso de envolver só hardware ou este tipo de camada mais baixa? Criamos uma user story grandona (que suba até o alto nível) ou deixamos ela mais técnica mesmo? Questionamentos, questionamentos...
Foi um dia de reuniões, pra variar. Agora irei disparar um email avisando os grupos dos horários das daily scrum. E vamos começar a ver o que acontece. Tomara que todos consigam cumprir suas user stories, pois não estamos exigindo nada demais.
Vou levantar um questionário e tasklist de itens que precisamos levantar para a semana que vem, para termos uma taskboard direita e também para lembrarmos de coisas para a retrospectiva.
Ufa, o dia hoje foi isso. Conversa, conversa e um pouco de desmotivação...
Será que consigo mudar? O tempo dirá.
Um abraço a todos!
PARTE VIII
Primeiramente, me deparei com alguns problemas operacionais. Comprei post-its (rosa, amarelo, laranja e um reciclável) e três cartolinas. As cartolinas eram pequenas... só vi na hora em que coloquei os post-its. Nada que atrapalhe para ESSA semana, mas para as demais, teremos que rever algumas coisas.
Bom, eu havia marcado para a partir das 14h começar a fazer as reuniões. 15h30 começamos, pois foi a hora que pelo menos UM dos grupos estava totalmente presente.
Eu cheguei as 13h. Fiquei montando os cartazes (taskboards) e pensando em formas de usar o processo no resto da semana. Essa demora para o pessoal chegar já me desmotivou um pouco. Eu noto que eles estão bem interessados em aplicar o SCRUM, mas por ser um laboratório de pesquisa, eles também se sentem descompromissados. É a velha reclamação sobre comprometimento... é dose, não sei mais como usar argumentos e conversar a respeito.
Nessas 1h30 (+/-) que fiquei sozinho, refleti sobre a dificuldade que terei em atingir os objetivos que pretendo. Por um lado eu encaro isso como um baita desafio... é aquela coisa de que temos que superar os limites com os recursos que temos, de ser posteriormente reconhecido por isso. Porém, ao mesmo tempo bate o desânimo em contar com pessoas que faltam um pouco com suas responsabilidades.
Bom, a reunião acabou sendo prejudicada também pois não consegui imprimir as index cards e nem as cartas para o planning poker. Então foi tudo improvisado. O feriado me atrapalhou um pouco e hoje de manhã acabei não tendo tempo de fazer isso.
A agenda foi a seguinte, com cada grupo: homologar as user stories, estimá-las com planning poker (só para eles saberem como funciona), gerar as tarefas e depois agendar a daily scrum.
Definimos que os post-its terão as seguintes cores:
AMARELO (padrão) : tarefas planejadas (planned tasks)
LARANJA : user stories
ROSA : tarefas não planejadas (unplanned tasks)
RECICLADOS : impedimentos
Cada tarefa deve ter no máximo 1 dia de duração, com no mínimo meio-dia. Definimos também que cada tarefa deverá ter só o nome da pessoa que está a fazendo, ou que responderá por ela (caso seja feita por mais de uma pessoa).
Um dos grupos foi bem tranquilo isso, o problema é que é o único projeto em que eu não tenho a menor idéia do que se trata. hehe
Outro grupo também foi tranquilo, pois foi o meu projeto piloto quando fiz a experiência com SCRUM. Eles já conhecem o processo todo.
Porém, nos outros três projetos tivemos problemas.
Um deles, decidimos momentaneamente tirar da dinâmica. Motivo? É um projeto muito teórico que é a base de dois mestrados e alguns trabalhos de conclusão e doutorado. Não consigo ver a geração de valor nele, pois haverá pesquisa, pesquisa e mais pesquisa. Seriam artefatos na forma de relatórios... além disso, as duas pessoas responsáveis não estão mais no laboratório, mas nas baias que servem para os mestrandos/doutorandos. Não teriam a taskboard à vista. E eles não possuem um gerente de projetos... essa é a figura direta de um dos coordenadores. Enfim, um projeto bem difícil e bem complicado para aplicar SCRUM. Decidimos deixá-lo de lado no momento.
O outro projeto trata exclusivamente de testes com RFID. Notamos que a pessoa (é uma só) responsável por ele, estava gerando testes e mais testes mas só obtendo dados... sem ter muita informação. Decidimos então criar cenários de testes, para homologarmos qual será a melhor configuração para captar o máximo de tags para aquela situação específica. Assim teremos um objetivo bem claro e um resultado aparente. Este projeto deixamos em separado, pois como envolve uma pessoa apenas, iremos exigir na dinâmica apenas um "ante-projeto" destes testes. Nada mais.
E por fim, o outro projeto problemático. O SCRUM prevê user stories onde representam a interação do sistema com o usuário. Exemplos de user stories, que achamos por aí:
"O usuário pode depositar o dinheiro na conta"
"O usuário pode definir quais são as pessoas que podem visualizar seu perfil"
"O usuário pode buscar livros pelo autor, nome do livro e código"
São coisas bem específicas e fáceis de visualizar. Mas um dos "projetos" é a criação de uma API para a comunicação da leitora de RFID com a antena. E aí, não há como definir um usuário!! Ficamos quase 1 hora em reunião para conseguir achar duas míseras user stories para essa situação e acabamos definindo coisas técnicas: a geração da versão em Java e a modelagem e estrutura padrão para as API's.
Nessa hora eu percebi como o conceito de user story precisa ser aprofundado por mim e pelo meu colega que está me auxiliando. Ainda temos dúvidas nesse tipo de situação. Um sistema pode ser um ator? E no caso de envolver só hardware ou este tipo de camada mais baixa? Criamos uma user story grandona (que suba até o alto nível) ou deixamos ela mais técnica mesmo? Questionamentos, questionamentos...
Foi um dia de reuniões, pra variar. Agora irei disparar um email avisando os grupos dos horários das daily scrum. E vamos começar a ver o que acontece. Tomara que todos consigam cumprir suas user stories, pois não estamos exigindo nada demais.
Vou levantar um questionário e tasklist de itens que precisamos levantar para a semana que vem, para termos uma taskboard direita e também para lembrarmos de coisas para a retrospectiva.
Ufa, o dia hoje foi isso. Conversa, conversa e um pouco de desmotivação...
Será que consigo mudar? O tempo dirá.
Um abraço a todos!
PARTE VIII
Sábado, 19 de Abril de 2008
Implantação do SCRUM no laboratório - Parte VI
Conforme o planejado, hoje foi o dia em que sentamos com cada uma das equipes (definimos que teremos CINCO projetos) e definimos quais seriam as user stories que eles teriam que cumprir até o fim.
Usei bastante o conceito do livro "User stories" do Mike Cohn, onde ele geralmente descreve uma user story com "Um usuário [pode/deve] [fazer algo de alto nível]".
Ou seja, por exemplo:
* Um usuário pode clicar em diversos pontos do simulador e o sistema irá apresentar as curvas paralelas resultantes (user story de um dos projetos)
* Um usuário pode passar diversos objetos na antena e o sistema apresentará os resultados
Como somos um grupo de pesquisa e a maioria dos projetos envolve hardware ou software de baixo nível, precisamos adequar as User Stories à nossa realidade. A maioria dos livros tratam as user stories como software de mais alto nível ("Um usuário pode buscar pelo nome de um livro" ou "Um usuário pode excluir seus dados pessoais"). Então temos que tentar buscar uma forma de manter o conceito mas adaptando ao máximo para nossa realidade.
Tivemos dificuldades em abstrair isso, mas é assim que a gente aprende: na prática!
Só não conseguimos fechar as user stories de dois projetos. Um pelos membros não terem aparecido e o outro pelo assunto ser muito técnico e nebuloso. Iremos tentar achar alguma parte que possamos apresentar.
Como eu disse, a idéia é fazê-los vencer essa etapa e não sofrer uma nova derrota.
========================================================
No fim do dia, eu e o outro gerente também discutimos a respeito da nova ordem de comunicação que implanteremos. Atualmente vivemos algo como três níveis de hierarquia:
COORDENADORES
GERENTES
EQUIPES
A comunicação correta seria de que os gerentes fossem um filtro. No máximo, na minha opinião, as equipes pudessem consultar os coordenadores. Porém, é comum os coordenadores comunicarem diretamente com as equipes, deixando os gerentes de mãos atadas.
Hoje ocorreu um caso típico: soubemos que um dos recursos de um projeto seria desligado do laboratório e passaria para a empresa parceira. Fomos os últimos a saber, lógico. E contávamos com ele para o nosso planejamento.
Com o SCRUM, a nossa idéia é criar mais um nível hierárquico, algo assim:
CLIENTES / COORDENADORES (stakeholders ou "chickens")
PRODUCT OWNERS
SCRUM MASTERS
EQUIPE
A primeira coisa que você deve estar pensando, aposto, é: "Pô, eles tão tornando tudo mais burocrático aumentando a hierarquia". Eu digo que não, e vou explicar o porque.
Primeiro, pois na nossa visão estaremos deixando os coordenadores apenas como "chickens", ou seja, apenas como envolvidos no projeto e não mais comprometendo eles. Nossos coordenadores já estão com demandas e tarefas até o pescoço! São professores universitários, então eles tem que orientar doutorado, mestrado, dar aulas, corrigir TCC, auxiliar os projetos, etc. Muita coisa!
Segundo, pois isolando os coordenadores, estaremos obrigatoriamente dando os poderes de decisão aos product owners. A minha idéia é que eu e o outro gerente nos transformemos nestes product owners. Porém, lógico, para que isso aconteça, precisamos encontrar scrum masters adequados. E isso vai demandar tempo.
Terceiro, pois criando mais uma hierarquia, deixamos muito mais difícil a comunicação direta entre os coordenadores e as equipes, o caso mais problemático. Em contrapartida, se isso ocorrer, serão DOIS níveis que estarão sem essa "informação".
Ainda assim, acredito que valerá a pena. Os coordenadores trabalharão como clientes ou com os clientes. E caberá aos P.O.'s fazerem essa interface com as equipes e manter os clientes/coordenadores informados do andamento das coisas.
Enfim, iremos apresentar essa proposta de mudança e eu tentarei expôr exatamente o que estou dizendo aqui. Precisaremos do comprometimento deles em acatar isso e não cobrarem as equipes diretamente, ou pior, dar demandas diretamente. Os recursos estão ficando escassos, se eles nos jogarem mais este problema no colo, a situação ficará difícil!
==================================================================
Também ao final da reunião expressei ao outro gerente qual é o meu plano para longo prazo, para o laboratório: torná-lo uma referência dentro da universidade. Como iremos fazer isso?
Bom, um passo de cada vez. Primeiro vamos nos tornar produtivos. Depois vamos buscar começar a aparecer de alguma forma. Os frutos começarão daí.
==============================================================
Terça-feira de manhã iremos adequar todo o laboratório com as taskboards prontas para receberem as user stories e atividades. Terei que comprar todo material de escritório necessário. Vou bancar do bolso, nesse primeiro momento. Depois eu peço um reembolso ;)
Um ótimo final de semana a vocês.
Abraços
PARTE VII
Usei bastante o conceito do livro "User stories" do Mike Cohn, onde ele geralmente descreve uma user story com "Um usuário [pode/deve] [fazer algo de alto nível]".
Ou seja, por exemplo:
* Um usuário pode clicar em diversos pontos do simulador e o sistema irá apresentar as curvas paralelas resultantes (user story de um dos projetos)
* Um usuário pode passar diversos objetos na antena e o sistema apresentará os resultados
Como somos um grupo de pesquisa e a maioria dos projetos envolve hardware ou software de baixo nível, precisamos adequar as User Stories à nossa realidade. A maioria dos livros tratam as user stories como software de mais alto nível ("Um usuário pode buscar pelo nome de um livro" ou "Um usuário pode excluir seus dados pessoais"). Então temos que tentar buscar uma forma de manter o conceito mas adaptando ao máximo para nossa realidade.
Tivemos dificuldades em abstrair isso, mas é assim que a gente aprende: na prática!
Só não conseguimos fechar as user stories de dois projetos. Um pelos membros não terem aparecido e o outro pelo assunto ser muito técnico e nebuloso. Iremos tentar achar alguma parte que possamos apresentar.
Como eu disse, a idéia é fazê-los vencer essa etapa e não sofrer uma nova derrota.
========================================================
No fim do dia, eu e o outro gerente também discutimos a respeito da nova ordem de comunicação que implanteremos. Atualmente vivemos algo como três níveis de hierarquia:
COORDENADORES
GERENTES
EQUIPES
A comunicação correta seria de que os gerentes fossem um filtro. No máximo, na minha opinião, as equipes pudessem consultar os coordenadores. Porém, é comum os coordenadores comunicarem diretamente com as equipes, deixando os gerentes de mãos atadas.
Hoje ocorreu um caso típico: soubemos que um dos recursos de um projeto seria desligado do laboratório e passaria para a empresa parceira. Fomos os últimos a saber, lógico. E contávamos com ele para o nosso planejamento.
Com o SCRUM, a nossa idéia é criar mais um nível hierárquico, algo assim:
CLIENTES / COORDENADORES (stakeholders ou "chickens")
PRODUCT OWNERS
SCRUM MASTERS
EQUIPE
A primeira coisa que você deve estar pensando, aposto, é: "Pô, eles tão tornando tudo mais burocrático aumentando a hierarquia". Eu digo que não, e vou explicar o porque.
Primeiro, pois na nossa visão estaremos deixando os coordenadores apenas como "chickens", ou seja, apenas como envolvidos no projeto e não mais comprometendo eles. Nossos coordenadores já estão com demandas e tarefas até o pescoço! São professores universitários, então eles tem que orientar doutorado, mestrado, dar aulas, corrigir TCC, auxiliar os projetos, etc. Muita coisa!
Segundo, pois isolando os coordenadores, estaremos obrigatoriamente dando os poderes de decisão aos product owners. A minha idéia é que eu e o outro gerente nos transformemos nestes product owners. Porém, lógico, para que isso aconteça, precisamos encontrar scrum masters adequados. E isso vai demandar tempo.
Terceiro, pois criando mais uma hierarquia, deixamos muito mais difícil a comunicação direta entre os coordenadores e as equipes, o caso mais problemático. Em contrapartida, se isso ocorrer, serão DOIS níveis que estarão sem essa "informação".
Ainda assim, acredito que valerá a pena. Os coordenadores trabalharão como clientes ou com os clientes. E caberá aos P.O.'s fazerem essa interface com as equipes e manter os clientes/coordenadores informados do andamento das coisas.
Enfim, iremos apresentar essa proposta de mudança e eu tentarei expôr exatamente o que estou dizendo aqui. Precisaremos do comprometimento deles em acatar isso e não cobrarem as equipes diretamente, ou pior, dar demandas diretamente. Os recursos estão ficando escassos, se eles nos jogarem mais este problema no colo, a situação ficará difícil!
==================================================================
Também ao final da reunião expressei ao outro gerente qual é o meu plano para longo prazo, para o laboratório: torná-lo uma referência dentro da universidade. Como iremos fazer isso?
Bom, um passo de cada vez. Primeiro vamos nos tornar produtivos. Depois vamos buscar começar a aparecer de alguma forma. Os frutos começarão daí.
==============================================================
Terça-feira de manhã iremos adequar todo o laboratório com as taskboards prontas para receberem as user stories e atividades. Terei que comprar todo material de escritório necessário. Vou bancar do bolso, nesse primeiro momento. Depois eu peço um reembolso ;)
Um ótimo final de semana a vocês.
Abraços
PARTE VII
Sexta-feira, 18 de Abril de 2008
Implantação do SCRUM no laboratório - Parte V - a
Uma coisa que esqueci de comentar e acredito que seja muito importante.
É preciso fazer com que as user stories que levantaremos para cada um dos projetos (os seis deles) sejam pequenas e, principalmente, que sejam factíveis de serem feitas três dias de trabalho.
Caso contrário, o resultado do sprint "zero" será a vivência deles no que eles estão acostumados há tempos: o fracasso!
Muito cuidado nessa hora...
PARTE VI
É preciso fazer com que as user stories que levantaremos para cada um dos projetos (os seis deles) sejam pequenas e, principalmente, que sejam factíveis de serem feitas três dias de trabalho.
Caso contrário, o resultado do sprint "zero" será a vivência deles no que eles estão acostumados há tempos: o fracasso!
Muito cuidado nessa hora...
PARTE VI
Quinta-feira, 17 de Abril de 2008
Implantação do SCRUM no laboratório - Parte V
Tcharam!
O dia da apresentação chegou.
Procurei chegar um pouco mais cedo no trabalho, com o intuito de já ir adiantando a preparação do notebook, projetor, etc. O horário era 13h45.
Entrei no auditório do prédio, instalei algumas coisas e fui verificar se estava tudo ok com a apresentação. Nisso chegou o meu colega que será o meu braço direito nesse processo todo. Conversávamos enquanto eu fui fazendo isso. O horário era 13h55.
As 14h05 chegou a primeira leva do guris. Um terço deles, dá pra dizer. Às 14h15 chegou a segunda leva. Às 14h20 chegaram os coordenadores e o resto do pessoal.
Enfim, comecei a apresentação às 14h30. Era o horário que eu queria ter marcado, MAS um dos coordenadores falou que era melhor começar as 14h........ :/
Como eu havia pensando, avisei no início que quem tivesse dúvidas que escrevesse em um papel para perguntar ao final da apresentação. Por que? Para evitar que gerasse uma discussão paralela no meio da apresentação.
A apresentação transcorreu muito bem. Achei que eu ficaria um tanto perdido em algum momento, mas o único momento em que eu senti que me embananei um pouco, foi ao explicar a tirinha dos "porcos e galinhas". Acho que quis explicar demais e acabei enrolando. Nada que afetasse.
Procurei colocar algumas interações com o grupo, para não ficar só uma falação. E foi legal para descontrair.
Ah, como eu mencionei no post anterior, coloquei um slide para falar a respeito dos resultados da minha "pesquisa com os grupos" de ontem. Iniciei falando sobre o que é um projeto, quais são as suas características... e daí expus o motivo daquilo. Os problemas que estavam acontecendo lá e que eu consegui identificá-los de forma explícita.
A apresentação original estava prevista para ter 25 slides. Mas, comecei a perceber que ela poderia vir a ser uma referência para o pessoal, posteriormente, ao ser impressa em PDF. Portanto acabei deixando ela bem completa, com alguns exemplos para contextualizar situações.
No fim, acredito que todos ficaram satisfeitos. Notei, na prática, que alguns itens estavam fora de ordem (falava sobre previsto x realizado antes de falar de sprint, por exemplo). Mas, como eu disse, nada que fosse tão ruim a ponto de deixá-los perdidos.
Acredito que vendi o peixe! Ao final da apresentação, todos se mostravam dispostos a experiementar o SCRUM... a vivenciar a dinâmica que aplicaremos de 6a a 6a feira. Agora terei BASTANTE trabalho pois atuarei como coach, scrum master e product owner ao mesmo tempo! Mas vai valer a pena!
Espero que na outra sexta-feira eu esteja aqui escrevendo os resultados sensacionais que tivemos. Espero mesmo!
Para quem quiser fazer download, o link está aqui embaixo. A apresentação em PDF :)
DOWNLOAD DA APRESENTAÇÃO EM PDF
Ou entrem na seção de downloads e vão em "Material de apoio MPE" :)
Abração
PARTE V - a
O dia da apresentação chegou.
Procurei chegar um pouco mais cedo no trabalho, com o intuito de já ir adiantando a preparação do notebook, projetor, etc. O horário era 13h45.
Entrei no auditório do prédio, instalei algumas coisas e fui verificar se estava tudo ok com a apresentação. Nisso chegou o meu colega que será o meu braço direito nesse processo todo. Conversávamos enquanto eu fui fazendo isso. O horário era 13h55.
As 14h05 chegou a primeira leva do guris. Um terço deles, dá pra dizer. Às 14h15 chegou a segunda leva. Às 14h20 chegaram os coordenadores e o resto do pessoal.
Enfim, comecei a apresentação às 14h30. Era o horário que eu queria ter marcado, MAS um dos coordenadores falou que era melhor começar as 14h........ :/
Como eu havia pensando, avisei no início que quem tivesse dúvidas que escrevesse em um papel para perguntar ao final da apresentação. Por que? Para evitar que gerasse uma discussão paralela no meio da apresentação.
A apresentação transcorreu muito bem. Achei que eu ficaria um tanto perdido em algum momento, mas o único momento em que eu senti que me embananei um pouco, foi ao explicar a tirinha dos "porcos e galinhas". Acho que quis explicar demais e acabei enrolando. Nada que afetasse.
Procurei colocar algumas interações com o grupo, para não ficar só uma falação. E foi legal para descontrair.
Ah, como eu mencionei no post anterior, coloquei um slide para falar a respeito dos resultados da minha "pesquisa com os grupos" de ontem. Iniciei falando sobre o que é um projeto, quais são as suas características... e daí expus o motivo daquilo. Os problemas que estavam acontecendo lá e que eu consegui identificá-los de forma explícita.
A apresentação original estava prevista para ter 25 slides. Mas, comecei a perceber que ela poderia vir a ser uma referência para o pessoal, posteriormente, ao ser impressa em PDF. Portanto acabei deixando ela bem completa, com alguns exemplos para contextualizar situações.
No fim, acredito que todos ficaram satisfeitos. Notei, na prática, que alguns itens estavam fora de ordem (falava sobre previsto x realizado antes de falar de sprint, por exemplo). Mas, como eu disse, nada que fosse tão ruim a ponto de deixá-los perdidos.
Acredito que vendi o peixe! Ao final da apresentação, todos se mostravam dispostos a experiementar o SCRUM... a vivenciar a dinâmica que aplicaremos de 6a a 6a feira. Agora terei BASTANTE trabalho pois atuarei como coach, scrum master e product owner ao mesmo tempo! Mas vai valer a pena!
Espero que na outra sexta-feira eu esteja aqui escrevendo os resultados sensacionais que tivemos. Espero mesmo!
Para quem quiser fazer download, o link está aqui embaixo. A apresentação em PDF :)
DOWNLOAD DA APRESENTAÇÃO EM PDF
Ou entrem na seção de downloads e vão em "Material de apoio MPE" :)
Abração
PARTE V - a
Quarta-feira, 16 de Abril de 2008
Implantação do SCRUM no laboratório - Parte IV
Véspera do dia da apresentação!!! Os tambores batem (tum-tum-tum-tum!).
Hoje tirei o dia para fazer duas coisas:
MAPEAR A ORGANIZAÇÃO
E foi o que eu fiz. Chamei todos os membros e questionei eles o seguinte.
a) Projeto
b) Equipe
c) Responsáveis
d) Objetivos
e) Data início
f) Data fim
g) Envolvidos (pessoas que seriam afetadas pelo resultado do projeto - stakeholders)
Por fim, listei as atividades de cada um desde janeiro até hoje (menos de 3 meses de trabalho, contando que fevereiro não houve atividades).
A idéia central era que ELES respondessem essas perguntas. Eu queria saber o que passava na cabeça DELES sobre os projetos em que atuam.
Meus caros leitores, vocês não tem noção do que eu descobri.
São seis "projetos" que o pessoal está envolvido atualmente. Destes seis, três NÃO são projetos, pois são demandas que surgiram para "tapar" algum buraco ou apagar algum incêndio.
Destes seis "projetos", as pessoas envolvidas não sabiam a data de término em CINCO deles. E em DOIS eles não tinham certeza de quando havia sido iniciado.
Destes seis "projetos", cinco deles não tinham certeza em quem eram os envolvidos. Dois deles não tinham certeza dos responsáveis. Um deles não sabia ao certo a equipe que atuava com ele. E um deles não tinha um gerente de projetos definido.
Destes seis "projetos", em dois deles eles não tinham noção ao certo de quais eram os objetivos gerais do projeto (não sabiam ao certo o que tinham que entregar ou porque estavam fazendo aquilo). Quatro deles não citaram objetivos específicos, apenas o objetivo geral (criar um protótipo é um geral, por exemplo. Mas existem marcos até chegar lá...).
Por fim, destes seis "projetos", identifiquei que em pelo menos três deles haviam pessoas que já haviam atuado em pelo menos outros DOIS projetos nesses 3 meses. E três recursos já haviam atuado em até QUATRO projetos em três meses.
Um recurso levantou que "felizmente" algumas demandas externas haviam diminuido. Outro citou que trabalhou em atividades ligadas à organização e outras que não tinham qualquer relação! E duas pessoas citaram que ao encerrarem um dos projetos anteriores, reclamaram da ociosidade! Isso mesmo, eles tiveram uma ociosidade forçada!
O que dizer disso?! A falta de comunicação é total!! TOTAL! É um problema crítico que deve ser resolvido para ontem!
Caros leitores, desafio vocês a pegarem um dia e fazerem essa mesma entrevista nas equipes das suas empresas. Vocês vão se assustar!! Mas ao mesmo tempo, vão ter TODOS os argumentos para implantarem a mudança que quiserem.
======================================================
PREPARAR A APRESENTAÇÃO
Depois de ter me assustado com o mapeamento, sentei na cadeira e ajeitei a minha apresentação de SCRUM. A primeira versão tinha 25 slides e tratava do SCRUM de uma forma bem macro, abordando apenas alguns pontos chave. A versão final agora tem 45 slides.
"O que, 45 slides? O pessoal vai morrer de tédio!" você deve ter pensado :)
Não. A idéia principal é a de não expôr o SCRUM apenas. Mas sim mostrar algumas situações. Então usei uns 10 slides só com exemplos de taskboards (para mostrar como é fácil identificar o status do projeto - 1o dia, 2o dia, ultimo dia, falta de prioridades, atividades não-planejadas que matam o projeto) e outras com exemplos ilustrando impedimentos, o backlog, o burndown chart... enfim.
Essa não é a versão final, pois preciso ensaiar para ver se consigo finalizar em uma hora. Caso contrário terei que cortar uma ou outra coisa.
Mas realmente acredito que ficará uma apresentação bem abrangente e bem dinâmica, apesar de aparentemente parecer longa. O negócio é refinar ao máximo as frases, para não ficar aquela enormidade de texto.
E, sim, irei disponibilizá-la para vocês depois. Em PDF, claro ;) hehe
Um abração!
PARTE V
Hoje tirei o dia para fazer duas coisas:
MAPEAR A ORGANIZAÇÃO
E foi o que eu fiz. Chamei todos os membros e questionei eles o seguinte.
a) Projeto
b) Equipe
c) Responsáveis
d) Objetivos
e) Data início
f) Data fim
g) Envolvidos (pessoas que seriam afetadas pelo resultado do projeto - stakeholders)
Por fim, listei as atividades de cada um desde janeiro até hoje (menos de 3 meses de trabalho, contando que fevereiro não houve atividades).
A idéia central era que ELES respondessem essas perguntas. Eu queria saber o que passava na cabeça DELES sobre os projetos em que atuam.
Meus caros leitores, vocês não tem noção do que eu descobri.
São seis "projetos" que o pessoal está envolvido atualmente. Destes seis, três NÃO são projetos, pois são demandas que surgiram para "tapar" algum buraco ou apagar algum incêndio.
Destes seis "projetos", as pessoas envolvidas não sabiam a data de término em CINCO deles. E em DOIS eles não tinham certeza de quando havia sido iniciado.
Destes seis "projetos", cinco deles não tinham certeza em quem eram os envolvidos. Dois deles não tinham certeza dos responsáveis. Um deles não sabia ao certo a equipe que atuava com ele. E um deles não tinha um gerente de projetos definido.
Destes seis "projetos", em dois deles eles não tinham noção ao certo de quais eram os objetivos gerais do projeto (não sabiam ao certo o que tinham que entregar ou porque estavam fazendo aquilo). Quatro deles não citaram objetivos específicos, apenas o objetivo geral (criar um protótipo é um geral, por exemplo. Mas existem marcos até chegar lá...).
Por fim, destes seis "projetos", identifiquei que em pelo menos três deles haviam pessoas que já haviam atuado em pelo menos outros DOIS projetos nesses 3 meses. E três recursos já haviam atuado em até QUATRO projetos em três meses.
Um recurso levantou que "felizmente" algumas demandas externas haviam diminuido. Outro citou que trabalhou em atividades ligadas à organização e outras que não tinham qualquer relação! E duas pessoas citaram que ao encerrarem um dos projetos anteriores, reclamaram da ociosidade! Isso mesmo, eles tiveram uma ociosidade forçada!
O que dizer disso?! A falta de comunicação é total!! TOTAL! É um problema crítico que deve ser resolvido para ontem!
Caros leitores, desafio vocês a pegarem um dia e fazerem essa mesma entrevista nas equipes das suas empresas. Vocês vão se assustar!! Mas ao mesmo tempo, vão ter TODOS os argumentos para implantarem a mudança que quiserem.
======================================================
PREPARAR A APRESENTAÇÃO
Depois de ter me assustado com o mapeamento, sentei na cadeira e ajeitei a minha apresentação de SCRUM. A primeira versão tinha 25 slides e tratava do SCRUM de uma forma bem macro, abordando apenas alguns pontos chave. A versão final agora tem 45 slides.
"O que, 45 slides? O pessoal vai morrer de tédio!" você deve ter pensado :)
Não. A idéia principal é a de não expôr o SCRUM apenas. Mas sim mostrar algumas situações. Então usei uns 10 slides só com exemplos de taskboards (para mostrar como é fácil identificar o status do projeto - 1o dia, 2o dia, ultimo dia, falta de prioridades, atividades não-planejadas que matam o projeto) e outras com exemplos ilustrando impedimentos, o backlog, o burndown chart... enfim.
Essa não é a versão final, pois preciso ensaiar para ver se consigo finalizar em uma hora. Caso contrário terei que cortar uma ou outra coisa.
Mas realmente acredito que ficará uma apresentação bem abrangente e bem dinâmica, apesar de aparentemente parecer longa. O negócio é refinar ao máximo as frases, para não ficar aquela enormidade de texto.
E, sim, irei disponibilizá-la para vocês depois. Em PDF, claro ;) hehe
Um abração!
PARTE V
Terça-feira, 15 de Abril de 2008
Implantação do SCRUM no laboratório - Parte III - a
Bom, acabei fazendo do limão que me tocaram, uma limonada.
A dinâmica de 1h que estava prevendo para fazer durante o dia da apresentação, foi adaptada de uma forma mais eficiente e produtiva.
Eles terão a semana que vem inteira para escolher uma ou duas estórias dos projetos deles mesmo e irão trabalhar com o SCRUM em cima delas. Iremos fazer todo o ciclo em uma semana, e ao final eles estarão entregando alguma coisa produtiva realmente, ao invés de apenas um produto "fantástico" que eu iria criar para eles.
Vai ser bacana, eu acredito.
Só aquele meu cronograma para mapear tudo.... bom, foi pro lixo. Os incêndios do dia-a-dia prejudicaram bastante. Então o negócio é apenas fazer a apresentação e fazer o que eu tinha planejado (o mapeamento) na 6a feira mesmo.
-----
Hoje um dos guris levou outro puxão de orelha. Mas confesso que foi merecido. A pró-atividade dos funcionários é ZERO. Eles seguem estritamente o que passamos, sem questionar. O guri teve 3 semanas para fazer alguns testes. Eu esperava que ele tivesse bastante coisa, mas ele havia feito apenas CINCO testes!!! Enquanto ele ia apresentando, eu quase fui me escondendo na cadeira.
Um erro meu, de não estar mais junto a ele para cobrar e solucionar os problemas que ele teve, mas erro dele também pela pró-atividade e comprometimento em níveis bem abaixo do que o esperado.
PARTE IV
A dinâmica de 1h que estava prevendo para fazer durante o dia da apresentação, foi adaptada de uma forma mais eficiente e produtiva.
Eles terão a semana que vem inteira para escolher uma ou duas estórias dos projetos deles mesmo e irão trabalhar com o SCRUM em cima delas. Iremos fazer todo o ciclo em uma semana, e ao final eles estarão entregando alguma coisa produtiva realmente, ao invés de apenas um produto "fantástico" que eu iria criar para eles.
Vai ser bacana, eu acredito.
Só aquele meu cronograma para mapear tudo.... bom, foi pro lixo. Os incêndios do dia-a-dia prejudicaram bastante. Então o negócio é apenas fazer a apresentação e fazer o que eu tinha planejado (o mapeamento) na 6a feira mesmo.
-----
Hoje um dos guris levou outro puxão de orelha. Mas confesso que foi merecido. A pró-atividade dos funcionários é ZERO. Eles seguem estritamente o que passamos, sem questionar. O guri teve 3 semanas para fazer alguns testes. Eu esperava que ele tivesse bastante coisa, mas ele havia feito apenas CINCO testes!!! Enquanto ele ia apresentando, eu quase fui me escondendo na cadeira.
Um erro meu, de não estar mais junto a ele para cobrar e solucionar os problemas que ele teve, mas erro dele também pela pró-atividade e comprometimento em níveis bem abaixo do que o esperado.
PARTE IV
Implantação do SCRUM no laboratório - Parte III
Santo de casa não faz milagre, já dizia o ditado.
Mandei um email para os meus chefes, explicando da apresentação e da dinâmica. Já fizeram cara feia pelo fato de durar o dia todo. "Acho que poderia ser 1 hora de reunião apenas".
Ou seja, eles querem que eu apenas faça a apresentação, sem a dinâmica. Dai eu começo a me perguntar: alguém realmente vai aprender isso se não tiver contato nenhum com as ferramentas?
A dinâmica seria algo bem simples. Apenas algum problema para cada grupo resolver usando o SCRUM. Index cards, planning poker, reuniões, retrospectiva, taskboard... eles teriam pelo menos um contato com essas ferramentas.
Mas, já vou ter que adaptar isso para uma nova realidade.
O problema é que os males perduram. A visão de que "reunião é perda de tempo" é a pior delas. Quero só ver a cara dos coordenadores quando eu falar que teremos reuniões diárias, reuniões para avaliação, reuniões de estimativas, reuniões de retrospectivas...
Conseguir o comprometimento da direção. Esse é o maior desafio, sem dúvida alguma.
PARTE III-a
Mandei um email para os meus chefes, explicando da apresentação e da dinâmica. Já fizeram cara feia pelo fato de durar o dia todo. "Acho que poderia ser 1 hora de reunião apenas".
Ou seja, eles querem que eu apenas faça a apresentação, sem a dinâmica. Dai eu começo a me perguntar: alguém realmente vai aprender isso se não tiver contato nenhum com as ferramentas?
A dinâmica seria algo bem simples. Apenas algum problema para cada grupo resolver usando o SCRUM. Index cards, planning poker, reuniões, retrospectiva, taskboard... eles teriam pelo menos um contato com essas ferramentas.
Mas, já vou ter que adaptar isso para uma nova realidade.
O problema é que os males perduram. A visão de que "reunião é perda de tempo" é a pior delas. Quero só ver a cara dos coordenadores quando eu falar que teremos reuniões diárias, reuniões para avaliação, reuniões de estimativas, reuniões de retrospectivas...
Conseguir o comprometimento da direção. Esse é o maior desafio, sem dúvida alguma.
PARTE III-a
Assinar:
Postagens (Atom)