Archive

Posts Tagged ‘Done’

Oubliez Scrum !

14 juillet 2011 2 commentaires

Joe: Nous sommes une équipe distribuée sur plusieurs fuseaux horaires. Il est impossible de trouver 15 minutes en commun pour faire un Daily Scrum. Scrum ne marche pas chez nous, il faut l’adapter.

Oubliez Scrum ! Est-ce difficile de se rencontrer rapidement dans la journée lorsque vous en avez subitement besoin ? Le Daily Scrum vous permet de vous entraîner à cela pour que cela ne soit jamais un problème dans la journée.

Dan: Chez nous il y a deux personnes différentes qui gèrent les priorités et le budget. Il est impossible de trouver un Product Owner. Scrum ne marche pas chez nous, il faut l’adapter.

Oubliez Scrum ! Sur quels critères décidez-vous (de continuer) d’investir dans un développement ? Sur quels critères décidez-vous d’arrêter un développement ? Sur quels critères décidez-vous de libérer une version au marché ? Le Product Owner vous permet de vous entraîner à ces questions en se les posant à chaque itération.

Jude: Notre système est extrêmement complexe, inclus des dizaines de modules qui gèrent des centaines de millions de dollars. Il est impossible de livrer chaque itération un incrément potentiellement prêt pour la production. Scrum ne marche pas pour nous, il faut l’adapter.

Oubliez Scrum ! Combien de temps se passe-t-il entre le moment où votre client préféré à une idée géniale et le moment où vous lui livrer un (morceau de) logiciel qui lui permet de tirer profit de son idée ? Que faudrait-il faire pour diviser ce temps par 2 ? La livraison d’incréments terminés à chaque itération vous permet de vous entraîner à diminuer ce temps pour pouvoir être opportuniste, pour pouvoir saisir facilement les opportunités marché.

Oubliez Scrum ! L’objectif n’est pas Scrum. L’objectif est l’amélioration. Scrum vous propose plusieurs axes d’amélioration. Chaque outils de Scrum – Sprint, Product Owner, Equipe, Done, Retro, Revue, Planning, Vision, Product Backlog, etc – se concentre sur un thème précis. Ils sont conçus pour fonctionner ensemble. Ils sont difficiles à comprendre. Votre Scrum Master est là pour vous les enseigner.

Catégories :Journal, Scrum Étiquettes : , , , ,

commitment and #scrum

14 juin 2011 1 commentaire

PM: I get angry when the team does not deliver its commitment because it breaks my plan.

PO: what do you call commitment?

PM: the features they commit to deliver.

PO: how does this understanding of commitment help you?

PM: well actually it doesn’t…

PM: what do you call commitment?

PO: the Team and myself we commit to be transparent.

PM: what do you expect from this commitment?

PO: from the Team, typically two things. First, the Team will ask me if it needs help to clarify requirements. Second, the Team will only deliver done increments.

PM: what if the Team does not deliver anything?

PO: it means we failed to express my vision into product backlog items that the Team can turn into potentially shippable increments

PM: … and it breaks your plan!

PO: my plan is never broken, I change it to maximize the value of my product.

PM: what if you don’t find a better plan?

PO: I’m accountable for maximizing the return on investment. Sometimes the best business decision is to stop investing in a product.

Catégories :Journal, Scrum Étiquettes : , , ,

#tdd at school

J’ai eu la chance plusieurs fois de discuter avec des professeurs qui enseignent le Java à l’université. Nous discutions d’intégrer le tdd à l’enseignement.

Une approche consiste à intégrer le tdd à la fin de l’enseignement. J’ai d’ailleurs eu la chance de participer à cette approche en allant enseigner le tdd dans plusieurs universités. En pratique ce sont les dernières années qui en ont profité puisque cette approche suppose qu’il faut tout d’abord apprendre un langage puis apprendre le tdd.

Une autre approche consiste à intégrer le tdd tout au long l’apprentissage. J’ai eu la chance d’assister à plusieurs des cours donnés par ces professeurs et ce qui m’a frappé c’est la manière utilisée pour avoir du feedback sur un code. Typiquement les étudiants exécute un programme et regardent les traces envoyées dans la console. L’idée est bien sûr de modifier cette habitude et d’utiliser des tests pour avoir du feedback sur le code.

