code/tests unitaires + CI voire CD à une cadence selon pré-requis
tests intégration bout en bout régulièrement, résorption des « bouchons » conditionnant la fin du sprint,
les bugs ajoutés et régressions font partie du livrable, yolo _o/
Paraît que les sprints doivent s'enchaîner
oui, bwalors ça : avant de démarrer un nouveau sprint, demande quelle est la ligne d'imputation sur laquelle imputer et à partir de quand elle sera ouverte, ça devrait te donner le temps pour la veille technologique^W^W glande sur Internet :-) et tu imputes ton prévisionnel dès le début, ce qui validera le démarrage du sprint, si tu ne peux pas, ça décale et tu as gagné du temps.
Et les sprints, ça peut ne pas être que de coder une nouvelle fonctionnalité, mais aussi faire du refactoring, vider le backlog d'un ensemble de tâches « faciles ».
tu peux aussi faire remarquer que si à 6 le daily dure plus de 15 min, ça permet d'identifier les sujets à reporter au sprint suivant ou à changer les priorités (généralement ça stabilise le besoin ou le réduit à ce qui a correctement été identifié — au prix d'augmenter la longueur du backlog).
Ah et une règle : commit du vendredi, build foiré pour le lundi :/
La meilleure qu'on m'ait sortie : « ya pas de doc', on fait de l'agile » o_O comme si la liste de use-cases constituait la doc' produit / installation / utilisateur... En même temps, si le commanditaire accepte que le product owner perde toute maîtrise de l'appli, à un moment, ce n'est plus vraiment de ta responsabilité...
[^] # Re: Ça s’appelle la prolétarisation des cadres
Posté par BAud (site web personnel) . En réponse au journal Et l’intelligence humaine, alors ?. Évalué à 6.
bin, au fur et à mesure :
oui, bwalors ça : avant de démarrer un nouveau sprint, demande quelle est la ligne d'imputation sur laquelle imputer et à partir de quand elle sera ouverte, ça devrait te donner le temps pour la veille technologique^W^W glande sur Internet :-) et tu imputes ton prévisionnel dès le début, ce qui validera le démarrage du sprint, si tu ne peux pas, ça décale et tu as gagné du temps.
Et les sprints, ça peut ne pas être que de coder une nouvelle fonctionnalité, mais aussi faire du refactoring, vider le backlog d'un ensemble de tâches « faciles ».
tu peux aussi faire remarquer que si à 6 le daily dure plus de 15 min, ça permet d'identifier les sujets à reporter au sprint suivant ou à changer les priorités (généralement ça stabilise le besoin ou le réduit à ce qui a correctement été identifié — au prix d'augmenter la longueur du backlog).
Ah et une règle : commit du vendredi, build foiré pour le lundi :/
La meilleure qu'on m'ait sortie : « ya pas de doc', on fait de l'agile » o_O comme si la liste de use-cases constituait la doc' produit / installation / utilisateur... En même temps, si le commanditaire accepte que le product owner perde toute maîtrise de l'appli, à un moment, ce n'est plus vraiment de ta responsabilité...