Pages

vendredi 17 décembre 2010

Tension entre la gestion des versions (ITIL) et de travail du projet (PMBOK) - une discussion de cas

Il s'agit d'une discussion de la tension et de son atténuation entre ITIL de gestion des versions et le développement d'application (projets) et des améliorations à partir d'une occurrence particulière du monde réel.

Contexte Tout en travaillant pour une entreprise de fabrication mondiale majeure ils ont choisi de re-confier à un nouveau modèle dans le milieu de l'année dernière. Cela a été géré de manière programme cohérent, mais bien sûr pas tous les détails susceptibles d'être étoffés et intégrés en amont car ils sont une énorme organisation.

Il y avait un schisme fondamental dans la re-traitance entre les Services (Infrastructure et opérations) et systèmes (support des applications et des projets pour des applications). Chaque côté de ce schisme placé des contrats à la fois pour la ligne de front d'interprétation fournisseurs, mais aussi à un niveau supérieur ensemble de services d'intégration.

Du côté des services, bien sûr, la musique rock lit par les accords d'employer des processus ITIL. Et bien sûr, le fournisseur intégration du côté des services sont arrivés avec leur propre vision et un outil (s).

Du côté des systèmes de ces contrats a apporté une approche standard pour une partie considérable de la demande de maintenir l'héritage (break / fix) et de petites améliorations. Les vendeurs ont été organisés par des ensembles d'applications du procédé à une bande de fonctions des processus d'affaires.

Cependant l'intégration devait se produire avec deux couches de fournisseur, et le général qui vaut ne pas arriver à une approche standard ou commune sur les améliorations application rapidement. En organisations résultat différent défini par des bandes de fonctionnalité exécutés un peu différemment pour appuyer la demande.

Mécanique des changements d'administration, étaient vagues, mais dans l'espace dans lequel j'ai travaillé discrétionnaire (pas le break / fix) des améliorations ont été mis en place avec le libellé de niveau de service clairement besoin de leur gestion du changement par le changement, point par point. En outre, plus en raison de l'histoire, la gouvernance a été mis en place pour soutenir le dialogue sur le moment où chaque changement pourrait être faite avec l'utilisateur final ou partenaire d'affaires.

La société a été beaucoup plus standard sur macro coordination des projets d'application. Il y avait une série de cas différents, mais tous ont été dérivés d'un reconnaissables PMBOK (Project Management Book of Knowledge) approche.

Pour nos besoins, je mettrai des projets en deux groupes. Il ya d'abord eu des projets cascade (planifier, de définir, concevoir, construire, tester et déployer) et puis il y avait itérative, ou cyclique (RUP) types de projets.

Il y avait de nombreuses variantes, telles que le plan de scission et de définir à partir de la construction à travers le déploiement. Souvent, dans ces cas une plan de définir pourrait lancer plusieurs construire par le biais du déploiement. Et souvent aussi le plan et définir des parties pourrait obtenir à l'écart et nécessitent un rafraîchissement avant d'entrer dans le vrai à travers la construction de déployer.

Communiqué de gestion de sortie de gestion au niveau de l'entreprise de large a été vraiment plutôt une nouvelle réflexion. Il a commencé avant la re-sourcing a eu lieu, mais il a été prévu pour une mise en œuvre fonctionnelle progressive.

Les premières mesures avaient déjà eu lieu sans tension. Un ensemble d'applications a été identifié comme le champ d'application cible. Logiquement, cela a été des choses comme les applications les plus importantes en termes d'affaires, et les applications SoX contrôlée. Les horaires des applications lorsque ces changements permettraient d'être promus à des productions ont été élaborées et communiquées à une équipe de contrôle de la production centrale. Le but bien sûr d'être en mesure de gérer ces changements entre les différents fonction de l'application et avec les modifications du serveur et des infrastructures.

Toujours dans la mise en œuvre rapide et moins controversée a été l'élaboration de politiques pour ces applications concernant la gestion des versions.

Et depuis une vision complète ITIL a été poursuivi la gestion du changement ont été partiellement mises en œuvre. Il était en fait le "back end" qui a été mis en place. La grille de maintien pour la promotion de la production a été mis en place avec le changement d'autorisation de commissions (réunions) pris en charge avec un outil. Chaque changement a été présenté dans l'outil, examiné à la réunion pour être acceptable, et suivis dans la production et l'acceptation.

Le "Rub" Maintenant, la tension a montré quand la prochaine étape logique a été prise, qui était le concept de la cartographie du «quoi» allait changer le "quand" cela pourrait changer dans le calendrier déjà défini. Ennuis ont commencé quand ils ont voulu des plans de libération dont la portée est bien définie.

Dans tous les cas la vision a appelé à des plans de sortie qui ont un horizon de 2 ans, dont 12 mois a été entreprise, et 90 jours commis ou est «verrouillé». Il est clair pour le développement d'applications et de personnel de soutien s'efforce d'être de plus en plus sensible aux utilisateurs finaux et les clients d'affaires de cette pensée est tout simplement pas bon. Nous parlons d'un organisme ayant pour but déclaré de fournir une valeur (code de promotion) tous les 90 jours dans le grand tableau. Il s'agit d'une entreprise qui conçoit et veut exécuter un programme de marketing pour réagir aux pressions du monde réel dans 30 jours ou moins. En bout de ligne - aucune façon, pas la façon dont a été de verrouillage 90 jours d'aller travailler. N'était pas non plus qu'il va y avoir beaucoup plus que d'un horizon de 6 mois à ce qui pourrait être prévu.

