Les Mêlées

Reading xml from PowerShell is really easy !

2013-01-10T11:56:00.001+01:00

It is amusing to see how simple we can read xml node values from powershell :

Here is a peace of xml file

<?xml version="1.0" standalone="yes"?>

<ModuleName>myLib.dll</ModuleName>

</NamespaceTable>

</Module>

</CoverageDSPriv>

PowerShell converts XML elements to properties on .NET objects without the need to write any parsing code !!

$coverageFileXml = “C:\temp\myCoverageInfo.xml”

[xml]$xml = (get-content $coverageFileXml)

[int]$BlocksCovered = $xml.CoverageDSPriv.Module.BlocksCovered

[int]$BlocksNotCovered = $xml.CoverageDSPriv.Module.BlocksNotCovered

[int]$TotalBlocks = $BlocksCovered + $BlocksNotCovered

$CoveragePercent = $BlocksCovered * 100 / $TotalBlocks

$CoveragePercent2Decimals = "{0:N2}" -f $CoveragePercent

Write-Host "Coverage is $CoveragePercent2Decimals %"

è Output is : Coverage is 48.62 %

More exemples here : http://www.codeproject.com/Articles/61900/PowerShell-and-XML

-->

SpecFlow : StepArgumentTransformation

2012-01-16T09:27:00.001+01:00

When writting BDD test features and feature steps, we often need to convert strings to types. Testing strings with a serie of if statement within steps does not maximise reusability and readability. The best would be to get the string recognise as a Type every time we use it in a feature without taking care of the conversion.

SpecFlow provides a StepArgumentTransformation attribute to achieve this :

https://github.com/techtalk/SpecFlow/wiki/Step-Argument-Conversions

Exemple :

 [Then(@"the value of the Shoulder mode is (.*) in the method file")]
 public void ThenTheValueOfTheShoulderModeIsDropInTheMethodFile(string shoulderModeString)
 {
     ShoulderModeType shoulderMode = ShoulderModeType.OFF; ;
     if (ShoulderModeType.Drop.ToString() == shoulderModeString) shoulderMode = ShoulderModeType.Drop;
     else if (ShoulderModeType.OFF.ToString() == shoulderModeString) shoulderMode = ShoulderModeType.OFF;
     else if (ShoulderModeType.Tangential.ToString() == shoulderModeString) shoulderMode = ShoulderModeType.Tangential;
     else Assert.Fail("Invalid shoulderModeString: " + shoulderModeString);
...
     Assert.AreEqual(expectedShouldMode, shoulderMode)
}

Can be refactored as

[StepArgumentTransformation]
public ShoulderModeType ShoulderModeTransform(string shoulderModeString)
{
     ShoulderModeType shoulderMode = ShoulderModeType.OFF;
     if (ShoulderModeType.Drop.ToString() == shoulderModeString) shoulderMode = ShoulderModeType.Drop;
     else if (ShoulderModeType.OFF.ToString() == shoulderModeString) shoulderMode = ShoulderModeType.OFF;
     else if (ShoulderModeType.Tangential.ToString() == shoulderModeString) shoulderMode = ShoulderModeType.Tangential;
     else Debug.Assert.Fail("Invalid shoulderModeString: " + shoulderModeString);
     return shoulderMode;
}

[Then(@"the value of the Shoulder mode is (.*) in the method file")]
public void ThenTheValueOfTheShoulderModeIsDropInTheMethodFile(ShoulderModeType shoulderMode)
{
   ...  
   Assert.AreEqual(expectedShouldMode, shoulderMode)
}

Converting Enum values to user frendly strings

2011-10-20T17:36:00.001+02:00

    public enum ErrorLevel
    {
        None,
        Low,
        High,
    }

    public static class ErrorLevelExtensions
    {
        public static string ToLocalizedString(this ErrorLevel me)
        {
            switch (me)
            {
                case ErrorLevel.None:
                    return "Everything is OK";
                case ErrorLevel.Low:
                    return "SNAFU, if you know what I mean.";
                case ErrorLevel.High:
                    return "Reaching TARFU levels";
            }
            return "";
        }
    }