Pour rendre cela concret, nous avons pris le sujet du cours qu’il venait de donner, un cours sur l’héritage et le polymorphisme en Java, et nous avons écrit le test ci dessous.

@Test public void
showPolymorphism() {
    Vehicle bicycle = new Bicycle();
    Vehicle car = new Car();
    assertThat( bicycle.wheelCount(), equalTo(2) );
    assertThat( car.wheelCount(), equalTo(4) );
}

Les professeurs ont vite imaginé comment ils pourraient grandement simplifier leur travail de correction ;).

L’utilisation des tests est ici bien différente. Au lieu de considérer le tdd comme une approche à part, nous l’intégrons tout au long l’enseignement. Les praticiens du tdd le savent et l’écrivent souvent : le tdd est parfait pour apprendre un nouveau langage. Alors pourquoi pas à l’école ?

Catégories :Journal, Non classé, TDD Étiquettes : ,

Définir « Terminé »

Résumé
Les axes de réflexion que je considère pour construire une définition de Terminé :

  • qualité externe
  • qualité interne
  • autorisations
  • déploiement
  • exploitation

Lorsque je travaille avec une équipe à établir ou modifier notre définition de « Terminé » (le Done de Scrum), je ne leur propose pas d’exemple comme point de départ de la discussion. Par contre je leur propose les différents axes de réflexion dans lesquels nous allons identifier les points pertinents pour eux.

Pour démarrer la discussion, je propose de commencer par explorer les axes qualitatifs :

  • qualité externe
  • qualité interne

Qualité externe
Cette notion de qualité externe nous parle de notre capacité à construire le bon logiciel, celui qui rend les services souhaités, à un niveau de performance satisfaisant, à un niveau d’ergonomie qui fluidifie sa prise en main et son utilisation. C’est la qualité perçue lorsqu’on utilise le système.

Pendant cette réflexion, nous partageons alors comment nous comprenons cette idée de qualité externe et nous décidons quels types de tests nous souhaitons construire notre confiance dans notre code : des tests automatiques qui exercent le système dans son ensemble avec des données réalistes, des tests qui spécifient les conditions aux limites des services rendus, des tests de performance, des tests de sécurité, des tests de traduction, …

La question des anomalies est parfois abordée à ce moment dans la discussion. Cette discussion peut être difficile parce que chargée d’un historique peu flatteur pour les programmeurs. On distingue ici deux types d’anomalies: les anomalies que l’on découvre après la mise en production et celles que l’on connaît avant la mise en production.
Pour les premières, il s’agit de définir comment nous allons les prendre en compte, c’est à dire comment leur découverte va impacter le travail en cours. La démarche stop the line du Lean est la démarche la plus cohérente avec une approche empirique, même si elle représente des défis importants.
Pour les secondes une attitude cohérente avec ce que l’on vient de dire consiste à ne jamais déployer un système avec des anomalies connues. Cela demande souvent beaucoup de courage dans des environnements qui ont malheureusement appris à supporter des systèmes avec beaucoup d’anomalies.

Qualité interne
Cette notion de qualité interne nous parle de notre capacité à construire correctement un logiciel. Par correctement, on entend ici un logiciel que l’on peut faire évoluer durablement. Plusieurs outils aujourd’hui sont capables de construire des indicateurs qui, lorsqu’on les améliore, nous aide à construire un logiciel que l’on peut faire évoluer durablement. Par exemple le pourcentage de couverture de code par des tests unitaires et d’intégration, la compléxité cyclomatique, le taux de duplication… Certains outils, comme Sonar, vous permettent même assez simplement d’implémenter votre propre règle.

Les tests automatiques sont des indicateurs de qualité assez simples à construire car ils se basent sur une analyse statique du code, c’est à dire sur une photo du code à un instant donné. Or il se trouve que l’on a constaté que le fait d’écrire un test avant d’écrire le code de production qui le fait passer a un impact majeur très positif sur la qualité du logiciel construit. On parle ici d’un indicateur de qualité dynamique qui nous renseigne sur la manière dont le logiciel a grandit. La plupart des équipes mettent en place cette idée simplement en ayant la discipline de toujours écrire un test avant d’écrire du nouveau code.

