blog de création d'un jeu vidéo

[Sephi-Chan]

perso je commence à avoir une expérience en scrum (un gros projet depuis plus d'un an avec 5 développeurs, moi en product owner) je suis moyennement convaincu (en particulier sur la notion de sprint

Qu'est-ce que tu n'aimes pas dans les sprints ?

Je trouve cette notion de temps très/trop contraignante. Au final, ça se transforme :
soit en mini cycle en V (donc pas très agile)
soit en "on fonce pour montrer quelque chose". Et là on bacle soit la qualité du dev, soit la qualité de la vie du développeur qui triple ces heures. Bref dans tous les cas on épuise soit l'équipe soit le product owner (et j'ai horreur d'être épuisé). Je pense que c'est l'élément majeur qui permet le retour en force de Kanban (maintenant y a certainement des équipes qui réussissent très bien en SCRUM, je ne dis pas)

Bien sûr que tu te retrouves avec de petits cycles en V, c'est le principe même des sprints : il faut bien écrire le code. Je ne comprends pas ton raisonnement : comment en arrives-tu invariablement à l'épuisement ?

gros point noir cependant : le risque de ne pas bien documenter (pas forcément le code mais les spec, doc d'architecture, etc...)

Sur ce point, je ne te suis pas. La pratique du TDD (et encore plus du BDD) documente naturellement le projet.

Rien n'impose dans SCRUM d'être en TDD. Mais je te rejoins, c'est ce que je vais essayer de mettre en place pour la nouvelle release. Cependant, les tests c'est bien, les tests + les doc d'archi c'est mieux ;-) et ça c'est pas facile à obtenir dans un process qui peut remettre en cause l'architecture applicative à tout moment

Scrum n'implique rien sur le plan technique, mais si tu Scrum, autant en profiter pour utiliser XP (ou au moins prendre les bouts qui t'intéressent).

Qu'est-ce que tu désignes par documentation d'architecture ? C'est abstrait pour moi.