Le blog de yquenechdu

Créer son planning de release

SecureOne — Sun, 28 Dec 2008 18:57:00 +0100

Suite à mon précédent billet sur la planification en méthode Agile dans lequel j'avais abordé le principe du planning de release et d'itération, je vous propose de continuer sur la planification est de développer le planning de release. Dans un prochain billet, je détaillerais la réalisation du planning d'itérations.

Au point de départ, nous avons un client qui nous a contactés pour développer une application. Ce projet est constitué d'un ensemble de besoins à la fois fonctionnel et technique (backlog).

La première action à réaliser dans le cadre de ce projet est de définir le planning de release. L'objectif est d'avoir une vision globale du projet en terme de planning, d'activité et de coût. Comment réaliser un planning de release ? Le schéma suivant nous donne une première approche, que nous allons détailler par la suite.

Un projet est soumis à plusieurs conditions, qui sont régies par le classique triangle : ressources (coût, budget), calendrier, périmètre (fonctionnalités, caractéristiques). Ce sont ses éléments qui vont nous permettre de constituer notre planning de release. Prenons un simple exemple, un client souhaite X fonctionnalités avec un cout de X euros. Après une première estimation des besoins du client, nous devons lui indiquer que par rapport aux coûts nous ne pourrons pas respecter le périmètre. Nous devons appliquer des priorités sur les fonctionnalités avec notre client pour choisir ce qui peut-être fait avec son budget.

L'exercice est de définir un planning de release selon les conditions inhérentes au triangle du projet. Nous pourrons réaliser un premier planning qui sera adapté et modifié selon les contraintes de ce triangle et ceci en relation avec notre client.

Une fois que nous avons déterminé les conditions spécifiques au projet, passons à la pratique et réalisons notre planning de release :

Remarque : Comme je l'ai déjà indiqué dans mes précédents billets, je n'utilise pas la notion de "vélocité" et de "user story" dans mes projets. Ces deux éléments sont trop vagues pour réaliser un projet en mode forfait, ce qui représente 100% de notre activité de développement.

Les activités à réaliser pour créer notre planning de release sont les suivantes :

Identifier les cas d'utilisation
Sélectionner la longueur d'une itération
Estimer la charge par cas d'utilisation
Appliquer les priorités sur les cas d'utilisation
Sélectionner les cas d'utilisation et les date de release

Identifier les cas d'utilisation

L'identification des différents cas d'utilisation est réalisée à partir d'un cahier des charges fourni par le client, d'une liste de fonctionnalités attendues dans le programme, etc.

La première démarche est de compartimenter en cas d'utilisation ou story (pour les non-techniques) les besoins fonctionnels et un cas d'utilisation transverse pour les éléments technique. Cette activité est réalisée par le product ower et le client. Ce sont les acteurs qui ont la vue fonctionnelle du projet. La partie technique sera abordée lors de la constitution du planning des itérations par l'équipe du projet. Il est important de créer un cas d'utilisation tranverses qui prend en compte les besoins du client, car il peut impacter de manière importante sur le budget et le calendrier de projet.

Pour permettre une évaluation budgétaire réaliste du projet (et surtout éviter de s'en rendre compte au milieu ou à la fin du projet), nous essayons d'obtenir une bonne granularité de nos cas d'utilisation. C'est à dire une cinématique nominale pour chaque d'utilisation. Ce qui pourra se traduire sous la forme suivante :

Contexte : Un utilisateur souhaite se connecter à l'application. Cet utilisateur possède un compte dans le référentiel de données.

Acteurs :

Collaborateur : utilisateur référencé dans le référentiel de données
Administrateur : Collaborateur ayant des droits d'administration.

Description du use case : Ce mode d'authentification permet à un collaborateur de se connecter à l'application. Celui-ci accède à une page d'authentification où il saisit son couple identifiant/mot de passe. Le système vérifie les paramètres d'authentification auprès du référentiel de données.

Pré-requis : L'utilisateur est enregistré dans lle référentiel de données.

Descriptif du cas d'utilisation

Le collaborateur ouvre son navigateur et accède à l'application
Le système demande son couple identifiant/mot de passe à l'utilisateur
L'utilisateur saisit son couple identifiant/mot de passe et valide
Le système vérifie les informations en relation avec le référentiel de données. En cas d'échec, on retourne à l'étape 2
Dans le cas d'une première authentification, le système initialise et crée un compte utilisateur dans le référentiel de données. L'application redirige l'utilisateur vers la page principale de l'application.

Post-conditions : Un compte utilisateur a été créé (en cas de première authentification) dans le système. L'utilisateur est sur la page principale de l'application et peut commencer à l'utiliser.

A la fin de cette phase, nous avons identifier les différents cas d'utilisation. Nous passer à la phase suivante.

Sélectionner la longueur d'une itération

Comme je l'ai expliqué précédemment dans mon billet sur "le planning en méthode Agile", la longueur d'une itération est subjective, la majorité des projets agile utilise une longueur de 30 jours (quatre semaines). Cette période ne doit pas être considéré comme acquise, car elle peut à la finalité, nous poser des problèmes dans notre projet. Je conseille de prendre le temps de bien choisir sa longueur lors de la conception du planning de release.

Certains éléments du projet doivent nous aider à définir la période d'une itération. Le premier point qui peut nous aider concerne la longueur du projet dans sa globalité, si nous travaillons sur un petit projet avec de nombreux cas d'utilisation ou story, il est plus intéressant de faire des itérations courtes pour que l'équipe en charge de l'intégration puisse les valider rapidement. Inversement, tous les projets n’ont pas la chance d'avoir une équipe d'intégration attitrée, le planning peut aussi dépendre de leur disponibilité. Pour choisir la longueur d'une itération, Je vous propose une petite liste de facteurs qui peuvent vous aider à la définir :

La taille du projet
Le nombre de cas d'utilisation
Les priorités du client en terme de calendrier
La flexibilité au changement
L'implication du client dans cette méthode de projet
La présence d'une équipe d'intégration spécifiquement sur ce projet
La politique de l'entreprise sur le projet
Le taux d'incertitude sur la mise en oeuvre de certaines fonctionnalités

Ce qu'il faut retenir : Il faut choisir une longueur et la conserver tous au long du projet. Cette longueur correspond au rythme du projet et de l'équipe. L'équipe prend son tempo sur ce rythme et le conserve, un changement de longueur engendrerait une coupure dans ce rythme et perturberaient rapidement les équipes et le rendement du projet.

Estimer la charge par cas d'utilisation

Un planning de release est un planning avec une vision très macro à la différence d'un planning des itérations. Néanmoins, il ne faut pas penser que le travail de calcul des charges doit se faire à la légère. Dans mon précédent billet sur le planning poker, je vous avais présenté une méthode pour calculer les charges par cas d'utilisation. L'activité de planification est réalisée de la même manière pour calculer les charges par cas d'utilisation.

Le calcul de charge ne porte pas exclusivement sur le développement, mais aussi sur la partie spécification (conception) et intégration. Dans notre méthode de travail, nous calculons les charges en idéal days et non en vélocité. La vélocité est considérée comme trop floue par nos clients et les équipes.

Chaque cas fonctionnel est présenté à l'équipe projet par le product ower (par celui qui à la vision la plus fonctionnelle du projet), une première planification est réalisée par la méthode du planning poker.

Les charges pourront être réajustées après la réalisation du planning des itérations (identification des taches par cas d'utilisation). À la fin de ce travail, nous obtenons notre tableau des charges par cas d'utilisation :

Cas d'utilisation	Charge
CU 100	13
CU 101	21
CU 102	8
CU 103	8
CU 104	5

Appliquer les priorités sur les cas d'utilisation

Un des points les plus importants du planning de release est d'appliquer une priorité sur chaque cas d'utilisation. En effet, cela permet de sélectionner les cas d'utilisation qui devront être développés en premier. Cette priorité est appliquée par le client et le responsable du projet, néanmoins, il est important de prendre en compte l'avis des développeur qui peuvent apporter une vision différente concernant la chronologie de réalisation des cas d'utilisation, ainsi que le risque afférent à chaque cas d'utilisation. .

À la fin de ce travail, nous obtenons notre tableau des priorités par cas d'utilisation :

Cas d'utilisation	Priorité	Charge
CU 100	1	13
CU 101	3	21
CU 102	2	8
CU 103	5	8
CU 104	4	5

Sélectionner les cas d'utilisation et les date de release

Après toute cette activité que l'on peut quantifier au maximum sur 2 jours (selon la taille du projet et l'expérience des acteurs), nous avons les éléments suivants :

La longueur d'une itération,
Une liste des cas d'utilisation, avec leurs priorités et les charges.

Nous sommes fin prêts pour réaliser notre planning de release. Ce travail est maintenant assez simple, nous allons associer les cas d'utilisation et les itérations. Pour ce faire, nous prenons les cas d'utilisation prioritaires, nous prenons leurs charges, nous les positionnons dans les itérations.

Nous avons sélectionné pour ce projet une longueur d'itération de 30 jours. Nous allons créer le planning suivant :

Itérations	Cas d'utilisation	Priorité	Charge
Itération 1	CU 100	1	13
Itération 2	CU 101	3	21
Itération 1	CU 102	2	8
Itération 2	CU 103	5	8
Itérations 1	CU 104	4	5

Nous avons dans notre exemple 2 itérations, nous pouvons proposer le planning de release suivant :

La première livraison au bout de 30 jours comportant 3 cas d'utilisation
une deuxième livraison au bout de 60 jours avec l'ensemble du projet.

Il faudra prévoir d'autres livraisons après les retours du client à propos de la première livraison et ensuite lors de la deuxième livraison.

Le Planning Agile

SecureOne — Sat, 27 Dec 2008 21:26:00 +0100

En méthode Agile, nous avons 2 plannings, le planning de release et le planning des itérations (ou sprint).

Planning release

Le planning release permet d'avoir une vision de la réalisation du projet dans sa globalité. Nous pouvons comparer un planning de release à une roadmap d'un projet.

L'exercice à réaliser dans un planning de release est d'évaluer grossièrement les fonctions qui seront livrées à une date donnée (date driven) ou choisir une date de livraison brute pour un lot de fonctionnalités (feature driven). Un planning de release est constitué de jalon qui représente le périmètre du projet à un moment donné.

Le but du planning release est d'avoir assez d'informations pour décider si le projet produira assez de ROI (Retour sur investissements) pour au moins le payer (et gagner de l'argent). Il permet de définir les fonctions que nous devrons développer en priorités (on n'oublie pas la règle des 80/20). Il indique au client, à l'équipe, à la communauté les différentes dates de livraisons.

C'est durant l'étape de définition, du planning release que l'on choisira la durée d'une itération. On parle souvent de sprint de 30 jours en Scrum, ce choix est assez arbitraire et ne se justifie pas, si ce n'est pour indiquer que cela doit être un maximum. Le choix de la longueur d'une itération doit être sélectionnée par rapport au planning de release global et les fonctionnalités du projet. Si le projet est constitué de nombreuses petites fonctionnalités sur un laps de temps court (3 à 4 mois de projet), il est peut-être plus intéressant de faire des itérations de 15 jours pour les faire tester par le client ou les bêta-testeur.

Un planning release est constitué de plusieurs itérations (ou sprint), qui elles-mêmes incluent les fonctionnalités du projet (backlog) au sens fonctionnel.

Planning des itérations

A la différence d'un planning de release qui est une vue de haut niveau du projet, le planning des itérations est une vue à court terme avec plus de détail. Un planning des itérations détail ce qui est nécessaire pour réaliser dans sa globalité une fonctionnalité (un cas d'utilisation).

