Business : Le développement axé sur le comportement convient-il à votre projet?

Ces étapes sont terminées dans un ordre séquentiel et chacune aura des protagonistes bien définis: les exigences sont dirigées par le Propriétaire du produit, La conception sera prise par Art créatif département, la mise en œuvre est lorsque le Développement équipe apparaît, la vérification marque l’introduction de la QA équipe, et enfin, la maintenance sera prise en charge soit par un équipe différente ou un sous-ensemble plus petit de toutes les équipes précédentes.

Généralement, dans Waterfall, vous ne souhaitez démarrer chaque phase que lorsque vous avez terminé l’étape précédente. C’est pourquoi, idéalement, vous investirez au moins 30% -40% de vos estimations de projet aux deux premières étapes (Exigences et conception), car il sera moins coûteux de réparer tout ce qui ne fonctionne pas à cette phase, par opposition à plus tard lors de la mise en œuvre ou de la vérification.

Les critiques adressées au modèle tournent autour, du moins àCascade pure« , Dans la mesure où, bien planifiées et robustes que soient vos exigences et votre conception, la prémisse est que chaque unité de travail agit indépendamment et atteintle travail est fait« Bouton à la fin de leur étape, signifie que l’imprévisibilité, les changements dans les objectifs commerciaux, les hypothèses ignorées, ne sont pas et, vous l’avez deviné… ça va bousiller tout le projet.

Autre Agile des méthodologies ont évolué à partir de ce modèle, telles que Application rapide (ou logiciel) Développement. RAD met plus accent sur le développement et la livraison, et s’appuie souvent fortement sur des prototypes pour piloter les efforts des ingénieurs. Pour être juste, en raison de son accent sur la vitesse, RAD est le plus souvent associé aux étapes de maintenance du projet et les versions modifiées de celui-ci ont tenté de corriger le manque d’accent dans la conception des produits.

Développement basé sur le sprint, autrement appelé Scrum, tente de combler les lacunes entre le développement axé sur la livraison et la vitesse et, en même temps, en tirant parti de l’implication de tous les membres d’une équipe.

L’idée est de garder des équipes petites, pas plus de 10 personnes, et d’avancer dans des objectifs progressifs successifs (ou Sprints). Maintenant, cette approche a le avantage de donner à l’équipe un chemin vers un cours correct à la volée. Si l’entreprise décide d’aller dans une direction différente, il est assez facile d’ajuster les objectifs d’un sprint au suivant.

Malheureusement, le intensité du rythme de Scrum peut affecter le burn out de l’équipe. J’ai rencontré de nombreux développeurs, travaillant sous le système Scrum, qui finissent par se sentir bloqués et épuisés seulement après quelques sprints. De même, puisque la prémisse du modèle est que le «problème« Ne peut pas être compris d’avance, il doit être reconnu lorsque l’équipe y travaille, accorder moins d’attention à l’intégration de produits et de nouvelles fonctionnalités avec l’ensemble de l’écosystème que ces fonctionnalités vont être publiées.

Enfin, il est important de considérer la figure majeure du Scrum Master. La position de cette personne joue un grand rôle dans le déroulement de chaque itération, nécessitant une bonne maîtrise du produit et des compétences de chacun des membres de l’équipe. Un mauvais Scrum Master peut s’avérer être un gros handicap pour un projet rapide et multicouche.