Scrum e XP das trincheiras

INTRODUÇÃO

É grande o número de empresas e instituições de TI que tentaram implantar SCRUM em em seus times de desenvolvimento e falharam. A principal causa, a meu ver, é a ausência de uma normatização a respeitos das práticas que constituem SCRUM. De fato, considero esta a maior força e a maior fraqueza do SCRUM: Ele pode e deve ser adaptado ao ambiente e ao contexto da instituição onde será implantado. Esta questão rende debates acalorados e já foi tema de um post deste blog (aqui ó).

“Scrum and XP from the trenches” (“Scrum e XP das trincheiras” em uma tradução livre) Descreve em detalhes o conjunto de práticas que funcionou em uma empresa sueca sob a liderança de Henrik Kniberg. Longe de ser uma “implementação de referência”, trata-se de uma caso de sucesso que acredito valer a pena ser lido e estudado.

O livro aborda temas comuns como:

• Como conduzir cada cerimônia SCRUM
• Como organizar o backlog do produto e do sprint
• Interação e responsabilidades de cada papel (PO, SCRUM master, time)
• Como lidar com múltiplos times e times geograficamente distribuídos
• Tamanho dos Sprints

E também temas menos comuns, tais:

• Arranjo físico do time
• Pausas entre sprints
• Comunicação do andamento do sprint para o restante da instituição. 

Seguem informações comentadas sobre alguns trechos do livro que julguei mais relevantes:

BACKLOG DO PRODUTO

O Backlog do produto é basicamente uma lista priorizada de requisitos, estórias, funcionalidades (escolha um nome, por aqui vamos ficar com estória). São coisas que o cliente quer descritas na linguagem do cliente.

É mantido em uma planilha do excel que fica em um drive compartilhado para todo o time. Cada item é composto pelos seguintes campos:

• ID – Identificador numérico único. Serve principalmente para evitar confusão caso uma estória mude de nome.
• Nome – Um nome que seja curto e mais descritivo possível. Normalmente entre 2 e 10 palavras.
• Importância – O grau de importância da história para o cliente (informado pelo PO). Quanto maior a importância maior a prioridade da estória.
• Estimativa Inicial – A estimativa do time com relação a esta estória.
• Como demonstrar – Uma descrição de auto nível de como a história será demonstrada na sprint review.
• Notas – Qualquer outra informação ou observação que o PO julgar necessária.

É importante manter o backlog do produto em um nível bastante negocial. Isso pode ser um problema se o PO possui background técnico, já que ele pode querer adicionar estórias como: “Incluir índice na base de dados”. Nestes casos o ideal é substituir o nome da estória por aquilo que seria na verdade o objetivo da tarefa técnica (neste caso, algo como “acelerar a resposta do sistema nas pesquisas”). O time é o papel mais adequado para decidir como isso será alcançado (embora a ideia original do PO pode e deve ser levada em consideração).

PLANEJAMENTO DO SPRINT

Esta é a cerimônia mais importante do SCRUM. Seu objetivo é levantar informação suficiente para que o time possa trabalhar tranquilamente por todo um sprint. Ao fim da reunião, é importante ter:

• O objetivo do sprint.
• Lista de membros do time.
• Sprint Backlog.
• Data da review.
• Local e hora para o daily meeting.

A presença do PO é fundamental não apenas para explicações e remoção de dúvidas, mas para negociar escopo e importância das estórias de forma a influenciar o sprint backlog de acordo com os interesses do cliente.

É comum que sprints plannings demorem mais do que esperado. Nestes casos o melhor a fazer é interromper a reunião no momento planejado e deixar o sprint sofrer. Da próxima vez a tendência é que todos se esforcem para concluir tudo no tempo pre estabelecido.

BACKLOG DO SPRINT

Para decidir os itens do backlog do produto que irão compor o backlog do sprint, o time pode usar 3 abordagens:

• Aproximação pelo sentimento
• Cálculo de velocidade através da média dos sprints passados.
• Cálculo de velocidade através cálculo de recursos.

Na aproximação pelo sentimento o time simplesmente inclui as estórias que acredita ser capaz de entregar ao fim do sprint.

No cálculo de velocidade através da média dos sprints passados o time inclui um total de pontos de estória equivalente a média dos pontos de estória entregues nos sprints passados.