Then it is easy to use :

   1:  Console.WriteLine(ErrorLevel.Low.ToLocalizedStrings())

This uses Extensions Methods

Tool to remove useless references in .net projects

2011-10-06T13:21:00.001+02:00

Including too much references in projects can lead to tricky dependency graphes. Checking all references is just boring and long; it’s why we have searched for a way to remove useless references automatically. Resharper provide the Clean Code feature which remove useless using directrives but it does not remove the references.

Googling made me discover a free VisualStudio extension that does just but exaclty what we need (ie remove useless references and using directives) : Reference Assistant

It works perfectly well so I think it is a must have tool !

CHAPTER 4: Preparing for Sprint Planning

2011-02-22T13:28:00.001+01:00

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

Sprint planning =

Review of highest priority items with PO + decision on how much work could be done according to previous sprints and velocity
Task break down to decide how the work will get done
Commit to the sprint plan

Risk at the sprint planning is that PO cannot answer team’s questions without contacting stakeholders who are not available in the meeting. This is often the sign that the team is not ready to do the Sprint Planning meeting.

There is no official pre-planning meeting in SCRUM but the team needs to have ready for the sprint planning the following points

A prioritized Poduct BackLog
User stories the team can complete within a sprint
Clear acceptance conditions for each user story

Preplanning meeting can make the sprint planning meeting shorter

Preplanning

Discuss and clarify acceptance conditions for high-priority user stories.
Provide a relative estimate to help the PO identify their priorities
Break down high priority user stories so that they can fit within a sprint
Consider story dependencies owned by different teams

Clarification of user stories

The participants have to confirm that the stories have the same meaning to everyone and that they understand what the deliverables for a user stories are.

Hint: A good mean to make sure participants have the same understanding is to make them rephrase it with their own words.

The product owner answers questions or take note of them if he cannot answer to get ready for the Sprint Planning
The team can identify what needs to be investigated technically speaking to be able to commit at sprint planning
The participant confirm if the estimates seem accurate

Breaking down User Stories

Looking at the stories only at the sprint planning – particularly at the beginning of projects – may lead to long time of disaggregating user stories instead of planning for the sprint. The can lead to create user stories sprint after sprint and the team may never understand the quantity of work they need to do for the release.

KEY POINT: The large user stories must be breakdown the soonest possible in the release to make the team understand how much work they need to do. Teams should not create user stories for the release from sprint to sprint

Estimating user stories

When new stories are added to the backlog, the team can estimate them at pre planning meeting

Dealing with dependencies

3 types of dependencies

Simple dependency : A user story needs another user story done within the same team
- Solution : reorder priorities to do first standalone user stories
External dependency : A user story needs another user story done from and other team
- Negotiate integration and delivery dates and reorder priorities
- The team should not commit the dependent user stories before integration of the other
Intertwined dependency: Two user stories need each other to get done.
- Rework user stories breakdown to get simple dependencies

Cleanup of Product Backlog

The Product Backlog is not a Parking lot for every possible feature that could potentially be in the product.

The Product Backlog must be cleanup up so that it reflects what the team is likely to address. Stories with very low priority can be removed from the PB.

Approaches for the sprint preplanning meeting

1 meeting at each sprint or 1 meeting every week or as needed
The regular meeting is best to get into a rhythm and limit interruptions
Time box the meetings to remain focused. 1 hour is good.
Sprint preparation can be 5 to 10% of team time

A ) The Full Team Approach

Regular meeting that involves the entire team.

PROS :

Provide a sense of team ownership
All team members can ask questions or voice concerns
The team can use meeting to size the stories
It allows the PO to get info from stakeholders before the Sprint Planning meeting

CONS :

It is harder to keep focus of the meeting with many distributed participants.
It may be difficult to schedule a time that works well for all Scrum Team members

B ) The Preplanning Team Approach

Weekly preplanning meeting with PO and the smallest subset of team representatives able to select and describe stories

PROS :

A smaller group of participant is more effective for teleconferences
It allows the PO to get info from stakeholders before the Sprint Planning meeting
It reduce the disruptions on the work of team members for the current Sprint

