• Intro to Continuous Integration | Mark Story http://awe.sm/5cWLT (#jenkins)
• IT staffing troubles begin, especially with younger developers #ZDNet http://awe.sm/5cWBG
• La méthode KISS pour embrasser le succès http://awe.sm/5c7T9

---

• Twitter : https://twitter.com/#!/Moosh_be
• Klout http://klout.com/#/moosh_be/

Ce post n'a rien de structuré. C'est une suite de notes prises hier au cours des sessions de l'Agile Tour à Lille

---

Sprint raisonnable 2, 3, 4 semaines

---

Scrumm Master n'est vraiment pas le chef projet mais le gardien de l'agilité de l'équipe qui gère elle-même son projet vis-à-vis du product owner

---

Besoin d'un coach, et surtout pour la globalité des intervenants du projet (et surement pas penser que le coach n'est nécessaire que pour l'équipe de développement)

---

Qu'est-ce que d'une tâche terminée ? -> critères autorisant ce statut à définir entre les développeurs et le product owner, ensuite le scrumm master vérifie que les développeurs ont respecté leur engagement.

---

Le scrumm master n'est pas le "point de passage de la communication", la communication DOIT se faire en direct.

---

Pas de (casquette) manager pendant la rétrospective

---

Faire de l'Agile au niveau de l'équipe de développement alors que hors de celle-ci on est pas encore dans la méthode, ce n'est que farce C'est encore pire quand cette partie "non développeurs" PENSE faire de l'agile.

---

Faire des speedformations (viser 10minutes de présentations, 5 minutes de questions, ne stopper que quand tout le monde à compris)

---

AGILE et LEAN ont énormément de points/socles commun et pourtant n'ont pas les mêmes images, agile passant un peut pour du hippie et LEAN pour du sérieux

---

Cas présenté: Disponibilité du "client"

