quinta-feira, 1 de maio de 2008

Dependência entre tarefas no Scrum

Um problema recorrente nas reuniões diárias do nosso projeto aqui na globo.com é a dependência entre tarefas. Sempre ocorrem interrupções entre o fluxo de "O que eu fiz" e "O que farei" para questionar a algum colega do time se determinada tarefa já foi concluída. No caso afirmativo ele pode então pegar a tarefa que era dependente. Isso acontece frequentemente, e quando ocorre o fluxo desanda e a atenção se dispersa. Começam então algumas conversas paralelas que acabam atrapalhando o andamento da reunião.

O ideal, é claro, é que não houvessem tarefas dependentes entre si em uma história. Mas isso é muito díficil, e segundo minha breve experiência com Scrum, e nesse ponto ela se resume a apenas alguns poucos projetos web, me parece ser impossivel. Como exemplo posso mostrar três tarefas que foram presentes na maioria das histórias dos projetos que participei e que são dependentes entre si:

1- Criar design
2- Criar html e css estático
3- Implementar camada de visualização

A tarefa 2 depende da tarefa 1, e a tarefa 3 depende da tarefa 2. É claro que seria possível paralelizar a tarefa 3 com a 2, fazendo com que a implementação da camada de visualização fosse apenas de um html tosco. Mas mesmo assim seria necessária uma quarta tarefa para fazer o merge do html bonito com a camada de visualização, e esta nova tarefa seria enfim dependente da tarefa 2.

Ou seja, não vejo como paralelizar todas elas. E cabe aqui uma brecha para colaboração dos leitores no caso de terem encontrado alternativas, ficaria feliz de conhecê-las. De qualquer forma, existem outras situações específicas de cada empresa e de cada time que elevam mais ainda o número de dependência entre as tarefas.

Eis então que presenciei em outro time uma boa adaptação da reunião diária. Ao invés de cada membro do time responder as três perguntas, um em seguida do outro, os membros dizem primeiro o que fizeram, uma após o outro, depois dizem o que pretendem fazer, um atrás do outro, e ao final o que os impede, também da mesma forma.

Com isso o time resolveu de maneira simples um problema que parece não ter solução, sem sacrificar a reunião diária, pois todos saem dela sabendo o que fazer, o que já está pronto e quais são os impedimentos do projeto. Cumprindo exatamente o propósito dela.

8 comentários:

  1. Acho que tem um problema com o post: a pessoa não deve focar em que história está pronta ou o que falta, ela deve focar no que conseguiu cumprir. Após todos falarem você tem uma visão de que histórias foram finalizadas e o que falta.

    []s

    ResponderExcluir
  2. Na verdade Phillip, no post estou falando sobre as tarefas dependentes dentro de uma história. Não sobre histórias dependentes. De qualquer forma concordo contigo que é muito melhor todos falarem antes quais tarefas foram finalizada para todos terem a visão do que falta, para então dizerem o que pretendem fazer. É exatamente isso que o time que citei passou a resolver o problea.

    ResponderExcluir
  3. essa sugestão, apesar de não ser a forma canônica, pelo menos para mim faz muito sentido. DEVERIA ser sempre assim. :)

    ResponderExcluir
  4. Ah...e eu acho q o phillip viajou dessa vez. :)

    ResponderExcluir
  5. O problema é que isso pode levar a Daily Scrums robóticos, que só servem para passar papel de um lado para o outro. Isso é prejudicial para o time:

    "Many teams really, truly believe that the purpose of the daily standup* is to “just answer the three questions without exceeding fifteen minutes.” Maybe it’s that the questions (what did you do yesterday, what will you do today, what obstacles are you facing) seem so simple. They are not. There is so much underneath the surface of the three little questions. Coach your team to think about these questions and come prepared to the daily standup (see sidebar articles “The Power of Knowledge” and “Seven Fundamentals for Effective Daily Standups”). In other words, think about the tasks, the accomplishments, how it may impact John’s work or Mary’s next task, and keep in mind who you are working with to complete the task. Go into the daily standup with answers to the three questions that are meaningful, insightful, and proactive."

    For example, right before I go into a daily standup, I will write down shorthand notes on a Post-It to capture my completed and planned tasks. I also think about the impact this might have to my team members and to our sprint goals. I might say in the daily standup: “I refactored the flux capacitor yesterday, improving it to a point of reasonable stability. John, I know that you were waiting on me to finish these changes so that you may work on the associated usability issues. Let’s get together after the meeting and talk about it. Mary, if you can, please stay after with us to discuss the impact this might have on the test case suite. Mr. ScrumMaster, I have no obstacles today.” Done. In fifteen seconds, I have highlighted not only what I completed yesterday, but also was proactive in pointing out who might need help or more information.


    http://www.scrumalliance.org/articles/32?class=article

    [ ]s, gc

    ResponderExcluir
  6. Guilherme, concordo contigo que a reunião diária é mais do que passar papel de um lado para o outro. Mas isso não invalida a sugestão. O que é prejudicial ao time é que a reunião acabe virando uma bagunça. O exemplo postado é muito bom, mas temos pelo menos um exemplo mais complexo a cada dois ou três dias, veja só um exemplo básico e bem humorado:

    Pedro diz: Terminei ontem de implementar a rebinboca da parafuseta, fiz isso apertando os parafusos. Tive uma dificuldade ao me deparar com aquelas teias de aranha mas o João me deu uma bola. Hoje gostaria de acertar a marcha do tapibaquigrafo, mas pra isso preciso saber se a tarefa criar plataforma tapibaquigrafica foi terminada.

    Juca corta: Eu não consegui terminar de criar a plataforma ontem pois tive um problema com os fios e placas de aço. Vou criar aqui um impedimento.

    Maria recorta: Isso não é impedimento, isso deveria ser uma tarefa nova, nosso time pode resolver esse problema de fios e placas de aço. Vou criar aqui uma tarefa nova e pegá-la pra mim.

    Pedro retoma a palavra: Ei gente, ainda não terminei, posso pegar outra tarefa, deixe-me ver qual hum hum hum... - Enquanto isso Maria e Juca discutem se deve ser impedimento ou tarefa.

    --

    O fato de seguir a sugestão dada na postagem não impede de que os membros do time deem maiores explicações durante a reunião diária. A sugestão dada só organiza melhor deixando o fluxo mais natural. E testa-la é só uma questão de desprendimento com paradigmas impostos.

    ResponderExcluir
  7. Tiago,

    Concordo com a sugestão.

    Na verdade, acho que temos 2 problemas:

    1 - Temos dependências entre algumas tarefas;

    2 - Por causa do problema 1, temos o problema que vc citou, que é não saber se posso pegar determinada tarefa por não saber se alguma tarefa que precisa estar pronta antes foi finalizada por alguém.

    Idealmente, deveríamos resolver o problema 1. Com isso, o problema 2 estaria resolvido automaticamente. Mas não vejo uma forma simples e imediata de resolvê-lo.

    Assim, concordo com sua sugestão, que tenta resolver o problema 2. Dessa forma, pelo menos, evitamos que a reunião vire uma bagunça.

    ResponderExcluir
  8. Thiago, acho que o problema está em as pessoas acharem que vão resolver todos os problemas no daily meeting, quando durante aqueles 15m podemos planejar as próximas horas, levantar problemas e atualizar as pessoas interessadas no projeto.

    Melhor seria o time se organizar para resolver as depêndencias - isso pode ser após o DM apenas com os envolvidos.

    []'s

    ResponderExcluir