Éprouvées, des tactiques pratiques pour Agile IT Release Management - Leçons apprises

Vue d'ensemble:

Cet article est le dernier d'une série de cinq qui expliquent comment une organisation qu'elle a livré un processus de validation qui a dépassé les attentes de sa direction et a fourni une base pour un succès continu. La série comprend:

   1. Comment avons-nous ici - LE CONTEXTE
   2. étapes Première solution - DEFINITIONS ET TRIAGE
   3. Initiale et de planification de sortie - la solution de base
   4. Control Change Production - contrôle de qualité final
   5. Métriques et Insights - ENSEIGNEMENTS


Résumé:

Beaucoup d'information des organisations de la technologie la limande à queue quand ils sont chargés de comprendre, organiser et mettre en œuvre les changements du système et les logiciels applicatifs servir leurs clients et les clients finaux sur une période de plusieurs années. Ce cinquième article se concentre sur les principaux résultats des solutions développées au cours de l'engagement de conseillers en gestion de sortie. S'il vous plaît se référer à l'Article premier - Le contexte d'un examen complet du domaine du problème et de l'organisation, au second article - DEFINITIONS ET TRIAGE pour une discussion sur les étapes rendez-vous prêt, à la troisième, LA SOLUTION DE BASE pour plus de détails sur la planification de presse , et à la quatrième CONTRÔLE FINAL DE LA QUALITÉ d'apprendre comment la qualité de la mise en œuvre a été améliorée. Ces articles étaient tous droit éprouvées, pratiques Tactics for Agile de gestion IT de sortie. Le moment est venu d'évaluer comment "Agile" nous avons été? Ce processus de sortie de gestion a été mis en œuvre en 1999, sans bénéficier de l'accès aux pensées et aux idées publié à la suite du Manifeste Agile. Nous avons également quelques mesures de base à examiner et à expliquer, et de réflexions sur les leçons sur la route.

Comment Agile Etait-ce de travail?

Je saisis volontiers admettre qu'il ya des experts dans la communauté Agile qui sont beaucoup mieux qualifié pour émettre un avis sur la façon de près ces travaux est conforme aux principes de développement Agile Software et les approches complémentaires Scrum au produit et de l'entreprise Gestion des besoins. D'une part ce n'était pas une discussion sur le développement de logiciels. Le Agile Manifesto (Note de l'auteur: la référence spécifique pour cette citation est donnée à la fin de cet article):. «Nous sommes à trouver des façons de développer des logiciels en le faisant et en aidant les autres le faire à travers ce travail, nous sommes venus à apprécier:

   1. Les particuliers et les interactions des processus et des outils
   2. logiciel de travail sur une documentation complète
   3. collaboration avec le client sur la négociation de contrats
   4. La réponse au changement plus en suivant un plan "


  Notre travail a été très ferme processus, disciplinée et essentielle à la réussite. Nos interactions sont fréquentes et très concentré. Nous avons utilisé des outils plaine bon marché, mais extrêmement bien. Particuliers - nous avons utilisé les forces de chacun pour réussir. Je nous donner une note de B sur le point 1. Le processus de sortie de gestion n'a pas pris connaissance des étapes intermédiaires du développement de logiciels. En fait, nous supprimés suivi des dates intermédiaires, puis remis en l'importance de commencer AQ. La seule chose que nous étions préoccupés par le logiciel a été prête pour la production. Je nous donner une note de A. Sur collaboration avec les clients, nous avons certainement amélioré les communications au sujet de ce qui était en cours d'élaboration (et ce n'était pas aussi était évident). Nous avons certainement montré la vice-présidents que nous avons essayé de glisser leur Top 5 des requêtes en à la première jonction dans le plan global. Le processus de sortie de gestion n'a pas fonctionné au niveau des exigences du logiciel, la conception et la fonctionnalité. Essentiellement nous venons de faire un grand travail de bien démarrer et d'arrêter le travail. Je nous donner un B sur le point 3. Ce processus excellé dans la réponse au changement plus en suivant un plan. Chaque semaine, nous allions construire une société Calendrier de sortie 6 de presse, et la semaine suivante, nous re-travailler le tout en raison de circonstances et la réalité. Nous l'avons fait avec clarté, la collaboration, la compréhension et le niveau élevé de communication. Je donnerais un A nous ici.

