C’est quoi Crisp ?

((/dotclear/public/photos/.HenrikKniberg_t.jpg|Henrik Kniberg|L|Henrik Kniberg))Henrik Kniberg a récemment publié un billet ++[« What is Crisp? »|http://blog.crisp.se/henrikkniberg/2010/05/08/1273272420000.html|en]++ qui raconte comment la société suédoise ++[Crisp AB|http://www.linkedin.com/companies/crisp-ab|en]++ a réussi à « matérialiser » son identité et sa stratégie. Je vous conseille la lecture de l’article, qui m’a du coup filé un gros coup de blues… En réaction, j’ai traduit ++[les deux A3|http://www.crisp.se/what-is-crisp.pdf|en]++ que vous trouverez en français ++[ici|/dotclear/public/traductions/c-est-quoi-crisp.pdf|fr]++ ou sur le wiki ++[« Traductions Agiles »|/dokuwiki/doku.php/traduction:start|fr]++.

Pourquoi j’échoue ?

[((/dotclear/public/lectures/.pourquoi-j-echoue_t.jpg|Pourquoi j’échoue ?|L|Pourquoi j’échoue ?))|/dotclear/public/lectures/pourquoi-j-echoue.gif] »Quatrième de couverture. » Dans la complexité des organisations, rendre performante une action collective requiert des compétences difficiles à maîtriser. Les effets d’un bon management ne se font pas sentir immédiatement et l’on a du mal à distinguer la chaîne complexe des causes. La seule chose dont on soit certain, c’est que tout est encore pire quand il n’y a pas de management ou quand on ne s’en occupe pas ! L’auteur, ++[Maurice Thévenet|http://www.essec.fr/professorsCV/showCV.do?keyUrl=maurice-thevenet|fr]++, croque, à travers dix chroniques savoureuses, les problématiques nées de cette réflexion. Un autodiagnostic permet à chacun de s’auto-évaluer.%%% %%%  »Sommaire : » * Introduction * Autodiagnostic * Ce que diriger voudra dire * Le management et la vie à deux * L’effet « divers » * Management de proximité : les fausses économies * Le paradigme de la bière * La théorie des trois béquilles * Vente et relations humaines : le test de la méthode douce * Temps, énergie et management * Leadership : l’ÊTRE et le FAIRE * M = EC2 * Quizz * Postface : les 11 tributs du management * Résultats du quizz

(Rappel) Scrum Café le 11 mai à 18h

Le prochain Scrum Café Bordelais aura lieu __le 11 mai à 18h00__.%%% %%% Le programme :%%% %%% [((/dotclear/public/logos/.alchimiste-agile_m.jpg|L’Alchimiste-Agile||L’Alchimiste-Agile))|/dotclear/public/logos/alchimiste-agile.png] %%% * Présentation de ++[l’Alchimiste-Agile|http://agile-alchemist.com/|fr]++, l’art de la rétrospective, par ++[Christophe Deniaud|http://www.scrumalliance.org/profiles/69669-christophe-deniaud|en]++ (1h) * Questions/Réponses (15 min) * Préparation prochain Scrum Café – Agenda et Date (15 min) %%% Nous partagerons ensuite un verre tous ensemble, verre qui nous sera offert par notre sponsor du soir (++[CIS Valley|http://www.cis-valley.fr|fr]++, __Rue de l’Hermite à Bruges__).%%% %%% Pour rappel, les informations sont aussi disponibles sur le Google Groupe ++[« SUG Bordeaux »|http://groups.google.com/group/sug-bordeaux|fr]++%%% %%% __Faites circuler l’information autour de vous.__%%% %%% __++[N’oubliez pas de vous enregistrer sur le site Meet-up|http://www.meetup.com/frenchsug/calendar/13191822/|fr]++__

Qu’est-ce-que TOC ?

((/dotclear/public/photos/josh-nankivel.jpeg|Josh Nankivel|L|Josh Nankivel))J’ai traduit l’article ++[« What is TOC?|http://pmstudent.com/what-is-toc/|en]++ de ++[Josh Nankivel|http://www.linkedin.com/in/joshnankivel|en]++ sur son blog ++[pmStudent|http://pmstudent.com/|en]++.%%% > Je suis un passionné de la ++[Théorie des Contraintes|http://www.google.com/search?q=Theory+of+Constraints]++ (TOC$$TOC : Theory Of Constraints$$). En quoi cela consiste-t-il exactement ? Voici une courte présentation.%%% > %%% > En résumé, c’est une méthode pour identifier et renforcer le maillon le plus faible (contrainte) dans un processus, en adoptant une approche itérative d’amélioration continue. Elle propose également des outils pour aider à identifier les hypothèses et les contraintes, … TOC a été développée par ++[Eli Goldratt|http://www.google.com/search?q=Eli+Goldratt]++. L’++[Institut Avraham Y. Goldratt|http://www.goldratt.com/index.html|en]++ est l’organisation qui maintient la connaissance autour de la démarche TOC.%%% > %%% > TOC met notamment en jeu ++[5 étapes logiques|http://www.google.com/search?hl=en&lr=&q=5+focusing+steps|en]++ axées vers l’amélioration continue :%%% > %%% > __1. Identifiez les contraintes__%%% > Trouvez le goulet d’étranglement en considérant l’ensemble du système, pas juste une partie.%%% > %%% > __2. Exploitez la contrainte__%%% > Tirez le maximum possible du goulot d’étranglement, cela augmentera directement le débit de l’ensemble du système.%%% > %%% > __3. Subordonnez tout à la décision ci-dessus__%%% > Changez les habitudes et la politique maison si besoin est pour vous assurer que vous tirez le meilleur parti de la contrainte. Plus de « c’est la manière dont nous avons toujours fait. » Par ailleurs, n’ajoutez pas de travail dans le système au-delà de ce que la contrainte est capable de gérer, cela génère simplement du travail en cours (WIP$$WIP : Work In Progress$$) en entrée de la contrainte. Cela signifie que faire fonctionner une machine dans un processus de fabrication (par exemple), de telle sorte que vous obtenez une utilisation à 100% n’est la bonne chose à faire si ce n’est uniquement générer du WIP en amont de la contrainte. Changez votre façon de penser … Nous voulons obtenir une optimisation globale, pas une optimisation locale. Rien n’est plus sacré que l’objectif d’amélioration globale.%%% > %%% > __4. Optimisez la contrainte__%%% > Si vous avez besoin d’un encore plus grand débit de la part de la contrainte, envisagez d’augmenter sa capacité en la déchargeant de certains travaux, en ajoutant des ressources supplémentaires, … Accélérez le goulet d’étranglement !%%% > %%% > __5. Retournez à l’étape 1 une fois la contrainte supprimée__%%% > « Supprimer une contrainte » signifie que vous avez amélioré le goulet d’étranglement si bien que le goulet d’étranglement a été déplacé à un autre endroit du système. Maintenant, ne laissez pas les nouveaux processus et la politique maison devenir des obstacles d’une future amélioration ! Retournez à l’étape 1 et recommencez !%%% > %%% > ++[Vous trouverez ici le concept TOC présenté dans un dessin animé de la société TOCCA.|http://www.tocca.com.au/Images/FlashFiles/demoOperations.swf|en]++%%% %%% ///html

/// __Feedback :__ * ++[« Et TOC »|http://www.aubryconseil.com/post/Et-TOC|fr]++ par Claude Aubry

Cessez d’attendre la fin du projet pour commencer la recette

((/dotclear/public/programmation.gif|Programmation|L|Programmation))J’ai traduit un billet intéressant ++[« Stop waiting to the end of the project to start QA!!! (And other QA principles) »|http://www.makinggoodsoftware.com/2010/05/02/stop-waiting-to-the-end-of-the-project-to-start-qa/|en]++ sur le ++[Blog de Alberto Gutierrez|http://www.makinggoodsoftware.com/|en]++. Si vous souhaitez continuer votre lecture sur ce sujet, je vous conseille le billet de Hiren Doshi, ++[« A quel moment engager l’équipe de recette dans une itération ? »|/dotclear/index.php?post/2009/12/08/A-quel-moment-engager-la-recette-dans-une-iteration|fr]++. Il est toujours intéressant d’avoir deux points de vue qui se rejoignent avec des différences « sensibles »…%%% > Beaucoup de chefs de projet considèrent qu’il est improbable de détecter des bogues majeurs durant la recette –technique–$$NdT : le terme anglais est QA (Quality Assurance). J’ai toujours du mal à le traduire, tantôt test d’intégration, recette technique ou même recette fonctionnelle suivant les organisations…$$, ce qui ressemble à aller à la guerre en espérant ne pas avoir de pertes humaines. L’une des conséquences d’un tel raisonnement naïf est qu’ils sont habitués à planifier la recette –technique– comme la dernière phase du processus de développement logiciel pour finalement découvrir que : %%% > – Cela n’offre pas assez de temps pour réagir lors de l’apparition de bogues majeurs.%%% > – Cela génère beaucoup de tension entre les équipes de recette –technique– et de développement. Il devient donc crucial pour les développeurs de passer avec succès la recette –technique– parce qu’ils savent qu’ils n’auront pas assez de temps pour corriger un bogue majeur.%%% > – Cela n’est pas adapté pour mener des tests exploratoires. Les tests exploratoires permettent aux testeurs d’appliquer une approche boîte noire qui est excellente pour trouver les bogues les plus importants dans l’application.%%% > – Cela exige des passages de relai et un paramétrage importants.%%% > %%% > Une leçon que j’ai apprise il y a longtemps, est que la recette –technique– peut opérer comme un processus distinct dans d’autres industries, par exemple le manufacturing, mais cela ne fonctionne pas dans le développement logiciel. Chaque fonctionnalité unitaire qui est implémentée dans une application devrait être passée immédiatement en recette –technique–. Vous trouverez ci-après mes principes concernant la recette –technique–.%%% > %%% > __1. Il n’y a pas de transferts de responsabilités entre le développement et les tests__%%% > Coder et tester ne sont pas deux processus distincts, ils sont réalisées en parallèle, et on ne peut pas terminer l’un sans terminer l’autre et vice versa (extrait de : ++[Intégration continue, aller encore plus loin que la compilation continue|http://www.makinggoodsoftware.com/2009/11/29/continuous-integration-going-beyond-continuous-compilation/|en]++).%%% > %%% > __2. Développeurs et testeurs ont un objectif commun__%%% > Ils ne réalisent pas des activités différentes, les développeurs ne sont pas seulement concentrés sur le développement et les testeurs sur les tests. Ils partagent un objectif commun, produire un logiciel de qualité de façon coordonnée à partir des attentes du propriétaire du produit (extrait de : ++[Intégration continue, aller encore plus loin que la compilation continue|http://www.makinggoodsoftware.com/2009/11/29/continuous-integration-going-beyond-continuous-compilation/|en]++).%%% > %%% > __3. Les équipes de recette –technique– et de développement doivent fournir leurs plannings au sein d’un planning unique__%%% > Il n’y a pas un planning de développement et un autre pour la recette –technique–, parce qu’ils dépendent l’un de l’autre.%%% > %%% > __4. Le rôle d’un recetteur –technique– ne devrait pas être moins valorisé, qualifié ou reconnu que le rôle d’un développeur__%%% > J’ai travaillé sur de nombreux projets où les recetteurs –techniques– sont considérés comme des collaborateurs de deuxième classe qui effectuent des tâches plus faciles que les développeurs. En réalité, dans de nombreux projets, le type de rôle tenu est celui d’un testeur qui suit uniquement un script de test et prenant notes des résultats attendus et obtenus à chaque étape.%%% > %%% > À mon avis, les testeurs apportent beaucoup de valeur ajoutée au projet, ils devraient être responsables de l’écriture de tests automatisés, de la mise en place des environnements et de la coordination avec le Métier pour s’assurer de leurs attentes réelles.%%% > %%% > __5. Le recetteur –technique– et le développeur n’ont pas besoin d’être deux personnes différentes, c’est seulement deux rôles différents__%%% > Parce que la recette –technique– a coutume de se passer à la dernière étape du développement logiciel, et parce qu’elle était considérée comme une sorte de processus de certification, le management a décidé que la recette –technique– devrait être confiée à une équipe totalement indépendante, et cela a conduit à l’idée que le recetteur –technique– et le développeur devraient toujours être non seulement deux rôles différents, mais aussi deux personnes différentes.%%% > %%% > __6. La recette –technique– devrait être planifiée de telle manière qu’elle puisse représenter jusqu’à 50% du temps de développement__%%% > C’est juste une règle empirique, et bien sûr c’est à juger au cas par cas, mais il est important de comprendre que la recette –technique– est une tâche très importante qui, lorsqu’elle est correctement réalisée, pourrait représentée jusqu’à 50% du temps de développement.%%%