Affichage des articles dont le libellé est SCRUM. Afficher tous les articles
Affichage des articles dont le libellé est SCRUM. Afficher tous les articles

mardi 1 février 2011

CHAPTER 2: Challenges faced by distributed teams

My notes out of the book “A Practical Guide to Distributed Scrum

Communication

Generally speaking, communication is a lot about non verbal channel. Indeed, verbal channel is only 35% of communication. As a consequence distributed teams communicate with a real handicap.

Meeting at least once help to know each other’s personalities, mannerisms, communication style and culture.

Time zone and working hours

Every meeting is a challenge

Cultural differences

In some countries, it is inappropriate to say “I don’t understand” the speaker. This can result to a big waste of time and energy.

Humor can differ from country to country. Handle it with care.

Words can have different meaning.

Management style can also be different.

Language differences

A scrum team needs to communicate a lot so the language difference makes it harder. Keeping language simple will help those who are not speaking mother language.

Give everyone a chance to speak.

Use chat tools to share links

Confirm understanding

Address communication tools issue such bad phone or poor network connection.

Software Engineering practices

“Good software engineering practices are important for both collocated and distributed teams BUT for distributed teams poor engineering practices are much more obvious and are a greater problem”

- TDD helps delivering high quality tested code. It helps the team to evolve design over the time.

- Continuous integration helps teams to integrate their work frequently

- CI running automated tests detect regression problem quicker

Generally speaking, any tool helping to discover problems soon is a good tool because the later issues are discovered, the more expensive they are.

Delivering value at every 2-3 weeks sprint is a challenge and good engineering practices will considerably help distributed teams.

Schedule difference

Take into account holidays of the different zones to help commitment.

Team dynamics

“Making the daily scrum a priority is one example of how to keep the whole team engaged”

Telephone dynamics

Providing access to call -> toll free numbers (very important for home workers)

The Scrum Master takes the responsibility everyone hears and participates

Identify the speaker (Luc’s speaking : “bla bla bla”)

Handling visual cues encourage participation and limit side conversation

Check for agreement and disagreement.

Impact of Communication problems

Obvious problems: Team members not doing the right task, doing the task correctly or doing the task at the expected time.

More subtle problems: tasks outside team’s mission can pull away members to work on lower priority matters. This is more difficult to see on distributed teams.

Scrum helps mitigate this problem through the daily Scrum.

“KEY POINT: The more closely a distributed team can adopt Scrum as designed by its creators, the more likely a team will experience success. The design of Scrum promotes good communication. At the same time, with some minor adaptations for distributed teams, Scrum can help teams deliver the right product, at the right time, with the right quality”.

Forming-Storming-Norming-Performing model: http://en.wikipedia.org/wiki/Tuckman's_stages_of_group_development

- Distributed teams easily block at the storming stage. When the team changes, it can start over at forming stage. The performing stage is fragile and because of the limited personal contact, remote teams take longer to get through this stage.

How does Scrum help?

It does not help fixing problems! It just puts a spotlight on them so that the teams can identify and address them. All scrum artifacts are designed to help the team seeing progress and issues. Sprints, daily scrums, retrospectives, sprint planning are all important and mastering them can lead the team to performance. Scrum is like glasses, it makes more visible dysfunctions.

Share/Bookmark

lundi 31 janvier 2011

A Practical Guide to Distributed Scrum – IBM Press

By Elizabeth Woodward, Steffan Surdek, Matthew Ganis.

http://www.ibmpressbooks.com/bookstore/product.asp?isbn=0137041136

Untitled 

Here are my notes picked up when reading the book

CHAPTER 1 : The Evolution of Scrum

Collocation is no longer the norm: only 45% of collocated teams – from a recent survey –

Advantages of distributed teams

  • Use time shift for 24/24 h development effort
  • Reaching market more quickly with the “follow the sum model” :
  • Multinational companies produce more ideas than domestic counterparts

A lot of distributed teams are the result of acquisition.

Four level of distribution with more and more difficulties

Collocated

Collocated part-time

  • dailies with remote callers,
  • “out of sight, out of mind”,
  • biggest challenge is to invite remote people to planning and design sessions.

Distributed with overlapping hours

  • Not easy to plannify sprint planning and review
  • Scrum meetings lack of body language
  • Cultural / language difference

Distributed with no overlapping hours

  • Every meeting is a challenge

Three ways of handling distributed teams

Isolated Scrums model

  • No synchronization needed between teams
  • Each location has a cross functional team.
  • Usually the first two level of distribution

Distributed Scrum of scrum

Scrum of scrum daily (Ken Schwaber 2004)

    1. What did you team do yesterday?
    2. What will your team do today?
    3. What blockers have you met?
    4. + What blockers might you be throwing into another team’s way?
  • Longer meeting fewer time to give all members time to communicate
  • Several Product owners who make a single team : Need to speak with single voice

Totally Integrated teams

  • Each team has members in several location (Ex : All testers in a single location)
  • In such a context, Scrum can improve productivity by 5 to 10 compared to industry average

 

Comments are welcome ; Comming soon : Chapter 2 : Challenges faced by distributed teams

Share/Bookmark

jeudi 25 novembre 2010

Agile Grenoble 2010 – 10 Messages que j’ai retenu

ag2010_logoheader

“Nombre de WTF par minute = métrique représentant la qualité du code”

– Aslak Hellesoy - WTF = What the fuck

_

“Loi de Little : Moins on en fait à la fois, plus on va vite”

– Hervé Lourdin, Cyril Mégard

_

“Il faut garder du mou pour absorber la variabilité”

- Hervé Lourdin, Cyril Mégard

_

“L’Agilité est un long voyage. Elle évolue depuis la fin des années 90 et va continuer à évoluer”

– Claude Aubry – Laurent Bossavit

_

