A la lecture des appels d’offres publics pour la réalisation d’applications logicielles, on assiste ces derniers temps à une percée des méthodes agiles, dont l’utilisation désormais est exigée dans les réponses des candidats ; l’Agile semble donc  enfin unanimement reconnu comme un outil d’amélioration, à la fois du processus de construction des applications, et de la satisfaction des acteurs, qu’il s’agisse des utilisateurs finaux, ou des artisans du système d’information.

Pour autant, la mise en œuvre de l’Agile dans des organisations traditionnelles ne va pas de soi. Le premier problème auquel on se heurte, avant même de commencer le projet, concerne la contractualisation. Ce problème de contractualisation a déjà été abordé sur ce blog. Nous proposons, dans ce billet, de nous concentrer sur un point précis : le Plan Assurance Qualité (PAQ), pièce contractuelle inévitable dans le cadre traditionnel des marchés…

Profitons donc de nos retours d’expérience _ nous avons été récemment amenés à rédiger des PAQ dans un cadre agile, et montrons comment valoriser la qualité dans un projet agile à travers l’exercice du PAQ. Le débutant en agilité trouvera dans ce billet un condensé des pratiques de qualité liées à l’Agile, tandis que l’initié pourra trouver de l’aide pour la rédaction d’un PAQ.

(Lire la suite…)

C’est votre 10eme itération, vous êtes en plein stand-up et Roger le nouveau ne sait toujours pas quel post-its prendre. Il faut dire que Roger n’arrête pas de vous demander quelle tâche de développement il doit prendre aujourd’hui.

Vous êtes tech –lead sur un nouveau projet et vous recherchez un nouveau framework de test en Javascript.

Vous êtes RH, et vous êtes en train de rédiger une fiche de poste pour ce curieux métier qu’est le « product owner ».

Vous êtes responsables produit d’une grande assurance et on vous demande de rédiger un backlog.

Vous avez envie d’en parler, venez le 27 Septembre à l’Apéro Agile !

Autour d’un verre, nous discuterons de l’état de l’Agile, de carrière, de pratiques, de techniques et de vos réussites.
Que vos équipes soient déjà Agiles, que vous soyez vous même praticien de longue date, ou que vous souhaitiez vous mettre à l’Agile prochainement, venez partager avec d’autres pratiquants vos problèmes du quotidien afin de les résoudre ensemble.

Pour venir à l’apéro agile, inscription ici.

Situation n°1 : Vous regardez votre agenda, combien de réunions ont déjà été posées pour résoudre les problèmes en cours. Vous vous dites que « Ca fait beaucoup pour la journée »  en terminant votre tasse de café. Et d’ailleurs combien de fois avez-vous posé une réunion pour comprendre ce problème sur la vélocité de cette équipe ? Une vélocité qui ne décolle toujours pas, mais ces réunions vous auront permis, au choix, de rajouter des développeurs, de changer des développeurs, de changer d’architecture. Beaucoup de décisions pour, au final se rendre compte que la vélocité n’augmente toujours pas … Bref, le problème est toujours là.

Situation n°2 : C’est la fin de l’année, combien de produits avez vous lancé ? Combien de ses produits ont apportés de la satisfaction pour un client ? Et combien de réunions avez vous fait pour définir ces produits ? Combien de brainstorms et d’ateliers ? Beaucoup et à chaque fois énormément d’idées et de concepts sur comment tout ça va s’articuler, pour au final se rendre compte que peu de personnes utilisent vos produits …

Si vous avez rencontré l’une des situations présentées, et qu’après toutes ces réunions vous vous demandez encore ce qui se passe réellement, alors il est temps de sortir votre chapeau de détective privé pour aller enquêter sur le terrain !

(Lire la suite…)

Dans ce billet, nous nous basons sur un expérience vécue de mise en place d’une méthodologie (Scrum) sur un projet de développement, pour analyser un piège qui, selon nous, guette toute organisation désireuse de s’améliorer via l’adoption d’une méthodologie : le piège de l’Artefact.

(Lire la suite…)

