3 Qualidades, 3 Tipos de Débitos

Atualmente surgiram algumas discussões em fóruns sobre a entrada de itens técnicos no Product Backlog do Scrum. A apostila do nosso curso Scrum pode dar uma idéia sobre o que é um Product Backlog:

“Os itens que aparecem no Product Backlog são qualquer tipo de funcionalidade ou tarefa que possua um valor para o Product Owner ou ao grupo de Stakeholders que este Product Owner representa. Esses itens seguem um conceito do SCRUM chamado incremento de funcionalidade potencialmente implantável. Uma funcionalidade potencialmente implantável significa que quando esse item do Product Backlog for finalizado ele estará completamente funcional e resolvendo algum problema de negócio dos Stakeholders.”
Rodrigo Yoshima, Gerenciamento de Projetos com Scrum

As discussões estão listadas abaixo:

http://br.groups.yahoo.com/group/agile-brasil/message/1738
http://br.groups.yahoo.com/group/scrum-brasil/message/751

Eu particularmente sou contra enfiar coisas que não agregam valor para o PO no Product Backlog. Bem, pra falar a verdade, defendo uma outra visão. Pode ser que existam itens criados por recomendação da equipe, mas tudo lá agrega valor de negócio para o PO. Lembre-se: O Product Backlog é um importante registro de métricas como prazos, produtividade, pesos funcionais e etc… É preferível que essas métricas importantes para o negócio não sejam poluídas com problemas técnicos da equipe (apesar desses problemas interferir nas métricas, são ortogonais à visão que defendo aqui). Gerar um script do Ant não é algo que constaria nos meus product backlogs.

Débito Técnico é um problema da equipe técnica. Se existem Débitos Técnicos é culpa (responsabilidade) da equipe técnica. Agora, nenhuma aplicação que desenvolví ou qualquer outra que tive contato É 100% LIVRE DE DÉBITO TÉCNICO. Já olhei código de algumas dezenas de projetos Open Source. Todos tinham algum débito, porém, isso é natural. Como vocês todos sabem, débito técnico é comparado com inflação. Tem que ser gerenciado. Nenhum economista consegue gerenciar algo como os 100.000% de inflação do Zimbabue.

É capaz que existam itens do tipo:

– Efetuar um teste de usabilidade com os usuários finais
– Efetuar um teste de carga com 480 usuários simultâneos

Já passei por essas duas situações. Mas esses itens foram para afastar riscos do negócio e não “Débito Técnico”. Esses itens constaram no Backlog sugeridos pela Equipe pois eram “técnicos”, mas negociamos com o PO. Esses itens constaram no Backlog pois tomaram muito tempo. Como exemplo, o teste de carga tomou quase 1 Sprint para ser efetuado.

Débito Técnico, Débito Funcional, Débito do Projeto

Atualmente defendo uma tese que nossa preocupação são as 3 qualidades do software. A qualidade interna, qualidade externa e qualidade do projeto (ver artigo “Modelagem Ágil”, MundoJava #27). Só para revisar, listo as 3 qualidades do software:

1. A solução atende ao negócio (qualidade externa).
2. O software é fácil de manter e evoluir (qualidade interna).
3. Menor custo e prazo possível (qualidade do projeto).

Um ponto que não mencionei no artigo é que com essa visão das qualidades nós temos 3 “listas de débitos” para gerenciar: débitos técnicos, débitos funcionais e débitos do projeto. Exemplos:

1. Débitos Técnicos:
– Melhorar o Build
– Melhorar a Documentação Técnica
– Melhorar a cobertura de testes
– Fazer passar PMD, Checkstyle
– Código Macarrônico
– Baixa coesão, alto acoplamento
– POG

2. Débitos Funcionais:
– Bugs
– Algumas funcionalidades pequenas não implementadas
– Funcionalidades não implementadas por conta de bugs em bibliotecas de terceiros
– Melhorar usabilidade
– Melhorar a “beleza” da aplicação

3. Débitos do Projeto:
– Uma linha de burndown acima do planejado (cheiro de atraso)
– Custo acima do esperado
– Falta de comprometimento dos Stakeholders
– Falta de financiamento
– Baixo ROI
– Falta de comprometimento da Equipe

Bem, logicamente essa minha tese ainda carece de melhores fundamentos teóricos. De qualquer forma não é algo novo. Simplesmente juntei vários aspectos que já constam em outras literaturas. Essa visão fez e faz sentido nos projetos que participei. Seu processo de desenvolvimento deve focar nas 3 qualidades e os 3 débitos devem ser gerenciados.

Documentando os Débitos

Débitos Técnicos podem ser facilmente gerenciados dentro do próprio código e com suporte das IDEs atuais. A maioria deles constam como //TODO:. Nas IDEs atuais como o Eclipse temos uma boa visão dos To Dos através da View “Tasks”.

[photopress:eclipseTasks.JPG,full,pp_image]

Relacionados com Débitos Técnicos temos restrições arquiteturais. Restrições arquiteturais não são débitos técnicos, mas podem se tornar um, principalmente em projetos ágeis e iterativos. Restrições arquiteturais importantes podem constar num documento de arquitetura.

Para documentar débitos funcionais podemos usar o proprio Product Backlog, porém, a granularidade desse tipo de item (débito funcional) costuma ser bem pequena (como os exemplos que citei). Eu relaciono débito funcional como uma funcionalidade pequena que não impede que os usuários dêem a história como pronta, mas não deixa de ser desejável. Vendo dessa maneira, talvez essas pequenas funcionalidades podem constar como issues do Bug Tracking.

Já o débito do projeto pode ser melhor compreendido como o sentimento dos envolvidos com relação ao projeto (vide exemplos citados). Débitos do projeto costumam surgir nos bate-papos das reuniões ou durante o cafezinho da equipe técnica. Para documentar isso de maneira iterativa uma lista de risco é uma boa opção. Essa lista pode ser revista e atualizada durante cada Retrospective ao fim das iterações.

Um alerta importante é: NÃO ADIANTA SÓ DOCUMENTAR! Débitos devem ser vencidos. Para exemplificar, é muito comum que um Gerente de Projetos tradicional encha uma lista de riscos e vire as costas para o problema que ela representa, assim como um programador que faz um código ruim e não tem preocupações com a qualidade interna.

Estude mais:

http://blog.fragmental.com.br/2008/02/17/gerenciando-debitos/

http://josepaulopapo.blogspot.com/2008/04/qualidade-cdigo-manutenibilidade.html