Gestion de projet traditionnelle vs Scrum - Square Pegs S'adapter à trous ronds

chefs de projet IT traditionnels ont du mal à utiliser la méthodologie PMI quand il s'agit de développement de logiciels depuis des décennies. En utilisant la méthodologie de projet traditionnel de gestion pour le développement de logiciels est similaire à essayer de mettre une cheville carrée dans un trou rond; vous pouvez le forcer, mais il ne s'intègre pas aussi bien qu'il le devrait.

Au cours des dernières années, la méthodologie Agile a vraiment commencé à prendre de l'ampleur. Ceci est dû en grande partie à la popularité de Scrum, même si Agile a été autour pendant presque deux décennies. Scrum est l'un des cadres de plusieurs qui tombent sous l'égide Agile. Parmi les autres comprennent Extreme Programming (XP), Rational Unified Process (RUP), et Design for Six Sigma.

La théorie du contrôle

Il ya généralement deux types différents de la théorie du contrôle. Le premier est le sens (ou théorique) processus. C'est ce que la gestion de projet traditionnelle suit: il s'agit de commande et de contrôle. Il ya beaucoup, beaucoup de planification. Vous planifiez ce que vous attendez de se produire, puis appliquer le plan, parfois, peu importe les conditions. Enfin, ce procédé permet l'utilisation du contrôle des changements. Vous trouverez souvent un conseil de contrôle des changements qui supervise toute demande de changement.

Scrum, d'autre part, emploie ce qu'on appelle le processus empirique. Dans ce processus, vous apprenez que vous avancez. Au lieu de planifier tout à l'avant et de planification sur la façon de gérer le changement, les Etats processus empirique de «plan pour le changement." En fait, le processus empirique ouverte au changement par l'inspection et l'adaptation, deux des trois piliers qui soutiennent la mise en œuvre du contrôle de tous les processus empirique.

Les trois piliers

gestion de projet traditionnelle depuis des années a suivi le «triangle de fer», le temps, de coût et de qualité. Ce sont encore les trois piliers chaque gestionnaire de projet doit jongler. Dans un monde idéal, les projets devraient être livrés à temps, au titre du budget, et être de la plus haute qualité. En réalité, cela arrive rarement. Pour les projets de développement de logiciels, d'obtenir les trois ne se produit jamais.

Un ScrumMaster suit également trois piliers. Leurs piliers sont la transparence, l'inspection, et l'adaptation. La transparence implique une communication ouverte avec tous les membres de l'équipe de projet Scrum, et le ScrumMaster affiche fièrement graver leur équipe vers le bas des tableaux où tout le monde peut voir. Ils ont également examiner dans quelle mesure ils l'ont fait au cours de leur sprint lors de ce qui est connu comme une revue de sprint. Enfin, l'adaptation consiste à faire des changements et des améliorations à des tâches qui peuvent être améliorées.

Début de la transition

Pour de nombreuses entreprises essaient de faire la transition vers Agile, la première chose qu'ils doivent comprendre, c'est qu'un bon chef de projet ne sera pas nécessairement faire un bon ScrumMaster. Ils ne sont pas directement interchangeables. Contrairement à une pensée, un bon ScrumMaster ne pas avoir l'expérience de gestion de projet.

En pratique, le meilleur ScrumMaster sont généralement très techniques. Ancien PME et qui mène techniques en font un grand ScrumMaster. C'est parce qu'ils peuvent mieux s'identifier avec les développeurs, ils comprennent la grande différence entre le niveau d'effort (LOE) et la durée, et qu'ils puissent mieux aider à prioriser les caractéristiques ainsi que le propriétaire du produit.

Know Your Role

Il ya trois principaux rôles dans Scrum: le ScrumMaster, le propriétaire du produit, et l'équipe. Souvent, vous entendrez des personnes étant désignées comme étant «poulets» ou «porcs». Les gens qui forment l'un des trois rôles principaux sont désignés comme des «porcs», alors que tout le monde est appelé "poulets". Un «cochon» est quelqu'un qui s'engage dans le projet, tandis qu'un «poulet» est une personne qui participe simplement.

L'origine de ces termes provient de l'histoire suivante:

"Une poule et un cochon sont ensemble quand le poulet dit:« Commençons par faire un restaurant! "Le cochon il réfléchit et dit:« Qu'est-ce que nous appelons ce restaurant? "Le poulet dit:« Les œufs n Ham! "Le cochon dit: «Non merci, je serais engagé, mais vous n'avez qu'à participer!"

ScrumMaster

La tâche principale ScrumMaster est d'adhérer aux valeurs de Scrum, les pratiques et les règles. Ils sont un défenseur de Scrum et l'aider à se accepté et adopté dans toute l'organisation. Ils agissent également comme la figuration "bouclier". Le ScrumMaster protège l'équipe de politique en dehors du bruit et garantit que personne ne va directement à n'importe quel membre de l'équipe, sans suivre la chaîne appropriée de commandement. Cela permet à l'équipe de rester concentré sur la tâche à accomplir, et si une question est une priorité, le ScrumMaster et propriétaire du produit sera en discuter et établir des priorités dans le backlog de produit, le cas échéant.

Product Owner

La principale responsabilité du propriétaire du produit est de gérer le carnet de commandes de produits. Le propriétaire du produit est une personne seule, et non pas un comité. La collection des parties prenantes peuvent influencer le propriétaire du produit, mais le propriétaire du produit a le dernier mot. Le propriétaire du produit établit la priorité de chaque fonction / demande. Pour les propriétaires de produits nouveaux, le ScrumMaster travaillera en étroite collaboration pour lui apprendre comment faire leur travail.