No cálculo de velocidade usando cálculo de recursos é feita uma equivalência entre os pontos de estória e a quantidade de trabalho que um membro do time realiza em um dia. São incluídos um total de pontos de estória equivalentes a capacidade do time (que é o total de membros vezes o total de dias do sprint) multiplicado por um fator redutor que representa imprevistos e momentos não produtivos do time (o chamado fator de foco).

O ideal é usar essas abordagens em conjunto. Primeiro calcula-se a velocidade através do cálclo de recursos (aplicando o fator de foco adequado). Compara-se a velocidade obtida com a velocidade dos sprints passados para eventuais ajustes. Após incluir estórias de acordo com esta velocidade, faz-se uma análise de aproximação pelo sentimento possivelmente incluindo ou removendo estórias.

Quebrar uma estória em tarefas é útil para obter estimativas mais precisas. Além disso, melhora a eficiência dos daily meetings.

A melhor forma de manter um backlog do sprint é um quadro de tarefas como este aqui:

Notar:

• Área para estórias (e tarefas) não iniciadas (mas planejadas), em execução e prontas.
• Ordem de importância de cima para baixo.
• Gráfico burndown
• Área específica para tarefas não planejadas
• Área específica para tarefas não incluídas no backlog, caso sobre tempo.

ESTÓRIAS NÃO NEGOCIAIS

Em todo Sprint existem tarefas que não constituem entregáveis, nem estão ligadas a nenhuma estória específica, enfim, não adicionam valor diretamente ao produto. São coisas como Configurar e manutenir o servidor de integração contínua, ou refatorar determinada camada da aplicação. Encarar estas tarefas normalmente como itens do backlog do produto não é bom porque naturalmente o PO vai negligenciá-las na hora de priorizar. Eis algumas possíveis soluções:

• Evitar estórias não negociais. Tentar ao máximo adicionar valor negocial a este tipo de estória e deixar que o PO priorizar normalmente.
• Verificar se a tarefa pode ser realizada como parte de outra estória negocial.
• Manter um backlog separado de estórias não negociais e incluir algumas em cada sprint, tentando conscientizar o PO sobre sua importância (é possível usar o cálculo da velocidade para barganhar!)

REUNIÃO DIÁRIA

A reunião diária é basicamente “by the book”. O time se reúne diante do quadro de tarefas do backlog do sprint, responde às três perguntas básicas e cada membro atualiza o quadro enquanto fala.

REVIEW

Esta reunião tende a ser subestimada, mas é importante principalmente porque:

• O time obtém crédito pelo seu trabalho.
• Outras pessoas ficam sabendo no que o time está trabalhando.
• Atrai feedbacks importantes dos clientes.
• Força o time a terminar os sprints com estórias realmente prontas.

Em uma review, não esquecer:

• Apresentar claramente o objetivo do sprint
• Foco em mostrar o produto funcionando.
• Manter sempre em nível negocial
• Se possível, deixe a audiência usar o produto.

RETROSPECTIVA

Essa é a segunda reunião mais importante do SCRUM. Como devem ser organizadas:

• Aloque de 1 a 3 horas, dependendo de quanto discussão é prevista.
• O time, o Scrum Master e o PO devem participar.
• A reunião deve ocorrer em uma sala isolada.
• Alguém é designado secretário
• O scrum master exibe o sprint backlog e com ajuda do time faz um resumo do sprint, incluindo acontecimentos importantes e decisões relevantes.
• Cada pessoa, na sua vez, fala, sem ser interrompida, o que achou bom, o que poderia ter sido melhor e o que gostaria de fazer diferente no próximo sprint.
• Compara-se a velocidade estimada e a real. Havendo grande discrepância, discute-se as possíveis causas.
• No final o scrum master resume as sugestões concretas sobre o que pode ser melhorado para o próximo sprint.
• Faz-se uma votação para decidir quais destas sugestões devem ser levadas a cabo no sprint que vai iniciar.

CONCLUSÃO

Obviamente há muito mais no livro do que foi enumerado aqui. Em especial, a parte de múltiplos times e times distribuídos, deixada de fora aqui por motivos de espaço, são bastante interessantes. Além disso, existem diversas dicas de como lidar com situações comuns que encontramos no dia a dia de um time que usa SCRUM. Enfim, trata-se de uma excelente leitura!

Agile Design

INTRODUCTION

As a developer, I've always been fascinated by software design. Usually defined as the activity to specify software components (classes) and its interactions, I consider it both interesting and challenging. When I first get in touch with agile principles (SCRUM and XP in particular) I realized that there is a huge gap between what I learned back at college and what the methodologies enforce.