Mesures

Je vais reformuler mon avis que 99% des documents publiés sur les processus IT absence significative des indicateurs statistiques. Il ya beaucoup de "chant" sur les méthodes et les outils, mais pas beaucoup d'informations concrètes crédibles. De plus, gardez à l'esprit que l'informatique effectifs ont été maintenues constantes pour les périodes en question. Voici un échantillon des données et des mesures que nous avons recueillies:

Les paramètres de gestion de sortie sélectionnés

                                             Fin de l'année 1998 Fin de l'année 1999 Amélioration

Satisfaction de la clientèle 2,5 4,0 60,0%

                                           6/1/98 - 5/31/99 6/1/99 - 31/05/2000 amélioration

ECNS ou annulés 97 218

Projet y compris les communiqués 118 218 84,7%

Grands projets terminés 10 15 50,0%

                                       Au 31/05/1999 Au 31/05/2000

Note moyenne d'âge du carnet de commandes CR 197 jours 187 jours -10 jours

Taille du carnet de commandes CR 307 297 -10 CR

Satisfaction des clients - IT Le CIO a effectué un sondage très simple des cadres supérieurs dans l'organisation chaque année, en demandant un degré de satisfaction globale de la performance IT pour l'exercice précédent. Sur une échelle de 1 à 5, les 10 gestionnaires sélectionnés à partir Très insatisfaisant (1) à Exceptionnel (5). Cette notation simple ne fait pas de distinction entre les performances dans les opérations ou sur les projets ou la mise en œuvre des demandes de modification. Il a été la simple vue de leur satisfaction globale. Nous croyons que les efforts sur la gestion des versions ont été un facteur majeur dans l'augmentation du score de l'année précédente. Une autre victoire importante était que l'organisation informatique tourné le coin de l'an 2000 sans encombre.