Vient ensuite, dans l’ordre chronologique des étapes à passer pour être prêt à déployer un système en production, la question des autorisations nécessaires.

Autorisations
Certaines industries contrôlées imposent aux créateurs de logiciels de faire la preuve de certaines caractéristiques dans un format imposée par une convention. C’est le cas par exemple dans l’avionique ou la pharmacie, pour en citer deux à priori assez éloignées. D’autres normes, internes celles-ci s’imposent parfois aux équipes.

La plupart du temps, ce besoin d’autorisation déclenche la rédaction de document dans un format souvent imposée à l’équipe. Le travail récurrent d’une itération à l’autre consiste alors selon les cas à les créer ou bien à les tenir à jour.

Déploiement
Le déploiement par incréments successifs suppose que plusieurs déploiements vont être effectués pour mettre à jour un système. Dans ce contexte, il est pertinent de ne pas considérer le premier déploiement comme un cas particulier mais bien comme le déploiement d’un incrément qui part d’un état précédent vide.
Des éléments de différentes natures sont à considérer. Sans ordre d’importance, on peut citer : un moyen d’interdire l’accès au système pendant le déploiement du nouvel incrément, la modification de l’environnement, la modification des configurations réseaux, la modification de la structure de données, la migration des données, … Disposer de tests automatiques de déploiement s’avère encore une fois très utile pour être capable de déployer chaque incrément sans détruire le système déjà en place.

Exploitation
Ce qui précède concerne la préoccupation de mise à jour d’un système existant. Il faut aussi considérer les activités qui tournent autour de l’utilisation du système en place. Selon les cas il s’agit de choses aussi variées que des scripts de redémarrage, la formation des utilisateurs, la formation des équipes travaillant à la hot-line du système, …

Si le développement incrémental est nouveau pour vous et que vous avez des difficultés à établir votre définition de Terminé avant de commencer, rassurez-vous c’est normal. Explorez pendant une première discussion les différents axes de réflexion qui vous semblent sensés et établissez vos premiers indicateurs en fonction de la vision du produit. Faites une itération et pendant la revue d’itération posez vous la question: est-on prêt à déployer cet incrément en production ? Si oui, faites le. Si non, améliorez votre définition de Terminé pour la suite.

Catégories :Journal, Scrum Étiquettes :

TDD vs DDD vs BDD vs xDD vs …

Ce que je tente d’expliquer pendant les cours de Test-Driven Development (TDD) c’est que le TDD est une approche générique pour aborder un développement logiciel.

« Malheureusement », quand on lit « TDD », on comprend souvent tests « unitaires ». Sans doute parce qu’historiquement les premiers tests écrits en suivant cette approche ont été des tests « unitaires ». Mais le concept peut se voir plus globalement.

Par exemple si on ne prend les deux cours suivants proposés par Pyxis:

  • Test-Driven Development
  • Specifications exécutables avec GreenPepper

Le premier propose des ateliers d’écriture de tests automatiques écrits avec un framework xUnit alors que le second se concentre sur l’écriture de tests automatiques écrits avec GreenPepper. En lisant plusieurs forums je réalise que certains contributeurs classeraient sans doute naturellement le premier dans une case TDD et le second dans une case DDD, voire BDD. En fait les deux cours appartiennent à la catégorie TDD.

« Test-Driven » est seulement une autre manière de dire : définissons ce que nous attendons sous la forme d’un test. Pour moi – je suis Scrum Master 😉 – cette approche est similaire à avoir une définition de « terminé ». Cette façon de nous exprimer pourrait d’ailleurs nous emmené sur plusieurs branches si nous poursuivions l’analogie avec Scrum. Quel est votre fil de penséé ? tests->liste de tests->backlog de tests->specifications exécutables->Product Backlog ?

Catégories :Journal, TDD Étiquettes :