Pyxis blog » GreenPepper

Agile in a Command-and-Control Organization : What to do when upper management forces overtime?

martin proulx — Mon, 23 Aug 2010 02:22:29 +0000

My colleague François Perron launched a very interesting discussion on our private wiki – “As a coach, what to do when executives and upper management force the project team to do over time in order to meet deadlines?”. As you can probably guess, this initiated very interesting discussions and an obvious reaction to such an approach. Everyone agreed that due to the project visibility and the position of the organization within its market, the project launch date was critical. Everyone also understood that the organization had very few options so nobody debated the need to achieve results. The discussion was strictly around which measures to use in an Agile context. I’ll admit up front that I am biased toward intrinsic motivation (I really loved Drive by Dan Pink) and the fact that it is well suited for an agile environment. As such, my first impression to the conversation that was going on were:

Does the organization wish that employees spend more hours at the office (attendance) or would they prefer more engagement (commitment)?
If their choice is to increase the hours of attendance, imposing overtime will achieve this goal while giving them a false sense of increased performance. People will show they are working longer hours but the real throughput is unlikely to be much higher. In addition, software development is a brain intensive activity and reducing the amount of rest people get is likely to increase the number of mistakes they make.
On the contrary, if the organization wanted more involvement, the inclusion of team members in determining the best way to achieve the results would probably come to a better decision – even possibly leading the willingness to do over time

It appears to me that by forcing overtime, the executives and senior managers will probably collect their bonus and congratulate each others in the short term only to realize in the longer term that they have simply pushed the problem forward for others to deal with – and possibly request more over time in the long run. You might be interested in these related posts:

GreenPepper 2.7 now available

pyxis — Mon, 08 Mar 2010 20:19:28 +0000

This new release includes a new plugin for Hudson (a continuous integration server), support for Jira4, a better use of accented characters in specifications, many improvements to the core and much more… See the release notes for more details…

Green is good!

pyxis — Sat, 06 Feb 2010 00:54:36 +0000

Éric Laramée, a colleague at Pyxis the other day was recalling the Greed is good scene from the movie Wall Street

The point is, ladies and gentleman, that greed, for lack of a better word, is good. Greed is right, greed works. Greed clarifies, cuts through, and captures the essence of the evolutionary spirit. Greed, in all of its forms; greed for life, for money, for love, knowledge has marked the upward surge of mankind. And greed, you mark my words, will not only save Teldar Paper, but that other malfunctioning corporation called the USA. Thank you very much.

We the started to play with that quote and here is the result:

The point is, ladies and gentleman, that green, for lack of a better word, is good. Green is right, green works. Green clarifies, cuts through, and captures the essence of the evolutionary design. Green, in all of its forms; green for life, for money, for love, knowledge has marked the upward surge of mankind. And green, you mark my words, will not only save your project, but that malfunctioning industry called IT. Thank you very much.

We had a good laugh and thought it was very cool!

Executable Specification and build integration

pyxis — Sat, 06 Feb 2010 00:41:33 +0000

It is usually not long after adopting the Executable Specification practice (aka Example Driven Development, Acceptance Test Driven Development – ATDD, Story Test Driven Development – STDD) that good software teams want to integrate GreenPepper in their build process. This is an area where we think GreenPepper shines. GreenPepper allows for a smooth process of adding / modifiying specifications -> implementing in TDD style -> committing code and specification –> automated continuous build. Let me walk you through what happens. At the beginning (and during) of an iteration or sprint some specification pages are modified or added. GreenPepper keeps track of the implemented vs working copy. The various build tool integration we have (Maven, MSBuild, Nant …) will continue to use the implemented version therefore your build is not broken and you do not need to move the modified or added pages in a temporary area. Great! At some point a developer will assign himself to the implementation. In his favorite IDE (Eclipse or Visual Studio) he can easily locate the modified specification page and switch to the working copy Then he executes the page and should see the page not passing Then he goes and develop the code TDD style with his favorite unit testing tool integrated in his IDE (JUnit, TestNG, Visual Studio, Nunit, etc.) He can frequently re-execute the page and see it slowly turn from red to green! Once it is all green, he commits his code in the source control and from the IDE he sets the specification page as implemented. The next build will use the committed code and page and life will be Green!

Exemple “Behavior Driven Developpement” (BDD) avec GreenPepper

pyxis — Tue, 02 Feb 2010 18:58:18 +0000

En découvrant les nouvelles fonctionnalités de GreenPepper 2.6 j’ai eu envie de les partager au plus vite ! GreenPepper autorise maintenant une syntaxe très flexible pour exprimer des scénarios (ou cas d’utilisation) dans un formalisme qui peut être défini en collaboration entre les experts métiers et développeurs. Le mot–clef associé à cette syntaxe est « scenario ». Je vais vous montrer dans ce billet comment utiliser GreenPepper pour exprimer des exigences sous la forme « Given, When, Then », formalisme recommandé par le courant « Behaviour Driven Developpement ».