Une autre couche de difficulté se pose avec les projets plus traditionnels en cours d'exécution. Le cadre conceptuel comprend le forage vers le bas ou l'élaboration d'arriver à des exigences distinctes. Il ya rarement une banque de dos connecté, les changements nets pour être tiré dans un groupe de définir un communiqué. (Parfois, quand un plan plus robuste et de définir déplacé dans la conception avant d'être abandonné ou mis en attente, ils peuvent exister.)

Tout au long de la vie du projet de l'oignon a été réduite "et des exigences est devenu évident. Mais une fois clair qu'il n'allait pas y avoir de retard dans l'obtention quelque chose de construit et déployé. Il n'y avait pas d'appétit pour mettre dans un calendrier à plus de 90 jours à l'horizon.

Itérative des projets témoignent d'un mélange de symptômes. Dans une certaine mesure lors de la seconde itération ou tard il y avait des changements nets qui ont été définis et de manière ciblée détenus à des fins itérations ultérieures. Très semblable à la libération de planification nécessaires. Mais le hic est, la saveur demande conjointe de développement signifie que quelque chose de nouveau, pourrait bien surgir dans le travail avec les utilisateurs d'une itération qui prévalent de toutes les autres choses et aller dans l'autre. Cette fois sauf exception. Ce devait être. Constamment resurfaçage des besoins plus importants et de ne pas privilégier un horizon ferme verrouillé ou. Il ne s'agissait pas de faire dans la prochaine version ouverte, mais constamment à l'examen, y compris les changements valeur la plus élevée dans la prochaine itération.

Avec les petites améliorations du problème était la gestion nécessaires à un par un. Ils n'ont pas fourni pour le codage et les tests, mais exécutée individuellement. Ils ont été prévues pour une date calendrier de sortie, mais le plan et la gestion n'a pas été pour une sortie groupée, mais devaient être point par point. Y compris les entrées dans le changement et un outil de gestion des versions. En retour, cela correspondait au niveau de service des contrats plus exactement.

Atténuation Donc, l'astuce pour atténuer ces arrangements sur le plan conceptuel autour de projets à tout le moins est assez facile. Ramollir sur les objectifs pour les horaires de l'entreprise sans littoral et de la portée et permettre l'élaboration de l'information autour de ce qui est dans ce communiqué que les choses sont connues.

Assez clair que ce que la durée doit être verrouillé et ferme devrait varier selon l'état des affaires, par l'application.

Quelle idée de la manière dans ce cas était l'outil. Il a été conçu avec deux couches. Un ensemble de documents de changement bien défini et un dossier détaillé communiqué de collecteur. En conséquence, la seule façon d'élaborer des changements en termes de combien était connu pour réviser les descriptions que les choses ont été comprises.

Dans un environnement vaste et complexe où la gestion de projet et l'outil de suivi n'a pas d'interface avec l'outil de gestion du changement et de libérer ce double effort devient considérable. Et pire, il s'agit d'une structure et un mode qui n'est pas naturel aux équipes de projet.

Donc, non seulement je vous informe que les outils doivent être intégrés, mais que l'outil de gestion des versions pourraient être construits avec des couches multiples. L'ensemble des documents top pourrait être juste la définition des dates ou des fenêtres d'opportunité pour la promotion de la production. Une couche suivante pourrait apporter une certaine définition de la portée, mais moins détaillée. Cela équivaudrait à une "fermeté" et ont un horizon approprié selon l'application. On pourrait définir ce que l'horizon entreprise devrait être dans la politique pour l'application.

Alors bien sûr, l'ensemble final équivaudrait à commis. Ceux-ci seraient bien définis changements. Toutefois, l'indemnité doit être fait pour permettre l'enregistrement de ces et en les déplaçant, lorsqu'ils sont connus. Plutôt qu'un des objectifs à horizon fixe pour combien de changements ont été enregistrés à ce niveau dans quelle mesure les aurait plus de sens. Par exemple:

95% devrait être connu 30 jours à

80% connu 60 jours à

60% connu 90 jours à

Les petites améliorations ont été en fait mis en correspondance avec des dates cibles calendrier de libération de la promotion de la production. Encore une fois il a été l'outil qui a obtenu de la manière. Il a été le concept selon lequel ils seraient regroupés et gérés par l'essai le code et l'unité comme un ensemble.

La solution serait de les gérer à partir de l'approbation par le biais d'exécuter du code et de tests unitaires individuellement. Ils «engagés» dossiers comme ci-dessus une fois approuvé. Qu'est-ce que la différence est que le statut et le suivi serait préservée à ce niveau inférieur, non pas au niveau de la version, jusqu'à la libération ou le faisceau était prêt pour les essais intégrés et la promotion de la production.

Une meilleure solution Alors que j'ai soigneusement évité ci-dessus est le fait qu'il y avait de maintenir ou de gestionnaires d'applications pour le traitement des changements de petites améliorations. Dans le même temps, il y avait les gestionnaires de projets de traitement des efforts de développement majeur pour les ensembles de fonctionnalités pour les applications même.

Du côté du projet que vous aviez en rotation les gestionnaires de projet et des équipes pour la même application. Souvent perdre la continuité de la supervision pour une application au fil du temps.

Pour vraiment faire ce travail mieux, vous avez besoin de faire le changement organisationnel et de changement attribué par les équipes de projet en collaboration avec les équipes de soutenir les équipes de produit avec les responsables de publication que de comprendre les petites améliorations et l'équivalent de travail du projet exécuté que des communiqués. Malheureusement, cela est loin d'être trivial.

cet article est traduisé en francais
l'origine de cet article (en anglai): http://ezinearticles.com/?Strain-Between-Release-Management-%28ITIL%29-and-Project-Work-%28PMBOK%29---A-Case-Discussion&id=546425

0 commentaires

Enregistrer un commentaire