• représentation par une personne du service informatique existant du client en permanence (parce que chance d'en avoir une)
• représentation par une personne utilisatrice du client régulièrement. (difficile à obtenir)

---

Cas constaté : Conflit entre

• décideur qui pense savoir ce dont les utilisateurs ont besoin (et/ou qui tente de faire passer dans l'outil construit ses règles de gestion)

et

• l'utilisateur qui ne voit que ses tâches, son apporche, sa vue, mais qui n'a pas le "recul" sur les ambitions, les objectifs et les contraintes du projet global

note : pas de solution évoquée si ce n'est le "courage" cité dans le manifeste de remettre chacun à sa place.

• Oser dire non au client (décideur) en évitant le "c'est moi qui paye, faites le"
• Oser dire non à l'utilisateur en évitant le "ils vont encore nous faire un outil inutile"

---

refactoring : c'est aussi rendre les couches supérieures plus "lisibles" ( style lecture de pseudo code)

---

gouvernance éthique

---

relire le manifeste agile

---

Utilisation moyen des fonctionnalités d'un produit

• 7% toujours
• 13% jamais
• 16% parfois
• 19% rarement
• 45% jamais

note : acceptable dans un logiciel générique (OOWriter, eclipse, ....) bcp moins dans un logiciel maintenu.

---

Pratique vue dans éclipse : Ecrire le code dans le test, puis utiliser la fonction "QuickFix" pour générer le squelette du code metier.

---

• Ecrire un test jusqu'à ce que le framework de test s'exécute et donne du rouge -> phase de conception
• Ecrire du code jusqu'à ce que le framework de test s'exécute et donne du vert -> phase de réalisation

---

Séparer les tests d'acceptance et unitaire pour présenter les premier comme "preuve de réponse à la demande initiale"

---

Dans php, utiliser SPL ArrayList pour les listes devant contenir des instance du même objet

---

• http://tcros.blogspot.com/
• http://davidbrocard.org/
• http://www.martinfowler.com/
• http://lolcx.blogspot.com/
• http://www.aubryconseil.com/
• http://letsgo-agile.blogspot.com/
• http://www.pedautreppe.com/
• http://emmanuelchenu.blogspot.com/

L'agile Tour 2009 passe peut-être dans votre région....

Agile Tour, une série d’événements à but non lucratif, répartis sur plusieurs villes pendant tout le mois d’octobre 2009.

Leurs objectifs :

Promouvoir massivement l’Agilité

Notre principale mission est de réaliser une communication massive sur nos pratiques de développement pendant tout le mois d'octobre. Nous voulons ainsi communiquer partout et en même temps afin de gagner en efficacité et attirer massivement l’attention sur notre nouvelle approche professionnelle.

Partager nos visions de l'agilité

L'agilité étant potentiellement évolutive, nous souhaitons nous ouvrir vers de nouveaux horizons et apprécier la compréhension, les interprétations et les évolutions que nous pouvons donner aux pratiques agiles.

Fédérer

Fédérer les acteurs de l'agilité dans toutes les régions du monde en même temps sur cette idée et inciter de nouvelles initiatives locales pour développer une culture de l’Agilité.

Soutenir

Nous souhaitons apporter notre soutien à nos confrères et aux entreprises locales pour les aider à adopter et à faire adopter ce savoir-faire.

---

J'ai dumpé un SVN alors pour mémoire...

Sur le svn source

[console]
svndump –r  :1000 > dump_part1.dumpfile
svndump –r  1001:2000 –incremental > dump_part2.dumpfile
svndump –r  2001: –incremental > dump_part3.dumpfile

note : --incremental n'a pas été nécéssaire sur le 1er

Sur mon svn avec trac

[console]
mv /somewhere/svn/myproject/ /somewhere/svn/myproject.bak2
svnadmin create /somewhere/svn/myproject/
svnadmin load /somewhere/svn/myproject/ < dump_part1.dumpfile
svnadmin load /somewhere/svn/myproject/ < dump_part2.dumpfile
svnadmin load /somewhere/svn/myproject/ < dump_part3.dumpfile
trac-admin /somewhere/trac/myproject resync

note : la dernière commande c'est parce que j'utilise trac. Pour svn seul ce n'est pas nécessaire.

Scrum methodology de Soul' sur Vimeo.

Non proposé par défaut, voici un rapport que je me suis ajouté dans certains trac.

Celui ci me donne par composant, les derniers tickets fermés

[sql]
 SELECT 
 component as __group__,
   changetime AS modified,
   id AS ticket, 
 
   component, 
   summary, 
   (CASE status WHEN 'assigned' THEN owner||' *' ELSE owner END) AS owner_,
 
 
   time AS created,
   t.type AS type, 
   version, 
   description,
   reporter
  FROM ticket t
  WHERE status IN ('close', 'closed') 
  ORDER BY (version IS NULL),version, (component IS NULL),component,  changetime DESC,   t.type, time

Voici mes notes pour la rétrospective. Je n'ai rien inventé, j'ai essayé de rassembler ce que j'ai trouvé sur le net. Comme il est temps de s'y remettre...

Durée de la réunion : approximativement 1/40 du temps de l'itération. (1 semaine -> 1h)

• Tout le monde se sent-il libre de parler ?
• Que nous étions nous fixé lors de la dernière rétrospective ? Qu'avions nous décidé ?
• Quels problèmes avons nous rencontré dans l'itération ?
• Quels problèmes avez vous rencontré dans l'itération ?

Pour pouvoir parler plus facilement de ces problème j'ai vu un premier truc, c'est de récolter les problèmes évoqués pendants les scrum meeting. Mais alors il est peu-être utile d'ajouter une 4eme question à ces meeting c'est qu'avez vous eu comme problème pour les tâches fraichement réalisées ?

Tous les problèmes recueillis vont donner lieu à un "backlog" de l'amélioration. On va donner une valeur et un temps à chaque "amélioration" et on va alors ainsi faire emmerger les améliorations sur lesquelles se concentrer.

Cela me donne d'ailleurs une autre idée. C'est que dans une équipe et un projet où on amène l'AGILE, le mélange dans un backlog des fonctionnalités et des améliorations peux amener une satisfaction à l'équipe. Les améliorations tenant à rendre le travail plus "simple", plus "souple" ne révèle pas forcément un intérêt direct et visible au supérieur qui n'est pas dans le trip agile.

Une fois valorisée et estimée cette amélioration devient une fonctionnalité en soit. On concrétise ces éléments abstraits pour ceux qui ne développent pas, pour ceux qui n'agilent pas

• Et enfin on fait comprendre que créer des tests pour du code qui existe et qui fonctionnait, c'est utile.
• Et enfin on fait comprendre que faire du refactoring sur du code qui existe et qui fonctionnait, c'est utile.
• Et enfin on fait comprendre que mettre en place des outils de contrôle automatisés, c'est utile.

C'est utile, et on le fait comprendre là où un "chef" peut se dire "la seule chose qui compte c'est de voir que ca avance". Car trop souvent, si ce n'est pas visible, c'est que ca n'avance pas.^[1]

références

• Rétrospective de sprint
• Le backlog de problèmes
• la photo

Belgium Testing Day

Belgium Testing Day le 23/02/2009 à l'Hotel Bloom, de Bruxelles

• Stephan Goericke : Assure Quality - Keep Training Testers
• Erik van Veenendaal : Risk Based Testing In Practice
• Alon Linetzki : Root Cause Analysis: Dealing with Problems, Not Symptoms
• Geoff Thompson : Software failures – can we learn from them
• Manu Cohen-Yashar : Security testing using free tools
• Steven Mertens : Usability Testing
• Geert Vanhove : When testing stops and politics takes over
• Claus Gittinger : Model-Based Test Development
• Geert Lemmens : Agile: Testing at the speed of light
• Yaron Tsubery : ATP – The Factors behind Success

(posté en retard, j'avais oublié de le publier)

---

Voilà ca aussi c'est fait.

Durée 65 minutes (mais on a aussi fait la rétrospective de la mise en place de la méthode agile).

J'ai utilisé ma petite fiche.

En pratique

On a relu les problèmes notés pendant les scrumm meetings.

Contrairement à la revue qui a duré la moité du temps prévu, celle-ci a débordé de 5 minutes, parce qu'on a enchainé sur la retrospective "de l'agile".

On a constaté les problèmes suivants

• l'absence de test unitaires (corrigé depuis)
• le manque d'info dans les feedback utilisateur
• la mauvaise gestion des spikes
• le conflit entre la maintenance de l'existant et des tâches du sprint (on ne sait pas isoler les équipes, puisqu'on est que 2 pour le moment)
• J'ai entendu le développeur exprimer une crainte quand j'ai parlé de travailler dans une classe précise. (Ca m'inquiète sur l'état de la classe)
• J'ai parfois manqué de droit système pour mettre en place les outils de travail.

On a repris ca dans 3 catégories

• l'environnement de travail
• la méthode
• la gestion de l'existant

zer48868586

Voilà j'ai fait ma première revue... (seulement ? )

Oui, c'est un peu loupé pour le time boxing, j'avais beaucoup d'autres choses à découvrir.

En gros l'ensemble des tâches prévues pour l'itération ont quasiment été faites dans les temps.

Ce qui a posé problème c'est leur mise en production. Je devais découvrir les méthodes, les cas particuliers, ...

Des bugs sont remontés, ont été traités en (et dans) l'urgence.

Pas mal de réunions pour découvrir l'entreprise, des entretiens d'embauche pour renforcer l'équipe,

Des hésitations de ma part pour le "comment organiser la revues et la rétrospectives"...

Pour ce point, je me suis surtout basé sur le post : les réunions d'un projet agile

Je me suis fait 4 fiches avec les objectifs et les "points chaud" de chaque réunion. Je vais les scanner lundi, je l'ai ai oubliée au bureau.

La revue a été assez simple. On a pas fait de démo parce que

1. on a travaillé pas mail sur l'architecture
2. tout le monde a bossé dessus et connaissait l'état.

On a donc fait un topo de ce qui n'a pas été fait, et de ce qui a été fait mais qui a révélé d'autres tâches.

• à suivre : Ma première rétrospective
• Prochaine lecture : Le backlog de produit n'est pas une todo liste

En fait je résumerai l'intérêt de l'agile avec la question suivante :

Est-il plus intéressant d'avoir un logiciel qui fait TOUT ce que vous aviez besoin quand vous l'avez demandé ou d'avoir le plus important de ce que vous avez besoin maintenant ?

Question raffinable parce qu'en plus c'est pas ce qu'on a demandé mais ce qui a été interprété dans ma demande.

Et je ne vois pas encore trop comment m'y prendre.

Il est temps de chercher quelques lectures

• http://www.aubryconseil.com/dotclear/index.php/2007/07/09/257-les-reunions-d-un-projet-agile ajouté
• http://www.qualitystreet.fr/?2008/08/28/144-retrospectives-des-moments-cles ajouté
• Livre:Agile Retrospective Making Teams Great
• http://www.aubryconseil.com/dotclear/index.php/2006/12/20/141-amelioration-du-processus-avec-les-retrospectives
• How To: Live and Learn with Retrospectives

Ben oui j'ai publié mon post d'hier sans l'avoir fini.

Je finissais par

Je me demande ce que vous en pensez. Ca me semblait pratique car découper toutes les tâches et les présenter dans le premier tableau ca me semblait "trop d'info". En fait j'ai un tableau

J'allais donc décrire les 2 Tableaux que j'ai fait.

Sans le savoir j'ai commencé à créer ma war room.

1° un tableau de 5 colonnes.

Itération 1 | It. 2 | It. 3 | It. 4 | It. 5

et un autre de 4 colonnes

à Faire | en cours | à vérifier | fini

Ce second tableau, c'est le Taskboard.

Dans le premier j'ai l'ensemble de mes post-it fonctionnalité. Avec donc 5 unités de temps arbitraire maximum.

Dans le second j'ai mes post-it "(sous) Tâches".

C'est chaque tâche qui rentre dans la colonne en cours subit le cycle 1 temps écriture de test, 1 temps code, 2 temps refactoring.

Puis elle passe en à vérifier.

En réalité, cette semaine, les tests et le refactoring ne sont pas fait parce que je n'ai pas eu le temps de l'expliquer.

J'espère commencer ca lundi.

Demain je continue a découvrir mon nouveau travail et ses futurs projets.

D'ici peu, je vais recevoir 2 nouveaux tableau blancs.

Mon tableau d'itération va être placé sur le mur extérieur du bureau, mur devant lequel tous les employés passent au moins une fois par jour.

J'y mettrai aussi le le burn up chart

J'ai voulu ça pour rendre visible notre travail aux autres département sans devoir les noyer de feedback ou à l'inverse leur laisser juste constater à la mise en production.

Dans le bureau j'aurais l'autre nouveau tableau blanc qui affichera

• le task board avec les étapes de mon itération.
• le burn down chart

Je viens de lire "information-radiator indispensable ?".

C'est amusant il y parle des personas. Un concept dont j'ai justement parlé aujourd'hui au travail, et dont j'avais entendu parler pour la première fois au World Usability Day à Louvain la neuve l'année passée. (notez que l'édition 2008 c'est dans 7 jours)

Lectures :

• Task Board et Burn Down Chart
• team room
• personas
• information-radiator indispensable ?
• "War Room" is gaining popularity over conventional cubicle
• Burn Up & burn Down charts

Remplacer l'existant en matière de gestion de tâches/requête n'est pas simple.

Arriver là où des processus existent, et où on veut en initier un autre, nécessite des remplacements.

Tout ces changements seront confrontés à une résistance au changement.

2 éléments opposés me viennent à l'esprit.

• laisser adopter la nouveauté par la présentation par valeur ajoutée. Laisser le temps qu'il faut pour que le changement soit accepté par les utilisateurs. La résistance au changement est bien plus forte quand on est au pied du mur, quand la nouveauté est imposée.

à l'opposé,

• on doit avancer, si on laisse le temps, on ouvre des failles aux tire-au-flancs (vision avec confiance faible aux collaborateurs), ou même avec une volonté affichée des collaborateurs, multiplier les outils de même "fonction" ou les canaux de communication est toujours source d'éparpillement.

Je me retrouve ici comme dans le boulot précédent avec 4 canaux pour les tâches.

• L'email
• les Tâches dans outlook
• un système de ticketing interne
• un radiateur de tâches.

Historiquement, humainement, (pragmatiquement ?) l'email a tendance à prendre le dessus. parce que même si les tâches d'outlook ou du ticketing interne sont techniquement identiques aux emails, le simple fait d'entrer dans un "autre" outil crée une appréhension que j'identifie comme identique à un automobiliste qui doit prendre le volant d'un autre véhicule que le sien.

Il faut pourtant essayer de l'éviter, ou de transformer la demande reçue par mail en l'entrant dans le flux d'un des autres outils.

Le second réflexe est d'informatiser. Le radiateur de tâche semble tellement "amateur" alors qu'on peut le faire avec un fichier excel ou un beau programme. C'est le syndrôme Notpad.

On prend ses notes dans notepad, puis on est bloqué, il faut l'imprimer ou sauver et envoyer, ... Un bon vieux blocnote et un crayon. C'est souble, économique, transportable, indépendant ...

Pour ma part voilà comment j'ai procédé aujourd'hui.

J'ai pris la liste existante des tâches dans outlook. On s'est mis autour de la table avec un bloc de postit.

1. ° chaque tâche est devenue un post-it.
2. ° une tâche modeste mais pas la plus petite à été estimée arbitrairement à 2 unités de temps de travail.
3. ° les autres tâches ont été évaluées en fonction de cette tâche de référence.
4. ° j'ai repassé les valeurs avec la série de Fibonacci 1,2,3,5,8,13,... (en pratique les 4 sont devenus des 5)
5. ° j'ai repris les informations de priorité et mon expérience pour évaluer la valeur des tâches (ca aurait dû être fait avec le "client", je vais en fait vérifier ca plus tard, je voulais avancer dans l'exercice).
6. ° On a calculé le ratio valeur/temps
7. ° j'ai totalisé le temps (on est arrivé à 24)
8. ° j'ai fait 5 colonnes en disant "5 unités par colonne d'itération"
9. ° j'ai pris de gauche a droite en plaçant les fiches à au ratio le plus grand en remplissant pour arriver à 5.
10. ° j'ai expliqué le burn down chart
11. ° j'ai refait un autre tableau de 4 colonnes "A faire" "En cours" "à vérifier" "fini"
12. ° j'ai repris les 3 post-it de la première itération et on a divisé ces tâches fonctionnelles en taches de réalisation. Avec une estimation en heure.
13. ° et finalement j'ai placé ces post-it là dans la colonne à faire.

Voilà l'exercice est fini, et on va partir là dessus.

Premier constat mes post-it estimés à 2 + 2 + 1, découpé en tâches on donnés 8h+8h+1h. On pourra en tirer des leçons au terme de l'itération.

L'exercice réalisé à l'agile tour m'a vraiment bien servi.

J'ai toute fois dérivé de l'exercice. pour le quel les tâches du radiateur d'itération n'était pas "redécoupées" en plus petite tâche.

Je me demande ce que vous en pensez. Ca me semblait pratique car découper toutes les tâches et les présenter dans le premier tableau ca me semblait "trop d'info". En fait j'ai un tableau

-edit- Oups je m'étais arreté au milieu d'une phrase. J'ai continue ici

Mes récents posts sur ma préparation à l'utilisation des méthodes agiles a quadruplé le nombre de lectures quotidiennes de mon blog, en ça je vous remercie, visiblement le sujet interpelle.

Je voudrais toutefois souligner qu'il s'agit avant tout d'une base d'échange, qu'il ne s'agit pas (encore) d'un retour d'expérience mais d'une réflexion ouverte, et lancée à la critique.

N'hésitez pas à faire vos remarques, qu'elles soient des réponses, des avis, des questions nouvelles, des retours de vos expériences ...

Tous les commentaires sont grandement bienvenus.

Notez que je valide tous les commentaires, il est donc normal qu'il n'apparaisse pas au moment où vous le postez.

Encore merci.

J'ai eu un commentaire en réponse à Organisation du temps de travail (agile ?)

La réponse me semble assez longue que pour être repostée

Comme je l'ai dit ici

Je vais commencer par

• créer une base de test et les automatiser
• créer des règles de codages
• découper les tâches et les organiser en itérations
• et le standup meeting.

Je compte imposer les tâches à faire dans l'itération mais laisser la liberté de choix dans ces tâches à l'équipe.

J'attends en retour, un "dévouement" et une prise de responsabilité par chacun pour mener à bien chaque tâche choisie. Ceci incluant, oser dire je bloque, je ne sais pas. Pour qu'on trouve le temps de chercher une issue au blocage. (Au lieu de le camoufler et de s'enfoncer)

Pour le pair programming, je dois apprendre à connaître/sentir l'équipe, mais en tout cas je compte au minimum pratiquer l'échange de code. Ou la vérification croisée.

Voici la réponse de GeoBar

Lire la suite...

Voici une discussion avec Xavier suite au post : Organisation du temps de travail

La question se pose à propos du "quand gérer", "comment installer la méthode."

Ensuite, je propose mes choix.

Lire la suite...

Dans mon organisation du temps de travail agile, je provois un standup meeting de 10 à 15 minutes. Mais dans dans la journée ?

Dans la littérature on parle du "matin". Voici une discussion sur le sujet :

Lire la suite...

Je parlais de mes valeurs dans le cadre d'un projet informatique.

Voici celle qui s'ajoutent dictée par l'envie de faire de l'agile.

Source : wikipedia

(entre parenthèse, les citations du manifeste) :

• L'équipe (« Personnes et interaction plutôt que processus et outils ») : Dans l'optique agile, l'équipe est bien plus importante que les moyens matériels ou les procédures. Il est préférable d'avoir une équipe soudée et qui communique composée de développeurs moyens plutôt qu'une équipe composée d'individualistes, même brillants. La communication est une notion fondamentale.

• L'application (« Logiciel fonctionnel plutôt que documentation complète ») : Il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est secondaire, même si une documentation succincte et précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l'équipe (on en revient à l'importance de la communication).

• La collaboration (« Collaboration avec le client plutôt que négociation de contrat ») : Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation du logiciel à ses attentes.

• L'acceptation du changement (« Réagir au changement plutôt que suivre un plan ») : La planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet. Les premières releases du logiciel vont souvent provoquer des demandes d'évolution.

---

De là quelques questions.

L'équipe

"Moi je suis motivé". Mais que faire de l'éventuelle velléité de certains collègues qui seraient là juste pour le salaire que le travail soit bien fait ou pas". (sorry je transfère la une certaine amertume envers mon précédent emploi). Normalement la réponse se trouve dans la motivation, par l'implication, ... si je suis acteur du projet et non un simple pion. Si on arrête de croire qu'il existe des "product manager" et des "analystes" qui savent tout et des codeurs juste là pour concrétiser". (sorry je transfère là encore ...). Bref il faut 2 ingrédients : un projet en le quel l'équipe croit et que chaque équipier s'y sente utile et acteur.

L'application

La valeur "application" était déjà d'application chez claroline. On y avait toutefois une autre approche, un autre objectif, exprimé différement : "Une documentation est un palliatif à un logiciel mal intuitif".

La collaboration

Le client fait partie de l'équipe en terme de motivation et d'implication tout comme le représentant des utilisateurs finaux, leurs activités au sein du projet est différente mais on ne doit pas se laisser croire qu'elle est optionnelle.

---

Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles :

Source : Garance

1. Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.
2. Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.
3. Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.
4. Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet.
5. Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.
6. La méthode la plus efficace de transmettre l'information est une conversation en face à face.
7. Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
8. Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
9. Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité.
10. La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.
11. Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent.
12. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.

Je vais travailler désormais en suivant les propositions des méthodes agiles.

Dans ce cadre j'essaye de préparer l'horaire de la journée standard de travail. Voici quelques réflexions et échanges que j'ai eu à ce propos

Je voudrais placer dans cette journée

• un minium de 4h de programmation agile (pair programming, refactoring, test, ...)
• 1 standup meeting de 15 minutes
• 1h de gestion du projet (pour moi)

Je voudrais aussi forcer les meeting (autres que le standup meeting) dans la tranche horaire 14h-15h. C'est à dire que si il y a lieu d'avoir un meeting, c'est après le repas.

Pour timeboxer une semaine, je opterai pour une solution de

• Lundi écriture des tests
• Mardi écriture du code.
• Mardi soir on a fini les fonctionnalités.
• Mercredi Jeudi refactoring
• Vendredi backlog, planification, analyse de la mise en pratique des méthodes agiles.

---

1. NEW (30/10/2008) : à propos du standup meeting de 15 minutes
2. NEW (31/10/2008) : à propos du Quand organiser le temps

Cette version n'est que transitoire, mais une mise à jour fera l'objet d'un nouveau post

En réfléchissant sur mon prochain boulot, j'ai essayé de lister les valeurs, les points que je voudrais vraiment mettre en avant.

Ils sont assez bateau peut-être mais ils me guideront.

Lire la suite...