Ter o Scrum como forma de gerenciar e acompanhar o desenvolvimento de um software é muito legal. Existem diversos conceitos interessantes de sprints, scrum master, sprint review, retrospective, product owner, etc.  Porém essas coisas estão inseridas no âmbito do gerenciamento e acompanhamento, e quando partimos para o lado mais “código” da coisa precisamos ter práticas, técnicas e princípios que possibilitem o desenvolvimento de forma diferente do que vinha sendo feito a muitos e muitos anos atrás (e ainda continua).

É aí que entra o eXtreme Programming Explained. Esse livrinho de cento e poucas páginas contém informações preciosas a respeito de novas formas de desenvolver software, tendo como preocupação principal um cenário aonde tudo pode mudar, os requisitos podem mudar (embrace change). Nesse livro Kent Beck fala sobre as formas que foram encontradas por ele e alguns companheiros de desenvolver software para o mundo real (o mundo onde as coisas continuamente mudam).

Logo no começo do livro, ele fala que programação extrema não traz nada de novo, ele apenas utiliza coisas que já conhecíamos no mundo do software e leva a níveis mais extremos (daí o nome :P). Por exemplo, se testar unitariamente o código é bom, vamos levar ao extremo, e então testar o código todo e o tempo todo (Test Driven Development). Se fazer revisão de código é uma coisa boa, vamos levar ao extremo e fazer revisão o tempo todo (Pair Programming). Se fazer a integração das partes do sistema e compilar o sistema como um todo é bom para antecipar problemas de integração, então vamos levar também ao extremo e fazer integração o tempo todo (Continuous Integration). Se trabalhar no design da aplicação para ficar o mais coerente e aderente a realidade é bom, então não vamos ter medo de fazer o tempo todo também (Simple Design and Refactoring). Se todos fazem parte da equipe não existe isso de um módulo ou parte do sistema ser de fulaninho, onde só ele modifica, e outra parte é de cicraninho, onde só ele que é o fera nessa parte que pode modificar. Nada disso, o código é de todos (Collective Ownership). Tudo isso sustentado por releases pequenos (Feedback Constante), o já conhecido jogo de planejamento (Planning Game) e testes de aceitação por parte do cliente (Customer Tests).

Essa imagem abaixo mostra as áreas descritas no livro, vale a pena dar uma conferida que é material de primeira.