1. Meu diretor pediu que tenhamos relatórios via Web para qualquer um ver. Daí veio o assunto de ferramentas. Porém, ele queria utilizar o Team Foundation, que será o substituto do Sourcesafe na empresa. Qualquer um dos templates utiliza horas. E eu, em minhas outras experiências em Scrum, utilizei horas internamente, para ter um acompanhamento incial, de transição, de como a equipe está andando, e sentir também a resistencia de alguns. Queira ou não, há pessoas que se você deixar livres (principalmente juniores e traines) que acabam fazendo corpo mole com uma boa malandragem.
2. Alguns amigos meus trabalham em consultorias. E tem uma diretriz de seguir Scrum. Como podem chegar o cliente de colocar na resposta de uma RFP que o projeto demorará “679″, um valor abstrato, mas com o aviso que será 100 pontos a cada duas semanas?

Isso sempre me deu as seguintes conclusões:

1. Em transição, não se pode fazer uma ruptura imediata. Mas não se pode, como algumas empresas tentam, de deixar o Scrum com complexidade e tarefas adicionais com horas. Isso faz com que não se tenha uma métrica geral da equipe.
2. A alta cupula quer gráficos. Em um primeiro momento, onde, apesar de um coaching e mentoring, não se tem uma maturidade de todos em fazer user stories, quebrá-las mais, e criar tarefas atomicas, um BurnDown de estórias por tempo será lento, crescerá a complexidade, enfim, não dará a eles a segurança necessária para se manterem na agilidade. As horas podem, inicialmente, até haver uma certa maturidade, ajudar nisto.
3. Empresas de consultoria precisam ou de mudar seu modelo ou haver um controle/definição de tempo no mínimo internamente. Acho que neste ponto às vezes nós, seguidores de agil, somos cegos quanto aos problemas deles. Terceirizar, as vezes, não é para baixar custos, mas necessidade para empresas de baixo orçamento. Eles precisam de algumas certezas, ou de serem convencidos da maleabilidade quanto ao RoI que terão ao utilizarem uma terceirização agil.
4. O apois a agilidade é complexo. Os stakerollers (como os chamos, rs) querem mais resultados. COmo no livro de Ken Schwaber fala, não interessa se é Scrum, Agile ou não, eles querem resultados. Não querem saber de periodo de adaptação. E, as vezes, para provar os problemas, temos que usar de horas, de impedimentos com horas (simbolos como bolas de dias impactantes as vezes não são claros, mostre em horas, ou em atraso, ou em aumento da complexidade), de novvas estorias derivadas das existentes, de aumento de complexidade bem claramente do por que, e por ai vai.

Esse é um tema que sei que provavelmente ainda teremos que amadurecer muito no agil, mas acho que estes pontos podem ajudar a muitos que passam por isso e não tem referencias (por isso o subject do que procurava no Google:)

1. Rally
2. Scrumworks
3. XPlanner
4. Mingle
5. VersionOne
6. TargetProcess
7. xProcess
8. Extreme Planner
9. ProjectCards
10. CardMeeting
11. XP Story Studio
12. PlanningPoker
13. Acunote
14. SilverCatalyst
15. PlanB

• MSF for Agile Software Development v.4.2: Não sei quem foi o louco que resolveu chamar isso de Agile, pois é RUP puro.
• MSF for CMMI Process Improvement v.4.2: Não há uma vantagem neste modelo, além de ser totalmente voltado para qualidade. os controles de Backlog e Task são rpecarios (sem tempo nem complexidade), porém com muitos pontos quanto a bugs e controles de falhas. Imagino que, em uma empresa que encontra-se muitos bugs em produção (nosso caso) poderia ser valioso, porém
• Light Weight Scrum v.2.1: Inclui nos Product Backlog  complexidade e critérios de aceite; um fluxo de impedimento bem processual envolvendo triagem, Backlog Item por complexidade e horas estimadas com sinalização de impedida, controle de release e “defect” (porque não bug?); relatorios de bugs e trabalho faltante.  Seus contras são não haver controle de sprint e poquissimos relatórios.
• Agile Software Development with Scrum v.2.1: O que acabamos escolhendo. Muito completo, mas só peca por não ter: aviso de task impedidas claramente, complexidade e gráficos por complexidade, por consequencia.

A ferramenta, como um todo, é boa, caso já tenha sido feito uma analise dela e várias adaptações. Sempre é necessária a criação de campos e relatórios que atendam a emrpesa, e a ferramenta de criação, dentro do Visual Studio, não facilita muito a vida.