Un planning d'itérations est constitué de cas d'utilisation (ou story) avec les tâches associées.

Agile Tour 2008

SecureOne — Fri, 26 Sep 2008 17:30:00 +0200

Agile Tour, une série d'événements gratuite répartie sur plusieurs villes européennes pendant tout le mois d'octobre 2008.

L'édition 2008 est organisée sur 7 conférences réparties en France et en Suisse :

   * 01 octobre : Besançon (Le programme)
   * 03 octobre : Mulhouse (Le programme)
   * 06 octobre : Genève (Le programme)
   * 09 octobre : Grenoble (Le programme)
   * 14 octobre : Lille
   * 16 octobre : Toulouse (Le programme)
   * 23 octobre : Valence (Le programme)

C'est le moment idéal pour rencontrer des professionnels de l'agilité, de voir des exemples de mise en place d'Agile en entreprises. Par exemple, Yahoo sera présent à Valence et Grenoble.

La conférence de Grenoble est composée de plus de 12 conférences.

Je ne peux que vous conseiller d'y aller faire un tour, pour ma par je serais le 9 octobre à Grenoble.

Principe 10 - Pas de place pour les Snipers !

SecureOne — Sun, 07 Sep 2008 17:39:00 +0200

Nous voici arrivés à la fin de nos dix principes Agile. Nous finissions sur un des principes que je trouve majeurs pour qui a mis Agile en oeuvre. Celui de la gestion de l’équipe projet.

Le développement Agile repose sur une étroite coopération et collaboration de tous les membres de l’équipe et des intervenants.

C’est une différence et même une divergence par rapport aux méthodes traditionnelles de gestion de projet, ou le chef de projet est celui qui décide et gouverne son projet et souvent de manière unilatérale. Le reste de l’équipe étant essentiellement des exécutants.

Dans un projet Agile, l’ensemble du projet est discuté et partagé avec l’équipe. Le responsable du projet reste néanmoins celui qui prend la décision finale après concertation avec son équipe.

Les principes du développement comprennent le respect des exigences et une documentation légère, et en reconnaissant que le changement est normal et acceptable dans le développement de logiciels.

Cette étroite collaboration rend particulièrement important de clarifier les exigences justes à temps et de garder tous les membres de l’équipe (y compris le produit propriétaire) « sur la même ligne » durant l’ensemble du développement.

Vous ne pouvez certainement pas aller très loin avec des spécifications importantes qui sont réalisées à l’avance et sans une étroite collaboration avec l’équipe. Cas que l’on retrouve trop souvent dans les projets en cascade. Il ne faut pas ensuite s’étonner que le projet ne ressemble pas aux spécifications et encore au réel besoin du client.

Mais contrairement à un projet en méthode traditionnelle, en développement Agile l’équipe travaille vers un objectif commun, créer un meilleur travail d’équipe, favoriser l’esprit d’équipe, et être plus fortes. À la finalité, satisfaire le besoin client.

Si vous travailler avec un responsable qui pense qu’il peut prendre toutes les décisions de manière unilatérale, qu’il possède la science infuse, il est temps de s’en séparer et de changer de méthode de projet !

Dans mes billets suivants, je vous présenterais, comment faire travailler une équipe ensemble avec Scrum

Principe 9 - Les tests c'est pas pour le nuls !

SecureOne — Sat, 30 Aug 2008 15:38:00 +0200

'' En développement agile, le test est intégré dans l'ensemble du cycle de vie, des tests continuent tout au long du développement du logiciel.''

Le développement Agile ne possède pas une phase de test en tant que telle. Les développeurs sont fortement engagés dans les tests et l'écriture des tests unitaires automatiques pour valider leur code.

En complément d'être orienté vers une meilleure qualité des logiciels, c'est aussi important de mettre en œuvre le principe « Des petits développements, itératifs et des livraisons incrémentales ». Avec des tests unitaires automatisés, les tests peuvent être effectués dans le cadre de la compilation, en veillant à ce que tous les éléments fonctionnent correctement chaque fois que la compilation est produite. Cette compilation doit être réalisée régulièrement, au moins une fois par jour, pour que l'intégration soit réalisée au fur et à mesure.

Le but de ces principes est de maintenir le logiciel dans état dit :« livrable » tout au long du développement, afin qu'il puisse être expédié chaque fois que c'est approprié. Il s’avère aussi utile pour ne pas laisser le logiciel accumuler les anomalies et attendre le dernier moment pour les corriger (méthode traditionnelle de développement)

Le XP (Extreme Programming) cette méthodologie Agile va encore plus loin. XP recommande le développement piloté par les tests, l'écriture des tests avant d'écrire le logiciel.

Mais les tests ne doivent pas seulement être réalisés par les développeurs tout au long du développement. Il y a un rôle très important dans l’équipe : l’intégrateur. Comme nous le savons, tous "les développeurs ne peuvent pas tester le caramel !"

Le rôle d'un intégrateur peut changer considérablement en développement agile, dans un rôle plus proche de l'assurance de la qualité que de simples tests. Il y a des avantages considérables d’avoir un intégrateur impliqué dès le début.

Cette situation est amplifiée encore par « Des besoins macro, léger et visuel » en développement agile, l'accent est mis sur la conversation et la collaboration des exigences par rapport à une approche traditionnelle d’écriture lourde des spécifications et des documentations.

Bien que les exigences peuvent être précisées en détail dans le développement agile (tant qu'ils se font juste à temps et pas tout à l'avance), il est tout à fait possible que cela puisse se traduire par une certaine ambigüité et /ou dans certains cas, les membres de l'équipe n’ont pas la même compréhension des exigences.

Alors qu'est-ce que cela signifie pour un intégrateur agile ? Une préoccupation commune des intégrateurs en particulier pour ceux qui changent régulièrement d’environnement projet - est qu'ils ne savent pas précisément ce qu'ils doivent faire comme test. Ils n’ont pas une spécification détaillée pour effectuer le test, alors comment peuvent-ils tester?

Même dans un environnement plus traditionnel de développement, j'ai toujours fait valoir que les testeurs ont besoin de spécification, et pourtant le produit pourrait encore être de mauvaise qualité, peut-être parce que les exigences ont été mal spécifiées ou parce qu'elle a été clairement mal écrite. Une spécification n'est pas nécessairement le bon produit !

En développement agile, il y a une conviction que, parfois - peut-être même souvent - ces choses ne sont réellement évidentes que quand on peut voir le logiciel fonctionner en livrant des petites livraisons incrémentales et progressives et en mesurant le progrès sur un logiciel fonctionnel, le test décisif est de voir le logiciel et alors seulement vous pouvez juger si oui ou non, il est de bonne qualité.

Les tests Agile induisent donc à plus de jugement de la part de l’intégrateur, d’une expertise de ce qui est bon et ce qui ne l'est pas, la capacité d'être plus flexible et avoir la connaissance et la vision de ce que doit être un bon logiciel. Ce n'est pas certainement une simple affaire de suivi de scénario de test, en s'assurant que le logiciel fait ce qui est écrit dans les spécifications.

C’est pour ces raisons, que les tests en Agile nécessitent une très expérience et une expertise !

Principe 8 : La règle du 80/20

SecureOne — Thu, 14 Aug 2008 23:46:00 +0200

La loi de Pareto est plus communément connue sous la règle du 80/20. Cette distribution des probabilités suit une loi des puissances. L’idée qui est régie par cette loi est que la majorité de vos résultats peuvent être réalisés avec un minimum d’effort.

Cette loi est un outil fondamental en gestion de la qualité. Elle est aussi utilisée en réassurance. Cette loi dit que « généralement » 80 % de résultat peuvent provenir de seulement 20% d’efforts !