CONS :

There is a potential loss of communication or information by not having the full team present.
Neglecting to go back to the whole team for their contributions can result in a loss if team ownership.
This approach can easily slip from Scrum to a command and control center

C ) The Balanced Team Approach

Compromise between Full-Team and Preplanning Team approach.

Weekly meeting with a core group of participant and the entire team as optional participant. The entire team is present only for the last meeting before the sprint planning

PROS :

A smaller group of participant is more effective for teleconferences
It allows the PO to get info from stakeholders before the Sprint Planning meeting
It provides a sense of team ownership
All team members can ask questions or voice concerns
It allows the optional team members to manage the disruptions on their work for the current sprint

CONS :

There may be a loss of communication or information because the full team is not always present

CHAPTER 2: Challenges faced by distributed teams

2011-02-01T09:48:00.001+01:00

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.

A Practical Guide to Distributed Scrum – IBM Press

2011-01-31T08:32:00.001+01:00

By Elizabeth Woodward, Steffan Surdek, Matthew Ganis.

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

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)

What did you team do yesterday?
What will your team do today?
What blockers have you met?
+ 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

How to implement a generic “waiting for” function with C#

2010-12-24T09:39:00.001+01:00

In order to avoid repeating myself in the code of my team’s project where we need several times to wait for something to happen such as waiting for a file, I learned how to use the type “Func”.

Here is how was the code before the refactoring :

public static bool WaitForFile(string filePath, int timeOutMs)
{
var fileFound = false;
var timeElapsed = false;

    var startTime = DateTime.Now;
    DateTime currentTime;
    while (!fileFound && !timeElapsed)
    {
        currentTime = DateTime.Now;
        TimeSpan span = currentTime.Subtract(startTime);

timeElapsed = span.TotalMilliseconds > timeOutMs;

        fileFound = System.IO.File.Exists(filePath);
        System.Threading.Thread.Sleep(1000);
    }
    return fileFound;

}

And here is the new generic implementation :

public static bool WaitForSynchrone(Func<bool> function, int timeOutMs)
{
    var actionReturnedTrue = false;
    var timeElapsed = false; var startTime = DateTime.Now;
    DateTime currentTime;
    while (!actionReturnedTrue && !timeElapsed)
    {
        currentTime = DateTime.Now;
        TimeSpan span = currentTime.Subtract(startTime);
        timeElapsed = span.TotalMilliseconds > timeOutMs;
        actionReturnedTrue = function();
        System.Threading.Thread.Sleep(1000);
    }
    return actionReturnedTrue;
}

public void WaitFile()
{
WaitForSynchrone(() => File.Exists("C:\myfile.txt"), 10000);
}

So, now, we have a new function WaitForSynchrone that take 2 arguments :

- Func<bool> function : A function that returns a boolean

- int timeOutMs : A timeout to prevent freezing !!

And we use it thanks to lambda expression for the first argument :

- () => File.Exists("C:\myfile.txt") : This is a function that takes no arguments and returns and boolean according to the left part of the expression

So now, we can use WaitForSynchrone for many other purpose instead of violating the DRY principle = ‘Do Not Repeat yourself ‘.

Agile Grenoble 2010 – 10 Messages que j’ai retenu

2010-11-25T10:30:00.003+01:00

“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/

Tester unitairement du “Legacy Code” : un exemple

2010-09-30T11:54:00.001+02:00

(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

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;

__________________________________________________________________

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;

__________________________________________________________________

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;

__________________________________________________________________

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;

_________________________________________________________________

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;

_________________________________________________________________

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) !

Les vacances sont finies !

2010-09-02T07:12:00.001+02:00

Je vous ai proposé il y a quelques semaines un sondage pour connaitre vos motivations à me suivre sur ce blog. Vous êtes près de 70 abonnés aux flux RSS et je n’ai eu que 13 réponses à ce jour. Je ne vous cache pas ma déception!

Voici mes motivations à écrire :

Partager mes connaissances
Obtenir du feedback sur ma façon de voir les choses
Consigner ce que j’apprends
M’entrainer à écrire, art qui se perd sans pratiquer
Me faire connaitre un peu

