Quelle méthodologie de programmation nous conviendrait le mieux?

Malheureusement, quelqu'un a appris le mot "Agile" à notre haute direction et maintenant, ils veulent que nous allions dans ce sens. J'ai une compréhension périphérique de l'agilité (en principe) mais je ne l'ai jamais utilisée dans la pratique. D'après ce que je sais, cela ne conviendra pas à notre organisation. En ce moment, les choses sont assez grincheuses. Voici comment c'est;

Nous sommes une très petite équipe - deux développeurs, un DBA, un designer. L'entreprise pour laquelle je travaille gagne une somme disproportionnée par rapport à sa taille, et près de 95% de ce montant est de la vente en ligne pure.

Du point de vue du développement, nous sommes soumis à de nombreuses invasions de bureau au cours d'une journée type (nous sommes également du support technique et du développement), le travail peut régulièrement tomber du ciel à tout moment si un membre de l'équipe de vente promet quelque chose à quelqu'un . Nous entreprenons également des projets plus importants, et ils sont un cauchemar avec des interruptions constantes. Certains d'entre nous commencent à arracher nos cheveux! Les plans de projet sont élaborés par des responsables non techniques dans des feuilles de calcul Excel, où ils essaient de décomposer la tâche en phrases de petite taille qu'ils peuvent comprendre et mettre une date à côté de chacun. Ces dates sont toujours hideusement irréalistes et souvent manquées, et nos réunions (que nous avons environ chaque semaine) sont régulièrement remplies de moments gênants avec des gens qui demandent "pourquoi cela n'a-t-il pas encore été fait".

