Contrat Agile. Suivi des tâches avec post-it {KISS 4} « Gestion de projet automobile. Bien souvent nous nous compliquons la vie : - à mettre en place de longues réunions projet - à rédiger des compte-rendus de réunion, des PV, des meetings minutes … - à convenir de revues hebdomadaires, mensuelles, trimestrielles … - à mettre en place des tableaux Excel pour le suivi des tâches de chacun et le partager sur le réseau - à relancer les membres de l’équipe sur les retards des tâches Malheureusement, nous y consacrons bien trop de temps ! Je vous propose à travers cet article de découvrir (ou re-découvrir) la visualisation des tâches avec de simples post-it. Visual tasks management board L’idée est simple : Voici un exemples concret qui vous permettra de forger votre propre opinion. Il est certes de taille réduite (feuille A4) nous verrons plus tard que le concept reste le même lorsque vous décidez d’aller vers des formats plus grands : Il est possible (et même recommandé) d’adapter et améliorer le concept vers quelque chose qui convient à votre activité/projet/état d’esprit.
Outil Excel pour Scrum : intérêts et limites. De la solution "post-it" ou carte bristol originale jusqu'aux outils les plus sophistiqués - Icescrum, Version One - voire alourdis par un large spectre de fonctionnalités - RTC - une solution simple basée sur un tableur célèbre offre de nombreux avantages. Être immédiatement accessible, très configurable, focalisé sur l'essentiel des concepts... Une solution "tableur" est parfois une étape souhaitable pour établir les features et stories de votre outil Scrum+XP. Nous allons considérer les avantages et les inconvénients d'une telle solution. Pour cela, je me base sur l'outil que j'utilise en formation ou - parfois - accompagnement, qui est disponible ici : Outil Scrum Excel . Intérêts Comme je le précisais en introduction, ce type d'outil offre plusieurs avantages. Disposer de microsoft excel.
Espace partagé : l'un des avantages décisifs d'un outil par rapport aux cartes bristol est sa capacité à être partagé. Ces pré-requis étant posés, voyons d'un peu plus près l'intérêt d'un tel outil. Quand l’Agile peine à s’imposer… Un de nos consultants est embarqué chez l’un de nos clients, dans un projet de dev d’une application web innovante, à interface très riche. Ce projet est conduit par le client suivant une bonne vieille méthode en cascade… Il se trouve dans l’équipe en charge du développement du « front ». Le reste du projet (web-services et stockage) est réalisé par une autre équipe. Et il et se désole tous les jours des freins qu’il rencontre à la production d’une application de qualité : IDE imposé et obsolète, système de gestion de versions inutilisable, batailles sans fin avec l’équipe d’architecture transverse qui impose des technologies obsolètes et incompatibles avec l’ambition du projet.
Les specs sont relativement contraignantes et conduisent au développement d’une appli assez pauvre sur le plan architectural (domaine anémique, code passe-plat…) Le design émergent voué à l’échec ? Pour Jonathan : On est dans le pari classique du « Big Design Up Front » vs « architecture émergente ». Jonathan : Bien démarrer avec "Scrum" Par Florent Lothon, mis à jour en juin 2013. La méthode Scrum (« Scrum » signifie « Mêlée » en anglais), ou plus exactement le cadre méthodologique Scrum est de loin la méthode Agile la plus utilisée dans le monde. Expérimentée en 1993, elle bénéficie aujourd’hui de nombreux retours d’expérience.
Les conférences, communautés, formations, blogs, outils et ouvrages à son sujet ne manquent pas. L’objectif de cet article est de vous aider à vous lancer dans la mise en oeuvre de Scrum. Il décrit le processus associé, ses étapes, réunions, rôles, etc. Au sujet de Scrum Parler d’une « méthode » concernant Scrum n’est pas ce qu’il y a de plus approprié. Au sein de ce cadre méthodologique de gestion de projet, les acteurs ajustent empiriquement, au fil des itérations, leur propre méthode en fonction de leur contexte. NB : Sachez que eXtreme Programming couvre également efficacement les aspects de gestion de projet, faisant d’elle l’une des méthodes Agile les plus complète qui existe. Démarrage. L’artefact ne fait pas le moine. 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.
Un jour, un homme décide qu’il veut devenir moine. Il accepte alors de s’astreindre à certaines règles de vie, à une discipline. Il revêt également un habit qui le fait apparaître comme moine aux yeux de tous. L’organisation qui souhaite devenir Agile, ISO, CMMi ou “Force Pure” (non, ne cherchez pas “Force Pure” sur Google : nous utilisons ici ce terme pour désigner une méthodologie ou une certification quelconque) accepte de s’astreindre à certaines règles de fonctionnement, à une discipline.
Elle produira des artefacts qui pourront notamment servir à démontrer aux observateurs son respect de ces règles, à prouver qu’elle “est” ce qu’elle prétend être. La DSI de la société X s’est lancée. 5 bonnes raisons de déployer en continu. Depuis la présentation retentissante de John Allspaw à Velocity 2009 sur la collaboration entre dev et ops, où il explique que chez Flickr le rythme de déploiement en production dépasse les 10 par jour, on entend beaucoup parler de « continuous delivery » et « continuous deployment ».
Ce dernier se différencie par une automatisation complète de la chaîne de fabrication et déploiement entre le commit du développeur et le déploiement en production, alors que le « continuous delivery » préconise des interventions manuelles (simples « push-button ») pour approbation humaine de certaines étapes : tests fonctionnels manuels, test d’usabilité, contrôle des déploiements par le marketing, etc. J’emploierai le terme « déploiement continu » dans cet article pour regrouper les deux notions. Quelques sociétés nous font part de leur retour d’expérience : pour exemple un présentation du QCon San Francisco 2010 où il est cette fois question de 50 déploiements par jour! 1. 2. 3. 4. Pourquoi? 5. Animer des rétrospectives d’itération. 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.
La rétrospective de sprint. De l'amélioration de processus, concrète (et sans s'encombrer de CMM-I !). Dans la série les réunions d'un projet agile, voici la rétrospective, présentée avec le vocabulaire de Scrum. Le but de la réunion est d'améliorer le processus pour le prochain sprint[1]. Participants Toute l'équipe Scrum participe à la réunion. La rétrospective a lieu juste après la revue de sprint et les intervenants qui sont venus y assister peuvent rester pour la rétrospective, à titre d'observateurs. La réunion peut être animée par le ScrumMaster. Produit en entrée le plan d'actions de la rétrospective précédentele backlog de problèmes Etapes Créer un environnement propice à l'expression Pour bien rester sur l'objectif qui est de s'améliorer et pas de juger, le principe de base d'une rétrospective est rappelé aux participants : S'il y a des doutes sur la confiance, il est préférable de demander à chacun, à bulletin secret, de dire s'il se sent en capacité de s'exprimer librement.
Consolider Définir les priorités. Your Scrum Checklist: Scrum Hard Facts: Roles. Artefacts. All Meetings. Bouzin Agile.