 Your new post is loading...
Your new post is loading...
Scoop.it!
Agile & CMMi, potion magique ou grand fossé ? Conférence lors de l'Agile Tour Toulouse 2011 - Par Pablo Pernot et Yassine ZAKARIA. 
No comment yet.
Sign up to comment
Scoop.it!
12 novembre 2013 2013-11-19-0800 CASSc CMMI au Service de Scrum Nicolas de Cagny Jean-Pierre Saugère 1
Scoop.it!
En 2007, la banque devenait la première entreprise européenne de cette taille à être évaluée CMMi 3. Deux mille informaticiens ont été accompagnés dans cette démarche d'amélioration continue.
Scoop.it!
Une bonne entrée en matière pour découvrir ces standards
Mickael Ruau's insight:
Au programme, par domaine : IT & IT Management Project Management Enterprise Architecture Business Management
Scoop.it!
Ce besoin permanent d’adaptabilité et de disponibilité que demandent les activités métier a conduit les DSI à chercher des moyens pour répondre à des problématiques concrètes dans des domaines très ciblés. C’est ainsi que nous avons vu naître nos ITIL, CMMi, eSCM et autre CFTL, chacun tâchant de répondre à des besoins précis. La généralisation de l’utilisation de ces cadres méthodologiques sur leur périmètre de prédilection a permis aux DSI de prendre conscience que de nombreux points de recouvrement existent entre ces référentiels et que, si la convergence ne doit pas être un objectif, il est capital de se poser les bonnes questions sur leur mise en œuvre.
Scoop.it!
Étant certifié PMP et, comme vous le savez, ayant occupé de nombreuses fonctions bénévoles au sein de PMI, le sujet proposé par Dave Nielsen m’a-t-il intéressé : CMM et le PMBOK. En voici une traduction personnelle.
Mickael Ruau's insight:
Ceci n’est pas un manuel pour réaliser CMM ou atteindre la certification CMMI, ni un manuel d’exécution des meilleures pratiques du PMBOK, j’indique simplement des façons de d’aligner les deux standards.
Scoop.it!
Voici un premier retour sur l'expérience de l'organisation de notre "voyage" vers la certification CMMI en mode Projet.
Mickael Ruau's insight:
Scoop.it!
There are about 55 named software development methods in use, and an even larger number of hybrids.
Some of the development methods include the traditional waterfall approach, various flavors of agile, the Rational Unified Process (RUP), the Team Software Process (TSP), V-Model development, Microsoft Solutions Framework, the Structured Analysis and Design Technique (SADT), Evolutionary Development (EVO), Extreme Programming (XP), PRINCE2, Merise, model-based development, and many more.
The data itself comes from studies with a number of clients who collectively use a wide variety of software methods. The predictions use the author’s proprietary Software Risk Master™ tool which can model all 55 software development methodologies.
Mickael Ruau's insight:
Table 4: Top Methods in 10 Categories 1. Development schedules Extreme programming (XP) 2. Development staffing Agile/scrum (tied) 3. Development effort CMMI/5 spiral 4. Development costs CMMI/5 spiral 5. Defect potentials TSP 6. Defect removal efficiency (DRE) TSP 7. Delivered defects TSP 8. High-severity defects TSP 9. Total Cost of Ownership (TCO) TSP 10. Cost of Quality (COQ) TSP
Scoop.it!
This course focuses on the development of a CMM-like model for FLOSS (Free/Libre Open Source Software). The aim is to enable software companies to use FLOSS software in production and, in particular, in their main stream products. The trust in the development process can bring consistent cost savings and reducing the time to market.
Mickael Ruau's insight:
According with this view the course includes eleven lessons: PresentationOMM OverviewTWETWE-CMMIOMMFLOSS Components IntegrationOMM in Process of Companies Producing FLOSSMetrics for Trustworthy ElementsFinal RemarksSummaryReferencesAttachmentSizeCMM-like Model for OSS Course4.84 MBDownload here the ontology related to this course3.78 KB
Scoop.it!
CMMI Forms, Templates, Checklists, Guidelines
Mickael Ruau's insight:
Following are the examples of CMMI templates: Project Management Plan (PMP)PM WorkbookRisk Management PlanSoftware Requirement Specification (SRS)Software Design Document (SDD)
For example, a Project Management Plan template can be used for the planning of the project, contains the information related to the planning, monitoring, execution & closure of project. This template will also provide evidence to satisfy the Specific Practices of the Project Planning Process Area of CMMI for Development (CMMI-DEV).
A Project Management Plan template may include the information about the following subjects: Project IntroductionIssue ManagementProject Monitoring & ControlConfiguration ManagementQuality Management
Scoop.it!
From
itil
SCAMPI signifie Standard CMMI Appraisal Method for Process Improvement. SCAMPI est une méthode d'évaluation du modèle CMMi dont l'objectif est d'évaluer la maturité des processus déployés par un organisme.
Mickael Ruau's insight:
3 types d'évaluation SCAMPI existent : SCAMPI C : L'évaluation SCAMPI C est généralement utilisée pour évaluer la maturité des processus avant d'initialiser une démarche CMMi. Elle fournit une appréciation du niveau de maturité.SCAMPI B est plus poussée. Elle est quant à elle utilisée dans une logique de déploiement du référentiel et fournit de précieuse indication à l'organisme sur ses forces et faiblesses, ainsi que sur les actions à mener pour par exemple atteindre un niveau de Maturité ou de Capacité.SCAMPI A est utilisée pour valider (certifier) la mise en œuvre de pratique d'un niveau deMaturité ou de Capacité donné.
Scoop.it!
SEI CMMI Representations - Learning SEI Capability Maturity Model (CMMI) Level 1, 2, 3, 3 and 5 in simple and easy steps.
Mickael Ruau's insight:
Continuous vs. Staged Representations:Continuous RepresentationStaged RepresentationProcess areas are organized by process area categories.Process areas are organized by maturity level.Improvement is measured using capability levels. Capability levels:
measure maturity of a particular process across an organization. range from 0 through 5. Improvement is measured using maturity levels. Maturity levelsmeasure maturity of a set of processes across an organization range from 1 through 5. There are two types of specific practices: base and advanced. All specific practices appear in the continuous representation.There is only one type of specific practice. The concepts of base and advanced practices is not used. All specific practices appear in the staged representation except when a related base-advanced pair of practices appears in the continuous representation, in which case only the advanced practice appears in the staged representation.Capability levels are used to organize the generic practices.Common features are used to organize generic practices.All generic practices are included in each process area.Only the level 2 and level 3 generic practices are included.Equivalent staging allows determination of a maturity level from an organization's achievement profile.There is no need for an equivalence mechanism back to the continuous representation because each organization can choose what to improve and how much to improve it using the staged representation.Which Representation is Better ?Because each representation has advantages over the other, some organizations use both representations to address particular needs at various times in their improvement programs. Organizational maturity is the focus of the staged representation, whereas process area capability is the focus of the continuous representation. Organizational maturity and process area capability are similar concepts. The difference between them is that organizational maturity pertains to a set of process areas across an organization, while process area capability deals with a set of processes relating to a single process area or specific practice. Below is the pictorial diagram depicting both the presentations. In this diagram ML indicates Maturity Level and PA Indicates Process Area. We will discuss maturity levels and capability levels in subsequent chapters.
|
Scoop.it!
lundi 12 octobre 2009 agiletour.org/fr/at2009_geneve.html B1 Convergences entre CMMI et SCRUM / XP Richard BASQUE
Scoop.it!
Anderson décrit comment l'examen des organisations sous un angle lentille CMMI fournit des analyses précieuses pour les gestionnaires, les ingénieurs de production et les parties prenantes externes, y compris les clients, les investisseurs, les organismes de gouvernance et les vérificateurs.
Mickael Ruau's insight:
Le concept de maturité organisationnelle reste controversé. Comment par exemple, la maturité d'organisation peut être évaluée ? Est-ce que le comportement d'une organisation est réellement distinct du comportement et des actions de ses membres ? Le concept qu'une organisation peut être évaluée à un niveau particulier de maturité et qu'il s'agit d'un indicateur de la capacité à fournir un travail fiable au gouvernement fait l'objet d'un débat. Toutefois, je reste un fervent défenseur du CMMI et je crois qu'examiner les organisations à la lentille CMMI fournit des analyses précieuses pour les gestionnaires, les ingénieurs de processus et les parties prenantes externes, notamment les clients, les investisseurs, les instances et les auditeurs de gouvernance.
Scoop.it!
Nous allons illustrer dans cet article comment une approche pragmatique basée sur une analyse de maturité et sur la mise en place de bonnes pratiques de test permet d’y répondre. Et nous allons étudier en quoi le référentiel TMMi (Test Maturity Model Integrated) peut accompagner cette démarche.
Mickael Ruau's insight:
Au premier abord, comme tout référentiel, il peut déconcerter et décourager de par sa structure rigide et sa complexité. Cependant, après l’avoir manipulé et utilisé sur de nombreux projets, nous avons élaboré une méthode de travail qui, basée sur le référentiel TMMi, permet d’adapter ce dernier à de nombreux cas de figure. D’une part, la méthode d’évaluation informelle constitue un bon point de départ pour avoir une vision claire du niveau de maturité de l’activité de test et dégager les axes d’amélioration principaux. D’autre part, le référentiel contient toutes les bonnes pratiques pour la mise en oeuvre de ces améliorations.
Scoop.it!
From
acial
Au premier abord, comme tout référentiel, il peut déconcerter et décourager de par sa structure rigide et sa complexité. Cependant, après l’avoir manipulé et utilisé sur de nombreux projets, nous avons élaboré une méthode de travail qui, basée sur le référentiel TMMi, permet d’adapter ce dernier à de nombreux cas de figure. D’une part, la méthode d’évaluation informelle constitue un bon point de départ pour avoir une vision claire du niveau de maturité de l’activité de test et dégager les axes d’amélioration principaux. D’autre part, le référentiel contient toutes les bonnes pratiques pour la mise en oeuvre de ces améliorations. Enfin, cette évaluation peut être étendue à un objectif de certification de l’activité de test.
Mickael Ruau's insight:
LA COMPLÉMENTARITÉ AVEC LE CMMI Sur la forme, il utilise le même modèle et la même approche étagée par niveaux de maturité. Il reprend également la même numérotation entre les objectifs et activités génériques ou spécifiques. Ceci facilite énormément le travail de comparaison pour les organismes qui adopteraient conjointement les deux modèles. Sur le fond, ce modèle a été développé spécifiquement pour se focaliser sur les activités de test logiciel et fournit une vision nettement plus spécifique que ce qui est fourni par le CMMi dans les processus de vérification et validation par exemple. On trouve, pour un niveau de maturité donné dans TMMi, des références vers des domaines de processus correspondants dans CMMi.
Scoop.it!
Agile & CMMi Potion magique & grand fossé Yassine Zakaria & Pablo Pernot
Mickael Ruau's insight:
Pour dédramatiser le sujet
Scoop.it!
Principaux apports de CMMI
CMMI encourage l’entreprise à capitaliser, d’un projet à l’autre, les enseignements de l’expérience : « règles de pouce », documents types, évaluations quantitatives. C’est là sans doute son apport le plus précieux : le responsable d’un projet nouveau pourra trouver dans une base documentaire un ensemble d’outils et de références qui lui éviteront d’avoir à réinventer la roue. Associé à SCAMPI, CMMI fournit une référence qui permet à chaque entreprise d’évaluer sa maturité en conduite de projet et de la faire progresser. CMMI définit, sous le nom de « processus », les diverses responsabilités qui interviennent dans la réalisation d’un projet ainsi que leur articulation ; il détaille selon une nomenclature arborescente le contenu de ces responsabilités en « pratiques » et « produits ». Cetteénumération permet à ceux qui la consultent de ne rien oublier d’important. Les auteurs précisent qu’elle n’est qu’indicative : on peut, si l’on a de bonnes raisons pour cela, décider de ne pas mettre en œuvre tout ou partie de certains processus. Toutefois CMMI n’évoque pas les « règles de pouce » de bon sens qui permettraient de faire ce choix. Rappelons que CMMI n’est pas une méthode de conduite de projet : c’est une méthode de qualification de l’entreprise en conduite de projet. Les définitions qu’il fournit comportent parfois des incohérences. Ainsi, le cycle de vie d’un produit est défini d’abord, de façon correcte (p. 30), comme « une période de temps qui commence quand le produit est conçu et s’achève quand il n’est plus utilisable ». Mais le paragraphe suivant précise les phases du cycle de vie : « (1) conception, (2) étude de faisabilité, (3) développement, (4) production, (5) phase finale » : cela correspond au cycle de vie d’un bien industriel vu par l’entreprise qui le produit, mais non à celui d’un service ni d’un logiciel car il manque dans cette liste la phase d’utilisation – souvent la plus longue, et qui demande elle aussi du travail. C’est que CMMI est destiné aux directions des études et aux SSII, et non aux maîtrises d'oeuvre et maîtrises d'ouvrage même si celles-ci ont intérêt à le connaître pour évaluer leurs fournisseurs. CMMI ne considère pas la mise en place des référentiels, l’arbitrage entre les divers projets, la façon dont les métiers définissent leurs processus de production et les outils d'aide aux utilisateurs, l’alignement des dépenses avec les priorités des métiers, ni la traduction d'un problème technique en impacts pour la production ou les clients. CMMI ne regarde ni vers l’amont, ni vers l’aval du projet. Il ne parle ni d’urbanisme du système d’information, ni de modélisation des processus de production de l'entreprise (il donne au mot « processus » un tout autre sens), ni d'animation du bon usage : il suppose donc tout cela fait par ailleurs, et bien fait. CMMI décrit les processus qu'il est opportun de maîtriser pour conduire un projet, mais ne dit rien des pièges que ces processus permettent d’éviter. Or comme certains pièges sont plus dangereux que d’autres, les divers processus n’ont pas une importance égale : la présentation de CMMI manque de relief à cet égard. CMMI ne fournit pas d’exemples de document bien rédigé, de processus bien mis en œuvre : il dit seulement « il faut écrire tel document », « il faut mettre en œuvre tel processus». Or il existe par exemple une grande différence entre un document bien rédigé (clair, lisible) et un document incompréhensible. Il ne suffit donc pas d’avoir défini le thème d’un document, il faut encore lui associer des critères de qualité et savoir les appliquer : CMMI ne fournit pas de tels critères.
Mickael Ruau's insight:
Précautions à prendre
Il ne convient pas de prendre CMMI au pied de la lettre, c’est d’ailleurs ce que disent ses auteurs eux-mêmes. Il serait en effet peu raisonnable pour une entreprise d’attendre des mois ou années avant d’introduire des indicateurs quantitatifs dans la gestion de projet, et certains des processus qui relèvent des niveaux 3 ou 4 sont donc de ceux que l’entreprise doit maîtriser en tout premier, notamment la qualité de l’expression de besoins et le suivi quantitatif de la réalisation. Il faudra en fait les mettre en œuvre dès le début, donc sans respecter exactement l’ordre prescrit par CMMI. Les niveaux les plus substantiels de CMMI sont les niveaux 2 et 3, qui font le plus souvent l’objet d’une certification et contiennent le plus grand nombre de processus. Les niveaux 4 et 5 relèvent, pour l’essentiel, d’un perfectionnement que l’on peut juger superflu et qui est peut-être impossible : les projets que réalise une entreprise ne sont pas nombreux au point que l’on puisse fonder sur eux une statistique représentative, encore moins une analyse causale en bonne et due forme. Enfin, l’entreprise qui adhère à CMMI risque peut-être de négliger ce que CMMI ignore, ou suppose déjà fait et bien fait : la gestion du portefeuille de projets, la sobriété des exigences, l’observation et l’animation de l’usage des produits. Si elle se focalise sur sa maîtrise de la « gestion de projet », seule chose que CMMI considère, et non sur la qualité de son SI, elle risque de lancer de nombreux projets sans percevoir que la pluie de nouveautés qui en résulte peut déstabiliser ses agents opérationnels et son organisation.
Scoop.it!
Mickael Ruau's insight:
The four levels of software immaturity. LevelDescription Characteristic0. Negligent IndifferenceFailure to allow successful development process to succeed. All problems are perceived to be technical problems. Managerial and quality assurance activities are deemed to be overhead and superfluous to the task of software development process. Reliance on silver pellets.-1. Obstructive Counter ProductiveCounterproductive processes are imposed. Processes are rigidly defined and adherence to the form is stressed. Ritualistic ceremonies abound. Collective management precludes assigning responsibility. Status quo ьber alles.-2. Contemptuous ArroganceDisregard for good software engineering institutionalized. Complete schism between software development activities and software process improvement activities. Complete lack of a training program.-3. Undermining SabotageTotal neglect of own charter, conscious discrediting of peer organizations software process improvement efforts. Rewarding failure and poor performance.
This article is based on the original research on lower maturity levels presented by Finkelstein in his immortal work, "A Software Process Immaturity Model." [1] This article extends Finkelstein's work by introducing many new Kounter Productive Areas and extending the taxonomy of immaturity levels, thus accelerating the research being done in this vitally important area.
Scoop.it!
Everything Sysadmin propose cinq étapes pour aider une organisation à adopter une culture DevOps. Le site replace ces étapes dans le contexte de Les Trois Voies, un ensemble de principes rendus populaires par "Le Projet Phénix".
Mickael Ruau's insight:
Suivre le Premier Principe consiste à réfléchir sur les processus de bout en bout d'un système, c'est à dire considérer toutes les étapes qu'une modification entraîne dans un logiciel, depuis la requête initiale du client jusqu'au déploiement en production. Ceci permet d'éviter des optimisations locales et de supprimer les silos, comme l'expliquent Gene Kim et al. dans "Le Projet Phénix".
Le Deuxième Principe permet l'amplification des boucles de retour, de telle sorte que les problèmes sont identifiés et corrigés rapidement. Par exemple, il s'agit de rendre disponibles les logs de production d'une application pour l'équipe de développement.
Le Troisième Principe favorise une culture d'expérimentation continue et de maîtrise par la répétition et la pratique. Chaos Monkey de Netflix peut être envisagé comme un exemple extrême du Troisième Principe en pratique. Tom Limoncelli, co-auteur de Everything Sysadmin, propose cinq étapes pour atteinder Les Trois Principes. Ces étapes sont des points de passage informels qui permettent à une organisation de vérifier comment ces principes ont pénétré sa culture.
La première étape est le point de départ, lorsque rien n'est documenté, mesuré ni automatisé. L'impossibilité d'exécuter de manière consistante les processus existants du système et/ou les récompenses accordées aux personnes pour des optimisations locales sont des symptômes de la première étape. L'organisation en est également au début de l'aventure alors qu'elle ne peut pas mesurer les processus du système, comme connaître le temps moyen d'un déploiement.
La deuxième et la troisème étape marquent le long chemin vers le Premier Principe. La première consiste à s'assurer que les processus sont documentés et peuvent être répétés, alors que la seconde milite pour des objectifs clairs pour les processus et évite le travail double. Une organisation pratique le Premier Principe lorsqu'elle peut, entre-autres, suivre de manière consistante les processus définis et attacher à chacune de ses étapes une liste de QA.
Le Premier Principe se manifeste également lorsque les changements de processus sont toujours sujets à discussion et communiqués à tous les tiers concernés.
Si une organisation peut faire des choses comme la mesure de processus de manière continue et revoit les défauts ou le temps de modification, elle a atteint la quatrième étape et le Second Principe.
A ce niveau, l'organisation possède des tableaux de bord qui montrent des indicateurs comme le temps de complétion des étapes, les defects ou les temps de cycle. Plus important, l'organisation tire avantage de ces mesures pour s'assurer que les processus corrigent les problèmes dont ils sont à l'origine.
Le Troisième Principe est atteint en même temps que la cinquième étape. Ce niveau de maturité présente quelques fonctionnalités importantes comme l'amélioration continue des temps de latence et de cycle, ou l'exécution de procédures de contingence (p.e. s'occuper d'un serveur défaillant) de manière régulière. Généralement, toutes les étapes d'une processus ont déclenché une modification de ce processus, sinon elles ont au moins été analysées pour s'assurer qu'aucune optimisation n'était nécessaire.
Scoop.it!
Download free ITIL CMM Comparison Matrix. Simple comparison between ITIL (Information Technology and Infrastructure Library) and CMM (Capability Maturity Model)
Mickael Ruau's insight:
AttachmentSizeITIL-CMM.pdf156.31 KBitil-cmm.png33.21 KB
Scoop.it!
From
itil
Présentation du CMMI. CMMI ou Capability Maturity Model & Integration est Conçu en 1987, à partir des meilleures pratiques de conception des logiciels par le SEI (Software Engineering Institute).
Mickael Ruau's insight:
En représentation étagée le niveau "0" n'existe pas alors qu'il existe pour l'approche continue. L'objectif des niveaux de CMMI est de permettre d'évaluer si les niveaux d'aptitudes des domaines de processus sont généralisés, dans l'approche continue lorsqu'un aucun domaine de processus n'est mis en œuvre on parle de niveau "0". Le niveau "1" s'appliquant à l'approche étagée signifie donc que le domaine de processus dans son ensemble satisfait aux exigences exprimées par CMMI. Ce qu'il faut retenir de ces 2 niveaux c'est qu'ils constituent un point de départ et qu'ils mettent en exergue que l'organisation n'est pas mature dans ses activités de conception.
Scoop.it!
CMMI est un modèle de bonnes pratiques qui repose sur une amélioration progressive des processus de développement informatique de l’entreprise.
Mickael Ruau's insight:
RéférencesLes livres de référence :Richard Basque. « CMMI un itinéraire fléché vers le Capability Maturity Model Integration ». Dunod, 2004Richard Basque. « CMMI : Un itinéraire fléché vers le Capability Maturity Model Integration Version 1.2″. Dunod, 2006Mary Beth Chrissis, Mike Konrad, and Sandy Shrum. « CMMI : Guidelines for Process Integration And Product Improvement ». Addison-Wesley Professional, 2006SEI Software Engineering Institute. « CMMI for Development, Version 1.2″. SEI, 2006Les liens :http://www.sei.cmu.edu/cmmi/index.htmlCette page contient tous les documents officiels de CMMI :http://www.sei.cmu.edu/cmmi/models/ ;
|
