Votre équipe fonctionne-t-elle bien sans suivre une méthodologie de travail (comme la mêlée)?

J'ai travaillé dans un certain nombre de petites équipes au cours des 9 dernières années. Chacun avait les bonnes pratiques évidentes, telles que les réunions courtes, le contrôle des révisions, le logiciel d'intégration continue, le suivi des problèmes, etc.

Au cours de ces 9 années, je n'ai jamais beaucoup entendu parler des méthodologies de développement; par exemple, il n'y a jamais eu de "nous faisons de la mêlée", ou "laisse faire agile", ou rien de plus qu'une référence passagère. Toutes les équipes semblaient bien fonctionner, sans suivre beaucoup de processus, nous étions simplement fluides et fonctionnions naturellement bien.

Quelqu'un d'autre a-t-il progressé pendant de longues périodes sans rencontrer de mêlée / agile / etc?

La seule exposition que j'ai eue sur ces sites est celle de sites comme celui-ci. J'ai lu des questions comme Sprint Meetings - De quoi parler ... et tout le discours semble décrire presque robotique comme des gens qui suivent une méthodologie de machine à états finis. Est-ce vraiment (quoique exagéré) comme ça? Je me demande si les gens qui publient sur Internet ne sont que de fervents partisans des "meilleures pratiques", avec des vues de manuels similaires, ne reflétant pas vraiment comment les gens travaillent ... Ou que j'ai rencontré des équipes qui élaborent leurs processus naturellement.

De plus (je suis au Royaume-Uni, ce qui peut être pertinent) ... Je pense que si une méthodologie était présentée à l'une des équipes sur lesquelles je travaillerais, ils la rejetteraient simplement comme étant stupide et inutile ... sur. J'aurais tendance à être d'accord, suivre les processus semble un peu contre nature. Est-ce typique ou courant?

Plus de 20 ans d'expérience en développement ici, et je n'ai jamais utilisé de méthodologie formelle. Je n'en ai jamais eu besoin et je n'envisage pas d'en utiliser un à l'avenir. Les méthodologies peuvent convenir à certaines personnes, mais elles ne remplacent pas les programmeurs qualifiés qui écrivent du bon code testé.

Personnellement, je pense qu'il incomberait à beaucoup de gens de se soucier moins de suivre la nouvelle méthodologie la plus chaude de la journée et de se concentrer davantage sur la qualité du code.

Honnêtement, si votre petite équipe a bien travaillé sans incident majeur pendant toutes ces années sans penser au processus, vous faisiez probablement une forme d'agilité. Tout processus agile signifie qu'il est conforme au "Manifeste Agile" http://agilemanifesto.org/ qui a peu de choses surprenantes à dire sur les itératifs, les story-boards, etc. Le tout premier locataire d'agile est que vous préférez "les individus et interactions sur les processus et les outils ". Toute équipe qui travaille bien ensemble n'a pas vraiment besoin de réfléchir sérieusement au processus.

Les différentes marques d'agile (comme Scrum, etc.) sont très utiles si vous avez une toute nouvelle équipe qui n'est pas habituée à travailler ensemble. Ils ont en quelque sorte défini le cadre de la façon de construire une équipe cohérente, qui à son tour va créer un produit cohérent.

Si ce que vous faites fonctionne, continuez à le faire. Si vous êtes constamment en retard avec les livrables, que vous devez régulièrement faire des heures supplémentaires ou que vous devez corriger des bugs majeurs après avoir déployé quelque chose - alors quelque chose ne va pas. C'est à ce moment que vous effectuez une série de petits changements pour résoudre les problèmes.

Si tout va bien et que tout va toujours bien, il n'y a pas de problème - donc introduire une nouvelle méthodologie (vos équipes auront suivi une sorte de méthodologie - formelle ou autre) serait en effet une perte de temps.

Cependant, lorsque les méthodologies aident vraiment, c'est lorsque l'équipe rencontre des problèmes ou se fait poser des problèmes à partir de sources externes - une méthodologie ne présente pas seulement de bonnes pratiques, elle vous aide à les protéger . Il est beaucoup plus facile de maintenir les bonnes pratiques sous stress lorsque vous les faites consciemment, sinon elles peuvent rapidement être éliminées.

Je ne pense pas que vous ayez nécessairement besoin d'une méthodologie formelle - mais chaque équipe a besoin d'une sorte de modèle (pas nécessairement répété, cela pourrait être axé sur les événements) pour que son travail soit efficace à mon humble avis.

Si vous n'avez pas de problème à résoudre, vous avez de la chance.

J'ai vu de nombreuses équipes (surtout dans de très petites entreprises) bien fonctionner sans méthodologie définie.

Mettre en œuvre une méthodologie (ou technique) parce que c'est amusant ou parce que vous lisez ce billet de blog sur Internet est très dangereux.

Si vous allez bien, ne changez rien. Essayez quelques optimisations quand vous le pouvez.

Il existe un large éventail de méthodologies, certaines très sensées, d'autres proches de la folie. Ils semblent tous codifier le bon sens , leur donner un nom drôle, puis vendre beaucoup de livres / séminaires / etc.

Maintenant, si votre direction, ou même votre équipe, manque de bon sens et n'a pas organiquement leurs propres méthodologies sensées en place (consciemment ou non), alors elles peuvent valoir la peine d'être étudiées, puis de prendre en compte les parties de la méthodologie pertinentes aux expériences de cette équipe .

L'imposition générale des dernières <insert-buzzword-here>pratiques de travail est susceptible de créer plus de confusion qu'elle ne vise à en résoudre. Mais généralement, il peut fournir de nombreuses mesures de case à cocher qu'un responsable de ligne non codant peut cocher avec enthousiasme.

Peut-être que vous ne l'appeliez pas agile ou scrum, mais cela ne signifie pas que vous n'aviez aucun processus et que vous ne l'utilisiez pas.

Tout comme le développement de logiciels lui-même. Vous utiliserez probablement plusieurs modèles de conception même si vous n'y pensez pas explicitement par leur nom.