Un cas concret à spécifier

Prenons un cas concret d’exigences fonctionnelles. Spécifions le comportement d’un agent virtuel d’assistance, dont le rôle est de répondre à des demandes d’aide en trouvant des interlocuteurs pouvant satisfaire les demandes d’aide. Les principales « user stories » seraient les suivantes :

En tant qu’utilisateur ayant besoin d’aide, afin de trouver une personne qui pourrait m’aider, j’interpelle l’agent virtuel afin de lui décrire mon problème.
En tant qu’utilisateur ayant besoin d’aide, afin de trouver une personne qui pourrait m’aider, je souhaite contacter une personne disponible et disposée à m’aider.
En tant qu’utilisateur pouvant apporter mon aide, je souhaite être contacté par l’agent virtuel afin de proposer mon aide.

Reformulons maintenant sous la forme d’exemples certains cas d’utilisation :

Etant donné que Marc n’a jamais contacté l’agent virtuel

Quand Marc dit à l’agent virtuel « Hello »,

Alors l’agent virtuel lui répond « Que puis-je faire pour t’aider ? »

Quand Marc dit à l’agent virtuel « Je n’arrive pas à installer Credanse+ sur MacOS »

Alors l’agent virtuel lui répond « J’ai bien pris note de ta demande d’aide et te contacte dès que possible »

Etant donné que Marc a déjà formulé la demande d’aide « Je n’arrive pas à installer Credanse+ sur MacOS »

Etant donné que Steve est disponible

Etant donné que Marc n’est pas disponible

Quand l’agent virtuel contacte Steve pour lui dire « Marc a besoin d’aide, il m’a dit : Je n’arrive pas à installer Credanse+ sur MacOS . Acceptes-tu de l’aider ?»

Quand Steve dit à l’agent virtuel « Oui »

Alors l’agent virtuel lui répond « Merci, je vais en faire part à Marc et il te contactera dès que possible »

Spécifier dans GreenPepper

Voyons comment écrire le premier scenario avec GreenPepper : Dans notre espace collaboratif d’édition de spécifications (Confluence ou XWiki), nous saisissons le tableau suivant : Mettons un peu de couleur pour faire mettre en relief ce qui relève de la syntaxe et ce qui est en rapport avec les données du scénario.

Coder la classe de test

Maintenant, nous devons écrire la classe de test (ou fixture). Une première implémentation naïve de cette classe pour faire passer le test est :

 public class AgentVirtuel
{
 private string lastwords = “”;
 private string lastuser = “”;
public AgentVirtuel()
{
}
[Given("Quand (\w+) dit à l'agent virtuel ([\w|\s|\'|\-|\?]*)”)]
public void WhenUserTellsTheAgent(string userName, string words)
{
lastwords = words;
lastuser = userName;
}
[Then("Alors l'agent virtuel répond ([\w|\s|\'|\-|\?]*)”)]
public void ThenTheAgentAnswers(Expectation answer)
{
if (lastwords==“Hello”)
{
answer.Actual = “Que puis-je faire pour t’aider?”;
}
else
{
answer.Actual = “J’ai bien pris note de ta demande d’aide et te contacte dès que possible”;
}
}
}

Dans cet exemple C# (il est possible d’écrire la même fixture en Java avec GreenPepper), nous voyons des attributs en charge de gérer la correspondance entre chaque « phrase » du scénario et une méthode de la classe de test. Le mot-clef « Given » permet de définir ou d’initialiser un comportement qui ne sera pas testé. Par contre, le mot-clef « Then » permet de déclarer des attentes et de les tester. Dans cet exemple, nous testons la réponse de l’agent virtuel.

Exécuter la spécification

Exécutons notre spécification avec GreenPepper et observons le résultat : Après exécution, une confirmation visuelle affiche automatiquement en vert les parties de texte qui ont été vérifiées positivement par GreenPepper. En cas de confirmation négative, la couleur rouge sera utilisée.

En conclusion…

Nous voyons à travers cet exemple, que l’utilisation d’expressions régulières associées à des méthodes de la classe de test, permet une grande souplesse ! Aux équipes de jouer et de trouver une syntaxe qui facilitera une compréhension partagée entre toutes les parties prenantes du projet ! Cette compréhension partagée sera de plus testable en continue!

GreenPepper 2.6 now available

pyxis — Fri, 20 Nov 2009 01:45:11 +0000

This new release includes a new Scenario interpreter that have a BDD style, XWiki integration (use XWiki to write your executable specifications), a plugin for Grails, a better compatibility with Confluence 3.0 and up, many improvements to the PHP extensions (Thanks to folks at Astria) and bug fixes. See the release notes for more details…