Vous pouvez m’aider de deux façons :

En répondant au sondage qui ne comporte qu’une question à choix multiple ICI : 30 secondes montre en main.
En me donnant du feedback car les commentaires des billets sont souvent aussi intéressant que les billets eux-mêmes.

Sondage

2010-07-29T21:30:00.002+02:00

CARA – Grenoble : Rétrospective des Dojos 2009-2010

2010-06-30T23:06:00.001+02:00

Lundi 28 Juin 2010 se tenait la dernière séance des Dojos du CARA pour cette année. Nous l’avons consacré à une rétrospective afin de nous améliorer pour l’année prochaine. J’ai eu le plaisir d’être facilitateur et voici le compte-rendu :

Nous étions 6 participants présents et plusieurs amis Agilistes nous ont envoyé leurs entrées.

Voici le plan :

En guise de check-in pour se mettre dans l’ambiance : Mr Face pour décrire son état d’esprit !

Puis nous avons fais une BrainStorming afin de rassembler

les points qui ont bien marché et que nous voulons conserver (+)
les points qui ont moins bien marché et que nous voudrions améliorer (-)

Nous avons ensuite regroupé en thèmes tous les points afin d’en choisir deux à améliorer :

Donc en point positifs, nous pouvons noter :

la qualité des échanges avec une confiance de haut niveau.
la variété des sujets abordés
la qualité des dojos lorsqu’ils sont préparés
la localisation de la salle
la permutation des animateurs
la mise en pratique des principes de programmation /TDD
le travail sur du code de production
… (jetez un oeil sur les post-its)

Nous avons voté et les deux sujets choisis pour amélioration sont :

La gestion du temps
Travailler sur du code réel

Voici les fruits de nos réflexions sur ces deux thèmes :

Bon, ça nécessite des petites explications :

Pour gagner un peu de temps lors des séances, nous avons estimé que les rétrospectives de 30 minutes / 2 heures n’étaient pas une bonne utilisation de notre temps. C’est pourquoi nous allons les réduire à 10 minutes en commençant par le ROTI. Nous pourrons expliquer notre choix et en particulier les notes extrêmes. Les Post-its ne seront plus un passage obligatoire! Nous déciderons également lors de ces 10 min si le sujet doit être poursuivi ou non.
Nous n’avons pas été très fort sur le démarrage des Dojos à 12h. Nous avons régulièrement commencé 15 ou 20 minutes en retard. Plusieurs causes sont à l’origine de cette dérive dont le fait qu’il ne soit pas évident de quitter son lieu de travail avant 12h et que nous avons eu plusieurs soucis d’utilisation du projecteur. Nous avons donc décidé de commencer à l’heure prévue quoi qu’il arrive; cette heure de début fera l’objet d’un sondage (12h, 12h10, 12h15, 12h20 ?). Nous rédigerons également un document de trouble shooting du projecteur. (Je vois deux actions sans propriétaire! … qui s’en occupe?)

Le fait de travailler sur du code réel / legacy code plutôt que sur des sujets très simples fait l’unanimité. Nous aimerions donc travailler sur une même base de code pendant plusieurs séances avec comme fil conducteur le fait de s’améliorer sur la prise en main de legacy code (code non testé).

Nous aurions bien poursuivi sur d’autres thèmes mais la time-box était terminée. Nous avons identifier le besoin de discuter sur le “recrutement” de nouveaux participants. Nous pouvons le faire via le groupe de discution : http://groups.google.fr/group/cara-dojo . (entrée perso : les séances planifiées sur jours tournants ne satisfont au final pas grand monde; il serait bien qu’on en discute également.)

Nous avons conclu par un ROTI pour noter la qualité du temps investi pour l’année des Dojos et pour cette rétrospective: 0 – J’aurais mieux fais de rester chez moi –> 5 – J’ai très bien investi mon temps

Merci à tous pour votre participation aux dojos!

Luc

Test Scrum sur Scrum.org

2010-06-07T08:56:00.001+02:00

