Les testeurs ne doivent pas être à la merci des développeurs.
Un test doit être planifié à l'avance. Il ne faudrait pas tester les fonctionnalités développées pendant le sprint en cours mais celles développées dans le sprint précédent, pour favoriser les retours et corrections dans le sprint en cours.
Toujours prévoir du temps de développement pour la correction des bugs.
Quelques questions à se poser lors du début d'un projet pour savoir si on doit partir sur de la méthode agile ou de la méthode type waterfall.
Je pensais pas (enfin un peu) qu'il fallait faire une distinction entre plusieurs types de méthodes selon les besoins derrière : soit agile soit pas agile. En voyant ça, oui, ça parait pas mal logique de se poser ce genre de questions puisqu'au final les méthodes agiles s'emploient pour régler certains problèmes dans les équipes de développement.
Le site a l'air pas mal.
La tagline est sympa, doit y avoir pas mal de bons contenus : Ideas, Comments, and Resources about Project Management from field experiences and materials from www.niwotridge.com
Les implémentations de Lean mènent donc très souvent à un échec, retour à la normale, selon pas mal de sondages.
La conclusion du post indique cependant que le modèle de sondage n'est pas le même d'un sondage à l'autre, et que s'il y avait un modèle commun, les chiffres changeraient sûrement "drastically".
Il faut aussi voir la définition de "fail" ... de la même façon qu'en scrum on a une définition de "done".
Toute une partie de l'agilité : l'information radiator. Ou comment montrer à l'équipe de développement qu'il y a une merde et la régler cash sans perdre des heures