UP FRONT DESIGN

I learned back at college that design is the software engineering phase that bridges requirements specification and the coding. The analyst defines WHAT to do, the design HOW to do it and the programmer just DO it. The design phase products are documents and diagrams to be used by the programmer to code the software as the analyst idealized it. This approach is called up front design and it doesn't come without its drawbacks and challenges.

• It is very hard (if not impossible) to come up, in advance, with such a design that both meets all requirements and is flawless.
• It would be necessary to come up with a design so flexible to accommodate the dreaded change of requirements. Even if possible, what would be the cost, in terms of complexity, of such design?

With SCRUM there's not such thing as design phase. There's a meeting when the product owner detail the sprint backlog items so the analysts can start documenting, the testers can start write tests cases and the developers can start coding. That simple. There's no design at all? Well, not as I learned back at college.

EVOLUTIONARY DESIGN

If its not possible to come up with a design that meets all the requirements, that is flawless and its impossible to avoid requirements changes, what could justify the effort (usually a big one, considering the complexity and level of abstraction required) spent with an up front design? Accepting that coding is design, agile methodologies come up with an approach called evolutionary design.

With that approach, design and coding walk side by side. The design evolves according to the functionalities been developed needs. There's no a formal role as designer nor a particular moment to do the design. Every developer design and redesigns every day.

YAGNI