Scrum.org propose un nouveau cadre de formation et certification. La certification Scrum est validée par un test de 50 questions sélectionnées au hasard dans une liste. Il faut obtenir 75% de bonnes réponses pour obtenir la certification!

J’ai fais le test, certaines questions ne sont pas évidentes. Voici mon résultat :

_____________________________

41 bonnes réponses sur 50, soit 82%

33 minutes

_____________________________

Faites le test ! http://www.scrum.org/scrumopen/

Une rétrospective pas comme les autres

2010-03-31T16:17:00.001+02:00

Introduction

Lundi 30 mars 2010 se tenait l'étape Suisse des XP Days 2010. La session que j'ai le plus aimé fut

"Apprenez les techniques de coaching avec le magicien d'Oz" de Portia Tung et Pascal Van Cauvenberghe

Cette session avait pour but de nous faire découvrir le Co-Coaching au travers d'un Jeu. En deux mots, le co-coaching permet à deux personnes de s'améliorer mutuellement en travaillant chacune leur tour sur un problème. Le jeu, quant à lui permet d'acquérir des techniques simple de coaching autour du questionnement, de l'observation de l'écoute et du feedback.
En pratique, il faut trois joueurs:

Dorothy (le coaché)
Le coach
L'Observateur

Les trois joueurs réfléchissent à un problème qui leur tient à cœur personnellement

Puis trois cycles vont se succéder afin que chaque joueur puisse s'entraîner dans chaque rôle.

Le coach va tout d'abord questionner Dorothy avec des questions ouvertes (pas de réponse par oui ou par non), des questions de contrôle pour caractériser le problème puis avec des questions de vérification pour être certain que le coach et le coaché se comprennent bien. Puis, le coach va demander à Dorothy de se mettre dans la peau d'un personnage et de décrire ce qu'il ferait. Ceci permet de changer d'état d'esprit sur son problème et d'imaginer des solutions non intuitives.

Par exemple : Arthur, si tu es Lion, c'est à dire courageux et courtois, que ferais-tu pour solutionner ton problème

Arthur, si tu es Singe Volant, c'est à dire pratique et prêt à aider, que ferais-tu?

De cette façon, Arthur, le coaché va trouver des solutions à ses problème.

Enfin, l'observateur commente ce qu'il a vu et entendu pour que tout le monde puisse progresser!

Seule Portia Tung peut expliquer le jeu dans les règles de l'art alors je vous invite à assister à l'une de ses présentations avec Pascal Van Cauvenberghe!

Le jeu peut être téléchargé sur Agile Fairy Tales : http://www.agilefairytales.com/dist/The-Yellow-Brick-Road-2-0.zip

Jai profité de ce que j'ai appris lors de cette session pour voir comment je pouvais l'appliquer en interne dans mon entreprise et je me suis dis pourquoi pas la rétrospective de sprint! Ca tombait bien, il y avait 3 participants. D'où la rétrospective pas comme les autres ...

Le plan

10h30 - 10h45 : Introduction / Check-in

Présentation du plan
Si vous aviez été un animal, qu'auriez vous été?

Voici les réponses des 3 participants ! Nous avons bien rigolé !

Un hibou car je n'ai pas beaucoup été présent (Vacance, support chez un client, 5 jours avec l'équipe en 2 fois)
Un singe car j'ai changer plusieurs fois d'activité (Développement de User Story, Support, Enquête sur problème de build)
Un âne car nous avons échoué plusieurs User Stories alors que nous avions largement le temps de finir.

10h30 - 11h40 : Le jeu de "La Route de Brique Jaune" expliqué brièvement ci-dessus

Nous avons pris 10 minutes pour expliquer le jeu et pour que chaque participant identifie le problème sur lequel il voulait travailler

Voici les problèmes choisis

Je crains que nous ayons d'autres problèmes tels que celui que j'ai du investiguer ce sprint
On a cru que toutes les User Stories étaient finies mais à la fin du sprint il y avait plusieurs grains de sables qui ont fait que seule la moitié des User Stories ont pu être montré.
Des tests automatisés se sont mis à échouer sans que l'on comprenne pourquoi

