Freemind sous Flex

++[Flex|http://freemind.happy-electronics.eu/export-freemind-to-flex/index.jsp|en]++, nouveau service de mise en ligne de carte Freemind, vu sur le blog « Freemind par l’exemple » de Franck Maintenay : ++[« Flex : et les cartes Freemind deviennent « fluides » »|http://www.freemindparlexemple.fr/2010/02/flex-et-les-cartes-freemind-deviennent.html|fr]++.%%% %%% J’ai fait un essai sur la traduction en français de la ++[mindmap « Scrum Checklist » de Henrik Kniberg|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/05/30/Scrum-checklist|fr]++ réalisée par mon pote Ivan.%%% %%% Ça génère la carte suivante (double-cliquez pour naviguer) :%%% ///html ///

Test IceScrum par Scrum 4 You

((/dotclear/public/logos/logo-icescrum.png|Logo IceScrum||Logo IceScrum))%%% J’ai traduit un billet intéressant de Boris Glogger sur son blog concernant le célèbre outil français open source agile IceScrum (Claude Aubry & Co) : ++[« Scrum Tools ; IceScrum ; Review »|http://borisgloger.com/2010/02/23/scrum-tools-icescrum-review/|en]++.%%% > ++[IceScrum|http://www.icescrum.org/|fr]++ est un outil agile créé par des ++[étudiants français|http://www.icescrum.org/index.php/documentation/team/|en]++. IceScrum est une application Web qui fonctionne sous serveur Tomcat et base MySQL avec la licence GPL. L’outil est uniquement axé sur Scrum, apporte les fonctionnalités de base pour gérer les équipes Scrum mais avec une interface utilisateur originale.%%% > %%% > __Mise en route__%%% > %%% > La première chose à faire est de créer votre projet et vous pouvez choisir entre deux types d’estimation, la plus populaire avec Fibonacci et une plus classique qui va de 0 à 99. Je pense que l’estimation classique peut faire perdre à l’équipe beaucoup trop de temps à essayer de parvenir à une fausse impression de précision, en tombant dans des discussions sans fin autour de la taille d’un élément du backlog valant 63 ou 64, mais le choix reste le vôtre. Ensuite, nous arrivons sur l’écran principal du projet et nous pouvons commencer à créer des versions (~releases), des stories, des sprints, etc. Mais un utilisateur ne peut pas exécuter toutes ces tâches, cela dépend de son rôle sur le projet, Scrum Master, Product Owner, etc. Ceci est une bonne chose mais vous ne pouvez pas paramétrer ce que chaque rôle peut faire, c’est pré-configuré et nous ne pouvons pas le changer, le point positif est que cela empêche les gens de paramétrer n’importe quoi, mais cela force l’équipe à s’adapter à l’outil, et par ailleurs, nous pouvons créer des rôles personnalisés mais ce n’est pas l’idéal.%%% > %%% > __Backlog__%%% > %%% > Avec l’option « backlog » vous créez vos stories, chaque story peut être associée à une Fonctionnalité (~Feature), qui peut être considérée comme un Thème ou une Epic, vous pouvez utiliser les modèles « En tant que-Je peux-Afin de » pour créer des stories si vous le souhaitez, et leur affecter une estimation en même temps, il y a aussi une option « Planning Poker » très simple qui peut satisfaire la plupart de nos besoins. Le Backlog peut être affichée sur une vue « tableau » ou une vue « post-it », mais vous ne pouvez prioriser que sur la vue « post-it » ce qui est très bizarre et ennuyeux aussi.%%% > %%% > Pour démarrer notre premier sprint, il faut d’abord créer une version. Pour ce faire, nous devons passer par l’option « Feuille de route » (~Roadmap), peut-être qu’ils pourraient changer le nom pour que ce soit plus clair. Une fois fait, nous serons en mesure de créer nos sprints ou de laisser l’outil les générer automatiquement.%%% > %%% > ((/dotclear/public/traductions/icescrum.png|IceScrum|L|IceScrum))Donc maintenant nous pouvons répartir nos stories sur les différents sprints et créer des tâches. L’option « tableau de tâches » est simple et efficace, avec ses trois colonnes de base et imite l’utilisation d’un tableau de tâches mural. Il y a aussi des options de BurnUp/BurnDown ainsi qu’un backlog d’Obstacles (~Impediments), les deux sont très clairs, mais le backlog d’Obstacles pourrait être encore plus puissant.%%% > %%% > __Conclusion__%%% > %%% > Je pense que l’équipe IceScrum essaye de créer un outil avec une interface utilisateur à part, mais à mon avis, ils n’y sont pas encore, et doivent la perfectionner encore un peu plus. Toutes les fonctions de base que nous pouvons attendre d’un outil Scrum sont couvertes et même un peu plus, mais ce n’est pas très intuitif, si ils peuvent mieux organiser le workflow, améliorer la présentation, en ce qui concerne l’organisation, et investir plus de temps sur le support (la vidéo disponible sur ++[YouTube|http://www.youtube.com/user/icescrum|fr]++ est pas mal mais ce n’est pas assez), ils pourront surmonter ces lacunes.%%% %%% __Feedback :__%%% * Blog de Claude Aubry : ++[« Feedback de Scrum 4 you sur IceScrum »|http://www.aubryconseil.com/post/Feedback-de-Scrum-4-you-sur-IceScrum|fr]++

The Chaos Report (1994)

((/dotclear/public/traductions/three-monkeys.gif|Les 3 Singes|L|Les 3 Singes))On en avait parlé lors de ++[l’Agile Tour bordelais 2009|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/10/26/Retrospective-de-l-Agile-Tour-Bordeaux-2009|fr]++ et ça faisait un moment que j’avais envie de traduire ++[ce fameux rapport|http://www.projectsmart.co.uk/docs/chaos-report.pdf|en]++. Ça a été un peu dur mais c’est chose faite !%%% !!!!RAPPORT DU STANDISH GROUP © The Standish Group 1995 !!!!CHAOS  » »Les ponts romains de l’Antiquité reposaient sur des structures peu efficaces. Au regard des normes modernes, ils utilisaient trop de matériaux, et par conséquent, cela générait beaucoup trop de travail. Au fil des années, nous avons appris à construire des ponts plus efficacement, en utilisant moins de matériaux et en générant moins de travail pour effectuer la même tâche. » »%%%  »Tom Clancy (La Somme de Toutes les Peurs) »%%% !!!INTRODUCTION En 1986, Alfred Spector, président de Transarc Corporation, co-rédige un article comparant la construction de ponts au développement logiciel. Son idée : les ponts sont généralement construits dans les temps, en respectant le budget, et ne tombe pas. De son côté, le logiciel n’est jamais livré à l’heure ou dépasse le budget. En outre, il tombe toujours en panne. (Par contre, la construction des ponts n’a pas toujours été irréprochable. De nombreux projets de construction de ponts ont dépassé les estimations initiales, les échéanciers, et certains sont même tombés.)%%% %%% L’une des raisons principales pour lesquelles les ponts se construisent dans les temps, en respectant le budget et sans tomber, est que la conception est extrêmement détaillée. La conception est figée et l’entrepreneur ne peut quasiment pas modifier les spécifications. Toutefois, à notre époque où tout évolue rapidement, une conception figée ne permet pas de s’adapter aux nouvelles contraintes du Métier. Par conséquent, un modèle plus souple doit être utilisé. Cela pouvait être et a été utilisé comme une justification de l’échec du développement logiciel.%%% %%% Mais il y a une autre différence entre les défaillances des logiciels et celles des ponts, au delà des 3000 ans d’expérience. Quand un pont s’effondre, une enquête est effectuée et un rapport est rédigé pour expliquer les causes. Ce n’est pareil dans le secteur informatique où les défaillances sont couvertes, ignorées et/ou justifiées. En conséquence, nous continuons à faire les mêmes erreurs, encore et encore.%%% %%% Par conséquent, le point central de ce dernier projet de recherche du Standish Group a consisté à identifier :%%% * Le périmètre des défaillances des projets logiciels * Les principaux facteurs qui entraînent l’échec des projets logiciels * Les ingrédients clés qui peuvent réduire les échecs des projets !!!CONSTAT D’ÉCHEC Aux États-Unis, nous dépensons plus de 250 milliards de dollars chaque année pour développer des applications informatiques représentant environ 175 000 projets. Le coût moyen d’un projet de développement pour une grande entreprise est de 2 322 000 $, pour une entreprise moyenne c’est 1 331 000 $ et pour une petite entreprise c’est 434 000 $. Un grand nombre de ces projets échouent. Les projets de développement logiciel sont chaotiques et ++__nous ne pouvons désormais plus imiter les trois singes : ne pas entendre les échecs, ne pas voir les échecs, ne pas parler des échecs.__++%%% %%% Les recherches du Standish Group montre que 31,1% des projets seront annulés avant la fin. D’autres résultats indiquent que 52,7% des projets coûteront 189% de leurs estimations initiales. Le coût de ces échecs et de ces dépassements constituent juste la pointe de l’iceberg. Les coûts d’opportunité perdue ne sont pas mesurables, mais pourraient facilement être estimés en trillions de dollars. On n’a qu’à regarder la Ville de Denver pour réaliser l’ampleur de ce problème. L’incapacité à produire des logiciels fiables pour la manutention des bagages à l’aéroport de New Denver coûte à la ville 1,1 million de dollars par jour.%%% %%% Sur la base de ces recherches, le Standish Group estime qu’en 1995, les sociétés américaines et les organismes gouvernementaux consacreront 81 milliards de dollars pour des projets logiciels qui seront annulés. Ces mêmes organisations verseront un montant supplémentaire de 59 milliards de dollars pour des projets logiciels qui seront terminées, mais qui dépasseront leur estimation initiale. Le risque est toujours un facteur important lorsqu’on parle technologie, mais beaucoup de ces projets étaient aussi banals que des base de données de permis de conduire, un nouveau logiciel de comptabilité ou un système d’entrée des commandes.%%% %%% Du côté des succès, la moyenne n’est que de 16,2% pour les projets logiciels qui se sont accomplis dans les temps et avec le budget prévu. Dans les grandes entreprises, les nouvelles sont encore pires : seulement 9% de leurs projets seront dans les temps et respecteront le budget. Et, même lorsque ces projets sont terminés, beaucoup ne sont plus que l’ombre de leurs spécifications d’origine. Les projets réalisés par les plus grandes entreprises américaines disposent seulement d’environ 42% des fonctionnalités proposées au départ. Les petites entreprises font beaucoup mieux. Un total de 78,4% de leurs projets logiciels seront déployés avec au moins 74,2% de leurs fonctionnalités d’origine.%%% %%% Ces résultats peuvent sembler décourageants, mais en fait, 48% des cadres informatiques de notre échantillon de recherche estiment que les échecs sont plus fréquents aujourd’hui qu’il y a seulement cinq ans. La bonne nouvelle c’est que plus de 50% estiment qu’il y a moins ou autant d’échecs aujourd’hui qu’il y en avait cinq ou dix ans plus tôt.%%% !!!MÉTHODOLOGIE L’enquête réalisée par le Standish Group a été aussi complète que possible, même s’il n’était pas possible de couvrir toutes les entreprises disposant d’un système d’information dans le pays. Les résultats sont basés sur ce que nous appelons, au Standish Group, des « résultats clés » obtenus lors de nos campagnes de recherche et de plusieurs entretiens. Les interlocuteurs étaient des cadres informatiques. L’échantillon comprenait des grandes, moyennes et petites entreprises de secteurs majeurs, comme par exemple, la banque, la finance, la fabrication, le commerce de détail, commerce de gros, la santé, l’assurance, les services, les organismes locaux, étatiques et fédéraux. L’échantillon total était de 365 entreprises et a représenté 8380 applications. En outre, le Standish Group a organisé quatre groupes de discussion et de nombreux entretiens pour fournir des résultats qualitatifs lors du sondage.%%% %%% Dans le cadre de cette étude, les projets ont été classés selon trois types :%%% * Type 1, ou projet réussi : le projet est terminé das les temps et respecte le budget, avec toutes les fonctionnalités initialement spécifiées. * Type 2, ou projet dégradé : le projet est terminé et opérationnel, mais dépasse le budget et le délai initial, et offre moins de fonctionnalités qu’initialement spécifiée à l’origine. * Type 3, ou projet annulé : le projet est annulé à un moment donné pendant le cycle de développement. Dans l’ensemble, le taux de réussite n’était que de 16,2%, tandis que les projets dégradés représentaient 52,7%, et les projets annulés comptaient pour 31,1%. !!!STATISTIQUES D’ÉCHEC Le Standish Group a en outre segmenté ces résultats selon la taille des entreprises, grandes, moyennes et petites. Une grande entreprise est une entreprise comptant plus de 500 millions de dollars de bénéfices annuels, une entreprise moyenne est définie comme ayant de 200 millions à 500 millions de dollars de bénéfices annuels, et une petite entreprise de 100 millions à 200 millions de dollars.%%% %%% Les chiffres d’échec étaient également tous décourageants quelque soit la taille de l’entreprise. Seulement 9% des projets dans les grandes entreprises ont réussi. Entre 16,2% et 28% respectivement, moyennes et petites entreprises ont obtenu un peu plus de succès. Un énorme 61,5% pour les projets dégradés des grandes entreprises (type 2) comparé à 46,7% pour les entreprises de taille moyenne et 50,4% pour les petites entreprises. La plupart des projets, soit 37.1%, ont été défaillants et annulés par la suite (type 3) dans les entreprises moyennes, comparativement à 29,5% dans les grandes entreprises et 21,6% dans les petites entreprises.%%% !!!!Redémarrages L’une des principales causes de ces deux dépassements en coûts et en temps sont les redémarrages. Pour 100 projets qui démarrent, il y en a 94 qui redémarrent. Cela ne signifie pas que 94 des 100 projets auront un redémarrage, certains projets peuvent avoir plusieurs redémarrages. Par exemple, le projet du California Department of Motor Vehicles, scénario d’échec résumé plus loin dans cet article, a subi de nombreux redémarrages.%%% !!!!Dépassements de coûts De même pour les résultats en dépassement de coûts, de délais, et concernant l’échec des applications à fournir les fonctionnalités attendues. Pour les types 2 et 3, près d’un tiers subirent des dépassements de coûts de 150 à 200%. La moyenne dans toutes les entreprises est de 189% de l’estimation initiale. La moyenne de dépassement des coûts est de 178% pour les grandes entreprises, 182% pour les entreprises de taille moyenne, et 214% pour les petites entreprises.%%% %%% ///html

Dépassements de coûts % de réponses
Moins de 20% 15,5%
21 – 50% 31,5%
51 – 100% 29,6%
101 – 200% 10,2%
201 – 400% 8,8%
Plus de 400% 4,4%

/// %%% !!!!Dépassements de délais Pour les types 2 et 3, plus d’un tiers ont subi des dépassements de délais de 200 à 300%. Le dépassement moyen est de 222% de l’estimation de délai initial. Pour les grandes entreprises, la moyenne est de 230%; pour les entreprises de taille moyenne, la moyenne est de 202%; et pour les petites entreprises, la moyenne est de 239%.%%% %%% ///html

Dépassements de délais % de réponses
Moins de 20% 13,9%
21 – 50% 18,3%
51 – 100% 20,0%
101 – 200% 35,5%
201 – 400% 11,2%
Plus de 400% 1,1%

/// !!!!Faiblesse du contenu Pour les projets dégradés, plus d’un quart ont été terminés avec uniquement entre 25% à 49% des fonctionnalités spécifiées à l’origine. En moyenne, seulement 61% des fonctionnalités spécifiées à l’origine sont disponibles sur ces projets. Les grandes entreprises ont les plus mauvais résultats, avec seulement 42% des fonctionnalités dans le produit final. Pour les entreprises moyennes, le pourcentage est de 65%. Et pour les petites entreprises, le pourcentage est de 74%.%%% %%% ///html

% de fonctionnalités % de réponses
Moins de 25% 4,6%
25 – 49% 27,2%
50 – 74% 21,8%
75 – 99% 39,1%
100% 7,3%

/// %%% Actuellement, les 365 entreprises ont 3682 applications 3682 en cours de développement. Seulement 431 d’entre elles, soit 12% de ces projets, respectent délai et budget.%%% !!!CRITÈRES DE SUCCÈS/ÉCHEC L’aspect le plus important de l’étude a été de découvrir pourquoi les projets échouent. Pour ce faire, le Standish Group a rassemblé les opinions des cadres informatiques en les interrogeant sur les raisons de succès des projets. Les trois raisons majeures pour qu’un projet réussisse sont l’implication des utilisateurs, le soutien du management opérationnel, et un énoncé clair des exigences. Il existe d’autres critères de réussite, mais avec ces trois éléments, les chances de réussite sont beaucoup plus grandes. Sans eux, les chances d’échec augmentent de façon spectaculaire.%%% %%% ///html

Facteurs de succès d’un projet % de réponses
1. Implication des utilisateurs 15,9%
2. Soutien du management opérationnel 13,9%
3. Énoncé clair des exigences 13,0%
4. Planning adéquat 9,6%
5. Demandes réalistes 8,2%
6. Jalons projets plus rapprochés 7,7%
7. Équipe compétente 7,2%
8. Propriétaire du produit 5,3%
9. Vision & Objectifs clairs 2,9%
10. Équipe dédiée, travaillant dur 2,4%
Autres 13,9%

/// %%% Les participants ont également été interrogés sur les facteurs qui pouvaient dégrader les projets.%%% %%% ///html

Facteurs de dégradation d’un projet % de réponses
1. Manque d’information de la part des utilisateurs 12,8%
2. Exigences & spécifications incomplètes 12,3%
3. Exigences & spécifications changeantes 11,8%
4. Manque de soutien de la part du management 7,5%
5. Incompétence technologique 7,0%
6. Manque de ressources 6,4%
7. Demandes irréalistes 5,9%
8. Objectifs pas clairs 5,3%
9. Délais irréalistes 4,3%
10. Nouvelles technologies 3,7%
Autres 23,0%

/// %%% Les opinions concernant les raisons pour lesquelles les projets sont défaillants et finalement annulés, mettent au premier rang les exigences incomplètes et le manque d’implication des utilisateurs.%%% %%% ///html

Facteurs de défaillance d’un projet % de réponses
1. Exigences incomplètes 13,1%
2. Manque d’implication des utilisateurs 12,4%
3. Manque de ressources 10,6%
4. Demandes irréalistes 9,9%
5. Manque de soutien du management opérationnel 9,3%
6. Exigences & Spécifications changeantes 8,7%
7. Planning insuffisant 8,1%
8. N’utilise plus les fonctionnalités demandées 7,5%
9. Mauvaise gestion des technologies de l’information 6,2%
10. Technologies trop complexes 4,3%
Autres 9,9%

/// %%% Une autre conclusion importante de l’enquête est qu’une forte proportion de cadres informatiques pensent que les projets échouent aujourd’hui plus souvent qu’il y a cinq ou dix ans. Ceci malgré le fait que la technologie a eu le temps de mûrir.%%% %%% ///html

Qu’il y a 5 ans Qu’il y a 10 ans
Beaucoup plus d’échecs 27% 17%
Plutôt plus d’échecs 21% 29%
Aucun changement 11% 23%
Plutôt moins d’échecs 19% 23%
Beaucoup moins d’échecs 22% 8%

/// !!!GROUPES DE DISCUSSION Afin d’obtenir davantage de résultats pour l’enquête, le Standish Group a organisé quatre groupes de discussion avec les cadres informatiques de grandes entreprises. Les participants faisaient partie d’un échantillon représentatif provenant de l’assurance, l’État, le gouvernement fédéral, le commerce, la banque, la finance, la fabrication et le service. Deux des groupes de discussion étaient à Boston. Les deux autres à San Francisco. Chaque groupe de discussion avait une moyenne de dix participants avec un total global de quarante et un cadres informatiques. Le but de ces groupes de discussion était de solliciter les opinions sur les causes d’échec des des projets. En outre, le Standish Group a interrogé divers responsables informatiques. Certains de leurs commentaires sont très instructifs sur la variété des problèmes qui pèsent sur les projets de développement.%%% %%% Bon nombre des commentaires ont fait écho aux conclusions de l’étude du Standish Group. « Nous avons 500 projets. Aucune ne respecte le délai et le budget. Cette année, 40% seront annulés », a déclaré Edward, adjoint au DSI dans une entreprise pharmaceutique.%%% %%% Les autres commentaires portaient directement sur les raisons des échecs. Jim, Directeur informatique chez un grand fabricant de matériel médical, a déclaré : « C’est un état d’esprit, il est très difficile d’obtenir de tout le management – qu’il soit au niveau mondial et même à un niveau local – de se mettre d’accord sur un ensemble de règles… C’est un défi en soi parce que vous devez, dans certains cas, les convaincre que c’est mieux pour l’entreprise, pas nécessairement mieux pour eux, mais le mieux pour l’entreprise. Et vous devez en passer par là. Si vous n’en passez pas par là, vous allez échouer. Je ne fait même pas entrer en ligne de compte la taille du projet ».%%% %%% John, DSI dans un organisme gouvernemental a ajouté : « 90% des échecs des projets sont probablement dus à la politique ! » Et Kathy, développeuse dans une entreprise de télécommunications, a fait un commentaire encore plus cinglant sur la politique : « Parfois, vous devez prendre une décision que vous n’aimez pas. Allant même contre votre propre nature. Vous vous dites : bien, c’est mal, mais vous appliquez la décision de toute façon. C’est comme prendre un marteau et s’écraser l’orteil. Ça fait mal. »%%% %%% Bob, DSI dans un hôpital, a commenté les facteurs externes contribuant à l’échec d’un projet. « Notre plus gros problème est la concurrence des priorités », a-t-il dit. « Nous venons de nous réorganiser aujourd’hui même. Cela va donc miner le moral de toutes les ressources. Il a donc expliqué la chose suivante à sa direction : « Eh bien, c’est vraiment prendre du temps que nous souhaitions consacrer à faire autre chose. Vous avez réorganisé la société, je vais donc prendre encore six mois sur ce projet parce que je fais autre chose pour vous. C’est mon plus gros problème. » Bill, DSI dans une société financière, a ajouté : « Les changements, les changements, encore les changements; c’est ce qui nous tue. »%%% %%% Certains des commentaires étaient empreints d’humour noir. « Des utilisateurs décérébrés, ce sont carrément des utilisateurs décérébrés » a dit Peter, un analyste fonctionnel dans une banque. « Lorsque le projet a commencé à foirer », a déclaré Paul, un programmeur chez un fabricant de produits personnels, « le management s’est effacé d’un coup. »%%% %%% Le commentaire le plus révélateur du chaos dans le développement de projets est venu de Sid, un chef de projet dans une compagnie d’assurance. « Le projet a deux ans de retard et en cours de développement depuis trois ans », dit-il. « Nous avons eu jusqu’à une trentaine de personnes sur le projet. Nous avons livré une application dont l’utilisateur n’avait pas besoin. Ils ont cessé de vendre le produit moins d’un an après. »%%% !!!CAS D’ÉTUDE Pour disposer d’un meilleur aperçu sur les échecs et les succès, le Standish Group a examiné attentivement deux projets de Type 3 (annulé) et deux projets de Type 1 (succès). A des fins de comparaison, les critères de réussite du projet initialisés à partir de l’enquête auprès des opérationnels informatiques, ont été utilisés pour créer un graphique « succès potentiel ». Ces critères de succès ont ensuite été pondérés suite à l’enquête menée auprès des managers informatiques. Le critère le plus important, « l’implication des utilisateurs », a généré 19 « points de succès ». Le moins important « équipe dédiée, travaillant dur » a généré 3 points. Deux critères de réussite très important – « demandes réalistes » et « jalons projets plus rapprochés » – ont été pondérées à 10 et 9 points respectivement. Enfin, tel que présenté plus loin dans ce rapport, chacune de ces études de cas a été graduée.%%% !!!!California DMV En 1987, le California Department of Motor Vehicles (DMV) s’est engagé dans un projet majeur de remise à plat de l’application gérant l’enregistrement des demandes de permis de conduire. En 1993, après avoir dépensé 45 millions de dollars, le projet a été annulé.%%% %%% Selon un rapport spécial publié par DMV, la principale raison de redévelopper cette application était le fait d’adopter de nouvelles technologies. Ils ont publiquement déclaré : « L’objectif spécifique du projet en 1987 était d’utiliser une technologie moderne pour soutenir la mission de DMV et soutenir sa croissance en disposant d’un traitement des données DMV qui s’adapte rapidement aux changements. » En outre, selon le rapport spécial de DMV : « Le phasage du projet a été modifié plusieurs fois, mais la communauté technique de DMV ne fut jamais véritablement confiante dans sa viabilité… »%%% %%% Le projet n’a pas eu de retombées financières, n’a pas été appuyé par la direction, n’a pas eu d’implication des utilisateurs, a été mal planifié, disposait spécifications insuffisantes et d’objectifs mal définis. Il n’a pas eu le soutien de l’équipe de management.%%% %%% Pourtant le projet de DMV n’était pas sorcier. Il existe des applications beaucoup plus dures que l’enregistrement des demandes de permis de conduire. Mais à cause de la politique interne, d’objectifs imprécis et d’une mauvaise planification, le projet était condamné dès le départ.%%% !!!!American Airlines Début 1994, American Airlines a réglé son litige avec Budget Rent-A-Car, Marriott et Hilton Hotels Corp, après que le projet de développement du système CONFIRM de réservation d’hôtel et de location de voiture, se montant à 165 millions de dollars, ait sombré dans le chaos.%%% %%% Ce projet a échoué parce qu’il y avait trop de « cuisiniers » et la soupe a été gâchée. Le management n’a pas seulement appuyé le projet, il a même activement mené le projet. Evidemment si un projet de cette taille a échoué c’est qu’il y avait de nombreux défauts. Parmi les causes majeures inclus : une description incomplète des besoins, un manque d’implication des utilisateurs et une constante évolution des exigences et des spécifications.%%% !!!!Hyatt Hotels Bien que Marriott et Hilton Hotels sortaient de cet échec de projet de réservation, Hyatt s’y mettait. Aujourd’hui, vous pouvez appeler avec votre téléphone portable à partir d’un avion à 35 000 pieds, réserver votre chambre d’hôtel Hyatt, réserver l’autobus qui vient vous chercher et récupérez les clés qui vous attendent au comptoir. Ce nouveau système de réservation fut en avance sur le calendrier, en dessous du budget, avec des fonctionnalités supplémentaires et pour la modique somme de 15 millions de dollars. Ils ont utilisé des logiciels modernes avec une base de données Informix, le moniteur transactionnel TUXEDO et des machines sous Unix.%%% %%% Hyatt avait tous les ingrédients du succès : l’implication des utilisateurs, le soutien de la direction, un énoncé clair des besoins, un planning adéquat et des jalons réguliers.%%% !!!!Banco Itamarati Un an après une réorientation stratégique, Banco Itamarati, une banque brésilienne privée, a généré une croissance du bénéfice net annuel de 51% et est passée de la 47è à la 15è place dans le secteur bancaire brésilien. Trois raisons fondamentales à mettre au crédit du succès de Banco Itamarati. D’abord, ils avaient une vision claire avec des objectifs précis et documentés. Deuxièmement, leur niveau d’implication du haut vers le bas de l’échelle a permis à Banco Itamarati de maintenir le cap. Et enfin, la banque a produit des résultats réguliers et mesurables tout au long de la période de planification et de mise en œuvre.%%% %%% L’objectif métier très clair de Banco Itamarati est de devenir l’une des cinq premières banques privées au Brésil avant l’an 2000. Leurs objectifs comprennent le maintien d’une relation étroite avec leurs clients afin d’améliorer et de maintenir une compréhension de leurs besoins, l’offre de solutions financières compétitives, garantissant la satisfaction des clients, et au final générant des résultats équilibrés pour le Groupe Itamarati. Les objectifs de Banco Itamarati ont été incorporés dans un plan stratégique qui a clairement identifié des résultats mesurables.%%% %%% Leur plan stratégique faisait de la technologie une composante clé de leur stratégie commerciale. Itamarati a utilisé le moniteur OLTP GRIP de Itautec comme un outil fondamental pour l’intégration de composants logiciels. Selon Henrique Costabile, Directeur du Développement de l’Organisation : « Nous sommes l’une des premières banques à mettre en œuvre une architecture client-serveur qui permette de maximiser le potentiel de cette architecture. » Un leadership exécutif, un bon plan de communication et une équipe multi-compétentes ont fourni le socle pour que Banco Itamarati puisse atteindre son objectif long terme, peut-être même plus tôt que prévu.%%% !!!CONCLUSION DES CAS D’ÉTUDE L’étude de chaque projet a notamment fait ressortir certains critères de succès à ajouter à la carte des « potentiels de succès ».%%% %%% ///html

Critères de succès Points DMV CONFIRM HYATT ITAMARATI
1. Implication des utilisateurs 19 NO ( 0) NO ( 0) YES (19) YES (19)
2. Soutien du management 16 NO ( 0) YES (16) YES (16) YES (16)
3. Énoncé clair des besoins 15 NO ( 0) NO ( 0) YES (15) NO ( 0)
4. Planning adéquat 11 NO ( 0) NO ( 0) YES (11) YES (11)
5. Demandes réalistes 10 YES (10) YES (10) YES (10) YES (10)
6. Jalons projets réguliers 9 NO ( 0) NO ( 0) YES ( 9) YES ( 9)
7. Équipe compétente 8 NO ( 0) NO ( 0) YES ( 8) YES ( 8)
8. Appropriation 6 NO ( 0) NO ( 0) YES ( 6) YES ( 6)
9. Vision claire et Objectifs 3 NO ( 0) NO ( 0) YES ( 3) YES ( 3)
10. Équipe dédiée et travaillant dur 3 NO ( 0) YES ( 3) YES ( 3) YES ( 3)
TOTAL 100 10 29 100 85

/// Avec seulement 10 points de succès, le projet DMV n’avait pratiquement aucune chance de succès. Avec 100 points de succès, le projet de réservation Hyatt avait tous les ingrédients de la réussite. Avec seulement 29 points de succès, le projet CONFIRM avait peu de chances de succès. Avec 85 points de succès, Itamarati, bien que pas aussi confortable que Hyatt, a commencé avec une probabilité de réussite élevée.%%% !!!EN ROUTE VERS LA RÉUSSITE Malgré tout, cette étude est à peine suffisante pour fournir une véritable solution à un problème aussi lourd que le taux d’échec des projets. Les projets logiciels naviguent véritablement en eaux troubles. Afin de de sortir du chaos, nous avons besoin d’examiner pourquoi les projets échouent. Comme pour les ponts, chaque défaillance logicielle majeure doit être examinée, étudiée, tracée et partagée.%%% %%% Parce qu’elle est le fruit des idées des responsables informatiques, la carte des « Potentiels de Succès » peut être un outil utile soit pour la prévision du succès potentiel d’un projet ou pour évaluer l’échec du projet.%%% %%% ++__Les recherches menées par le Standish Group indiquent également que des délais plus petits, avec des livraisons des composants logiciels plus tôt et plus fréquentes, va augmenter le taux de réussite. Le raccourcissement des délais se traduit par un processus itératif de conception, prototypage, développement, test et déploiement de petits éléments.__++ Ce processus est connu sous le nom de « développement incrémental » (NdT : growing software), par opposition à l’ancienne notion de « développement global » d’un logiciel. Le développement incrémental implique l’utilisateur plus tôt, chaque composant a un propriétaire ou un petit groupe de propriétaires, et les attentes sont établies de manière réaliste. En outre, chaque composant logiciel a un énoncé clair et précis et un ensemble d’objectifs. Les composants logiciels et les petits projets ont tendance à être moins complexes. Faire des projets plus simples est une démarche très utile car la complexité génère de la confusion et augmente les coûts.%%% %%% Il y a un dernier aspect à considérer dans les cas d’échec d’un projet. Tout succès est enracinée dans la chance ou l’échec. Si vous commencez avec de la chance, vous n’apprendrez rien sauf l’arrogance. Toutefois, si vous commencez par l’échec et apprenez à l’évaluer, vous apprenez aussi à réussir. __++L’échec engendre la connaissance. La connaissance engendre la sagesse, et c’est en faisant preuve de sagesse que vous pouvez atteindre le véritable succès.++__%%% %%% __Feedback :__%%% * Sabine Bohnké, fondatrice du cabinet ++[Sapientis|http://www.sapientis.fr/]++ : ++[« La controverse du chaos »|http://www.itrmanager.com/articles/117518/controverse-chaos-sabine-bohnke-fondatrice-cabinet-sapientis.html]++%%% %%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

7 secrets pour mes rétrospectives

((/dotclear/public/logos/.boris-gloger-icon_t.jpg|Boris Gloger|L|Boris Gloger))J’ai traduit un billet intéressant de Boris Gloger sur son blog Scrum 4 You : ++[« Retrospectives ; 7 Secrets of my Retrospectives »|http://borisgloger.com/2010/02/14/retrospectives-7-secrets-of-my-retrospectives/|en]++.%%% > Exécuter des rétrospectives n’est PAS un art absolu, mais un art expérimental. L’animation efficace des réunions et des rétrospectives est possible pour n’importe qui. Je souhaite vous livrer ici 7 secrets :%%% > %%% > 1. Ayez confiance en chaque membre de votre équipe qui a fait de son mieux tout au long du Sprint.%%% > %%% > 2. Rassemblez d’abord les faits. Il existe plusieurs moyens de le faire, mais s’il vous plaît, rassemblez les faits.%%% > %%% > 3. Ne discutez pas. Employez des techniques d’animation de réunion pour rassemblez les faits au lieu de parler, parler, parler.%%% > %%% > 4. Créez d’abord une bonne ambiance. Faites participer tout le monde à votre succès.%%% > %%% > 5. Faites preuve de bonne foi !%%% > %%% > 6. Démarrez une session de brainstorming pour trouver des axes (processus, comportement, …) d’amélioration future.%%% > %%% > 7. Concentrez-vous sur l’avenir ! Distinguez les sujets sur lesquels l’équipe doit s’améliorer de ceux sur lesquels le ScrumMaster doit s’améliorer.%%% > %%% > Il y a beaucoup d’autres idées à mettre en oeuvre pour améliorer les Rétrospectives. Restez à l’écoute.%%%

Rétrospective Apéro Okiwi du 15 février 2010

2010 est manifestement l’année des changements pour tout le monde ! mais gardons une part de mystère, chaque chose viendra en son temps… donc ce soir je vous propose une rétrospective sous forme d’un nuage de tags (merci ++[Wordle|http://www.wordle.net/|fr]++) :%%% %%% [((/dotclear/public/./.cr-okiwi-20100215_m.jpg|Wordle Rétrospective Okiwi||Wordle Rétrospective Okiwi))|/dotclear/public/cr-okiwi-20100215.JPG]%%% %%% __Feedback :__%%% * Le week-end du 6-7 mars 2010, Colin a créé le ++[Blog Okiwi|http://okiwi.org/blogs/|fr]++ sous WordPress avec agrégation de nos blogs respectifs.

Tokyo Sanpo

[((/dotclear/public/lectures/.tokyo-sanpo_t.jpg|TOKYO SANPO|L|TOKYO SANPO))|/dotclear/public/lectures/tokyo-sanpo.jpg]Il paraît que Tokyo est la plus belle des villes moches du monde. Plus qu’un guide, voici un livre d’aventures au cœur des quartiers de Tokyo. Pendant ces six mois passés à tenter de comprendre un peu ce qui l’entourait, Florent Chavouet est resté malgré tout un touriste. Avec cette impression persistante d’essayer de rattraper tout ce qu’il ne sait pas et cette manie de coller des étiquettes de fruits partout, parce qu’il ne comprend pas ce qui est écrit dessus. A son retour en France, on lui a demandé si c’était bien, la Chine. Ce à quoi il a répondu que les Japonais, en tout cas, y étaient très accueillants.%%% %%% Ce livre bande dessinée m’a permis de retrouver les sensations qui m’ont envahies lors de mon ++[voyage au Japon|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/10/19/Retrospective-de-mon-sejour-au-Japon|fr]++. C’est donc une belle surprise ! Je le conseille vivement à ceux qui ont déjà séjourné dans la ville de Tokyo.%%% %%% Liens :%%% * ++[le site du livre|http://www.florentchavouet.com/|fr]++ * ++[le blog de l’auteur|http://florentchavouet.blogspot.com/|fr]++

Jeux Olympiques de Vancouver 2010

((/dotclear/public/logos/AtosOrigin_Olympic_Games_Logo.gif|Logo Atos Origin, Olympic Games|L|Logo Atos Origin, Olympic Games))((/dotclear/public/logos/vancouver-2010.png|JO Vancouver 2010|C|JO Vancouver 2010, aoû 2009))%%% Atos Origin est le partenaire informatique mondial et Top Partner des Jeux Olympiques. Atos Origin détient le plus gros contrat informatique jamais signé dans le monde du sport. Ce contrat conclu entre Atos Origin et le Comité International Olympique (CIO) concerne les Jeux de Salt Lake City 2002, Athènes 2004, Turin 2006, Beijing 2008, Vancouver 2010 et Londres 2012. Il a été renouvelé en 2009 pour Sochi 2014 et Rio de Janeiro 2016. Atos Origin assure la conception, l’intégration, la gestion et la sécurisation des multiples systèmes informatiques nécessaires au bon déroulement des Jeux Olympiques et des systèmes informatiques qui transmettent les résultats au monde entier.%%% %%% Pour plus d’information :%%% * ++[Site JO Vancouver2010|http://www.vancouver2010.com/fr/-/32678/q0c15c/index.html|fr]++%%% * ++[Site Atos Origin JO Vancouver 2010|http://www.fr.atosorigin.com/fr-fr/jeux_olympiques/vancouver_2010/default.htm|fr]++ * ++[Blog Atos Origin et Vancouver 2010|http://atosoriginvancouver.blogspot.com/|fr]++ %%% En prime, une très belle ++[affiche|http://www.fabrice-aimetti.fr/dotclear/public/210_297_GENERIC_71764_PI_VISA.pdf|fr]++ :%%% %%% ((/dotclear/public/210_297_GENERIC_71764_PI_VISA.png|LES JEUX VIVONS-LES|C|LES JEUX VIVONS-LES))

Check-list Scrum : faites-vous vraiment du Scrum ?

J’ai traduit en français la ++[Check-list Scrum|http://www.crisp.se/scrum/checklist|en]++ « non officielle » de Henrik Kniberg.%%% %%% Vous la trouverez ++[ici|/dotclear/public/traductions/Scrum-checklist-FR.pdf|fr]++.%%% %%% PS : annule et remplace la ++[version mindmap|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/05/30/Scrum-checklist|fr]++.%%% %%% ((/dotclear/public/traductions/.scrum-checklist_m.jpg|Checklist Scrum – Henrik Kniberg||Checklist Scrum – Henrik Kniberg))%%% %%% __Feedback :__%%% * Thierry Cros : ++[« Grille d’évaluation Scrum »|http://etreagile.thierrycros.net/home/?post/2011/05/25/Grille-d-%C3%A9valuation-Scrum]++%%%