Sortie d'IceScrum beta

Logo IceScrum version 1 Cédric travaille comme un chef pendant son stage. L'application de Scrum sur le projet fonctionne bien. Les builds sont très fréquents. La nouveauté dans le build du jour, c'est la planification automatique de la release en fonction de la vélocité et de l'ordre et des points des exigences.
Nous allons pouvoir sortir début juin une version d'IceScrum qui va être pas mal du tout.

Commentaires

1. Le mercredi 24 mai 2006, 10:37 par JPS

Un peu d'agilité c'est mieux que pas du tout mais Scrum c'est parfois trop !
Je vois avec beaucoup d'intérêt se développer ce nouvel outil qui va permettre de gérer plus facilement les développements en mode agile. Avec cependant un regret : l'agilité "type Scrum" est aussi une contrainte en elle-même, par exemple en imposant les sprints. Je viens de reprendre le pilotage d'un projet qui a été mené précédemment en mode standard (specs mal validées - dévt - MeP) avec catastrophe à l'arrivée pour cause de résultat inadapté aux besoins du client. Il faudrait maintenant introduire de l'agilité pour finaliser proprement ce projet - mais les équipes ne sont pas prêtes à basculer en mode Scrum, le saut serait culturellement trop rude dans un délai court. Ne pourrait-on pas imaginer le même outil fonctionnant dans un mode light, donc sans les sprints, mais en conservant l'intérêt de piloter les developpements par les exigences et les tests clients progressifs ?

2. Le mercredi 24 mai 2006, 23:17 par Oaz

J'ai du mal à comprendre quelle est la contrainte que vous voyez dans les sprints ?
Les méthodes agiles sont itératives (en tout cas je n'en connais aucune qui ne le soit pas). Les itérations se présentent généralement sous forme de 'timeboxes', des durées pré-déterminées.
C'est peut être cela que vous trouvez contraignant ? Si tel est le cas jetez un coup d'oeil à FDD en.wikipedia.org/wiki/Fea... qui n'utilise pas ce concept de timeboxes mais rythme le développement par l'implémentation des fonctionnalités.

3. Le jeudi 01 juin 2006, 14:01 par claude aubry

JPS, je suppose que tu voulais plutôt dire sans les scrums que sans les sprints. Parce que sans itérations, ce n'est plus agile, comme le dit l'agilitateur

Les projets que je suis ne font pas des mêlées (scrums) tous les jours. Chez un client, cela se passe 2 fois par semaine et éventuellement plus souvent si un membre de l'équipe le demande. Pour le projet IceScrum pour lequel je suis Directeur produit, les scrums n'ont pas lieu quand je suis en déplacement (j'essaie quand même de faire un point par téléphone).

Cependant je ne vois pas où est la contrainte de faire des réunions quotidiennes chaque fois que c'est possible. Cela ne coûte rien d'essayer. A quel problème "culturel" penses-tu ?

Un rythme quotidien est aussi important pour la visibilité : je préconise que le reste à faire de chaque tâche soit actualisé à l'occasion des "scrums". Cela permet de produire un burndown chart utile qui donne à tout le monde la réalité de l'avancement.