Nous avons effectué 3 tours de jeu de 10 minutes et chacun a pris son rôle très au sérieux. De vraies idées d'actions ont été trouvées par les coachés!

11h40 - 11h55 : Débriefing et choix des actions

Nous avons ensemble fait le tour des actions potentielles et finalement l’équipe les a toutes adopté!

11h55 - 12h00 : ROTI / Conclusion

En fin de rétrospective, il est bien d'obtenir un feedback sur la qualité du temps investi. Tous les participants ont voté pour la note maximale (0-J'aurais mieux fais de rester chez moi --> 5-J'ai vraiment bien fait de venir)

5 +
5 ++ Nous avons identifié des solutions à nos problèmes qui ne seraient pas sorties dans une rétrospective plus classique.
5+

Conclusion

Merci à Portia Tung et Pascal Van Cauvenberghe de m'avoir fait découvrir le Co-Coaching à travers le jeu de "la route de la brique jaune"

Merci à l'Equipe d'avoir joué le jeu !
Le co-coaching est très facile à mettre en place et un outil très efficace pour progresser.

Que contient la vélocité?

2010-02-24T10:57:00.001+01:00

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:

La vélocité des bugs d'Alexandre Boutin
Le graphique de vélocité de Claude Aubry

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 :

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

Coup de gueule contre mon assurance

2010-02-05T07:31:00.001+01:00

Rien à voir avec l’Agilité ni même la productivité.

En discutant avec mon assureur de mon contrat d’assurance habitation, j’ai découvert que le consommateur que je suis se fait une fois de plus avoir.

En effet, voici un exemple qui explique mon mécontentement:

Mr Dupont est propriétaire d’un T5 et paye un contrat d’assurance immobilier (pour les murs) de 200 euros
Mr Durand, locataire de Mr Dupont souscrit un contrat d’assurance habitation pour son mobilier (le contenu de l’appartement) à 200 euros.

--> L’assureur empoche 400 euros pour assurer l’immobilier + le mobilier.

Maintenant considérons que Mr Dupont habite le bien en question et demande à son assureur d’assurer son appartement pour l’immobilier + le mobilier. Son contrat s’élève alors à 200 euros.

--> L’assureur empoche seulement 200 euros pour assurer l’immobilier + le mobilier.

Cherchez l’erreur! Je n’ai pas hésité à challenger mon assureur pour obtenir des explications et il a fini par me dire qu’en générale, propriétaire et locataire ne se parlent pas à propos des montants des contrats d’assurance et que le système profitait de cela.

Avez-vous déjà remarqué cela avec votre assureur?

Le Café des Scrum Masters

2010-01-19T17:15:00.001+01:00

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

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

GTD présenté par David Allen en personne

2010-01-10T09:47:00.001+01:00

En cette journée froide et neigeuse, je vous propose une vidéo de David Allen enregistrée chez Google:

Résultat enquête de satisfaction Agile Tour 2009

2010-01-06T12:59:00.001+01:00

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!

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.

La liste des blogs que je suis

2010-01-03T15:14:00.001+01:00

Voilà environ 3 ans que j’utilise Google Reader pour suivre tous les blogs que j’ai sélectionné au fil du temps. Cet outil me fait gagner un temps précieux en m’apportant l’information plutôt qu’en allant la chercher sur chaque blog de façon individuelle. Google Reader fait partie de la liste de mes outils qui ne me séparent jamais.

Pour cette nouvelle année, j’ai décidé de vous offrir cette liste! Elle est composée de plus de 60 blogs quasiment tous dédiés à l’Agilité + un petit nombre au développement personnel. Certains sont en français et d’autres en anglais. Je pense que les acteurs les plus connus du domaine ont leur blog dans ma liste. Si vous en connaissez d’autres, faites-nous en profiter!

La liste est au format OPML et peut être importée par les agrégateurs de flux tels que Google Reader.

Pour télécharger ma liste cliquez ici !

Bonne lecture.

La puissance du “Time Boxing”

2009-12-30T13:20:00.001+01:00