“Le TDD dans le Legacy Code, c’est possible et bénéfique”

– Bernard Huguet, Cyrille Roy, Johan Martinsson, Luc Jeanniard ;o)

_

“La programmation fonctionnelle permet de résoudre des problèmes de façon élégante et efficace”

– Emmanuel Gaillot

_

“Bonjour Mr Orsier, je vous apporte le cahier des charges (un énorme classeur) – c’est presqu’ … le définitif”

– Rémy Sanlaville, Bruno Orsier

_

“Il faut commencer le dev le plus tôt possible pour obtenir du feedback rapidement”

– Alexandre Boutin

_

“Portfolio agile : synchroniser les releases pour être réactif au changement”

- Jean Dupuis, Jean-François Jagodzinski

_

“'jcQualitystreet #agilegrenoble: On est loin mais on attend des tweets et du feedback! @NicoRuffel @claudeaubry @agilex @LucJeanniard @jfjago @calton13”

– Jean Claude GROSJEAN via Twitter !

_

Il y a très certainement d’autres messages importants mais c’est la loi de ce genre d’événement, il faut faire des choix, on ne peut pas tout voir, tout entendre, tout retenir … Rendez-vous en 2011 !

Le programme complet est sur http://agile-grenoble.org/

.

Share/Bookmark

jeudi 30 septembre 2010

Tester unitairement du “Legacy Code” : un exemple

(Note au utilisateur de GoogleReader : Pour une raison inconnue, les couleurs ne sortent pas … lisez plutôt ici)

 

Je souhaite vous montrer dans ce billet un exemple d’ajout de test unitaire dans du legacy code. Du legacy code, c’est du code non testé automatiquement. Je travaille tous les jours sur du code non couvert par des tests automatiques alors capitaliser en ajoutant petit à petit des tests est un réel enjeu pour éviter les régressions.

 

Le Problème

 

Voici une classe développée il y a presque 10 ans pour dessiner des annotations sur un graphique. Il se trouve que dans certaines  rares conditions, l’annotation sort du graphique et ceci ne fait pas propre lors de son impression. Nous avons donc souhaité corriger ce défaut.

__________________________________________________________________

TSKRAnnotDrawer = class

 private

   FAnnotList: TList;

   FSquaring: TSquaringType;

   FHorizontalMaille: Real;

   FVerticalMaille: Real;

 

   procedure Sort;

   function GetAnnot(Index: Integer): PAnnotRec;

   procedure FindCorrespondingSquaringRectangle(aRect: TRect;

X, Y: Integer;

var SquaringRow, SquaringCol: Integer);

   procedure CalculateSquaringRectanglesNumber(aRect: TRect;

W, H: Integer; var SquaringWidth, SquaringHeight: Integer);

   function FindFreeSpace(SquaringRow, SquaringCol,

SquaringWidth, SquaringHeight: Integer;

var SquaringFreeRow, SquaringFreeCol: Integer;

var UpOrDown:         Boolean): Boolean;

   function TestIfItIsInTheGraphic(row, col,

SquaringWidth, SquaringHeight: Integer): Boolean;

   function TestIfTheSpaceIsFree(row, col,

SquaringWidth, SquaringHeight: Integer): Boolean;

   procedure UpdateFSquaring(row, col, SquaringWidth, SquaringHeight: Integer);

 public

   PeakAnnotation: TSKRPeakAnnotationPrefs;

   EventAnnotation: TSKREventAnnotationPrefs;

   procedure Create;

   procedure Destroy; override;

   procedure ClearList;

   procedure AddToList(aAnnot: TAnnotRec);

   procedure Draw(Canvas: TCanvas3D; arect: TRect);

 end;

__________________________________________________________________

 

Nous allons nous intéresser à la méthode “Draw”. Après investigation, l’erreur provient du calcul de la hauteur de la première annotation. En effet, la ‘font size’ est assignée après le calcul de la hauteur du texte : voir ci-dessous le texte en rouge.

__________________________________________________________________

procedure TSKRAnnotDrawer.Draw(Canvas: TCanvas3D; aRect: TRect);

var

i, Width, Height: Integer;

UpOrDown: Boolean;

w, h: Integer;

AnnotationPrefs: TSKRAnnotation;

row, col: Integer;

SquaringRow, SquaringCol: Integer;

SquaringWidth, SquaringHeight: Integer;

SquaringFreeRow, SquaringFreeCol, XFree, YFree, YFreeTemp: Integer;

begin

assert(EventAnnotation <> nil);

assert(PeakAnnotation <> nil);

 

// sort annotation according time

Sort;

Width := 0;

Height := -1;

 

 //initializing the squaring array.

 for row := 0 to Pred(SquaringSize) do // Iterate

 begin

   for col := 0 to Pred(SquaringSize) do // Iterate

   begin

     FSquaring[row, col] := True;

   end; // for

 end; // for

 

 for i := 0 to Pred(FAnnotList.Count) do

   with GetAnnot(i)^ do

   begin

  

     if Typ = 0 then

       AnnotationPrefs := EventAnnotation

     else

       AnnotationPrefs := PeakAnnotation;

 

     UpOrDown := AnnotationPrefs.AutoUpDown = apUp;

 

     if AnnotationPrefs.Orientation = aoOblique then

     begin

      //We take the size of the rectangle projection on a vertical axis

       H := round(Sin(Pi / 4) * (Canvas.TextWidth(Text) + Canvas.TextHeight(Text)));

      //and for W the size of the rectangle projection on the horizontal axis

       W := round(Cos(Pi / 4) * (Canvas.TextWidth(Text) + Canvas.TextHeight(Text)));

     end

     else if AnnotationPrefs.Orientation = aoVertical then

     begin

       H := Canvas.TextWidth(Text);

       W := Canvas.TextHeight(Text);

     end

     else //Horizontal

     begin

       H := Canvas.TextHeight(Text);

       W := Canvas.TextWidth(Text);

     end;

 

     H := H + 4;

 

    if AnnotationPrefs.AutoUpDown = apAuto then

     begin

       Canvas.Font.Name := AnnotationPrefs.Font.name;

       Canvas.Font.Size := AnnotationPrefs.Font.Size; //INTERVIENT TROP TARD

     end;

 

     if AnnotationPrefs.LinkType = ltNone then

     begin

                ... 6 lines

     end

     else

     begin

                ... 30 lines

     end;

 

     DrawAnnotation(Canvas, Text, Point(XFree, YFree),

       XFree, AnnotationPrefs, UpOrDown, Width, Height, X, Y, aRect);

   end;

