Scrum e as práticas de engenharia de software

O Scrum é uma metodologia adaptativa e voltada à gestão. Deixa lacunas em termos de riscos e engenharia. Por isso, o Scrum, de acordo com o contexto de cada projeto, deve ser combinado com outras práticas como, por exemplo, a gerência de riscos do PMI e práticas de engenharia de software. Neste post cito 2 práticas de engenharia do XP (Extreme Programming):

- Refactoring (refatoração): muito importante para que o código tenha um design cada vez mais limpo, elegante e flexível. Como o Scrum é um processo ágil, ocorrem vezes em que, devido ao prazo de entrega do release ao final do Sprint, um determinado código é entregue sem estar de acordo com o ideal. Isto gera um débito técnico (tech debt). Ou seja, quem entregou o código mentaliza que assim que houver a possibilidade, este código será melhorado, se tornará mais semântico, que aquele dado método que está muito grande será quebrado em métodos menores etc. E implementa estas melhorias! Para o usuário do software, o refactoring não muda nada, já que as mesmas funcionalidades serão mantidas. Porém, para o Time que desenvolveu o software, é um grande ganho de qualidade e, também, de tempo quando for necessário atender a requisitos de evolução relativos à manutenção, adaptação ou adição de novas funcionalidades.

- Pair Programming (programação em pares): visa a propriedade coletiva do código. Tem como meta a melhoria contínua do código e a idéia de que, em casos onde haja alguma dificuldade de imaginar a implementação de alguma estória, 2 cabeças pensem melhor que uma. Devido à questão da propriedade coletiva do código, a sugestão é que não se utilizem sempre os mesmos pares. O piloto deve trocar com o co-piloto e, também, as pessoas devem formar pares diferentes. Ao mesmo tempo, ninguém é obrigado a trabalhar em par o dia inteiro. Pode, por exemplo, trabalhar em par na parte da manhã e individualmente na parte da tarde. Ou vice versa! Pode trabalhar individualmente e, quando sentir a necessidade, devido a algum bloqueio de inspiração, programar em par. A programação em pares não deve ser imposta, mas uma atitude de convencimento através da conversa e da pontuação de seus benefícios.

Muitas empresas ainda não entendem a utilidade da programação em pares, com a mentalidade “pago o salário individualmente, não em par”. E muitos desenvolvedores dizem que é uma prática “furada”, sem nunca tê-la experimentado. Não se pode dizer que algo é ruim sem antes experimentar.