Limiter une activité dans le temps peut paraître frustrant. En effet, si je suis entrain de faire quelque chose et qu’un foutu timer sonne … le premier reflexe sera de le faire taire et de continuer sans se préoccuper du temps qui passe. Agir ainsi est se priver de la puissance d’un tel outil!

Contraindre une activité en temps à y consacrer permet de devenir plus efficace

Ce qui aura le plus de valeur est abordé en premier
La concentration est améliorée car nous voulons un résultat dans le temps fixé
La motivation est améliorée car toutes les boîtes de temps sont des défis à gagner
Le perfectionnisme avec le bien connu adage “Le mieux est l’ennemi du bien” est limité
Les travaux exploratoires, qui par définition peuvent ne pas aboutir rapidement, sont maîtrisés
Les tâches rébarbatives deviennent plus agréables car limitées dans le temps
Les gros travaux peuvent être découpés en objectifs atteignables dans des temps limités; ceci évite la procrastination –> Fort lien avec le GTD

Comment utiliser le time-boxing

Convenir d’un temps pertinent, seul ou en équipe pour les réunions, en fonction de l’importance de la tâche à accomplir
Activer un timer visible à tout moment de tous
Lorsque le temps imparti est terminé, décider activement si un temps supplémentaire doit être accordé. Il convient de juger si cela en vaut la peine et si le focus doit être redressé pour privilégier ce qui a le plus de valeur

Quand utiliser le time-boxing

Pour la gestion des e-mails. Ex : 15 minutes en arrivant le matin
Pour la lecture d’articles
Pour les recherches exploratoires ou plusieurs voies sont ouvertes
Pour l’essai d’un outil
Pour les réunions. Souvent, on peut arriver à un résultat pertinent rapidement en se focalisant sur l’objectif à atteindre
Pour le ‘Social networking’. Ex : 10 minutes par jour
Pour l’écriture de billet sur un blog. Cette fois-ci, je me suis donné 45 minutes!
Pour le Daily Scrum meeting. :o)

Caddie / Coach GTD - Getting Things Done – (V2)

2009-12-30T09:43:00.001+01:00

Il y a un an environ, j'ai adopté la méthode d'organisation GTD - Getting Things Done - de David Allen. Un mois plus tard, j'avais fais le point ici même.

Depuis, notre entreprise a développé une initiative permettant de s'améliorer, d'apprendre et développer ses compétences: le CADDYING. Plusieurs volontaires se sont proposés pour travailler sur des sujets techniques tels que le Lean Software Development, les tests "Agiles", la programmation fonctionnelle, etc. Alors je me suis dis pourquoi pas un peu de développement personnel! Le GTD m'a tellement apporté que je trouvais dommage de ne pas en faire profiter mes collègues! Je me suis proposé comme Caddy et rapidement 4 joueurs ont voulu tenter l'expérience.

Le principe que j'ai retenu est basé sur 4 étapes principales:

Une prise de contact avec auto-évaluation sur 10 points que la méthode permet d'améliorer : 10'

Respecter ses rendez-vous
Trouver un document en moins de 2 minutes
Ranger un document en moins de 2 minutes
Faire tout ce qui doit être fait en temps et en heure
Avoir l'esprit libéré pour se concentrer sur sa tâche en cours
Ne pas réapprendre les choses
Ne pas oublier ses idées et projets
Avoir une vue claire sur ses projets à cours terme
Avoir une vue claire sur ses projets à moyen terme
Avoir une vue claire sur ses projets à long terme

Voici mon évaluation sur ces 10 points:

Une explication des principes GTD à l'aide d'un logigramme : 15'

Mise en pratique immédiate en rassemblant tout ce qui n'est pas à sa place et création des listes : 3h

Suivi régulier de 15' à 30' chaque semaine pour affiner la pratique de GTD

Le fait d'être Caddie sur ce sujet m'a permis de me perfectionner et de tirer encore plus partie de la méthode. En particulier, j'ai progressé sur la mise en forme de mes projets en formulant mieux mes objectifs et en identifiant les premières étapes atteignables pour que ceux-ci avancent - parfois lentement - mais sûrement!

