“No nosso projeto, estamos sempre 90% prontos”
Recentemente, o Jeff Atwood (“Coding Horror”) escreveu um post com o título acima. Vale a pena dar uma liad no post inteiro; por enquanto, veja o trecho abaixo que extraí – foi o que mais me chamou a atenção:
Johanna Rothman makes the same point in a recent email newsletter, and offers specific actions you can take to avoid being stuck 90% done:
- List everything you need to do to finish the big chunk of work. I include any infrastructure work such as setting up branches in the source control system.
- Estimate each item on that list. This initial estimate will help you see how long it might take to complete the entire task.
- Now, look to see how long each item on that list will take to finish. If you have a task longer than one day, break that task into smaller pieces. Breaking larger tasks into these inch-pebbles is critical for escaping the 90% Done syndrome.
- Determine a way to show visible status to anyone who’s interested. If you’re the person doing the work, what would you have to do to show your status to your manager? If you’re the manager, what do you need to see? You might need to see lists of test cases or a demo or something else that shows you visible progress.
- Since you’ve got one-day or smaller tasks, you can track your progress daily. I like to keep a chart or list of the tasks, my initial estimated end time and the actual end time for each task. This is especially important for you managers, so you can see if the person is being interrupted and therefore is multitasking. (See the article about the Split Focus schedule game.)
I’m not big on scheduling – or lists – but without the latter, I cannot have the former. It’s like trying to defy the law of gravity. Thus, on our project, we’re always 90% done. If you’d like escape the 90% done ghetto on your software project, don’t learn this the hard way, like I did. Every time someone asks you what your schedule is, you should be able to point to a list of everything you need to do. And if you can’t – the first item on your task list should be to create that list.
Jeff Atwood - On Our Project, We’re Always 90% Done
Sabe o que mais me chamou a atenção no trecho acima? É que quando visito cliente para falar de Team Foundation Server e explico como usar work items para a gestão de projetos, é exatamente desse jeito que eu sugiro usar o TFS!
Se você seguir essas dicas como um princípio de boas práticas no uso de work items (independentemente do processo de desenvolvimento que esteja usando) sua experiência será muito mais rica.
Relacione tudo o que você tem que fazer (“List everything you need to do to finish the big chunk of work”)
Aqui o Excel é seu aliado. Use-o para relacionar rapidamente todas as atividades-macro que você já identificou durante a fase de levantamente/especificação/planejamento (ou como chamar no seu processo de desenvolvimento). Aproveite para dividir as atividades por área e/ou iteração.
Estime cada item na lista (“Estimate each item on that list”)
Use o Excel ou o Project (para muitos, o Project é o preferido nesse tipo de atividade). Faça uma estimativa inicial do tempo que se levaria para executar cada uma das atividades identificadas no processo anterior. Não se preocupe em ser preciso; você vai refinar essas estimativas depois.
Divida suas atividades em pedaços de no máximo 8 horas (“If you have a task longer than one day, break that task into smaller pieces”)
Na minha opinião, este é o ponto-chave para um uso bem-sucedido do TFS. Se você fizer um bom WBS (work breakdown structure), chegando um nível de detalhamento que garanta que suas atividades terão no máximo 8 horas, terá conseguido algo muito difícil: o comprometimento da equipe de desenvolvedores com a prática de relatório de status (status report).
O “pulo-do-gato” é que nenhum desenvolvedor seria obrigado a fazer nada além daquilo que ele faz normalmente: o check-in do código que acabou de produzir. Ao dividir as atividades em unidade de até oito horas, você praticamente garante que seus desenvolvedores:
- Farão check-in apenas de código completo (afinal, eles terminam a atividade no mesmo dia em que começaram);
- Farão check-in ao menos uma vez por dia (pelo mesmo motivo do item 1).
Alie-se a isso a política de check-in de work items__ e você terá feedback diário das atividades dos seus desenvolvedores – tudo o que eles precisam fazer é clicar uma checkbox na caixa de diálogo de check-in. “Magicamente” seus relatórios começarão a ter dados para os alimentar. 
Divulgue o status do seu projeto (“Determine a way to show visible status to anyone who’s interested”)
Quer ferramenta melhor que o Portal do Projeto do TFS, feito em SharePoint, para isso? Crie seus painéis de controle (“dashboards”) para que os interessados possam acompanhar o andamento do projeto.
Acompanhe o progresso do projeto diariamente (“Track your progress daily”)
Além do Excel, Project ou mesmo os relatórios disponíveis no Portal do Projeto, você pode usar também as inúmeras consultas de work items do TFS (e até mesmo criar suas próprias) para acompanhar seu projeto.
Viu? Com alguns cuidados básicos (e com um esforço relativamente pequeno) você consegue tirar proveito facilmente dos recursos de gestão de projetos do TFS!
09/08/2008 | Por Igor Abade V. Leite | Em Técnico | Tempo de leitura: 5 mins.