L'équipe

L'équipe est responsable pour le tournage des articles sur le carnet de commandes de produits dans la fonctionnalité potentiellement livrable chaque Sprint. L'équipe Scrum est multi-fonctionnel. En d'autres termes, ils se composent de personnes avec une ou plusieurs spécialités, y compris, mais non limité à un contrôle de qualité, le développement, la conception de base de données, l'analyse commerciale. L'équipe est auto-organisation et l'auto-gestion. En tant que tel, tout le monde a le même titre: Scrum membre de l'équipe.

La taille de l'équipe devrait être autour de sept (7) personnes, plus ou moins 2. Cette taille ne comprend pas le propriétaire ScrumMaster et produit (sauf si elles sont les porcs qui travaillent sur les tâches incluses dans le backlog du sprint).

Haies de transition

Méthodologie Agile n'est pas conforme à la méthodologie PMI. C'est absolument le plus grand obstacle à surmonter et où le conflit interne de gestionnaires de projets se produit; encore plus pour les chevronnés PMP. Pour mener à bien la transition, le ministère doit choisir l'une ou l'autre quand il s'agit de développement logiciel. Défaut de se conformer aux principes Agile conduira à une transition a échoué.

Rôle double ou deux ressources différentes

Tout passage à Agile est en-et-de-soi un projet. Par conséquent, un gestionnaire de projet doit être choisi pour diriger cette transition. En outre, cycle de vie du ScrumMaster est tourné autour du développement logiciel, ce qui est seulement un sous-ensemble du cycle de vie du projet.

Comme tout gestionnaire de projet est conscient, être un gestionnaire de projet est un travail à plein-temps. Être un ScrumMaster est également un emploi à temps plein. La grande question est une ressource unique peut réaliser avec succès les deux rôles? La réponse, comme si les développeurs exigences tant de donnée est «ça dépend». Certaines entreprises vont essayer de combler ces deux postes avec une ressource unique en raison de contraintes budgétaires ou d'autres raisons. C'est une des raisons tout à fait acceptable, mais pas nécessairement la meilleure. Un gestionnaire de projet qui est un ScrumMaster certifié peut réaliser ce double rôle, mais cela est déconseillé.

Deprograming gestionnaires de projet

Traditionnels gestionnaires de projets axés sur plan doit être déprogrammée avant celui qu'ils peuvent devenir un coordinateur de projet agile. Le président Eisenhower a dit le mieux quand il a dit, "La planification est essentielle, les plans sont inutiles." Cette phrase résume la plus grande différence entre Agile et PMI. Le succès ne se mesure plus par la manière dont la triple contraintes sont équilibrées, il est seulement mesurée par le Client. La portée du projet n'est plus le conducteur; champ d'application est entraînée par le temps et le budget. Ce n'est plus le succès mesuré par l'achèvement des tâches et des commentaires phase porte elle est mesurée par la prestation de caractéristiques et de fonctions. Enfin, apprendre à embrasser le changement, c'est l'amour, vivre pour elle.

Travailler ensemble

Le gestionnaire de projet et ScrumMaster doivent être traités comme des pairs, si le projet soit couronné de succès. Le gestionnaire de projet est en charge de l'ensemble du projet, tandis que le ScrumMaster est en charge de la partie développement logiciel du projet. Il est très important que la direction ce qui concerne la différence.

Au cours du développement logiciel lui-même, le gestionnaire de projet doit laisser tourner le ScrumMaster Scrum en utilisant la méthodologie Agile, pas la méthodologie PMI. En tant que gestionnaire de projet, la partie difficile est «lâcher prise» et de faire confiance au ScrumMaster. Cette partie du groupe d'exécution de processus doit être considéré comme une «boîte noire». Le gestionnaire de projet est maintenant considéré comme un «poulet», il ou elle peut écouter, mais n'a aucun poids.

Devenir vraiment agiles

Beaucoup d'entreprises se sentent Agile simplement parce qu'ils font du développement logiciel itératif. Cependant, faire Cascade dans un mode itératif, n'est certainement pas Agile. Agile est beaucoup plus que de développement itératif et libère rapidement. La manière traditionnelle de penser PMI ne peut pas être le guide de tout mettre en œuvre Agile, il va devenir un obstacle. Il s'agit d'une toute nouvelle façon de penser, une toute nouvelle philosophie. Pour devenir vraiment agile, l'ensemble du département IT doit passer par un changement de paradigme.

Frank est le fondateur et consultant à protéiforme IT Management, LLC. (Http://proteanitmanagement.com/). Il est un consultant technique expérimenté, chef de file, et chef de projet dans les secteurs public et privé avec une solide expérience en gestion de projet, architecture des applications, et le développement d'applications. Ses spécialités sont l'affaire de techniques et de gestion de projet agile, contrôle de gestion du programme, et l'amélioration des processus.

Grâce à sa combinaison de l'entreprise et l'expertise technique, Frank a été en mesure d'apporter une valeur ajoutée aux équipes et les entreprises, en améliorant la communication entre les départements commerciaux et techniques, la réduction des exigences ambiguës, et augmentant le temps de mise sur le marché.

cet article est traduisé en francais
l'origine de cet article (en anglai): http://ezinearticles.com/?Traditional-Project-Management-vs-Scrum---Adapting-Square-Pegs-to-Round-Holes&id=4046842