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

[Ter Rowan]

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)

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

[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.

[Ter Rowan]

désolé de répondre si tard, mais des conneries au boulot, par fois ça vide l'énergie ^^

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 ?

je vois pas le lien entre la notion de cycle en V et "il faut bien écrire le code" (dans le sens ou cycle en V ne se résume pas au code, bien au contraire)
Je suis pas forcément le mieux placé pour expliquer les différences mais globalement dans le sprint tu dois avoir des interactions aller retour etc pendant toute la durée, des tests en // du dev, des modifications/adaptations/précisions de besoin pendant les dev, ... , dans un cycle en V quelque soit sa taille, on a des jalons qui permettent des passages de témoin, de l'expression du besoin jusqu'à la fin de la période post go live (passage en mode maintenance)

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

j'ai utilisé ce terme (pas forcément consacré) pour désigner toute doc technique permettant à une équipe de développement de prendre en main une application, d'identifier rapidement où et comment intervenir

ce qui veut dire, par exemple les docs qui expliquent :

les interfaces avec d'autres systèmes (appels aux web services, bdd, etl, etc...)
les couches applicatives
les modèles de données, de classes, ...
des explications sur les différents modules, sur la factorisation de code, etc...
spec techniques diverses etc...

grosso modo une doc qui permet de savoir où aller et quoi faire avant même d'ouvrir un code source