end;

__________________________________________________________________

 

La correction est triviale, il suffit de remonter l’affectation de la font size avant la première utilisation du Canvas.

 

Mais comment tester ce que l’on souhaite modifier?

 

Le cheminement vers le test unitaire

 

Ma première idée fut d’instancier la classe et appeler la méthode Draw dans un test unitaire. En effet, le constructeur ne prend pas de paramètre alors ça paraissait facile. Ensuite, il a fallu ajouter des assertions à mon test et là les ennuis commençaient. En effet, je n’avais aucune envie de vérifier le rendu sur le graphique (via le Canvas) car je ne savais pas comment m’y prendre.

 

Donc je suis reparti de zéro afin d’isoler mon problème. J’ai suivi les étapes suivantes :

 

1- Extraction de la partie de code problèmatique

 

Je ne prend pas de risque à ce niveau là et je fais confiance au compilateur pour m’indiquer les éventuels problèmes.

 

__________________________________________________________________

 

procedure TSKRAnnotDrawer.getTextHeightAndWidth(

     const aCanvas: TCanvas3D;

     const aAnnotationPrefs: TSKRAnnotation;

     const aText: string;

     var oTextHeight, oTextWidth: integer);

begin

   if AnnotationPrefs.Orientation = aoOblique then

   begin

    //We take the size of the rectangle projection on a vertical axis

     H := round(Sin(Pi / 4) * (Canvas.TextWidth(Text) + Canvas.TextHeight(Text)));

    //and for W the size of the rectangle projection on the horizontal axis

     W := round(Cos(Pi / 4) * (Canvas.TextWidth(Text) + Canvas.TextHeight(Text)));

   end

   else if AnnotationPrefs.Orientation = aoVertical then

   begin

     H := Canvas.TextWidth(Text);

     W := Canvas.TextHeight(Text);

   end

   else //Horizontal

   begin

     H := Canvas.TextHeight(Text);

     W := Canvas.TextWidth(Text);

   end;

    H := H + 4;

   if AnnotationPrefs.AutoUpDown = apAuto then

   begin

     Canvas.Font.Name := AnnotationPrefs.Font.name;

     Canvas.Font.Size := AnnotationPrefs.Font.Size; //INTERVIENT TROP TARD

   end;

end;

 

__________________________________________________________________

 

Là, ça devient plus simple de tester cette fonction mais celle-ci n’est pas publique et changer l’API, c’est à dire le contrat de la classe, à des fins de tests n’est pas élegant. En effet, cette méthode n’a pas d’intéret pour l’utilisateur de la classe.

 

 

2- Extraction de la méthode vers une classe spécifique

 

En ayant en tête les principes SOLID et plus particulièrement celui qui dit qu’une classe ne doit avoir qu’une responsabilité, je n’ai pas d’état d’âme à créer une classe pour isoler ma méthode:

 

__________________________________________________________________

 

TTextPixelSizeHelper = class

public

 class procedure GetTextHeightAndWidth(

   const aCanvas: TCanvas3D;

   const aAnnotationPrefs: TSKRAnnotation;

   const aText: string;

   var oTextHeight, oTextWidth: integer);

end;

 

class procedure TTextPixelSizeHelper .getTextHeightAndWidth(

     const aCanvas: TCanvas3D;

     const aAnnotationPrefs: TSKRAnnotation;

     const aText: string;

     var oTextHeight, oTextWidth: integer);

begin

  ... idem ...

end;

__________________________________________________________________

 

 

Je ne prend toujours pas de risque et je fais confiance au compilateur pour les éventuelles erreurs de refactoring. Je n’ai changé aucun comportement.

 

La méthode Draw peu maintenant utiliser cette nouvelle classe :

 

__________________________________________________________________

procedure TSKRAnnotDrawer.Draw(Canvas: TCanvas3D; aRect: TRect);

var

...

begin

...

 for i := 0 to Pred(FAnnotList.Count) do

   with GetAnnot(i)^ do

   begin

     if Typ = 0 then

       AnnotationPrefs := EventAnnotation

     else

       AnnotationPrefs := PeakAnnotation;

 

     UpOrDown := AnnotationPrefs.AutoUpDown = apUp;

 

     TTextPixelSizeHelper.GetTextHeightAndWidth(Canvas, AnnotationPrefs, Text, H, W);

        ...

 

     DrawAnnotation(Canvas, Text, Point(XFree, YFree),

       XFree, AnnotationPrefs, UpOrDown, Width, Height, X, Y, aRect);

   end;

end;

__________________________________________________________________

 

Au passage, nous avons diminué la complexité cyclomatique de la fonction et facilité sa compréhension.

 

 

3- Ecriture d’un test qui échoue

 

Le principe du test est d’appeler deux fois de suite la fonction ‘GetTextHeightAndWidth’  avec le même texte et de vérifier qu’elle donne deux fois le même résultat.

__________________________________________________________________

  

procedure TSKRAnnotDrawerTest.testPeakNamesMightBePrintedBeOutisdeOfTheChartArea;