Bruno a remarqué que je n'utilise plus mon agenda Filofax pour la gestion des listes au profit d'Evernote sur iPhone et m'a demandé les raisons que voici:

Le Filofax est un outil qui fonctionne très bien. Il a fais mon affaire pendant 1 année. Néanmoins, ce support avait pour MOI quelques inconvénients:

Mes listes devenaient vite brouillon car je n'écris pas très bien
Le support, bien que petit prend un peu de place et pèse dans ma sacoche
Lors de la revue hebdo, il n'était pas possible de déplacer un élément d'une liste à une autre.

Lorsque que je me suis procuré un iPhone, j'ai rapidement cherché si un outil gratuit existait pour GTD puisque la pub dit qu'il y a une application pour presque tout! Cette application est "Evernote". Combinée à l'agenda de l'iPhone, j'ai tout ce qu'il me faut. En effet, "Evernote" dispose d'une synchronisation sur le net, de client pour PC et une version mobile pour iPhone. Après 3 mois d'utilisation, je peux dire que les inconvénients cités ci-dessus sont levés.

3 questions de Dragos Dreptate, Responsable R&D Logiciel

2009-12-09T08:27:00.025+01:00

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!

Un test vert sans avoir été rouge sent mauvais (V2)

2009-09-04T06:07:00.007+02:00

Contexte

Dans un contexte Agile, le développement dirigé par les tests (TDD) est incontournable. Ces tests sont le plus souvent unitaires ou d'intégrations car ils aident à construire l'application et couvrent les fonctionnalités existantes en apportant un feedback très rapide. La règle de base du TDD est l'application du cycle RED / GREEN / REFACTOR. Donc on code d'abord le test puis on le fait passer rapidement et enfin on remanie le code si besoin pour éliminer les duplications et améliorer le design.

Un test vert sans avoir été rouge ne sent pas très bon

Un test qui est vert sans passer par l'étape rouge doit interpeller le développeur. En effet, rien ne prouve alors qu'il teste ce qu'il doit tester. Plusieurs scénarios peuvent amener à ce cas :

Le cas que je m'apprête à coder est déjà couvert donc mon test passe immédiatement
Je code le test après avoir développé la fonctionnalité; ce n'est plus du TDD et on passe son temps à douter de la pertinence de ses tests.
Mon test ne teste pas ce qu'il devrait tester

Dans tous les cas, si le test est vert immédiatement, on doit se poser des questions. Au minimum, Il faut faire une contre vérification pour s'assurer de sa pertinence. C'est très simple, il suffit de modifier volontairement le code "under test".

Donc pour qu'un test ait de la valeur il doit nécessairement passer par l'étape rouge.

Et les tests fonctionnels alors?

Les tests fonctionnels servent à tester les "user stories" dans leur globalité en vérifiant que les critères d'acceptance sont bien remplis. Ces tests ou recettes peuvent être exécutés manuellement et l'oeil averti du testeur permet de vérifier que la fonctionnalité est conforme aux attentes du client. Le problème c'est que sur des projets de taille conséquente, cette approche n'est pas viable car le feedback à beaucoup trop long. A mes débuts de développeur, un des projets sur lesquels j'ai travaillé nécessitait 2 jours de tests à plusieurs personnes. Autant dire que lorsque qu'une régression était découverte, le sprint était compromis.

La solution est donc d'automatiser les tests fonctionnels. Oui MAIS! Mais alors attention aux tests qui seront verts sans passer par l'étape rouge! Pour factoriser la vérification de critères, mon équipe avait développé un module spécialisé. Ce module a parfaitement bien fonctionné pendant plusieurs mois. Un jour, ce module a du être modifié pour prendre en compte un changement d'architecture. Puis de nouveaux tests fonctionnels ont été ajoutés à la liste. Ces nouveaux tests ainsi que tous les autres étaient verts pendant plusieurs mois ... mais notre module ne testait plus une bonne partie des critères...

Conclusion

Un test vert sans avoir été rouge ne peut pas apporter la confiance recherchée et doit interpeller le développeur.