One of the most intriguing concepts related to evolutionary design is known as YAGNI (You Aren't Gonna Need It). “Always write only the code you need right now, never the one you thing you're gonna need tomorrow.” Even when you are absolutely sure you're gonna need the code and the cost of implementation is zero: just write it when you actually need it.

YAGNI is counter-intuitive because it goes against what is believed to be the greater benefit of a good design: anticipation of complexity and consequent risk mitigation. Nevertheless, there are very good arguments in favor of such approach:

• Respects the clients ROI: write code that doesn't aggregate any value to the functionality under construction means to disregard the PO prioritization and , in consequence, the client's ROI.
• Time saving: Time used to write code that is only going to be used in a later iteration may be missed when it comes to deliver the functionalities promised to the actual iteration.
• Possible changes: To write code in advance is unnecessary risk because the understanding may have been incorrect or the logic/rule may simply change, what originates the need to rewrite the code.

MAKE IT WORK

By now the reader may have came to the conclusion that a evolutionary design projects may end up with no design at all, or a very poor design.

Critics accuse evolutionary design to be over-dependent on the maturity of the team, what is somewhat the true. On that matter, XP defines the role of a coach, who is a more experienced programmer responsible for guiding other developers in technical issues (including design).

Besides, there is a number of practices, from the agile environment or not, I believe should be judiciously used to maintain design quality:

• Emphasis on tests (unit tests, integration tests, etc): It gives you some confidence during design changes.
• Continuous Integration: keep the team synchronized with code and find out possible bugs earlier.
• Pair Program: If the functionality is complex, maybe a god idea to get two developers working on it.
• White box analysis: Its a good idea to keep an activity of code review to detect design issues that not necessarily show themselves as bugs.
• Good practices list: To keep a list of design good practices so the developers can refer to it when in doubt. The list could evolve as the project goes and experience is gain.

CONCLUSIONS

The agile wold has no place to up front design on its conceptual manner, as a well defined phase and trying to anticipate all details  of the development of a functionality, but it could benefit from some of it features such as better risk management and strong standardization.

Evolutionary design is an alternative approach indicated by the agile principles, but it must be applied together with other practices in order to keep the quality of the design.

REFERENCES

Great Martin Fowler article on design and XP (http://martinfowler.com/articles/designDead.html)

Article on up front design problems (http://architects.dzone.com/news/great-lies-design-vs)

Design Ágil

INTRODUÇÃO

Como desenvolvedor, sempre fui fascinado por design de software. Comumente definida como a atividade de especificar os componentes de software (classes) e suas interações, considero a tarefa desafiadora e bastante interessante. Quando comecei a entrar em contato com princípios de desenvolvimento ágil (em especial SCRUM e XP), percebi que havia uma grande incompatibilidade entre o que aprendi na faculdade (e acreditava ser a forma correta de fazer design) e o que pregam as metodologias.

UP FRONT DESIGN

Aprendi na faculdade que design é fase da engenharia de software que faz a ponte entre a especificação de requisitos e a construção propriamente dita. O analista decide O QUE fazer, o projetista decide COMO fazer e o programador FAZ. O produto da fase de design são documentos e diagramas que o desenvolvedor irá usar para construir o software que o analista idealizou. Esta abordagem hoje é chamada de up front design e sem dúvida não é livre de seus problemas e desafios:

• É muito difícil (senão impossível) criar antecipadamente um design tal que atenda todos os requisitos (funcionais e não-funcionais) e esteja livre de falhas.
• Seria necessário criar um design que fosse flexível suficiente para acomodar as temíveis mudanças de requisitos. Mesmo que seja possível, qual seria o custo em complexidade de um design assim?

No SCRUM não há fase de design. Há uma reunião onde o product owner explica para o time em detalhes as características de cada item do sprint backlog e a partir daí analistas começam a documentar, testers especificam casos de testes e programadores começam a desenvolver. Simples assim. Não tem design? Não da forma como aprendi na faculdade.

EVOLUTIONARY DESIGN

Se não é possível gerar um design que atenda a todos os requisitos, seja livre de falhas e se não é possível evitar mudanças de requisitos, o que justifica o esforço (geralmente grande devido a natureza complexa da atividade) despendido na criação de um up front design? Entendendo que codificar é projetar as metodologias ágeis propõem algo chamado evolutionary design.

Nesta abordagem, o design e codificação andam lado a lado. O design evolui de acordo com as necessidades das funcionalidades sendo construídas. Não há o papel formal de projetista nem um momento específico para desenvolver o design: Todos os desenvolvedores fazem e refazem o design todos os dias.

YAGNI

Um dos conceitos mais intrigantes relacionados a evolutionary design é conhecido pela sigla YAGNI (You Aren't Gonna Need It). “Sempre escreva apenas o código que você precisa agora, nunca o que você vai precisar amanhã” Mesmo que você tenha absoluta certeza de que vai precisar daquele trecho de código e que o custo de escreve-lo seja zero: Deixe para fazê-lo quando for necessário.

YAGNI é contra-intuitivo porque vai contra aquilo que acredita-se ser maior benefício de um um bom design: antecipação de complexidade e consequente redução de riscos. Entretanto, existem bons argumentos em favor desta abordagem:

• Respeito ao ROI do cliente: Escrever código que não agrega valor a funcionalidade em construção é desrespeitar a priorização do product owner e consecutivamente o ROI do cliente.
• Economia de tempo: O tempo usado para escrever código que só será usado posteriormente pode fazer falta na hora de entregar as funcionalidades previstas para esta iteração.
• Possíveis mudanças: Escrever código antecipadamente é um risco (desnecessário) porque o entendimento pode ter sido equivocado ou a lógica/regra pode mudar, gerando a necessidade de reescrever o código.  

FAZENDO EVOLUTIONARY DESIGN FUNCIONAR

Neste ponto, o leitor já deve ter percebido que um projeto que usar evolutionary design corre grandes riscos de acabar mesmo é sem design, ou com um design muito pobre.

Críticos acusam evolutionary design de ser super-dependente da maturidade do time, o que tem um fundo de verdade. Neste sentido, o XP define o papel do Coach, que seria um desenvolvedor mais experiente com a responsabilidade de orientar o time nas decisões técnicas (inclusive de design).

Além disso, existe uma série de práticas, do próprio mundo ágil ou não, que acredito devam ser empregadas criteriosamente de forma a manter a qualidade do design:

• Ênfase em testes (unitários, de integração, etc..): É importante ter uma boa margem de segurança quando são feitas mudanças de design.
• Integração contínua: Integrar o código do projeto como um todo (mantendo o time em sincronia) buscando detectar o mais cedo possível possíveis problemas de design.
• Pair program: Se a funcionalidade for muito complexa, colocar 2 desenvolvedores responsáveis por ela pode ser uma boa ideia.
• Análise caixa branca: Incluir uma tarefa de inspeção de código a fim de detectar design inadequado (devido ao auto custo, a análise poderia ser feita por amostragem apenas)
• Lista de boa práticas: Manter uma lista de boas práticas que sirva de orientação aos desenvolvedores. Tal lista seria incrementada ao longo do projeto com a experiência adquirida. 

CONCLUSÕES

O mundo ágil não tem lugar para up front design em sua forma conceitual, como uma fase bem definida e buscando “prever” todas as nuances do desenvolvimento de uma funcionalidade, mas poderia se beneficiar de algumas de suas caraterísticas como redução de riscos e forte padronização.

Evolutionary design é a abordagem alternativa que os métodos ágeis indicam, porém ele deve ser empregada em conjunto com outras práticas que garantam a qualidade do design do software a ser construído.

REFERÊNCIAS

Excelente artigo de Martin Fowler sobre design e XP (http://martinfowler.com/articles/designDead.html)

Artigo sobre problemas de up front design (http://architects.dzone.com/news/great-lies-design-vs)

Scrum and the context

When Scrum become popular a few years ago, promoted a sharp turnaround in the development community. That's because, much more than a new methodology, Scrum advocates a new approach, a new philosophy in software development - strongly based on the ideas of the agile manifesto.

By encouraging practices like having a customer representative directly involved in the design or maintenance of self-managed teams Scrum directly influences the structure, the culture of organizations – it interferes in what is called the team context: the environment in which it falls. Obviously these changes are usually costly and sometimes impractical.

As agile methodologies grow in popularity, also grows the questioning of its efficacy. In this context, rises a group that advocates grater rigidity in the team’s context maintenance. According to this group, establishing that an agile methodology is made up of a predefined set of practices, without taking the context into account is nonsense since some of these practices could turn into pure bureaucracy – the one thing agile methods seek to eliminate!

Also it’s important to notice that the agile manifesto says nothing about keeping the customer close to the development team or even on shorter construction cycles. These are concepts of Scrum and it is certainly possible to have an agile team without these characteristics.

On the other hand, saying that the methodology must bow to the context is inappropriate. Due to its innovative nature, adopting an agile methodology requires at least some cultural and structural adaptation. If it is to ignore the breadth of the change that the introduction of an agile methodology requires, you’re certainly better off not starting at all!

The ideal path, I beleave, is the middle way: adaptation of the context as appropriate and judicious adoption of practices always taking the context into account. What then would be the measure of this balance? The team of course. After all, we must not forget that individuals and their interaction are more important processes and tools.

References

 http://xprogramming.com/blog/2009/01/30/context-my-foot/

http://www.noop.nl/2009/02/the-decline-and-fall-of-agilists.html

http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html

http://martinfowler.com/bliki/FlaccidScrum.html

Scrum e o contexto

Quando Scrum se popularizou alguns anos atrás, promoveu uma grande reviravolta na comunidade de desenvolvimento. Isso porque, muito mais do que uma nova metodologia, Scrum prega uma nova abordagem, uma nova filosofia na construção de software - fortemente baseada nas ideias do manifesto ágil.

Quando incentiva práticas como ter um representante do cliente diretamente envolvido no projeto ou manutenção de times auto-gerenciados Scrum influencia diretamente na estrutura, na cultura das organizações – naquilo que convencionou-se chamar de contexto da equipe: o ambiente no qual ela se insere. Obviamente tais mudanças são muito custosas e por vezes impraticáveis.

Com a popularização das metodologias ágeis, e o crescente questionamento em torno de sua real efetividade, surge um grupo que defende mais rigidez na manutenção do contexto da equipe. De acordo com este grupo, estabelecer que um conjunto X de práticas definem uma metodologia ágil, sem levar em consideração o contexto da equipe é, na verdade, um contrassenso. Tais práticas seriam, na verdade, pura burocracia – exatamente uma das coisas que os métodos ágeis buscam eliminar!

Inclusive, vale lembrar que a filosofia ágil não entra no mérito de práticas. O manifesto ágil não fala nada sobre manter o cliente próximo ao time de desenvolvimento ou mesmo sobre ciclos curtos de construção. Esses são conceitos do Scrum e certamente é possível ter um time ágil sem estas características.

Por outro lado, penso que afirmar que a metodologia deve curvar-se ao contexto é descabido. A adoção de uma metodologia ágil requer alguma mudança cultural e na estrutura da organização devido a sua natureza inovadora. Se for para ignorar a abrangência da mudança que a introdução de uma metodologia ágil requer, é melhor nem começar!

O ideal seria, como a maioria das coisas na vida, o caminho do meio: Adaptação do contexto na medida adequada e adoção criteriosa de práticas levando sempre o contexto em consideração. Qual seria então a medida deste equilíbrio? O time sem dúvida. Afinal, não podemos esquecer que indivíduos e sua interação são mais importantes processos e ferramentas.

Referência

 http://xprogramming.com/blog/2009/01/30/context-my-foot/

http://www.noop.nl/2009/02/the-decline-and-fall-of-agilists.html

http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html

http://martinfowler.com/bliki/FlaccidScrum.html