const

  TEXT1_TO_DRAW = 'TestPeakAnnot';

  TEXT2_TO_DRAW = TEXT1_TO_DRAW;

  PEAK_ANNOTATION_TYPE = 1;

var

  chart: TOrlandoChart;

  form: TForm;

  canvas: TCanvas3D;

  peak_annotation_prefs: TSKRPeakAnnotationPrefs;

  text1_height_result, text2_height_result: integer;

  text1_width_result, text2_width_result: integer;

begin

  peak_annotation_prefs := TSKRPeakAnnotationPrefs.Create;

 

form := TForm.Create(nil);

chart := TOrlandoChart.Create(form);

chart.ParentWindow := form.Handle;

canvas := chart.Canvas;

 

 try

   canvas.Font.Size := 4;

   assert(canvas.Font.Size <> peak_annotation_prefs.Font.size, 'Font size must be different to show the defect problem');

 

   TTextPixelSizeHelper.GetTextHeightAndWidth(

canvas, peak_annotation_prefs, TEXT1_TO_DRAW,

text1_height_result, text1_width_result);

   TTextPixelSizeHelper.GetTextHeightAndWidth(

canvas, peak_annotation_prefs, TEXT2_TO_DRAW,

text2_height_result, text2_width_result);

 

   CheckEquals(text1_height_result, text2_height_result,

'calling twice the function with same text should provide the same Height  result!');

   CheckEquals(text1_width_result, text2_width_result,

'calling twice the function with same text should provide the same Width result!');

 finally

   peak_annotation_prefs.Free;

   chart.Free;

   form.free;

 end;

end;

_________________________________________________________________

  

red

 

 

 

4- Correction du bug

 

La correction conciste à déplacer quelques lignes de code afin d’assigner la “font size” du canvas avant de s’en servir:

 

_________________________________________________________________

  

procedure TTextPixelSizeHelper.getTextHeightAndWidth(

     const aCanvas: TCanvas3D;

     const aAnnotationPrefs: TSKRAnnotation;

     const aText: string;

     var oTextHeight, oTextWidth: integer);

begin

   if AnnotationPrefs.AutoUpDown = apAuto then

   begin

     Canvas.Font.Name := AnnotationPrefs.Font.name;

     Canvas.Font.Size := AnnotationPrefs.Font.Size;

   end;

   if AnnotationPrefs.Orientation = aoOblique then

   begin

    //We take the size of the rectangle projection on a vertical axis

     H := round(Sin(Pi / 4) * (Canvas.TextWidth(Text) + Canvas.TextHeight(Text)));

    //and for W the size of the rectangle projection on the horizontal axis

     W := round(Cos(Pi / 4) * (Canvas.TextWidth(Text) + Canvas.TextHeight(Text)));

   end

   else if AnnotationPrefs.Orientation = aoVertical then

   begin

     H := Canvas.TextWidth(Text);

     W := Canvas.TextHeight(Text);

   end

   else //Horizontal

   begin

     H := Canvas.TextHeight(Text);

     W := Canvas.TextWidth(Text);

   end;

    H := H + 4;

end;

_________________________________________________________________

  

green 

 

 

La barre est verte! Donc place au refactoring si nécéssaire.

 

 

Conclusion

 

Tester du legacy code peut décourager bon nombre de développeurs. Ce n’ai pas très compliqué mais ça demande une petite gymnastique intellectuelle. Tout m’a semblé plus facile après quelques essais et la lecture du bien connu livre de Michael C. Feathers “Working Effectively with Legacy Code” . Ce n’ai pas toujours possible à un coût raisonnable alors dans notre équipe, nous ne nous demandons pas une obligation de résultat.

 

Avec quelques amis développeurs Grenoblois, nous allons présenter une session dédiée à ce sujet sur du vrai code lors de la conférence Agile Grenoble 2010; venez nous voir ;o) !

 

 

 

 

Share/Bookmark

mercredi 24 février 2010

Que contient la vélocité?

Qu'est ce que la vélocité

La vélocité est un indicateur de Scrum permettant d'obtenir de la visibilité. Elle mesure l'effort en points qu'une équipe peut réaliser sprint après sprint. Donc à partir d'un Product Backlog où les fonctionnalités sont estimées en points, on peut obtenir une idée du contenu du produit à une date donnée. L'équipe se sert également de sa vélocité pour savoir à quelle quantité de travail elle peut s'engager.

Doit-elle contenir les points provenant des défauts et besoins techniques?

Pour moi, la vélocité contient seulement les points des "user stories"; les défauts et besoins techniques n'en font pas partie. Plusieurs fois, j'ai rencontré des équipes qui souhaitaient intégrer à la vélocité les points des défauts et besoins techniques pour avoir plus de précision sur le nombre de points qu’elle est capable de réaliser tout type d’éléments de backlog confondus. Pourquoi pas mais il faut être très vigilant car la vélocité doit représenter la capacité d'une équipe à ajouter de la valeur à un produit or si aucune distinction n'est faite quant à la provenance des points, une équipe peut avoir une vélocité presque constante et ne pas ajouter de valeur au produit. 

Ma façon de penser vient d'être renforcée par le Tweet d'Elisabeth Hendrickson alias @testobsessed:

<< Thinking: Giving bug fixes velocity pts artificially inflates the number and creates a dangerous illusion of progress. >>

Je vous suggère de lire les billets suivants qui traitent de la même problématique:

Ma Conclusion

Intégrer l'effort des défauts et besoins techniques à la vélocité oui mais en gardant l'information de la provenance des points avec un graphique tel que celui-ci :

image

ou encore pour y voir plus clair sans lunette ;o), tiré de « Pour passer la crise, rembourser votre dette technique » - Freddy Mallet / Rémy Sanlaville - cf. p55

image

Share/Bookmark

mardi 19 janvier 2010

Le Café des Scrum Masters