Par exemple : En fiscalité : 20% des citoyens imposables génèrent 80% de la trésorerie publique, En sport: 20 % de l'effort à l'entraînement permet d'atteindre 80% de la performance, en service après-vente: 80% des réclamations proviennent de 20% des clients.

Cette loi est bien connue des managers : En préparant leurs ambitions, les managers expérimentés savent que seuls quelques éléments majeurs sont décisifs. Le reste sera traité par la même occasion en tant que parties de ces éléments — Juran, 1964

Ainsi, un bon directeur de produits est une personne qui peut voir (à l'avance sans l’avantage du travail déjà accompli) les 20% sur lesquelles se concentrer. En développement Agile, nous devons essayer d'appliquer la règle des 80/20, qui cherche à se concentrer sur l'importance des 20% qui engendre la majorité des résultats.

Si la qualité de votre application n’est pas la première exigence, si vous avez le contrôle sur son périmètre et si la mise à disposition de votre application est votre première priorité, pourquoi ne pas fournir 80 % de votre produit en seulement 20% du temps. En fait, dans ce scénario particulier, vous pourriez vous demander pourquoi faire les derniers 20% restant.

Maintenant, cela ne signifie pas que votre produit doit être fondamentalement bugé, laisser une mauvaise expérience à l'utilisateur, etc. Cela signifie simplement que le développement de certaines fonctionnalités, ou la richesse de certaines caractéristiques, va plus loin et a une diminution de rendement pourrait ne servir à rien.

Cette affirmation n'est elle pas en conflit avec le précédent billet: "terminer" signifie "TERMINER!". Pas réellement, parce qu’à l'intérieur de chaque itération ou Sprint, ce que vous décidez ou ne décidez pas de « de développer » peut ne pas être réalisé à 100%.

Pour exemple, sur la règle des 80/20, Microsoft lui-même a montré que l'utilisateur moyen de Word utilise seulement 8% des fonctionnalités. 8% Et nous pouvons penser que moins de 80% d'entre eux n’utilisent même pas 8%. Si Microsoft n’avait développé que les 8% importante de Word, pourraient ils encore avoir pris la même part de marché? Peut-être, peut-être pas, malheureusement nous ne le saurons jamais.

Il est également utile d'examiner l'impact sur l'expérience de l'utilisateur. Google nous a montré que les utilisateurs préfèrent souvent des applications qui font au plus près du besoin. Seulement ce que vous voulez. Et pas plus. Le reste est sans doute encombrant et en fait, interfère avec l'expérience de l'utilisateur et apporte seulement un intérêt réduit pour un nombre limité d'utilisateurs.

Nous pouvons donc inverser le 80/20, pour dire que seulement 20% des fonctions d’une application seront nécessaires à 80% des utilisateurs. Dans un développement agile, lorsque vous développez un nouveau produit, concentrez-vous sur ce que votre logiciel doit faire avant tous. Pourriez-vous prendre le marché avec toutes les caractéristiques importantes, ou seulement avec des fonctions qui sont moins riches fonctionnellement, en seulement peu de temps ?

En dehors de la réduction des coûts, réduction des risques et des prestations plus élevées en étant plus rapide sur le marché, vous pouvez également vous appuyer sur la première version du produit basé sur le retour du client réel.

Donc, tout cela est réellement du bon sens (cf. MMM notre DGA).

A la finalité, ce n'est pas aussi simple, car il faut être un très bon visionnaire pour découvrir les 20% qui fourniront 80% des résultats. Par expérience et dans de très nombreux cas, les responsables n'ont pas cette vision.

Principe 7 - Terminer une fonction avant de commencer une autre

SecureOne — Thu, 14 Aug 2008 23:22:00 +0200

En développement agile, "terminer" doit réellement signifier "TERMINER!".

Une caractéristique développée dans une itération (Sprint dans Scrum) doit être terminée à 100% à la fin du Sprint.

Trop souvent dans le développement de logiciels, "terminé" ne signifie pas vraiment "TERMINE !". Cela signifie non tester. Cela ne signifie pas forcément que l’aspect graphique est terminé. La plupart du temps, il n'a pas encore été validé par le directeur de produit et encore moins par le client. Cela signifie simplement développer.

Dans une situation idéale, chaque itération ou Sprint devrait conduire à une version du produit. Certes c'est le cas pour la BAU (business as usual) les changements apportés aux produits existants. Dans les projets ou il n'est pas possible de faire une release après chaque Sprint, réaliser chaque caractéristique à la suite, permet d’obtenir une vue très précise des progrès et dans quelle mesure elles correspondent à la cible du projet ou au contraire s’en éloigne.

En développement agile, il faut s’assurer que chaque caractéristique est pleinement développée, testée, l’aspect graphique stabilisé, et accepté par le directeur de produit et le client avant de la considérer comme "TERMINÉE !". S'il y a le moindre doute sur ce qui devrait ou ne devait pas être achevé dans le Sprint pour chaque fonction, "TERMINER!" devrait signifier être livrées.

Une caractéristique peut nécessiter d'autres caractéristiques en voie d'achèvement avant que le produit puisse être réellement expédié. Mais une caractéristique propre peut mériter d’être livrée. Donc, si vous êtes n’est pas sur qu’une caractéristique ce "suffit", posez-vous une simple question: "Est-ce que cette fonctionnalité est prête à être livrée ? ".

Il est également important de bien compléter chaque caractéristique avant de passer à la prochaine ...

Bien sûr, plusieurs caractéristiques peuvent être développées en parallèle dans une équipe. Le travail de chaque développeur est de ne pas passer à une nouvelle fonction jusqu'à ce que la dernière soit livrée. Ceci est important pour s’assurer que l'ensemble des produits est dans un état "prêt à être livré" à la fin du Sprint, et non dans un état où plusieurs caractéristiques sont à 90% ou non testé. Ce qui est une habitude dans les projets de développement traditionnels.

En développement agile, "terminer" signifie "TERMINER!".

La réunion quotidienne - Daily Scrum

SecureOne — Mon, 28 Jul 2008 18:48:00 +0200

La direction est activement impliquée dans Scrum sur une base quotidienne. À la réunion journalière (Daily Scrum), le ScrumMaster écoute attentivement ce que chaque membre de l'équipe annonce avoir réalisé comme activité. Ces informations sont comparées à ce que la direction de projet s'attend à voir réaliser. Par exemple, si quelqu'un a travaillé sur une petite tâche durant trois jours, il est probable que ce membre de l'équipe a besoin d'aide. En outre, la direction fait un point sur l'avancée de l'équipe : ils sont coincés, ils pataugent, sont-ils des progrès ? La direction peut intervenir et résoudre les problèmes si cela est nécessaire.

Le ScrumMaster est également responsable de maintenir l'équipe de projet au plus haut niveau possible de productivité. Lorsque des décisions sont nécessaires dans la réunion quotidienne , prenez-les même si vous avez des informations incomplètes. Il est généralement préférable de procéder avec des informations partielles. Si les informations ne sont pas disponibles, créer un item de backlog (une tâche) pour prendre la décision.

Lorsque des blocages sont signalés au cours des réunions quotidiennes - et l'équipe ne peut pas résoudre elle-même les blocages - le ScrumMaster est responsable de leur résolution ou il escalade le blocage dans les plus brefs délais vers le directeur de produit.

Principe 6 : Concentrez-vous sur la livraison fréquente des fonctionnalités

SecureOne — Mon, 14 Jul 2008 23:58:00 +0200

Le développement Agile c’est la fréquence des livraisons des produits.

Comme nous avons pu le constater dans le principe n°5, les méthodes de gestion de projet traditionnelles réalisent la livraison une fois l’ensemble du produit terminé. On se demande pourquoi ne pas vous vouloir en tirer certains avantages plus tôt? Pourquoi ne voulez pas entendre le retour de l’utilisateur avant de tout construire ? Pourquoi ne pas vouloir regarder ce qui fonctionne et ce qui ne fonctionne pas, avant de tout construire ?

Ce n'est réellement possible qu’en raison de certains des principes importants de développement agile tels que l'approche itérative, des fonctionnalités simples et réalisées justes à temps, la conduite par itération, les tests intégrés dans le cycle de vie, et ainsi de suite.

Garder en vue la livraison, la constance des livraisons des différentes itérations permet de réduire les risques sur les projets et de conserver l’équipe dans une dynamique. On remarque dans tous les nouveaux projets, une « euphorie », une dynamique de groupe au lancement du projet. Cette dynamique s’atténue rapidement plus le projet avance. Agile permet de conserver cette énergie, par cette constance de la livraison.

Ainsi, la fréquence est fréquente ?

Scrum propose des développements par itération (sprint) sur un maximum de 30 jours. À partir de cette période, il doit être possible de réaliser une démonstration de l’itération. Cette démonstration doit permettre de prendre une décision sur cette itération telle que changer certaines fonctionnalités, l’intégrer dans l’architecture globale, la livrer, etc. La réactivité est un important avantage concurrentiel.

Ce qui est assez important, c'est d'en faire une décision positive, de décider ce qui est approprié pour vous. Et puis de s'en tenir, si vous le pouvez conserver un cycle régulier. Un cycle régulier vous permet de planifier, de construire et parce que des travaux de développement agile à un calendrier fixe, la planification est assurée.

Un cycle régulier vous permet également d'apprendre plus efficacement. Votre estimation pourrait être la bonne, elle pourrait être aussi la mauvaise. Si vous estimez des caractéristiques à un niveau granulaire (idéalement moins de 1 jour) et si vous réalisez un suivi dans le temps, vous commencez à connaitre votre taux normal de réalisation. Et quand vous comprenez cela, vous serez surpris de voir à quel point vous réussissez vos prévisions.

Ainsi, en développement agile on se concentre souvent sur la livraison des produits. Et peut-être encore plus important, se concentrer sur des livraisons de produits.

Lean Software Development

SecureOne — Mon, 14 Jul 2008 23:38:00 +0200

J’ai évoqué plusieurs fois la méthode Lean Software Development, j’avais envie de vous la présenter cette technique pour mieux expliquer son but. Mais avant d’aller plus loin, commençons par les origines de la lean Thinging, cela nous permettra de comprendre la cible attendue par cette technique.

Dans les années 40, une petite société nommée Toyota avait l'intention de fabriquer des voitures au Japon. Mais il avait un problème. Puisque les gens n'avaient pas d'argent, les voitures devaient être bon marché. La production de masse était le moyen le moins cher de faire des voitures, mais la production de masse destinée à fabriquer des milliers de voitures du même type, et le marché japonais n'était tout simplement pas compatible, le marché était trop petit pour toutes ses voitures. Donc la question a été, comment Toyota pourrait faire des voitures en petites quantités tout en restant bon marché ?

De ce dilemme, le Toyota Production System a émergé pour former la base d'une toute nouvelle façon de penser la fabrication, la logistique, et finalement le développement produit. Le cerveau derrière cette nouvelle façon de penser était Taiichi Ohno, connu comme le père du Toyota Production System. Au cœur de la réflexion d’Ohno, il y a le principe fondamental de la lean thinging: éliminer les déchets.

Voir les déchets :

Apprendre à voir des déchets est la première étape dans le développement de la Lean Thinking. Si quelque chose n’apporte pas directement une valeur ajoutée telle qu'elle est perçue par le client, il constitue un déchet.

Shigeo Shingo, l'un des cerveaux de la Toyota Production System, a identifié sept types de déchets de fabrication. Sa liste a permis à de nombreux chef de fabrication de trouver les déchets où ils n’auraient jamais pensé à regarder. Pour faciliter le travail des responsables de projet de développement logiciels dans leur quête de trouver les déchets, la Lean Software Development à traduit les sept déchets de l'industrie manufacturière dans sept des déchets du développement qui sont :

Travail partiellement terminé
Processus complémentaire sans valeur ajoutée
Caractéristiques supplémentaires sans valeur pour le produit
Permutation de tâches
Attente (entre deux tâches par exemple)
Le mouvement (Aller quelque part pour rencontrer quelqu'un ou aller chercher quelque chose pour obtenir des informations)
Les défauts, imperfection.

En complément de l’étude des déchets, il existe 6 autres grands domaines :

Amplification de l'apprentissage par rétroaction. La meilleure approche pour améliorer un environnement de développement logiciel est d'amplifier l'apprentissage. L'accumulation de défauts doit être empêchée en réalisant des tests aussitôt que le code est écrit. Le processus d'étude est accéléré par l'utilisation de cycles itératifs courts.

Décider le plus tard possible : L'idée est d'attendre ce que les auteurs de ce terme définissent comme "le dernier moment responsable" pour prendre une décision. C'est le moment où, si l'équipe ne prend pas de décision, la décision sera prise pour eux (ne rien faire est un choix). Les avantages en sont d’éviter ou de retarder les coûts du changement.

Livrer le plus vite possible : C'est la base du développement itératif. Le pourcentage des exigences change des exigences originales de manières non linéairement et ceci plus le temps avance. Typiquement dans les projets de 9-12 mois il y a un changement de 25% (grossièrement) des exigences initiales. Cependant, le cout des exigences augmente par mois de seulement 1 à 2 %.

Responsabiliser l'équipe : la qualité de l’équipe de développement est le facteur le plus important dans la réussite des projets. Afin d'amener les gens à assumer leur responsabilité, qu’ils soient motivés, et se voient comme une équipe, ils doivent être responsables des résultats et autorisés à en faire une réalité.

Construire à l'intégrité - à la fois l'intégrité conceptuelle, et la perception de l'intégrité. Les auteurs font la distinction entre perceptions de l’intégrité et l'intégrité conceptuelle. La perception de l'intégrité est l'expérience du client avec votre logiciel. L'intégrité conceptuelle est de savoir comment bien construire de concert l'architecture et les composants du système pour aboutir à la perception d'intégrité. De toute évidence, les tests unitaires et d'intégration sont une partie importante de l'intégrité.

Avoir une vision d’ensemble : il faut regarder les processus d'abord dans une vue d'ensemble ou de manière holistique, car si vous ne le faites pas, vous pouvez vous retrouver avec des sous-systèmes optimisés ou fragmentés et des solutions qui ne tiennent pas compte de l'ensemble du processus. La résolution habituelle à la résolution des problèmes est de les subdiviser en éléments constitutifs et d'optimiser chaque pièce. C'est suboptimisation, conduite à la «tragédie des biens communs."

Le secret derrière Lean cela réside dans l'élimination des goulets d'étranglement dans les processus de développement sous-jacents et le renforcement de la rétroaction du cycle.

Un rapport menée par McKinsey baptisé ""Applying Lean To Application Development And Maintenance,», explique que cette technique peut conduire à des gains de productivité de 20% et 40%, et que la qualité et la rapidité d'exécution peuvent s"améliorer sensiblement en l'espace de quelques mois. (Boost productivity with lean software development)

Évidemment cette article donne une vu très générale de cette méthode, si vous souhaitez approfondir votre connaissance de ce sujet, je vous recommande fortement l'ouvrage : Lean Software Development: An Agile Toolkit qui est l'ouvrage de référence .

Principe 5 : Des petits développements, itératifs et des livraisons incrémentales

SecureOne — Sun, 06 Jul 2008 19:54:00 +0200

Les projets à base de développement Agile sont livrés en plusieurs petits morceaux, des petites livraisons, des livraisons incrémentales et itératives.

Dans les projets de développement traditionnel, le cycle de vie (simplifié) se compose de l’analyse, le développement et les tests – tout d'abord, toutes les exigences sont recueillies pour l’ensemble du produit, ensuite les éléments du logiciel sont développés, une fois terminé, le produit est entièrement évalué et tester avant sa livraison.

En développement Agile, le cycle de vie et d’analyser, développer, tester, analyser, développer, tester, et ainsi de suite. Réaliser chaque étape pour chaque fonction, une fonction à la fois.

Les avantages de cette approche itérative du développement sont :

Réduction des risques: Permet d’avoir une visibilité de ce qui est achevé à un moment précis du projet.
Augmentation de la valeur : livrer rapidement à des avantages, être en mesure de livrer le produit quand il est considéré comme assez bon, plutôt que de devoir attendre tous les éléments destinés à être livrés,
Plus de souplesse / agilité: on peut choisir de changer de direction ou d'adapter les prochaines itérations sur la base ce qui a été développé et sur l’utilisation du logiciel.
Une meilleure gestion des coûts: si, comme tous les trop nombreux projets de développement de logiciels, vous courez après le budget, une certaine économie peut-être apportée par la méthode Agile.

Pour cette approche et pour être pratique, chaque fonction/caractéristique doit être pleinement développé, dans la mesure où elle est doit être livré, avant de passer à la suite.

Une autre pratique consiste à faire en sorte que chaque fonction/caractéristique soit développée par ordre de priorité, pas nécessairement dans un ordre logique par rapport au logiciel. Plutôt selon des critères de priorités client et de fonctions de haut niveau indispensable au logiciel. Dans le cas contraire, vous pourriez manquer de temp, pour avoir passé du temps sur des fonctions de moindres importances.

Construire les fonctionnalités du logiciel "importante, mais peu technique" est également souhaitable pour la même raison.

Ce n'est que lorsque vous avez terminé tout ce que vous devait avoir comme fonctions, que vous pouvez passer à ce que vous devriez avoir comme fonctions, et ensuite passer à ce que vous pourriez avoir comme fonctions. Sinon, vous pourriez obtenir une situation où vos premières caractéristiques sont fonctionnellement très riches, alors que du côté logiciel les caractéristiques sont de moins en moins sophistiquées avec le temps qui passe.

Essayez de garder votre produit backlog (terme lié à la méthode Scrum) ou votre liste de fonctionnalités pour qu’elle s’exprime en termes de cas d'utilisation, de scénarios utilisateur, ou caractéristiques - pas en tâches techniques.

Idéalement, chaque point de la liste doit toujours être quelque chose qui a une valeur pour l'utilisateur, et toujours vue comme un livrable plutôt qu’une activité pour pouvoir « taper dans les pneus » et de juger de la complétude, la qualité et prêt à livré.

Ce sont les caractéristiques importantes du développement itératif. Ils sont essentiels si vous prévoyez de délivrer dans les délais fixés - un des 10 principes clés du développement Agile.

Principe 4 : Des besoins macro, léger et visuel

SecureOne — Sat, 05 Jul 2008 18:04:00 +0200

La synthèse de cet article : Une équipe de développement identifie les exigences à un niveau élevé et au coup par coup, juste à temps pour chaque élément à développer. Avec une vision globale de l’objectif du projet.

Le développement Agile est idéalement visuel et doit être à la limite de l’acceptable, c'est-à-dire le strict minimum nécessaire pour permettre le développement et l'expérimentation pour procéder avec une efficacité raisonnable. La raison d'être est de minimiser le temps consacré à tout ce qui ne fait pas partie du produit final.

Le développement Agile peut-être confondu à tort par certains comme dépouillé de processus ou de règles. En d'autres termes que l’on réalise les choses au fur et à mesure . Cette approche n'est pas réellement Agile mais plutôt fragile !

Bien que le développement Agile est beaucoup plus souple que les méthodes de développement traditionnelles, le développement Agile n’est pas néanmoins exempt de rigueur et il est basé sur l'approche structurée (Lean Manufacturing) initiée par le groupe Toyota (leader de la productivité) - Remarque: Le travail de Toyota à été permis de créer la méthode "Lean Software Development" qui complète les méthodes Agile pour apporter la qualité tout au long du cycle de vie du projet. Je vous présenterais bientôt un billet sur cette méthode.

Je crois personnellement que les équipes de développement Agile peuvent créer de meilleurs produits s'ils ont une idée assez claire de l'ensemble des besoins avant de partir sur le développement, afin que les décisions de conception qui peuvent s’avérer erronées ne conduisent pas à l'équipe dans des impasses. Elle permet en complément des investissements plus raisonnables pour financer les projets.

Cependant, toutes les exigences identifiées au début doivent être vues à un niveau élevé et dans un format visuel, par exemple, comme un story-board de l'interface utilisateur. À ce stade, les exigences doivent être assez bien comprises pour déterminer les grandes lignes du produit et produire une première prévision du budget et rien de plus.

Idéalement, les équipes de développement Agile identifient les exigences à haut niveau dans des ateliers. Ils travaillent ensemble dans une grande collaboration de manière que tous les membres de l'équipe puissent comprendre les exigences. Il n'est pas nécessairement d’avoir des personnes avec des compétences particulières, comme un architecte comme dans des projets plus traditionnels, afin de recueillir les exigences indépendamment les unes des autres et de les formaliser par écrit. C'est une activité conjointe de l'équipe qui permet à chacun de contribuer et de comprendre ce qui est nécessaire.

XP (eXtreme Programming) applique des « pauses » aux exigences sous la forme de petites parties appelées « User stories ». Ils sont fondamentalement similaires au cas d’utilisation (Use Case), mais sont plus légers et plus simples par leur nature.

Une équipe de développement Agile visualise les exigences sur un tableau blanc et crée des sessions de story-board (séquences de captures d'écran, des visuels, des croquis, des wireframes ou des diagrammes de séquence) pour montrer à peu près à quoi ressembleront la solution et l’interaction de l'utilisateur dans la cinématique de la solution. Il n'existe pas de long cahier d’exigence ou des spécifications à moins qu'il y ait des zones de complexité qui le justifient réellement. Sinon, les story-boards sont tout annotés et seulement lorsque cela est nécessaire.

Une approche commune entre les équipes de développement Agile est de représenter chacune des exigences, cas d'utilisation ou de story board sur une carte et utiliser une T-card (une représentation visuelle très efficace de plusieurs story board) pour permettre aux scénarios d’être facilement déplacés pour permettre d’ajuster les priorités. Exemple de T-card :

Les exigences sont ventilées en très petits morceaux afin de parvenir à ce résultat; en fait, c’est la force des cartes de pouvoir réaliser cette ventilation en très petits morceaux. L'avantage par rapport à une documentation classique, c’est que cette approche est extrêmement visuelle et tactile, vous pouvez être debout autour du système de T-card et le tableau blanc pour discuter de l’avancé, des priorités et des questions.

La technique de la carte et du T-card est très utile quand le contexte métier ou la technologie n’est pas totalement maitrisée par l’équipe projet. Toutefois, quand l’équipe de développement à une expérience importante du métier et peut rapidement identifier le périmètre et les cas d’utilisation, il est préférable d’utiliser un tableau blanc et un appareil photo pour capturer les cas d’utilisation et les diagrammes de séquence. Les cartes restent néanmoins utiles pour se rappeler des différentes exigences nécessaires du projet et pour l’évaluation de la charge.

les besoins évoluent, mais les délais sont fixes. Au cas où il serait nécessaire de changer les priorités ou d'ajouter de nouvelles exigences dans le projet, le responsable du projet doit retirer une charge comparable au montant de la nouvelle exigence avant de pouvoir placer la nouvelle carte dans le projet.

Les équipes traditionnelles de projet qui ne contrôlent pas le changement peuvent terminer le projet hors du champ initial avec le redoutable glissement de planning, une des raisons les plus communes pour quoi les projets de développement échouent.

Les équipes Agile, en revanche, acceptent le changement, en fait, ils s'attendent. Mais elles gèrent le changement en fixant les délais et la négociation.

Les cartes peuvent bien sûr être complémentées par une documentation appropriée (souvent nécessaire pour le client), mais toujours dans un principe de développement agile, il faut toujours documenter le strict minimum d'informations qui permettra à une fonction d'être développées et toujours ventilées en très petites unités.

Pour exemple, pour mes projets nous faisons avec l’équipe de développement des cas d’utilisation (CU), des diagrammes de séquence (DS), les visuels (UHM) un par un sur un tableau blanc, nous terminons une série en prenant des photos du tableau. Ensuite on transfère au client un par un les CU, DS et interface IHM. Une fois stabilisé, nous pouvons écrire le document (par exemple une spécification fonctionnelle), mais jamais avant que le développement du CU ne soit réalisé.

Utiliser Scrum est une bonne pratique pour la gestion des projets, les exigences (ou les fonctionnalités ou les cas d’utilisation, quelle que soit le mot que vous préférez utiliser) sont ventilées en tâches qui ne dépassent jamais plus de 16 heures (c'est-à-dire 2 jours de travail) et de préférence pas plus de 8 heures, de sorte que les progrès peuvent être mesurés objectivement sur une base quotidienne.

Une dernière chose et qui je pense devrait être certainement adopté de PRINCE2 (la méthodologie de gestion de projet pas agile du tout !), est l'idée de s'assurer que tous les besoins sont des éléments à fournir plutôt que des activités ou des tâches. Vous pouvez voir un produit et donner un "coup de pied dans les pneus", afin de juger de sa qualité et de son exhaustivité. Avec une tâche vous ne pouvez pas le faire.

Principe n°3 - Les besoins évoluent, mais les délais sont fixes.

SecureOne — Tue, 24 Jun 2008 06:11:00 +0200

Ceci est un des contrastes frappant avec un projet de développement traditionnel, où un des premiers objectifs est de capturer toutes les exigences connues et leur champ d'application et que toute modification doit être suivie d'une conduite du changement.

Traditionnellement, les utilisateurs sont éduqués qu'il est beaucoup plus coûteux de changer ou d'ajouter des exigences pendant ou après la phase de développement du logiciel. Certaines sociétés citent quelques statistiques impressionnantes destinées à effrayer les utilisateurs. Il devient donc impératif d'inclure tout ce qu'ils peuvent penser - en fait tout ce qu'ils ont toujours rêvé !

Et qui plus est, il est important de le faire lors de la première version du logiciel, parce que nous savons tous que la phase 2 est toujours difficile à obtenir, une fois approuvée 80% des dépenses ont été réalisés de la phase 1.

Ironiquement, les utilisateurs utilisent seulement une infime partie de tout logiciel, plus ou moins 20%. Mais de nombreux projets commencent leur vie avec une portée pléthorique. En partie, parce que personne ne sait réellement qu'elles seront les 20% du produit qui seront réellement utilisés par l'usager. De même, même si les exigences sont soigneusement analysées et traitées en priorité, il est impossible de penser à tout, les choses changent, et les choses sont comprises différemment par des personnes différentes.

Le développement Agile travaille sur un principe complètement différent. Le développement Agile fonctionne sur le principe que les besoins apparaissent et évoluent. Quelques que soient les analyses et conceptions que vous faites, ce sera toujours le cas parce que vous ne pouvez pas vraiment être sûr de vous jusqu'à ce que vous utilisez le logiciel. Et le temps que vous avez passé en phase d'analyse des besoins et de conception, les conditions extérieures ont peut-être changé.

Donc, si vous pensez que personne ne peut réellement imaginer ce que sera la solution finale en début de projet - il est intrinsèquement difficile, voire pratiquement impossible, de construire la bonne solution en utilisant une approche traditionnelle de développement.

Les méthodes de projet traditionnelles combattent le changement, avec des processus de contrôle du changement visant à minimiser et à résister au changement dans la mesure du possible. En revanche, les projets de développement Agile acceptent le changement, en fait, ils l’attendent et l'évaluent. Parce que la seule chose qui est certaine dans une vie, c'est le changement.

Il existe différents mécanismes dans le développement Agile pour gérer cette réalité. Dans les projets de développement Agile, les besoins sont autorisés à évoluer, mais le calendrier est fixe. Donc, pour inclure un nouveau besoin, ou pour modifier une exigence, l'utilisateur ou le directeur de produit doit retirer du projet une charge de travail comparable afin de tenir compte de ce changement.

Ainsi, l'équipe peut continuer à se concentrer sur les délais, et le produit permet d'évoluer dans la bonne direction. Toutefois, il faut aussi présupposer qu'il y a suffisamment de fonctions optionnelles prévues dans le projet pour permettre ces changements, cela doit se faire sans compromettre fondamentalement le produit final.

Mais qu'est ce que l'entreprise pour attendre de ses équipes de développement ? Délivrer le logiciel dans les délais et le budget prévus dans le contrat, et bien sûr avec une qualité acceptable. Tous les professionnels du développement sont bien conscients que vous ne pouvez pas de manière réaliste résoudre tous ces facteurs et espérer répondre aux attentes. Quelque chose doit être variable pour la réussite du projet. En développement Agile, il existe toujours un champ d'application (ou des caractéristiques du produit) qui est variable, le coût et le calendrier ne doivent pas l'être.

Bien que la portée d'un projet de développement Agile est variable, il est reconnu que seule une fraction d'un produit est réellement utilisée par ses utilisateurs et donc une partie des fonctionnalités d'un produit n'est pas vraiment indispensable. Pour pratiquer cette philosophie de travail, il est impératif de commencer le développement par le noyau, et par la suite avec les cas d'utilisation qui ont la priorité la plus élevée, en s'assurant qu'ils sont livrés dans les temps.

Dans cette méthode, nous favorisons le CRI (Conception - réalisation - Intégration) par itérations. Chaque itération terminée, peut-être livrée pour que le client final puisse valider le contenu de l'itération. Cette méthode permet rapidement d’avoir un état des lieux de la charge consommée et celle restant pour satisfaire au besoin.

Principe n°2 - L'équipe Agile doit être responsabilisée

SecureOne — Fri, 20 Jun 2008 23:09:00 +0200

Une équipe de projet de développement Agile doit inclure tous les membres de l'équipe qui doivent prendre des décisions, et les rendre dans les temps.

La participation active des utilisateurs est un des principes clés. L'utilisateur ou le représentant de l'entreprise doit être étroitement associé sur une base quotidienne.

L'équipe de projet doit être habilitée à prendre des décisions afin de s'assurer qu'il est de leur responsabilité de livrer le produit et qu'ils en ont la propriété. Toute interférence avec l'équipe du projet est perturbatrice et réduit leur motivation à livrer.

L'équipe doit travailler ensemble à établir et préciser clairement les exigences, définir les priorités, être d'accord avec les tâches nécessaires pour fournir les besoins, et estimer les charges.

Il peut sembler opportun de se passer d'un niveau de l'équipe au début du projet. Il est tentant d'avoir seulement un sous-ensemble de l'équipe pour commencer (genre le directeur de produit et l'architecte) , car cela est beaucoup plus efficace.

Toutefois, il s'agit d'un principe-clé pour moi ! Faire participer l'ensemble de l'équipe dès le début du projet. Cette méthode assure la participation et l'engagement de toute l'équipe de projet dès le départ, quelque chose qui paie par la suite.

Lorsqu’un défi se pose tout au long du projet, l'équipe se sent un réel sentiment d'appartenance. Si cela peut sembler couteux. Il faut y penser dès la négociation avec le client et lui faire comprendre l'importance.

Un projet c'est avant tous des hommes avant même les méthodes, une équipe soudée est souvent plus importante qu'une méthode de projet, car elle se sent impliquée.

Principe n°1 - La participation des utilisateurs de manière active est impérative

SecureOne — Fri, 20 Jun 2008 12:02:00 +0200

Dans la suite de mon billet sur "10 principes clés pour le développement Agile". voici le premier principe. Bonne lecture !

Principe Agile 1: La participation active des usagers est un impératif

Le premier principe est la participation active des usagers dans le développement agile.

Il n'est pas toujours possible que les usagers soient directement impliqués dans les projets de développement, en particulier si le projet de développement Agile est de créer un produit où les utilisateurs seront des clients externes ou des consommateurs.

Dans ce cas, il est impératif d'avoir un sénior qui a une très bonne connaissance du besoin métier et qui agit comme le représentant des utilisateurs.

Vous n'êtes pas convaincu ? Voici 16 raisons :

Les exigences sont clairement communiquées et comprises (à un niveau macroscopique) dès le début du projet.

Les exigences sont positionnées en priorités selon les besoins de l'utilisateur et du marché.

Les exigences peuvent être clarifiées sur une base quotidienne avec l'ensemble de l'équipe de projet, plutôt que de recourir à de longs documents qui sont difficiles à lire ou qui seront mal compris.

Les nouveaux besoins peuvent être pris en compte dans le calendrier de développement de manière appropriée, en vérifiant l'impact et avec un arbitrage des décisions qui soit clairement compris par tous.

Le produit est livré.

Le produit à livrer à la fin de chaque itération, et les itérations répondent bien aux attentes des utilisateurs.

Le produit est intuitif et facile à utiliser.

L'utilisateur ou l'entreprise est considéré comme un acteur intéressé par le développement sur un plan quotidien - L'utilisateur ou l'entreprise voit l'engagement de l'équipe.

Les développeurs sont responsables, tous les jours, il partage les avancées de manières transparentes avec l'utilisateur ou l'entreprise.

Il est d'une transparence totale, car il n'y a rien à cacher.

L'utilisateur ou l'entreprise partage les responsabilités pour les questions qui se posent dans le développement, ce n'est pas une relation client-fournisseur, mais un travail d'équipe.

En temps voulu les décisions peuvent être prises, concernant les fonctions, les priorités, les questions, et en relation avec les utilisateurs ou l'entreprise.

La responsabilité est partagée, l'équipe dans son ensemble est responsable de la livraison du produit.

Les individus doivent rendre des comptes, ils doivent faire un point sur leur travail et sur eux-mêmes lors des réunions quotidiennes

Dans les moments difficiles, toute l'équipe - commerciales et techniques - travaille ensemble!

Présentation du séminaire "Extreme Productivity"

SecureOne — Tue, 17 Jun 2008 18:41:00 +0200

Pour faire rapide le schéma de principe de la méthode GTD (Getting Things Done) - proposé par Ismael Ghalimi , je ferais la suite dans la semaine...

Cette image est lien vers une image au format original.

Pour les plus impatients voici le PDF de la présentation : Exterme productivity.

Pour info : Je donnerais une formation sur les bases de la méthode d'Ismael Ghalimi avant la fin du mois. Adressez-moi un courriel si le sujet vous intéresse : yquenechdu@linagora.com

10 principes clés pour le développement Agile.

SecureOne — Sun, 15 Jun 2008 17:24:00 +0200

Après diverses discussions au sujet d'Agile au sein de LINAGORA, j'ai décidé d'écrire un petit billet pour expliquer les principes du développement Agile. Pour ce faire, je me base sur les 10 principes du développement Agile. Par la suite, je pourrais détailler chaque principe dans des billets différents.

Qu'est-ce qu’Agile ? À part une nouvelle méthode pour faire de la gestion de projet de développement ! Tout d'abord, Agile est fondamentalement différent des méthodes de projets de développements traditionnelles sur les points suivants :

Il y a diverses méthodes et standards qui adressent les divers aspects du développement logiciel, par exemple PRINCE2 pour la Gestion de projet, utilise les Cas d'utilisation/UML pour l'Analyse et la Conception, ISEB pour les tests. Bien que ceux-ci soient typiquement appliqués aux projets de développement en cascade, les éléments de ces méthodes peuvent aussi être appliqués dans une approche de développement Agile.

Il y a aussi les méthodes qui sont spécifiquement conçues autour du Développement Agile :

DSDM : est probablement la méthode originelle du développement Agile. DSDM (Dynamic systems development method) était présent avant que le terme le Développement Agile est été même inventé, il est basé sur tous les principes qui sont connus dans le développement Agile

SCRUM : est aussi une méthode de développement Agile qui se concentre notamment sur la façon de gérer les tâches au sein d'une équipe axée sur l'environnement de développement.

XP (eXtreme Programming) est la plus radicale des méthodes Agile, en se concentrant sur le processus de développement logiciel et l'analyse, le développement et les phases de test avec de nouvelles approches en vue d'apporter une différence substantielle à la qualité du produit final.

DSDM est probablement la plus complète des méthodes Agile, alors que SCRUM et XP sont plus faciles à mettre en œuvre et sont complémentaires, car elles abordent différents aspects des projets de développement et sont à la fois fondées sur les mêmes principes de développement agile.

En réalité, il n'y a pas de méthode magique pour le développement logiciel. La meilleure approche est de connaitre un tas de techniques provenant des méthodes en cascade et des méthodes de développement Agile et de choisir un mélange des meilleures techniques qui sont les plus appropriées pour n'importe quelle situation donnée. La réussite exige un très bon niveau d'expérience et de compétences.

Dans des projets de développement Agile, la gestion de projet prend une forme légèrement différente, comptant plus sur les compétences du chef de projet pour la communication, la facilitation et la coordination et en soulignant moins la planification et le contrôle. Le développement agile peut être très passionnant et excitant, bien que certains projets conviennent mieux au développement Agile plus que d'autres. La collaboration et la visibilité peuvent fournir une expérience beaucoup plus riche et plus utile pour les équipes qui développent des grands logiciels. Le développement Agile peut être beaucoup plus agréable que l'approche en cascade qui exige beaucoup plus de documentation et est moins souple par sa nature. Et quand les gens aiment leur travail, c'est incroyable ce qu'ils peuvent réaliser.

Attention : les prochains billets expliqueront un par un les 10 points clés du développement Agile.

Planning Poker la suite...

SecureOne — Thu, 05 Jun 2008 22:58:00 +0200

Lors de mon dernier billet sur le planning poker, je vous avez indiqué que je détaillerais la méthode (carte et attribution des points) pour bien mettre en œuvre cette technique. Me voila de nouveau pour clore ma présentation sur le planning poker.

Le Planning poker combine des opinions d'experts, des analogies et des échanges dans une ambiance agréable et ludique, qui permettent d'obtenir des estimations rapides avec des résultats fiables.

Les participants au planning poker inclus tous les développeurs de l'équipe. Rappelez-vous que le terme développeurs en méthode agile se réfère à tous les programmeurs, testeurs, ingénieur système, ingénieurs base de données, les architectes, concepteurs de l'interaction avec l'utilisateur, et ainsi de suite.

Sur un projet agile, qui ne dépasse pas généralement plus dix personnes. Si c'est le cas, il est généralement préférable de se séparer en deux équipes. Chaque équipe pourra alors faire une estimation de manière indépendante. Le directeur de produit participe à la planification, mais il ne fait d'estimation.

Au début de la planification, chaque participant reçoit un jeu de cartes. Chaque jeu de cartes distribué doit permettre de réaliser une estimation fiable. Chaque participant peut, par exemple, recevoir un jeu de cartes qui va de 0, 1, 2, 3, 5, 8, 13, 20, 40 à 100. Les cartes doivent être prêtes avant la réunion de planification et les nombres doivent être assez grands pour être vu de l'autre côté de la table.

Pour chaque cas d'utilisation ou fonction à estimer, un animateur lit le descriptif. Le modérateur est généralement le directeur de produit ou un architecte. Toutefois, le modérateur peut être n'importe qui, car il n'existe pas de privilège associé avec le rôle. Le directeur de produit répond à toutes les questions des participants. Néanmoins, tout le monde doit savoir qu'à un certain moment les discussions complémentaires ne conduisent pas à améliorer la précision. L'objectif avec le planning poker est de ne pas procéder à une estimation qui supportera toutes les futures fonctionnalités. Au contraire, l'objectif est de qualifier la première vue pour arriver sur la fin à une estimation fiable, d'où une première estimation peut être considérée à « bon marché ».

Après que toutes les questions ont trouvé des réponses (enfin, on essaye), chaque participant choisit une carte représentant son estimation. Les cartes sont montrées une fois que chaque participant a fait son choix. À ce moment-là, toutes les cartes sont retournées en même temps de manière à ce que tous les participants puissent voir chaque estimation individuelle.

Il est très probable à ce stade que les estimations diffèrent sensiblement. Il s'agit en fait d'une bonne nouvelle. Si les estimations diffèrent, les participants avec des valeurs hautes et des valeurs basses doivent expliquer la raison de leurs estimations. Il est important que cela ne fonctionne pas comme un reproche à l'intention des participants. Mais un échange sur des visions différentes.

A titre d'exemple, un participant avec une estimation haute peut dire: Eh bien, pour tester ce cas d'utilisation, nous devons créer une base de données avec des objets fictifs. Cela pourrait nous prendre un jour. Je pense aussi que l'algorithme de compression n’est pas bon, ce qui impliquerait d'en développer un nouveau plus efficace . Le participant qui a fait une faible estimation peut répondre : Je pensais que nous allions stocker les informations dans un fichier XML - ce qui serait plus facile qu'une base de données.

Le groupe peut discuter de nouveau sur le cas d'utilisation et de leurs estimations respectives quelques minutes de plus. Le modérateur peut prendre des notes qu'il pense utiles pour le développement et le test de ce cas d'utilisation. Après la discussion, chaque participant fait une nouvelle estimation en sélectionnant une carte. Les cartes sont une fois de plus gardées secrètes jusqu'à ce que tout le monde ait réalisé son estimation au cours de laquelle elles seront affichées en même temps.

Dans de nombreux cas, les estimations convergent déjà au second tour. Mais si cela n'est pas le cas, il faut continuer à répéter le processus. L'objectif pour les participants est de converger vers une seule estimation qui peut être utilisée pour le cas d'utilisation. Cela prend rarement plus de trois tours de scrutin, mais le processus doit continuer jusqu'à ce que les estimations convergent. Il n'est pas nécessaire que tout le monde dans la pièce retourne une carte avec exactement la même estimation. Si je suis un modérateur et sur le deuxième tour quatre participants proposent, 5, 5, 5 et 3, je vais demander au participant qui a fait la plus faible estimation, si il est OK si on décide d'une estimation à 5. Encore une fois, l'estimation ne nécessite pas une précision absolue, mais raisonnable.

Le droit à la discussion

Certaines discussions sur la conception préliminaire du cas d'utilisation sont nécessaires et appropriées, lors de l'estimation. Toutefois, dépenser trop de temps sur des discussions à propos de la conception est souvent un gaspillage d'efforts et de temps. Voici un moyen efficace d'encourager certains débats, mais assurez-vous qu'il ne va pas trop durer.

Acheter un sablier, et placez-le au milieu de la table de poker où la planification est en cours. Toute personne assistant à la réunion doit pouvoir voir le compte à rebours à tout moment. Lorsque le sablier est épuisé (environ deux minutes), la prochaine série de cartes est jouée. Si un accord n'est pas atteint, la discussion peut se poursuivre. Mais quelqu'un doit tourner immédiatement le sablier pour limiter la discussion à deux minutes. Le sablier n'a rarement besoin d'être utilisé plus de deux fois. Avec cette méthode, les équipes apprennent à estimer plus rapidement.

Les petites sessions

Il est possible de jouer au poker avec un sous-ensemble de l'équipe, plutôt que de tout le monde. Ce n'est pas idéal, mais cela est parfois une option raisonnable, surtout si l'équipe est nombreuse, s'il y a beaucoup de cas à estimer, comme cela peut se produire au début d'un nouveau projet.

La meilleure façon d'y parvenir est de scinder la plus grande équipe en deux ou trois petites équipes, dont chacun doit disposer d'au moins trois participants. Il est important que chacune des équipes de participant estime successivement.

Pour ce faire, commencer avec toutes les équipes ensemble dans une session de planification conjointe d'une durée d'une heure environ. Demandez-leur une estimation pour 10 à 20 cas d'utilisation. Ensuite, assurez-vous que chaque équipe a une copie des cas d'utilisation et leurs estimations et qu'ils les utilisent comme base pour estimer les cas d'utilisations qu'ils leur sont donnés à estimer.

Quand jouer au planning poker

Les équipes devront jouer au planning poker à deux moments différents. Tout d'abord, il sera généralement nécessaire de faire des estimations sur un grand nombre de cas d'utilisation avant que le projet ne commence officiellement ou au cours de sa première itération. Estimer une première série de cas d'utilisation avec l'équipe sous la forme de deux ou trois réunions allant d’une à trois heures chacune. Naturellement, cela dépendra du nombre de cas d'utilisation à estimer et de la taille de l'équipe, et si le directeur de produit a les capacités de préciser les exigences de manière succincte.

Deuxièmement, les équipes devront faire de nouveaux efforts à chaque nouvelle estimation de cas d'utilisation qui sont identifiés au cours d'une itération. Une façon d'y parvenir est de planifier une estimation sous la forme de réunion très courte vers la fin de chaque itération. Normalement, cela est tout à fait suffisant pour estimer les travaux qui sont à réaliser au cours de l'itération, et permet d'obtenir les priorités à appliquer à l'itération en cours.

Sinon, Kent Beck propose une enveloppe accrochée sur le mur avec tous les nouveaux cas d'utilisation positionnés dans l'enveloppe. L'équipe va récupérer un ou deux cas d'utilisation dans l'enveloppe et les estimer. Les équipes doivent établir une règle pour eux-mêmes, généralement que tous les cas d'utilisation doivent être estimés d'ici la fin de la journée ou à la fin de l'itération. J'aime bien l'idée d'accrocher une enveloppe sur le mur qui contient les cas d'utilisation non estimés. Toutefois, je préfère lorsque quelqu'un qui a un peu de temps consacre quelques minutes à faire une estimation, il trouve au moins une autre personne et ils font une estimation conjointe.

Pourquoi le planning poker fonctionne

Maintenant que je viens de décrire la mise en oeuvre du planning poker, je vous propose de passer un petit moment sur les raisons pour lesquelles il fonctionne si bien.

Tout d'abord, le planning poker rassemble de multiples expertises pour réaliser les estimations. Parce que ces experts forment une équipe pluridisciplinaire sur un projet de développement applicatif, ils sont le plus à même pour estimer une tâche que d'autres personnes. Après avoir réalisé un examen approfondi de la littérature sur les estimations des charges en développement, Jørgensen (2004) a conclu que les personnes les plus compétentes pour résoudre la tâche doivent l'évaluer .

Deuxièmement, un dialogue animé s'ensuit au cours de la planification, et les planificateurs sont appelés par leurs pairs pour justifier leurs estimations. Cela a été proposé pour améliorer la précision de l'estimation, en particulier sur les cas d'utilisation avec de grandes quantités d'incertitude (Hagafors et Brehmer 1983). Être invité à justifier les estimations a démontré que cela se traduit par une meilleure estimation pour compenser les informations manquantes (Brenner et coll. 1996). C'est d’autant plus important sur un projet agile parce que les cas d'utilisations sont souvent intentionnellement vagues.

Troisièmement, des études ont montré que la moyenne des estimations individuelles conduit à de meilleurs résultats (HOEST et Wohlin 1998) de même que des discussions de groupe de planificateurs (Jørgensen et Moløkken 2002). Le groupe de discussion est la base du planning de poker, et ces discussions aboutissent à une sorte de moyenne des estimations individuelles.

Finalement, le planning poker fonctionne parce que c'est amusant !

Le planning poker

SecureOne — Sat, 17 May 2008 11:12:00 +0200

La définition des plannings est des charges associées à un projet sont un mélange d'expérience, d'échange et un peu de hasard. Je vous propose dans ce billet une méthode ludique et en équipe pour définir les charges d'activités sur les projets. Cette méthode découle des méthodes de gestion de projet Agile.

Le Planning Poker est l’un des outils de la méthode Scrum. Il permet à une équipe lors d’une réunion de planification de donner des cotations pour le développement d’une fonctionnalité. Lors de la réunion, le product owner (directeur de produit) représente le client, le commanditaire. Il donne l’ordre dans lequel doit s’effectuer les développements des nouvelles fonctionnalités. L’équipe a pour responsabilité de donner des quantifications au directeur de produit afin que celui-ci sache aussi que telle fonctionnalité coûte 10 unités et qu’une autre fonctionnalité ne coutera que 2 unités. A noter que je ne parle pas de jour/homme pour l’instant. Et c’est là qu’intervient le Planning Poker.

Mettons-nous en situation. Vous réunissez votre équipe de 5 personnes dans une salle. Vous demandez à tout le monde “combien de temps pour développer l’ajout de la fonction X sur mon logiciel ?” .

Mr A pense qu’il sait exactement ce qu’il faut faire, donc il pense 5 jours. Mr B et Mr C sont plus prudents. Mr D et E ne participent pas activement à la conversation et n’écoutent pas. Bref, c’est Mr A qui prend la parole et qui vous répond, “Je pense 5 jours“.

L’équipe est influencée par la première personne qui s’exprime. C’est un risque important, car en fait on voit que B et C pensaient que cette fonction demande plus de temps à développer. Nous risquons de perdre de l’information ici et leurs doutes doivent être exprimés.

Reprenons la même scène avec le planning poker. Le principe est de donner à chacun de vos équipiers un jeu de carte spécial, le fameux Planning Poker dont voici une photo :

Vous distribuez un jeu complet à chacun de vos équipiers.

Comme vous pouvez le constater, les cartes ne se suivent pas. Elles sont basées en partie sur la suite de Fibonacci afin de forcer les personnes à trancher. L’unité n’est pas le nombre de jours/homme, mais une unité arbitraire. Il est important de donner un jeu à chaque personne de l´équipe.

Ensuite voici comment se déroule la séance : refaisons l'évaluation. Le product owner (directeur de produit) dit :

L’équipe lui pose des questions afin d’affiner la demande pendant environ 5 mn. Ensuite commence la phase du vote. Chacun prend une des cartes et la pose devant lui face cachée. Cette fois-ci chacun pense librement et activement. Mr D et Mr E sont obligés aussi de participer. Une fois que tout le monde a sélectionné une de ses cartes, on retourne celle-ci en même temps et le résultat du premier vote est discuté par l´équipe.

Cette fois-ci nous voyons bien qu’entre Mr A et Mr C, une discussion s’impose à propos de l’histoire. Après quelques discussions, Mr A réalise qu’il a oublié une partie du développement et qu’il faut l’inclure. Mr C réalise qu’avec la proposition de Mr A en effet il est possible de réaliser plus rapidement la fonction et que donc son estimation est un peu trop pessimiste. Après 5 mn, toute l’équipe refait une estimation en reprenant les cartes, et en sélectionnant une nouvelle carte, ou la même s’ils n’ont pas changé d’avis.

Voilà maintenant une cotation réaliste et réalisable de la demande initiale. Les développeurs se sont parlé activement afin de présenter une vision sur la solution envisagée. Et tout le monde y a participé. Ce qui est aussi efficace en terme d’échanges et de communications.

Il existe quelques cartes spéciales:

la carte 0 représente une fonction qui est déjà implémentée
la carte ? représente le fait que vous n’avez vraiment aucune idée sur la question
la carte “tasse de café” c’est le joker pour signaler que vous voulez faire un break

Ressources complémentaires:

Vous pouvez fabriquer un jeu de cartes avec quelques fiches cartonnées ou en acheter un à cette adresse CRISP

Vous retrouverez aussi la version en anglais (CRISP) de ce que j’ai librement traduit à cette adresse et donc le crédit de cet article va en premier à Crisp SE. Merci à eux.

Je vous prépare pur la prochaine un billet qui décrit la valeur des cartes et l’attribution des unités

Investir dans le PMO

SecureOne — Fri, 16 May 2008 23:54:00 +0200

Déjà entendu parler de PMO ? du Project Management Office ? de la cellule de pilotage projet ?

Vous en avez compris que c’était tout juste un groupe de personne qui contrôle les chefs de projet en terme de budget, délai et respect des divers autres processus mis en place par l’organisation pour sa gestion de projet.

Les structures projets françaises ont pour défaut de ne pas avoir, encore une fois, pris la mesure du rapport investissement stratégique / bénéfice long terme. Il est pourtant simple d’investir dans de bonnes pratiques, dans des procédures fiables, de les faire appliquer, mesurer leur efficacité et les aménager pour augmenter leur portée !

En gestion de projet le Standish Group nous apprend dans son étude « Chaos Study » que les projets au niveau mondial dépassent en moyenne leur budget de 43%. Voila, l’investissement annuel que pourrait faire une entreprise (enlevons une petite marge de sécurité parce que même avec un PMO il y a toujours des surprises).

Or dans les PMO que j'ai côtoyé je constate que :

Les intervenants ont peu d’expérience en gestion de projet et beaucoup sont des juniors qui cherchent une première approche de l’activité projet
Les référentiels n’existent que rarement, et souvent à des fins de certification affichable face au client qu’il soit interne ou externe, quasiment jamais pour unifier les pratiques
La visibilité et le partage de pratiques sont dépréciés par le pré carré et l’individualisme politique de chaque petit chef (c’est mon truc, ça fait 20 ans que je fais comme ça, c’est mon avancement…)
L’intervention du PMO n’apporte pas de valeur ajoutée et se contente d’être comptable (respect du budget et des délais) ; pas de retour d’expérience, peu d’analyse et de recherche d’amélioration ; du pilotage au rétroviseur !

L’investissement premier c’est la compréhension de ce que peut amener un PMO :

Une assurance qu’une méthode est appliquée rationnellement, de manière unifiée dans l’entreprise,
Ensuite, une analyse fiable et cohérente du portefeuille projet (délais, qualité, coûts et risques),
Puis une vigilance par rapport à la stratégie d’entreprise : les délais, les coûts, le périmètre sont-ils toujours dans la norme fixée ?
Enfin, une amélioration constante des pratiques, de la sécurisation du taux de succès.

Dans ce que peut amener un PMO il n’y a jamais le flicage et la dénonciation. Dans un PMO on se doit de penser maîtrise, support, valeur ajouté au service de la stratégie et des projets. Le vrai PMO se construit à la Deming : Plan Do Act Check, une élaboration itérative de la performance et de la maitrise.

Buts recherchés d’une organisation institutionnalisant le PMO :

. Modèle de gouvernance et processus définis : 44%
. Alignement stratégique (projet/entreprise) : 32%
. Utilisation des métriques pour l’amélioration et la croissance : 14%
. Accroissement de la performance de l’équipe : 11%

Le second investissement c’est l’homme, la compétence. Pour surveiller un projet il suffit d’être espion, délateur, calculateur. Pour maîtriser un projet et aider à son succès il faut avoir vécu le projet, ses ambiguïtés, ses difficultés, la psychologie inhérente. Il faut savoir partir de rien, se référer à des analyses, à des exemples, tester, revenir en arrière et recommencer. J’irai même plus loin : contourner les règles établies pour s’assurer le succès et faire parvenir à les transformer pour améliorer l’avenir.

Seules des ressources formées, conscientes, sachant, expérimentées peuvent tirer les projets vers le haut et conférer au PMO une activité à valeur ajouté. Vous avez fait un peu de Java à l’école ? Est-ce que pour autant vous êtes intervenus en expertise sur un code dans ce langage ? A 99% non ! Vous avez d’abord « pissé du code », transpiré sur votre environnement de développement, acquis des réflexes et affronté des difficultés !

En gestion de projet c’est pareil ! Il ne faut pas maîtriser que la gestion (i.e. les chiffres), mais aussi le mode projet. Et là c’est l’expérience qui compte.

Un project Management Officer ne peut aider à l’atteinte de la stratégie que s’il la comprend, s’il sait la modéliser en actions avec les chefs de projet. Mais il doit aussi comprendre le mode de fonctionnement psychologique du chef de projet : gagner coûte que coûte le succès du projet et ne pas hésiter sur les moyens à mettre en œuvre, préserver ses ressources…

Le troisième investissement c’est l’outillage. Un bon PMO, après être rentré dans ses critères de bénéfices doit s’améliorer, faire de la qualité. A la façon de CMMI : une montée en qualité itérative, par brique.

Ce qui doit être rodé ce sont les processus, le système d’information (au sens partage de l’information). L’outillage vient en complement pour automatiser les processus, favoriser la mutualisation des méthodes.

Un processus doit être unique et accepté par tous. Par exemple l’un des PMO que j’ai connu avait un cycle de planification commun à tous les projets : Une macro-planification, basée sur des méthodes d’estimation gravées dans le marbre et des modèles de plannings, un affinage du périmètre-charges-délais à horizon 3 mois, une ré-évaluation à mi année.

Même processus pour tous, identicité des pratiques, des outils et des modèles, d’où une compréhension générale, un arbitrage facilité, un maîtrise du portefeuille.

Ce troisième investissement est au gout du jour : qui ne parle pas de Clarity (système global de gestion de projet successeur de Niku) ? de EPM (Enterprise Project Management ? de PS-Next ? Ces systèmes, appelés SRM (pour Services Relationship Management) sont les équivalents des ERP pour gérer les projets dans l’alignement stratégique de l’entreprise. Et cette dimension globalisante, cette volonté d’aller de la stratégie du Top Management à la gestion d’un projet est clairement affichée par les noms même de ces produits : Clarity (visibilité), Enterprise (le projet n’est plus un monde à part dans l’organisation), Next (transversalité).

Les deux premiers investissements sont pourtant prioritaires. Autant qu’une phase de conception dans un développement logiciel. Avant la course à l’outil, c’est la course à l’organisation qu’il faut gagner. Et celle-ci coûte plus cher, bouleverse les habitudes et les cultures professionnelles, provoque donc plus de résistance et de difficulté, mais est un préalable nécessaire !