Je suis quasiment sûr qu'Agile n'est pas fait pour nous. Maintenant, étant donné que (et j'ai essayé) cette entreprise ne changera pas ses façons de faire et que seule l'équipe de développement est disposée à changer, existe-t-il une méthodologie de développement que nous pourrions adopter qui est un bon moyen de simplement nous sauver un peu de raison?

Agile a été conçu pour répondre à la plupart des problèmes que vous rencontrez. Si la direction a vraiment adhéré et ne pervertit pas le processus, vous pourriez voir une grande amélioration. Permettez-moi d'aborder vos problèmes point par point. Mon expérience est avec Scrum, donc je vais parler de ce point de vue, mais je suis sûr que d'autres implémentations ont des avantages similaires.

• travail tombant du ciel Ces histoires sont placées au bas de l'arriéré jusqu'à ce que le propriétaire du produit et l'équipe puissent se rencontrer pour accepter de le faire monter. Sa priorité est déterminée par rapport à tous les autres engagements de votre équipe, et cette priorité est visible pour chaque partie prenante intéressée. Il devrait être extrêmement rare d'ajouter une nouvelle fonctionnalité au milieu d'un sprint, et seuls les bogues les plus prioritaires devraient être autorisés à interrompre un sprint. Il est étonnant de voir combien d '"urgences" peuvent attendre jusqu'à la fin de la semaine prochaine, alors que cela se fait régulièrement.
• entreprendre des projets plus importants Vous aurez la visibilité nécessaire pour montrer comment les priorités à court terme affectent vos projets à long terme. Si les gens déplacent continuellement des histoires d'utilisateurs devant vos projets à long terme, c'est bien, mais pour prendre cette décision, tout le monde saura l'impact que cela aura sur le calendrier du projet à long terme.
• les plans de projet sont élaborés par des responsables non techniques Les histoires d'utilisateurs sont censées être écrites d'un point de vue non technique, mais votre équipe Scrum doit être habilitée à faire des estimations et à déterminer les détails de la mise en œuvre.
• les dates sont hideusement irréalistes Votre équipe gère toutes les estimations, car vous êtes ceux qui savent ce que vous faites. Si ces estimations ne sont pas acceptables pour l'entreprise, elles doivent décider comment hiérarchiser les fonctionnalités. S'ils ont besoin de plus de travail que vous ne pouvez en gérer, la nécessité d'embaucher plus de personnes sera clairement visible.
• les dates sont souvent manquées Premièrement, vos estimations seront plus réalistes, ce qui devrait aider. , Vous mordre des morceaux plus petits et en fait aussi la finition eux, ce qui contribue à la sensation d'entreprise comme vous avez produit quelque chose d' utile , même si ce ne complète des fonctionnalités.
• réunions remplies de moments difficiles Agile a plus de visibilité et un cycle de rétroaction beaucoup plus rapide, avec un propriétaire de produit fortement impliqué. Vos problèmes de blocage et vos raisons de retard ne devraient pas être une surprise.
• faisant également du support technique Contrairement à la croyance populaire, l'agilité n'est pas incompatible avec un horaire divisé. Scrum prend en compte vos interruptions dans la vitesse de votre équipe. Si vous passez normalement la moitié de votre temps à faire du support technique, vous aurez simplement la moitié de la vitesse.

Ce que la direction et les ventes doivent réaliser, c'est que l'agilité n'est pas un moyen d'exercer un contrôle plus strict sur l'équipe de développement, elle donne à l'équipe plus d'autonomie pour faire ce qu'elle est bonne tout en aidant l'entreprise à considérer de manière réaliste toutes ses priorités lors de l'attribution du travail à l'équipe.

Je dirais profiter de vos caprices de gestion! On dirait qu'ils vous rendent service et vous donnent un moyen d'améliorer vos méthodes de travail.

Dites-leur que nous irons agiles, cela nécessite entre autres: -

• une séparation du développement et du soutien
• un processus formel de collecte des exigences - sous le contrôle de l'équipe informatique. "Histoires" etc. semble très vague - mais c'est en fait une méthode "formelle" habillée pour avoir l'air informelle.
• la planification est sous le contrôle de l'équipe informatique.

S'ils n'acceptent pas cela, dites-leur que vous ne pouvez pas devenir agile.

Agile n'est pas une méthodologie de programmation, Agile est une méthodologie de gestion de projet. Si la haute direction veut vraiment que vous essayiez ce nouveau mot à la mode qu'elle a trouvé, elle doit être en mesure de comprendre que la méthode Agile commence par le haut et implique la direction à chaque étape du processus. Si vous avez besoin de leur donner une bonne dose de réalité, organisez peut-être une présentation Powerpoint de 30 minutes sur Agile pour leur donner un peu d'éducation. Les gestionnaires adorent Powerpoint.

Cependant, si, comme vous le dites, l'équipe de développement est la seule personne prête à changer, aucune méthodologie de développement ne pourra vous aider. Sans allégement du reste de vos fonctions, des interruptions continueront de se produire et il vous sera toujours demandé de respecter des délais que vous ne pouvez tout simplement pas respecter.

Mon conseil dans ce scénario est d'éduquer, et non de réprimander, la direction sur la façon dont elle est vraiment en première ligne.

Aucune méthodologie de développement de logiciel et de gestion de projet ne peut aider dans une organisation où les vendeurs dictent le calendrier quotidien. Comment êtes-vous censé gérer un projet au milieu d'une semaine de travail aussi chaotique et distraite?

De nombreux cadres supérieurs voient la valeur d'Agile et en veulent les avantages, mais ils ne sont presque jamais en mesure d'apporter les changements internes nécessaires pour s'assurer que le déménagement est réussi. Les seuls magasins Agile à succès que j'ai connus avaient commencé de cette façon. Je ne me souviens pas d'un seul cas dans mon expérience professionnelle d'un magasin de développement de logiciels de gestion des ventes ou en cascade qui a pris la décision car cela nécessite un changement fondamental de culture.

Ce changement de culture est-il possible? Oui, mais dans votre cas, certainement pas.

Un changement de culture est généralement rendu nécessaire par un concurrent menaçant l'existence de l'entreprise ou une situation de création ou de rupture ou une autre situation similaire pour justifier une réorganisation. Dans votre situation, votre entreprise est à l'autre bout du spectre où l'argent est facile en ce moment et tout le monde grossit.

Les entreprises ne changent JAMAIS de l'intérieur lorsque l'argent est facile. Pourquoi devraient-ils, ils réussissent malgré les échecs de développement logiciel, pas à cause des succès de développement logiciel.

Mon dernier conseil est que si j'étais vous je chercherais mieux. Les gens ici ont de bons conseils, mais j'ai déjà vu cette chanson et cette danse et cela ne fonctionne tout simplement pas dans votre situation.

regardez extremeprogramming.org - XP est une forme d'Agile avec des aspects faciles à comprendre que vous pouvez choisir et choisir à la carte; un très bon point de départ

l'engagement du client à ne pas changer d'avis lors d'une interaction serait un bon point de départ pour votre environnement, à en juger par le son ;-)

Si l'on considère le paysage des méthodologies, à la fois traditionnelles et contemporaines, on se rendrait compte que "Agile" est plus une "anti-méthodologie" qu'une méthodologie. Les modèles visent à représenter la solution du «meilleur cas» à un problème donné dans un contexte particulier. Les tentatives de violation directe d'une telle solution ou d'un tel schéma sont généralement appelées «anti-schémas» ou pratiques pires. De même, alors que les véritables méthodologies de développement logiciel tentent de prescrire les meilleures pratiques en matière de développement de solutions, "Agile" (Scrum, XP, etc.) tente de violer directement toutes les structures du processus de développement logiciel, en faveur d'un processus aléatoire et chaotique. approche - qui (récemment), semble également exiger des applaudissements de spectateurs (naïfs).

Cela dit, il convient de garder à l'esprit le contexte dans lequel la philosophie Agile est née. Bien que des méthodologies itératives sophistiquées (par exemple un processus unifié) existaient à l'époque, la méthodologie principale était toujours l'ancienne approche en cascade, qui prescrivait une "meilleure pratique" d'analyse complète des exigences, puis une conception complète, puis développait / codait la solution, puis mettait en œuvre la solution. De toute évidence, cette approche d'ingénierie du développement logiciel était mal avisée - et a entraîné des tas de paperasse avant (et parfois sans jamais) de voir une solution exécutable.

Cependant, cela ne justifie toujours pas le rejet du bébé avec l'eau du bain, comme ce fut le cas avec les conjurateurs d'Agile. L'approche Agile impose presque une négation directe de tout ce qui a été utilisé avant - sauf peut-être le codage réel de la solution. De toute évidence, cela indique une perspicacité limitée de la part de ses auteurs, ou peut-être est-ce simplement un cas "il n'y en a pas d'aussi aveugles que ceux qui ne veulent pas voir".

Néanmoins, le mérite de l'agile est qu'il encourage les processus rationalisés et se concentre sur le code exécutable - qui est inévitablement votre produit livrable ultime.

MAINTENANT, pour répondre plus directement à votre question:

Compte tenu de votre aperçu de votre environnement, je vous suggère tout d'abord de sélectionner une implémentation Agile (ie Scrum, XP, etc.). Ensuite, personnalisez l'approche pour adapter votre environnement, en définissant un processus clair de la façon dont votre équipe fonctionnera, par exemple:

• Recevoir la demande des utilisateurs;

• Prioriser les demandes des utilisateurs;

• Gage de l'impact de l'amélioration sur le système existant (peut-être lors de vos réunions de stand-up quotidiennes / hebdomadaires);

• Estimez le temps de développement de chaque amélioration - et communiquez-les à divers utilisateurs demandeurs;

• Effectuer des améliorations réelles sur le système existant (c.-à-d. Codage).

• Effectuer des tests utilisateurs - et obtenir l'engagement des utilisateurs (par exemple par e-mail) que les modifications demandées ont été mises en œuvre avec succès.

Cela devrait fournir une certaine structure (et ordre), tout en maintenant un semblant d'une approche Agile.

Cela dit, souvenez-vous que la vieille figure de style anglaise «As Agile as a monkey» n'a pas été inventée sans raison!

Je dirais que vous avez besoin d'une méthodologie telle qu'Agile est essentielle pour votre équipe. Comme votre entreprise est tellement désorganisée, vous devez être plus organisé au sein de votre propre équipe de développement. Je ne pense pas cependant que vos directeurs non techniques devraient y être pour quelque chose.

Si vous allez repousser vos vendeurs et exiger des délais réalistes, vous devez le justifier avec des plans organisés.

Également sur une note séparée s'ils vous viennent avec des estimations sans consulter le technicien, refusez-les simplement.

Peut-être que se concentrer sur les aspects incrémentiels / itératifs est ce que votre équipe et les parties prenantes impliquées doivent être en mesure de fournir régulièrement et de manière cohérente. Au fil du temps, l'équipe de vente et la direction gagneront à croire que lorsqu'elles soumettront une nouvelle demande de fonctionnalité, elles pourront être sûres que votre équipe livrera dans un délai approprié.

Bien sûr, vous devez investir dans des tests unitaires / système / de régression, des constructions automatisées, des aliments pour chiens, etc., pour y arriver si vous n'y êtes pas déjà.

Je suggère d'abord de rassembler quelques données. Asseyez-vous à un moment calme et découvrez ce qu'est réellement le statu quo - comment les choses se font. Si la direction est résolue à implémenter quelque chose qu'elle peut appeler agile, alors trouvez quelque chose qui fonctionnerait pour votre équipe, rédigez un document, giflez "Agile" sur le nom et vous êtes prêt à partir. Gardez à l'esprit que la seule chose qu'ils savent vraiment sur l'agile est le mot et une vague association avec rapidité pour sa définition habituelle en anglais. Donc, ce que je préconise, c'est que votre équipe se place devant le problème, trouve une saveur qui fonctionne pour vous, puis la présente à votre direction de la manière Agile (tm). Sinon, certains PHB vont prendre un livre et essayer d'insérer la cheville carrée dans le trou rond et personne ne sera content.

Si vous optez pour une forme «pure» d'agilité, il peut être difficile pour votre équipe de remplir également le rôle de support. Avouons-le, votre patron peut avoir du mal à accepter que les membres de votre équipe répondent aux demandes du service d'assistance en disant "laissez-moi créer un élément de backlog, j'y arriverai dans (le temps jusqu'à la fin du sprint) semaines."

Le plus gros obstacle est celui de l'argent. Si tout est de la sauce verte, il est beaucoup plus difficile de dire que quelque chose ne va pas et doit changer.

Bonne chance.

Au contraire, il me semble qu'une méthode Agile est exactement ce dont vous avez besoin pour faire face aux délais manqués, aux attentes irréalistes et aux projets mal planifiés.

Votre direction a indiqué qu'elle était intéressée par ce nouveau mot Buzz. Très probablement, ils voudront l'utiliser pour augmenter la commercialisation de vos produits. ce n'est pas nécessairement une mauvaise chose, mais cela devra être géré très soigneusement si vous voulez faire fonctionner une méthode Agile pour vous.

La moitié de la bataille consiste à obtenir l'adhésion de la direction. Les avoir réceptifs à l'idée même d'Agile est la majeure partie de la bataille. Le reste consiste à s'assurer que leurs attentes sont gérées de manière à ce qu'ils continuent à vouloir que vous soyez agile, et à éviter qu'ils ne soient désenchantés quand et si vos managers ont l'impression que leur contrôle sur la gestion de projet leur passe largement entre les doigts.

Avant que votre entreprise ne décide quoi que ce soit, je recommanderais de prendre un coach Agile pour faire un séminaire et un atelier d'une demi-journée. Faites en sorte que vous réfléchissiez tous, en tant qu'équipe - gestionnaires et développeurs - à ce que vous pensez qu'Agile fonctionnera pour vous et ce que vous ressentez ne fonctionnera pas. Si, d'autre part, la direction fait confiance à votre jugement, vous devrez vous familiariser avec un certain nombre de pratiques et de méthodes agiles et créer un séminaire ou le vôtre. Personnellement, je m'orienterais vers un coach expérimenté pour ne pas perdre beaucoup de temps et maintenir l'élan. En attendant, prenez une copie de quelques bons livres Agile comme références, lisez-les attentivement, mais laissez-les également traîner autour de votre bureau où la direction peut les voir. La psychologie subliminale peut faire des merveilles dans une situation comme celle que vous avez décrite.

Je recommanderais au moins de lire ce qui suit:

• Développement logiciel Lean - Mary & Tom Poppendieck
• Développement de logiciels agiles - Robert C. Martin

et pour un crédit supplémentaire (parce que je pense que c'est un excellent compagnon pour les autres livres que j'ai mentionnés):

• Code propre - Robert C. Martin