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

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

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.

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