Il y a quelques temps, je trouvais que les échanges entre les Scrum Masters de notre entreprise étaient trop limités. Ceci était selon moi dommage car nous étions relativement livrés à nous même. Les succès n’étaient pas partagés et les difficultés non échangées… Pas terrible, non?

J’ai alors eu envi de créer un espace d’échange informel avec tous les Scrum Masters de tous les projets soit 5 personnes. Je me suis dis qu’autour d’un café, ceci permettrait une discussion plus décontractée.

Voici ci dessous l’e-mail que j’ai envoyé à mes collègues pour que cet espace puisse devenir réalité :

____________________________________________

Chers collègues Scrum Masters,
J'aimerais organiser un espace d'échange entre les Scrum Masters de notre site. Un tel espace nous permettrait de partager  nos expériences, de trouver des réponses à nos questions, de synchroniser nos actions et d'avoir une vue globale de nos projets et besoins. Aujourd'hui, le lien entre les équipes est assez faible bien qu'amélioré grâce aux journées labo; alors le challenge, c'est d'améliorer ces liens entre les Scrum Masters et de progresser ensemble sur notre rôle qui est vital pour le succès de l'application de Scrum.
Je vous propose un café pris ensemble une fois par semaine sur un créneau d’une heure, le Vendredi par exemple. Si un autre format vous semblerait meilleur, n'hésitez pas à proposer!
Alors, partant? Sinon, qu’est ce qui vous bloque? Et quelles seraient vos propositions pour répondre à ce challenge?

____________________________________________

Les réponses ont toutes été favorables alors très vite notre première rencontre a été planifiée. Voici les sujets que nous avons abordé pendant les quatre premières rencontres:

  • Comment partager les bonnes pratiques issues des rétrospectives?
  • Comment être facilitateur d’une rétrospective alors que l’on est développeur dans la même équipe?
  • Discussion subjective sur la qualité de nos produits.
  • Discussion sur le découpage des “user stories” et évaluation en heure
  • Débat sur l’utilité d’une méta-rétrospective pour les Scrum Masters d’un même projet.

 

Conclusion

  1. Des vraies actions sont issues de ces discussions; on peut donc dire que le ROTI (Return On Time Invested) est bon.
  2. La durée retenue est de 1/2 heure; ceci permet de se focaliser sur un seul sujet.
  3. Le coté informel est confortable; il n’y a pas d’obligation de résultat.
  4. C’est un excellent exercice de construction d’équipe (Team Building).
Share/Bookmark

mercredi 6 janvier 2010

Résultat enquête de satisfaction Agile Tour 2009

image Jean-François vient de publier le résultat de l’enquête de satisfaction de l’Agile Tour 2009 à Grenoble. Merci à toi Jean-François et à toutes les personnes qui se sont dévouées pour extraire les informations de l’enquête!

Lors de cet événement, j’ai co-animé avec Eric Mignot la session « La gestion des défauts et besoin non fonctionnels avec Scrum ». C’était une première pour moi et je dois dire que j’ai dû canaliser une certaine appréhension! A la fin de notre session, j’étais satisfait et n’avais pas de regret alors mon challenge personnel était réussi.

Je n’ai pas eu beaucoup de feedback après la session alors la question que je me posais - “notre session a t-elle plu au public” - était restée sans véritable réponse. L’enquête révèle à mon agréable surprise que notre session arrive 5 ème / 17 au classement des sessions préférées! Donc je suis content et un peu fière quant même!

image

Bravo à Rémy Sanlaville et Freddy Mallet qui décrochent le pompon derrière nos invités de renommée internationale pour leur session « Pour passer la crise, rembourser votre dette technique ». Je dois dire que cette session m’a également beaucoup plu.

Share/Bookmark

mercredi 9 décembre 2009

3 questions de Dragos Dreptate, Responsable R&D Logiciel

Dragos, Responsable R&D Logiciel, envisage le passage aux Méthodes Agiles et à se titre se renseigne et se documente sur la question. Je lui ai proposé de partager mon expérience en répondant à quelques-unes de ses interrogations car être Agile, c'est aussi savoir partager sa connaissance. Dragos a accepté la démarche alors que nous ne nous connaissions pas! C'est un signe de confiance "à priori" que je salut; c'est une valeur très importante.

Voici le contenu de nos premiers échanges:

[Dragos]

Ma première question va dans la direction du recrutement. Il est clair, la qualité des membres de l’équipe est primordiale, bonne communication, team player et excellence technique s’imposent. La question : Comment faire pour être sur que la personne qu’on recrute est « agile » ?

[Luc]

Chez nous, voici les étapes que nous mettons en oeuvre pour recruter:
- Rédaction d'une annonce qui souligne les points essentiels sur le contexte de notre entreprise et les valeurs que nous recherchons chez notre futur collaborateur.
- Nous organisons une session de tests avec une douzaine de candidats où nous décrivons plus précisément notre entreprise. Puis il y a deux heures de tests écris sur des points techniques, logiques, d'Anglais. Ces tests ne sont pas très difficiles et nous permettent de faire un premier filtre.
- Les 3-4 candidats que nous estimons les meilleurs sont reçus en entretien individuel pour apprendre à mieux les connaître et découvrir leurs motivations et aspirations.
- Puis nous avons expérimenté une mise en situation dans une équipe sur une "journée accélérée" afin de mieux évaluer les aptitudes des candidats à travailler en équipe. Ce fut assez intéressant pour tester la capacité d'adaptation des candidats!

Quelques pistes:
http://www.cio.com/article/print/478106
http://www.agilex.fr/2009/01/recrutement-agile/


[Dragos]