Terminé les demandes de modification ou l'annulation La mission de conseil a commencé au début de mai 1999. À ce moment-là la définition des demandes de modification ne comprend pas les modifications apportées au logiciel de production causées par les grands projets. Utiliser les nouvelles définitions de ce que la gestion des versions considérée comme une partie du champ de demande de changement, la base de demandes de changement complété a été élargie pour la période de temps plus tôt afin que d'une comparaison équitable ne peut être tirée. L'organisation informatique, en utilisant la gestion des versions, a dépêché environ 85% de plus les demandes de changement de plus de 12 mois. Comme une observation parallèle mesures, le groupe IT fixer des objectifs annuels pour remplir les demandes de changement. Leur objectif pour l'année 1999 était de 140 (ce qui était considéré comme un objectif ambitieux à l'époque). Sur une année civile, il a complété 172 demandes de modification en 1999.

Grands projets terminés en cas où les gens me demande si c'est juste l'effort de re-dirigé à faire des demandes de changement de plus, donc à court changer les efforts sur les projets, les chiffres pour les grands projets sont présentés. Nous ne savons pas ce que% du total des ressources ont été utilisées sur un an, que la comptabilité du projet heures a été faible. Étant donné que le projet An 2000 a été une entreprise importante, je propose qu'il est raisonnable de supposer qu'il n'y avait pas de décalage disproportionnée des ressources qui ont favorisé une meilleure changement résultats Demande.

Moyenne d'âge de l'arriéré des demandes de changement, nous avons décidé d'examiner la façon dont nous faisions en termes de réduction de la quantité de temps les clients attendent d'obtenir leur demandes de changement de prise en charge. Pour la période en question, pas de signification peut être observée. Au moins il n'a pas tendance à la hausse! Notre expérience de première main, c'est que nous recevions des demandes haute priorité plus rapide, mais nous n'avons pas recueillir les données dans Excel pour cela.

Taille du changement arriéré de demandes Dans la même veine, nous avons gardé un œil sur les demandes de changement total. Nous avons vu des fluctuations mineures, mais en général, la communauté des clients a toujours été la présentation d'autres améliorations. Il n'y avait pas de mécanisme de rétrofacturation budgétaires du service informatique à la vice-présidents, et poser pour plus de travail en TI avait pas de conséquences directes pour eux.

Leçons apprises

   1. Tout d'abord, les investissements directs dans la gestion des versions de mise en œuvre a des résultats meilleurs que prévu pour les parties prenantes.
   2. J'ai été surpris et ravis de voir le mur de cartes d'index à transformer au fil du temps à un radiateur d'informations plus élaborées pour l'organisation. Un exemple a été l'ajout de points de couleur pour les cartes pour les Top 5 et l'état QC. Nous avons également délicate avec des cartes de positionnement ci-dessus et ci-dessous certaines des lignes horizontales de transmettre de nouvelles informations. Nous avons également commencé à afficher le thermomètre des demandes de changement réalisé par rapport à l'objectif annuel (il a été édifiante). Il ya beaucoup de vérité à l'adage que vous avez appris tout ce que vous devez savoir à la maternelle .....
   3. Les solutions que nous ont été appliquées à peu près parfaite pour une organisation au même endroit que la gestion de la configuration et les processus QC en place et un engagement organisationnel à la libération de gestion.
   4. Le CIO, en voyant que le processus a été intégré avec succès, à la fin de 1999 a demandé au consultant de faire une nouvelle étude du marché des logiciels commerciaux pour des outils de soutien dans le domaine de la gestion des versions - aucun n'a été trouvé qui pourrait correspondre à la efficacité de l'équipe nous avons réalisé avec cartes sur un mur.
   5. Le rôle et les actions du gestionnaire de sortie ont été très bien défini. Par conséquent, j'ai préparé un plan de transition à faire appel à un gestionnaire interne pour le poste en cours de Release Manager. Il a fallu plus de 4 mois pour trouver et former un remplaçant pour le poste permanent. Le premier candidat choisi ne pouvais pas suivre le rythme de la gestion d'objets détaillée qui a été nécessaire.
   6. Si ce problème avait concerné 600 demandes de changement, il n'aurait pas travaillé du tout. Tant que nous avions moins de 350, nous pourrions y faire face sur un mur et vous pouvez lire toutes les cartes d'environ 15 pieds plus loin. Il ya des limites à ce média / storyboard approche.


Conclusion / Transition

Il ya une quantité énorme de la valeur à la création d'un conseil Visual décision qui couvre l'ensemble du problème pour une organisation. Ce constat général peut être appliqué de manière à faible coût à de nombreux problèmes. Dans mes recherches pour trouver une solution logiciel adéquat forfait pour la gestion des versions, la quasi-totalité trébucher sur le problème d'échelle sur un moniteur informatique 21 ". A ce jour, le dixième anniversaire de cette entreprise, systèmes matériels très sophistiqués et que les environnements de salle de conférence commencer faire correspondre le Mur et la pratiques que nous avons utilisés. Je souris chaque fois que je vois un film d'espionnage moderne, ou "24" ou CSI Miami éblouir le public avec la technologie de l'espace virtuel et la carte index / approche manipulation puzzle d'une façon sophistiquée.

Si vous souhaitez me contacter pour discuter de l'amélioration des processus dans votre organisation, dwlarsen1946@gmail.com email

David W. Larsen est un consultant en technologie de l'information les pratiques d'amélioration des processus, le commerce électronique, gestion de portefeuille, et des programmes et la gestion de projet. Il a obtenu son baccalauréat ès arts de l'Université de Valparaiso, son MBA à St. Mary's College de Californie, et un diplôme en gestion des télécommunications de l'Université de Californie, Berkeley. Dave a servi entreprises mondiales de premier plan dans les projets de développement d'applications et d'intégration et a travaillé main dans la main avec des entreprises aux États-Unis, le Canada, la République tchèque, Angleterre, Suède, Allemagne, Italie, Japon, Australie et Inde.

cet article est traduisé en francais
l'origine de cet article (en anglai): http://ezinearticles.com/?Proven,-Practical-Tactics-For-Agile-IT-Release-Management---Lessons-Learned&id=2473293