10 ans de Scrum

Closure

En rangeant mes papiers, je suis tombé sur le premier article parlant de Scrum que j’ai lu. Il s’agit “Scrum Development Process” de Ken Schwaber. Il date de 1996. 10 ans !

Je ne me souviens plus où je l’avais trouvé, mais je me rappelle très bien l’avoir lu avec curiosité et étonnement, en pleine période de l’orienté objet (qui est souvent mentionné dans l’article). 10 ans plus tard, et maintenant que je pratique couramment Scrum, je l’ai relu avec intérêt.

J’ai été amusé de lire le paragraphe suivant concernant la phase de “Closure” :

When the management team feels that the variable of time, competition, requirements, cost, and quality concur for a new release to occur, they declare the release “closed” and enter this phase. This phase prepares the developed product for general release. Integration, system test, user documentation, training material preparation, and marketing material are among closure tasks.

J’ai pensé à Avangel qui vient de mettre à jour Scrum sur Wikipedia et qui a fait des commentaires sur les explications les plus dangereuses de la version précédente. En fait la version précédente était plus ou moins la traduction de l’article de Schwaber de 1996.

C’est un point sur lequel il y a évolution depuis 10 ans, puisque Schwaber ne parle plus de phase de “Closure” maintenant. Il parle de Release Sprint et le présente de la façon suivante :

When the Product Owner and Stakeholders identify that there is sufficient functionality in the system to provide immediate business value they may choose to put this into production. Typically, a Release Sprint will follow that contains all the necessary Sprint Backlog tasks to put the system into production. These tasks shouldn’t contain additional functionality but they may include:

  • Deploying the code to the Production Environment
  • Production data population
  • Setting up management and operational systems and processes
  • Training and handover for support staff
  • Cutover and fallback planning

On ne parle plus d’intégration, de test et de documentation. Ni d’équipe de management. Avangel a bon.

Voir aussi