Google
 

jeudi 13 mars 2008

Revues par les pairs

Les revues par les pairs (ou inspections) peuvent prendre de nombreuses formes, mais l'un des avantages que l'on ne peut ignorer est la suivante: faire d'importantes économies! Paradoxalement, c'est probablement la plus coûteuse à mettre en œuvre. Certains types de revues par les pairs peuvent exiger beaucoup d'efforts à planifier, à exécuter et à contrôler les activités, cependant, d'autres types peuvent avoir de très petits coûts.
La mise en œuvre des revues par les pairs sur nos produits de travail de spécifications ont réduit de 80% notre travail repris sur la conception et le codage. Et ces chiffres ne comprennent même pas les tests que nous n'avons pas à répéter. Parce que les spécifications sont vérifiées avant le codage, nous avons maintenant un aperçu sur les causes du travail repris et nous sommes en mesure de réduire l'effort requis par les revues. En bout de ligne, on obtient un produit de haute qualité.
Il faut également garder à l'esprit que "pairs" signifie ce qui fonctionne pour vous dans votre environnement. Dans un type de revue par les pairs formelle , les pairs comprendront une partie prenante de chaque groupe touché de l'équipe de développement. Par exemple, pour une revue par les pairs d'un cas d'utilisation, il y aura un auteur de cas d'utilisation, un analyste d'affaire, un concepteur d'interface utilisateur et un testeur (auteur du scénario de tests connexe). Chacun révisera basé sur leurs intérêts et le potentiel d'impact sur leurs produits de travail.
Quels sont les autres types de revues par les pairs en utilisation, vous demandez? Autant qu'il y a d'équipes de développement, je réponds. Ceux-ci doivent être pratiquées et façonné à votre environnement pour être efficace. Dans un premier temps, l'acceptation peut être très difficile, car les revues «semblent» ajouter un supplément de travail au personnel. Bien sûr, ce n'est qu'une illusion car tant de reprise de travail est évitée plus loin dans le cycle de vie du projet.
En conclusion, les économies de coûts, la haute qualité des produits et la collaboration étroite qui s'intègre sont des raisons pour lesquelles les développeurs deviennent très attachés aux revues par les pairs. En fin de compte, elle contribue à rendre chacun plus à l'aise avec leurs tâches individuelles.
Je ne peux pas imaginer une équipe de développement qui ne peut pas bénéficier d'un tel exercice.
Bonnes revues!

jeudi 7 février 2008

Une culture de qualité

Un objectif clé dans la mise en œuvre d'un programme d'amélioration des processus est d'inculquer un environnement orienté vers l'amélioration des activités de processus des développeurs. Il s'agit là d'un grand pas dans l'institutionnalisation du domaine de processus OPF et de toutes les pratiques GP 3,2 des autres domaines.

Pour le faire avec succès, il est important d'avoir 2 facteurs en main: un registre des demandes d'amélioration des processus et les ressources permettant de gérer les modifications des processus et des produits du travail.

Au début de cet exercice (la mise en œuvre d'un programme d'amélioration continue), les vérifications d'assurance qualité (PPQA) sont généralement la source des demandes de modification. Une fois que les changements ont été gérés et appliquées rapidement, les développeurs constateront les avantages de faire des demandes de changement et seront ravis de voir leurs activités se mouler à leurs besoins. Ceci est le résultat d'agir rapidement sur les demandes de changement pour montrer aux développeurs que l'organisation est intéressé à les aider à travailler plus efficacement.

Nous entreprenons ces activités depuis 2005 et nous recevons plus de 150 demandes de modification annuellement depuis avoir été évalué avec succès au CMMI ML2.

Ceux-ci ne sont que le début des effets d'un environnement de qualité.

jeudi 24 janvier 2008

Améliorer les processus...

Se concentrer sur l'amélioration des processus implique souvent une gestion des demandes de changement sur les activités et produits de travail de processus  existantes, une fois que les processus ont du vécu. Pour chaque demande de changement enregistrée , plus nous jugeons que la santé de notre culture de « qualité » est bonne.

En tant que « champion » de ce processus, la méthode que j'ai établi pour développer les demandes de changement est semblable à la méthode adoptée par SixSigma. J'ai conçu, avec l'aide de ma collègue, Véronique, un formulaire InfoPath (nous avons nommé ce produit de travail le DAP pour: document d'amélioration de processus). Le DAP est utilisé pour planifier et suivre le développement de nos améliorations de produit de travail et de processus. Naturellement, chaque demande de changement est approuvée en s'assurant premièrement qu'elle impacte une des catégories d'objectifs d'affaires. Ces objectifs sont clairement définis dans le plan de projet de l'amélioration des processus.

Les phases suivantes sont incorporées aux processus et font partie intégrale de l'accomplissement de chaque demande d'amélioration approuvée:

Définir
- Notre liste de demande d'amélioration de processus (nous l'appelons notre LMD pour la liste maîtresses des demandes) est où nous définissons les opportunités d'améliorations et leurs bénéfices potentiels.

Mesurer
- Nous prenons une mesure de la performance initiale de l'activité (ceci peut être basé sur beaucoup d'éléments). Nous noterons la « nouvelle » mesure une fois que le pilote est en cours.

Analyser
- Une analyse est fait pour décider quelles solutions sont acceptées par les représentants de la demande. 

Améliorer
- La solution choisi est appliquée au processus ou/et le produit de travail et un pilote est fait pour mesurer le bénéfice.

Contrôler
- Une fois que le changement a été piloté et approuvé par les représentants assignés dans la phase « Définir », une formation est planifiée et le changement est incorporé aux processus standards de développement. Finalement, l'élément est ajouté dans la liste de contrôle du processus affecté par l'assurance qualité (PPQA).