La deuxième question s’attaque aux problèmes de test. L’activité de test est intégrée au sprint. Les méthodes agiles essaient de diminuer le temps alloué a cette activité en accordant plus d’attention a la qualité du design et du codage, en gros a tout ce que tienne de l’ingénierie logiciel, pour produire un meilleur code avec moins défauts. C’est bien, mais parfois pas suffisant. Nos clients, des grands laboratoires pharmaceutiques, utilisent notre application scientifique en phase de recherche de nouveaux médicaments. Une étape très sensible et coûteuse. Nous sommes soumis à des réglementations strictes concernant la qualité logicielle et sommes certifiés ISO9001. Mais au delà des certifications, la qualité du livrable est un engagement très fort que nous avons envers nos clients. Actuellement la phase de test a lieu après la fin du développement et consiste dans de plans de test « statiques », quasiment manuels, de tests qui s’appuient sur de spécifications détaillés écrites après la fin du codage. Très peu de tests unitaires. Et enfin la question : Connaisez-vous des outils de test "agiles", permettant de créer des tests automatisés adaptés aux logiciels avec beaucoup d’IHM et beaucoup d’intervention de l’utilisateur dans les scenarios d’usage ?

[Luc]

Avant de répondre à la question j'aimerais revenir sur la notion de test dans un contexte Agile. Tout d'abord, pour fixer le périmètre de mes propos, je vais m'appuyer sur deux méthodes Agiles complémentaires : SCRUM pour la gestion du projet et XP (ExtrêmeProgramming) pour les pratiques de développement. Dans ces méthodes, tout est itératif et incrémental car on recherche le feedback en permanence. Plus tôt est le retour sur les problèmes tels que les défauts où incompréhensions des besoins utilisateurs, moins cher coûtera la correction ou l'adaptation. De ce fait, les tests sont quotidiennement nécessaires à mesure que le développement évolue. Ces méthodes ne diminuent pas le temps alloué aux tests mais au contraire l'augmente. Le principe, c'est de ne pas dire qu'une fonctionnalité est terminée tant qu'elle n'est pas testée et le but recherché est de terminer des fonctionnalités dans les sprints (2-3 semaines). En d'autres termes, on ne repousse pas la phase de tests à la traditionnel Release Candidate pour y trouver des défauts qui prendront plusieurs semaines à corriger. A chaque fin d'itération, on doit avoir un incrément de produit potentiellement livrable au client donc entièrement validé et de qualité irréprochable. Alors évidement, on ne plus se permettre de dérouler des plans de tests pendant des jours entiers alors il faut changer les pratiques de test.

Il y a plusieurs types de tests à considérer:


- Les tests unitaires sont écris pendant le développement et se situes au niveau des classes. Idéalement il faut pratiquer le TDD (Test Driven Development) où on écrit toujours un test unitaire avant d'ajouter du code pour une fonctionnalité. De cette façon, on ne développe que ce qui est nécessaire (pas de provision ni de code mort) et ceci permet de faire émerger un design qui soit testable avec peu de couplage, etc. Je vous propose de lire le Tutoriel de Bruno.

- Les tests d'intégration sont également écris par les développeurs pour s'assurer que les classes fonctionnent bien ensemble.

- Les tests fonctionnels testent les critères d'acceptation de la fonctionnalité. Il est largement préférable de les automatiser car plus les projets grossissent, plus dérouler l'ensemble des tests fonctionnels en fin d'itération devient long et pénible. Sur des petits projets, il peut être acceptable de garder ces tests manuels.

Au final, il n'est pas anormal de passer les 2/3 du temps de développement à écrire des tests. Pour que le feedback soit rapide, il faut respecter la pyramide pour la répartition des tests. Les tests unitaires doivent être nombreux et couvrir un maximum de cas possibles. Ils doivent également être très rapides pour pouvoir être exécutés par tous les développeurs, tout le temps, pour vérifier que rien n'a été cassé. Il est très important de comprendre qu'automatiser ces tests permettra d'avoir des tests joués tous les jours. En effet, toutes les nuits, un système d'intégration continue doit construire l'application de A à Z (compilation, setup, etc) et exécuter tous les tests (unitaires, intégrations, fonctionnels). Ainsi, chaque matin, les équipes ont une vue claire sur l'état du projet. Si un test n'est pas passé, la priorité sera de le réparer.

Quand on travail sur une base de code non couverte par des tests, il faut apprendre à ajouter de la fonctionnalité en ajoutant des tests. Cela peut-être difficile mais plein de techniques existes pour isoler et modulariser la base de code. A ce sujet, je vous recommande la bible en la matière : Working Effectively With Legacy Code

Concernant les tests d'IHM, la pratique nous a montré que les tests manipulant les IHM sont souvent fragiles. En découplant bien la présentation des données, il est plus efficace de tester la couche juste en dessous. Ceci dit, nous utilisons pour nos projets en C# le framework de tests NUnit avec NUnitForms. Pour les applications Web, il y a Selenium (que je ne connais pas). Je vous propose de lire le billet suivant : http://blog.octo.com/demarches-de-tests-fonctionnels/

Les tests d'IHM coûtent cher par rapport à des tests plus bas niveau donc nous nous en servons pour vérifier qu'il n'y a pas de bug mais nous comptons principalement sur des tests plus bas niveau pour couvrir l'application et traiter le maximum de cas.

Il faut aussi donner de l'importance aux tests exploratoires. Ils permettent de challenger le logiciel sur toutes les couches et ne sont pas automatisables. Ce sont des tests structurés mais pas prédéfinis.


[Dragos]


J’ai pu trouver pas mal d’informations sur les points forts et les bénéfices que les méthodes agiles apportent mais il me manque une meilleure vue sur les risques engendrés par l’adoption de ces méthodes et sur leurs points faibles en général. Pouvez-vous m’en dire plus à ce sujet ?

[Luc]

Voici quelques points à considérer lors d'un passage à Scrum/XP:

- Scrum, de part sa nature itérative et empirique, ne permet pas de s'engager sur les trois points suivant en même temps

