Dans une version récente de "The Scrum Papers", je documente l'utilisation du système de suivi des bogues GNATS dans mon entreprise PatientKeeper pour gérer une implémentation complexe de Scrum. Dans mon cours Scrum Tuning, j'utilise un nombre de complexité égal à (nombre d'équipes) x (nombre de versions par an) x (nombre de produits) x (nombre de kits ou de branches de versions séparées pour prendre en charge les plates-formes des fournisseurs). PatientKeeper a un indice de complexité de 3240, ce qui est plus élevé que toutes les autres entreprises Scrum que j'ai vues, à l'exception d'un projet de British Telecom qui compte plus de 1000 personnes.
La prise en charge d'un tel niveau de complexité chez PatientKeeper nécessite un "tout-en-un-Scrum" utilisant un système entièrement automatisé. J'ai abandonné le terme Scrum de type C utilisé dans mon article Agile 2005 sous le nom de Scrum Trainers, car il prête à confusion. Il n'y a qu'un seul Scrum et certains prétendent même qu'un Scrum qui multiplie les Sprints à travers plusieurs équipes n'est pas vraiment Scrum. Permettez-moi de noter que Mary et Tom Poppendieck ont documenté le All-At-Once-Scrum dans leur récent livre sur la mise en œuvre du développement de logiciels allégés comme l'une des mises en œuvre Agile les plus performantes de la planète, Ken Schwaber a fait remarquer qu'il s'agissait d'un "monstre compétitif" et au moins cinq entreprises ont discuté avec moi de leur mise en œuvre de ce vilain petit canard. L'une d'entre elles a même publié un article sur sa mise en œuvre lors de la Hawaii International Conference on Software Systems en janvier 2007. Cette mise en œuvre de Scrum nécessite la participation totale et entière de la direction générale et d'un MetaScrum dirigé par un Chief Product Owner qui conduit la stratégie produit de l'entreprise, sans parler du déploiement en direct à la fin de chaque Sprint. Mais je m'éloigne du sujet...
Très peu d'entreprises utilisant Scrum sont des entreprises de plateforme. Ces entreprises ont tendance à faire appel à des équipes d'architecture en couches, car les API des différentes couches logicielles sont des produits utilisés par des dizaines de partenaires technologiques et constituent donc des fonctionnalités qui doivent être prises en charge avec encore plus de soin qu'une fonctionnalité typique orientée vers l'utilisateur dans une application web. J'ai travaillé avec Google, Palm et PatientKeeper. Amazon utilise Scrum pour traiter des fonctions de plateforme similaires. Pour prendre en charge correctement la complexité de ces implémentations, un outillage avancé est nécessaire. L'un des avantages de cet outillage est qu'il prend en charge des équipes évolutives, distribuées et externalisées, ce qui est un effet secondaire trivial, mais important.
L'outil mis en place chez PatientKeeper répondait à une exigence clé fixée par l'équipe de développement dès les premiers jours de l'entreprise. Il devait prendre moins de 60 secondes par jour à un développeur et moins de 10 minutes par jour au ScrumMaster pour fournir à l'entreprise un rapport d'analyse actualisé et tout autre rapport qu'un responsable pourrait demander à la demande.
La solution consistait à ajouter cinq éléments de données à un système de suivi des bogues open source, ainsi que des améliorations mineures de l'interface utilisateur et la possibilité d'effectuer des vidages nocturnes de données pour les importer dans des feuilles de calcul Excel. Bien que j'aie régulièrement recommandé de mettre à niveau le système GNATS de PatientKeeper vers une solution open source plus récente, il est devenu aussi essentiel pour PatientKeeper qu'un système de comptabilité en ligne pour une banque. S'il tombe en panne, l'entreprise tombe en panne. C'est pourquoi l'équipe de développement a refusé d'envisager une mise à jour.
Parmi les nombreuses fonctionnalités que j'aimerais trouver dans un nouveau système, il y a une meilleure interface utilisateur et une connexion automatisée à un système de contrôle de version. Trac était intéressant car il s'agit d'un système de suivi des bogues basé sur un wiki qui peut être étendu pour prendre en charge un "Tout-en-un-Scrum" et qui dispose d'une liaison directe avec Subversion. Comme le système de gestion de la configuration du code Subversion est une mise à niveau facile de CVS, je le recommande également à PatientKeeper. Cependant, la nature de notre gestion complexe des branches de code pour soutenir un All-At-Once-Scrum est encore plus critique que le système de rapport Scrum en temps réel. "Hélas, dit l'ingénieur, n'y pensez même pas !
J'espère que le jour viendra où PatientKeeper décidera de se mettre à niveau. Ils devront le faire comme les grandes banques avec lesquelles je travaillais et qui utilisent deux systèmes en ligne en parallèle pendant plusieurs semaines pour s'assurer que tout fonctionne parfaitement avant de passer à la vitesse supérieure. Pour ceux d'entre vous qui n'ont pas encore opté pour le zéro papier, le zéro carte et le zéro note, il existe d'autres options.
Note : En 2008, PatientKeeper est passé à Jira et Subversion.
Les premières versions de Trac ne prenaient pas facilement en charge Scrum. Cependant, la dernière version de Trac est plus flexible et une société basée à Londres a développé un plugin Scrum open source, la première des nombreuses exigences de l'outil dont j'ai besoin.
Voir le blog de Daan pour les dernières mises à jour sur le plugin Trac Scrum.
French 
English 
Spanish