La rétrospective dans les méthodes agiles est un moment important dans un projet. La rétrospective est une pratique qui permet de répondre au 12ème principe agile du Manifeste Agile: « À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens ». Ritualiser cet événement permet de mettre en place un processus d’amélioration continue. Même si parfois, l’équipe a l’impression qu’il ne s’est rien passé, il s’est passé quelque chose, le plus important étant de garder cet espace de prise de recul.

Couramment, deux types de rétrospectives sont faites dans les projets agiles: les rétrospectives d’itération et les rétrospectives de release/projet. Cet article parlera des rétrospectives d’itérations et présentera 2 outils simples, le Keep Drop Start et la note d’itération.

Pour une rétrospective d’une itération de deux semaines, il est recommandé de faire une rétrospective de 2 heures, pour une itération d’une semaine, 1h.

(Lire la suite…)

« Et après avoir enregistré la livraison, on voit que le stock du produit… n’est pas mis à jour… »

Une application pas assez stabilisée, des scénarios déroulés de manière trop hasardeuse, un démonstrateur peu familier de l’application… l’ »effet démo » devrait alors être rapidement invoqué pour justifier les comportements inattendus et autres « stacktraces » présentés à l’écran devant un auditoire au mieux interloqué, au pire moqueur.

Pourtant, cet effet et les moments de solitude qui en découlent peuvent être maîtrisés avec peu de préparation. Au travers d’un cas réel, nous vous proposons dans cet article de parcourir les principales astuces vous permettant de sécuriser une démonstration et de combattre l’effet démo qui, un peu à la manière du « Plouf« , s’instille sournoisement dans les habitudes d’une équipe. Le cas pris pour exemple de cet article est un projet mené sur un mode « Scrum ». Cependant, le principe de la démo reste valable hors de ce contexte.

Vous trouverez en pièce jointe une checklist synthétisant les vérifications à faire afin de mettre toutes les chances de votre côté.

(Lire la suite…)

UPDATE : Cette formation se déroulera finalement le 12 et 13 mai

Si vous êtes en train de lire ce post à 23h, au travail, devant votre écran d’ordinateur, à corriger les bugs de votre application dont vous aimeriez bien terminer la mise en production, alors sauvez vos qualités de vie, gagnez en sérénité, ne vous énervez plus contre vous-même, ni votre ordinateur, venez vous avez sûrement besoin d’une formation sur le développement piloté par les tests.

(Lire la suite…)

OCTO accueille le troisième meetup devops parisien, le mercredi 16 mars à 19h.

Au programme, de courtes présentations sur la culture devops (déjà évoqué sur ce blog ici et là), et plus précisémment les méthodologies, process et outils permettant de favoriser la coopération entre études et production.
Il est notamment prévu :

• une introduction orientée organisationnel
• un retour d’expérience sur la mise en place d’un processus de déploiement continue avec les outils Rundeck et Jenkins.

C’est aussi et surtout l’occasion d’échanger avec des gens intéressés par le mouvement : développeurs, exploitants, architectes, testeurs, managers, etc.
Donc venez avec vos sujets, vos questions et vos retours d’expérience, on fera le programme ensemble !

Pensez à vous inscrire et notez bien l’adresse :
OCTO Technology
50 avenue des Champs Elysées (métro Franklin Roosvelt) - 5ème étage

OCTO organise un petit-déjeuner avec Danone et Open ERP sur le thème « Agilité et ERP » le mardi 22 mars 2011 de 9h à 11h à l’atelier BNP Paribas.

Vous pouvez vous inscrire directement sur notre site internet.

Le 15 et 16 Octobre ont eu lieu les DevOpsDays 2010 à Hamburg. Cette conférence est l’occasion de réunir les DevOps désireux d’apprendre des retours d’expérience et surtout d’échanger via des Open Spaces. Si le terme DevOps est nouveau pour vous, je vous conseille de lire cet article d’introduction.

Un an après la première édition en Belgique, et un passage aux quatre coins du globe (US, Australie et Brésil), on peut dire que le mouvement prend de l’ampleur : le retour en Europe fût un réel succès ! Je vous propose ici un résumé de ces deux jours passionnants autour de 4 axes : des outils, des processus et méthodologies, de l’architecture, et enfin la culture et le facteur humain.

(Lire la suite…)