-> Contenu du produit
-> Qualité du produit.
-> Délais

Le plus souvent, c'est le contenu qui est adaptable car chacun sait qu'une grosse partie des fonctionnalités d'un logiciel ne sont jamais ou très peu utilisé. Donc c'est le jeu, le Product Owner doit faire des choix de priorité en permanence.

- Les chefs de projets et les représentants de la QA doivent changer de rôle pour laisser les équipes s'auto-organiser. Ils peuvent devenir ScumMaster (facilitateur), Product Owner si ils connaissent bien le métier, expert-technique ou ne pas trouver leur nouvelle place.

- Les Testeurs ne peuvent plus travailler comme avant. Je vous recommande le livre "Agile Testing: A Practical Guide for Testers and Agile Teams". Ceci dit, personne en ma connaissance ne regrette l'époque cycle en V avec des campagnes de tests de plusieurs semaines.

- Les équipes, avant de devenir productives, vont traverser plusieurs étapes donc il ne faut pas changer ces équipes trop souvent car le processus peut prendre plusieurs années.
-> Forming (création de l'équipe)
-> Storming (turbulence)
-> Norming (harmonisation)
-> Performing (performance)

- Il n'est pas toujours évident d'insérer les contraintes non fonctionnelles telles que l'Architecture et les Performances aux Product BackLog. Les ProductOwners ne sont pas toujours les personnes adaptées pour fournir des critères sur ces points. Le danger, c'est de considérer certains points trop tardivement.



Chers lecteurs, si vous avez des compléments d'information à partager, n'hésitez pas! Si un échange sur un point particulier vous intéresse, contactez-moi!





Share/Bookmark

mercredi 15 juillet 2009

La gestion des défauts

Face à la réalité

Le meilleur des mondes serait celui où les défauts n'existent pas, où les bugs n'empêcheraient jamais nos clients de travailler. En attendant d'en arriver à cet idéal, nous devons apprendre à gérer les défauts que nous produisons.

Un des piliers de Scrum est la "Visibilité", alors ne pas les gérer devient un péché. Quoi de pire qu'une version de logiciel planifiée sur 6 mois avec, par exemple, une trentaine de défauts à corriger non estimés en effort, et un release burndown qui montre que tout va bien, nous sommes dans les temps? Cela revient à conduire dans le brouillard avec un oeil caché!

Il y a, selon moi, 3 aspects à considérer pour sortir du brouillard:
  • Est-ce bien un défaut et non une amélioration? Une limitation, bien que gênante, n'est pas un défaut.
  • La criticité pour nos clients. Elle va nous aider à décider quand corriger le défaut.
  • La taille du défaut. Elle va nous donner plus de précision sur l'avancement du projet.
Chaque projet, chaque équipe doit trouver le moyen le plus adapté à son contexte pour gérer les défauts. Néanmoins, il convient d'avoir les éléments suivant en tête:
  • Il n'y a pas de Scrum sans IPPS (Incrément de Produit Potentiellement Shippable/Livrable).
  • Plus un défaut est corrigé tard, plus il coûte cher.

Quelques pistes à considérer

Je trouve intéressante la solution décrite par Mitch Lacey car elle permet une correction plus ou moins immédiate suivant 4 niveaux de criticité P0 à P4 :

- P0 Catastrophique : Fonctionnalités majeures du système ne fonctionnent pas. Il y a aucun moyen de contourner le défaut.
- P1 Haute : Fonctionnalités majeures du système ne fonctionnent pas. Il existe un moyen de contourner le défaut.
- P2 Modéré : Utilisabilité du système diminuée
- P3 Basse : Peu d'impact; défaut d'aspect, désagrément

Quand un défaut est identifié, il est rapidement classifié et deux scénarios peuvent être suivis:

--> Soit c'est un P2 ou P3 et le défaut est ajouté au product backlog avec tous les éléments nécéssaires à sa reproduction afin d'être priorisé par le Product Owner.
--> Soit c'est un P0 ou P1 et sa correction doit-être entreprise immédiatement. Sachant que certain défauts sont parfois grave mais ne prennent que quelques dizaines de minutes à corriger, la solution décrite permet de ne pas créer de travail administratif si en une heure, le défaut est corrigé.


J'aime aussi la pratique d'Alexandre Boutin lorsqu'il accupait la fonction de Process Group Manager; je cite : "Si le backlog comptabilise plus de 10 défauts, je vais voir l'équipe et lui demande d'arrêter tous les travaux en cours et de diminuer ce nombre pour qu'il soit en dessous de 10". Cette pratique très Lean, permet de maîtriser le coût des défauts et de les corriger avant que d'autres fonctionnalités soit ajoutées sur une base défectueuse.

Le coût des défauts

Pour finir, j'aimerais mettre l'accent sur le coût des défauts. Il est bien connu que plus le défaut est trouvé tard dans le cycle de développement, plus son coût de correction est important. Un bug trouvé lors de la phase de développement sera moins cher à corriger qu'un défaut identifié juste avant le déploiement. Évidemment, chez les clients, c'est encore pire. Ensuite, tout défaut devant être corrigé avant la sortie d'un logiciel va apporter un retard sur l'amortissement de son développement. On peut imaginer la catastrophe si un concurrent commercialise un logiciel similaire pendant que nous corrigeons des défauts ... le coût des défauts devient extrêmement important.

Une fois le défaut identifié, là encore, nous pouvons faire monter la facture en fonction du délai de correction. La gestion administrative des défauts a un coût, ils "polluent" le backlog, il nous gênent dans l'avancement du projet. Ainsi, un défaut P0 critique corrigé en 2 jours dès son identification pourra coûter moins cher qu'un défaut P3 moins important corrigé en 2 heures mais 10 semaines plus tard. Pour mesurer la portée de ces propos, nous pouvons imaginer une nouvelle unité pour mesurer le coût des défauts : le "$Day". En reprenant l'exemple ci-dessus, en considérant qu'une heure de travail vaut 100$, le défaut P0 vaut 1600 $Day alors que P3 vaut 16000 $Day soit 10 fois plus. Cette unité est à considérer de manière relative comme l'effort des éléments du Backlog, elle reflète un coût mais n'est pas directement convertible en dollars.

Que pensez-vous de ces approches? Comment gérez-vous les défauts?





Share/Bookmark

vendredi 3 avril 2009

Optimisation globale des équipes SCRUM (V2)

 

Suite à une réorganisation interne et au départ d'un collègue pour de nouvelles aventures, deux de nos équipes SCRUM ont vu leurs effectifs réduit d'une personne :

Équipe G:
  • 3 développeurs
  • 2 représentants utilisateurs --> 1 représentant utilisateurs
  • 1 ScrumMaster
  • 1 ProductOwner
--> Avant le changement, les deux représentants utilisateurs n'étaient pas pleinement occupés sur les projets de leur équipe. Cependant le passage à 1 représentant utilisateurs a inversé les contraintes. Maintenant, les développeurs doivent parfois ralentir leur flux de développement.

Équipe D:
  • 3 développeurs --> 2 développeurs
  • 1 représentant utilisateurs
  • 1 ScrumMaster
  • 1 ProductOwner
--> Avant le changement, il y avait un certain équilibre de charge de travail entre les développeurs et le représentant utilisateurs. Le passage à deux développeurs laisserait très probablement du temps libre au représentant utilisateurs.

Les équipes ont les contraintes suivantes:
  • Le projet D devra être terminé avant l'été, bien qu'il y ait un développeur en moins
  • Le projet D devra être maintenu et nous devrons être réactif aux demandes de nos clients; et ce, même pendant les congés annuels de cet été.
  • L'équipe G doit produire une release du projet G pour mi-mai.
  • L'équipe G doit maintenir d'autres projets : S, P, etc.
  • L'équipe D devra aider l'équipe G une fois le projet D terminé.

Un brainstorming nous a permis d'imaginer les solutions suivantes:
  1. On ne fait rien, et nous ferrons face aux retards possibles sur Projet D et G
  2. Un développeur de l'équipe G rejoint l'équipe D pour terminer le projet D avant l'été aux frais de l'équipe G et de la release du projet G.
  3. Nous fusionnons le deux équipes pour finir le projet D, terminer la release du projet G et faire au mieux sur les autres projets.

Toutes ces solutions ont leurs avantages et inconvénients:
  • La première solution à pour avantage de ne pas trop perturber les équipes qui ont un bon équilibre et qui sont devenues performantes mais on comprend bien que l'objectif de date du projet D sera difficile à tenir car le "product backlog" a déjà été sérieusement raffiné. De plus, dans l'objectif de maintenir le produit, concentrer la connaissance sur trois personnes parait une option assez risquée.
  • La deuxième solution serait valable pour terminer le projet D mais ça serait déshabiller l'équipe G déjà réduite pour habiller l'équipe D. D'un point de vu maintenance, cette option est guère mieux que la précédente. De plus, terminer la release du projet G pour mi-mai serait difficile.
  • La dernière solution, quant à elle, a pour inconvénient de bouleverser complètement les deux équipes dont les pratiques au quotidien sont différentes, et dans lesquelles une complicité c'est formée. Cependant, la connaissance de tous les projets se diffuserait vers plus de personnes et le projet D pourrait être privilégié afin d'être terminé avant l'été. Le projet G pourra aussi bénéficier de tous les membres de la nouvelle équipe pour valider la release d'ici à mi-mai. 

Auriez-vous d'autres idées? Quelle option choisiriez-vous?

Avec une approche Lean, il faut rechercher une optimisation globale plutôt qu'une optimisation locale. Les deux premières options où rien n'est changé et où un développeur change d'équipe sont des optimisations locales avec au mieux le projet D pouvant être terminé dans les temps. Dans ces options, on refuse de changer radicalement pour ne pas casser les dynamiques des deux équipes. Cependant, on conserve de gros risques sur tous les projets que ce soit sur les dates ou la connaissance commune pour la maintenance. La fusion des deux équipes, aux delà du changement complet des équipes parait une solution plus pérenne dans le temps alors s'il faut changer, autant y aller franchement!

Nous avons donc choisi la fusion avec une certaine appréhension face à ce changement mais nous sommes convaincus que c'est la meilleure solution.

Voyons donc maintenant les changements que nous devons mener:
  • Reconstruire une équipe : Cela va prendre du temps car pour arriver à la performance nous devrons passer par une certain nombre d'étapes (http://blog.octo.com/stades-de-developpement-dune-equipe/)
  • Nous allons devoir travailler avec deux ProductOwner tant que le projet D n'est pas terminé
  • L'un des product owner est aux Etats-Unis avec 6 heures de décalage. Les cérémoniesSCRUM vont donc devoir être adaptées en conséquence
  • L'équipe D perd son ScrumMaster
  • Nous devrons faire des choix de pratiques
  • Nous allons devoir fusionner les "product backlogs" (en gardant des sous-projets) pour avoir une meilleure visibilité
  • Chacun va devoir apprendre à travailler sur tous les sous-projets.
  • Nous allons très probablement centraliser les sources des différents projets et fusionner les plates-formes d'intégration continue pour une maintenance plus facile.

Dans un prochain billet, j'essayerai d'approfondir la théorie des contraintes sur ces deux équipes afin d'expliquer le choix qui a été fait de façon plus analytique. Je ne manquerai pas aussi de vous faire un retour sur ce choix avec les succès et difficultés rencontrés avant l'été ...

Share/Bookmark