Devs backend posés par les user stories

10

Je prévoyais de découper verticalement le développement back-end en histoires d'utilisateurs. Mais un gars du backend de notre équipe a commencé à se plaindre que cela rend leur travail invisible.

Ma réponse était que

  • lors des réunions de planification et d'examen du sprint, nous discutons des tâches de backend devant les parties prenantes afin de le rendre visible, et

  • le maintien d'une haute qualité pendant le projet entraînera un rythme de démarrage plus lent que les autres équipes, mais nous aurons une vitesse stable pendant le projet. Et la vitesse est très visible pour les parties prenantes.

Il insiste toujours pour avoir des histoires comme: "En tant que développeur, j'ai besoin d'une couche de domaine pour pouvoir encapsuler la logique métier."

Comment puis-je résoudre le problème avant qu'il ne pollue l'équipe?

La racine du problème est que notre direction considère systématiquement le travail de backend comme invisible et appelle les mineurs de développement soutenus, ou d'autres termes péjoratifs.

agile scrum team user-story Szili
la source
7
Je n'aurais pas les histoires de backend, elles n'ont aucun sens .. Cependant, je n'aimerais pas avoir ce genre de managers .. Je pensais que les développeurs backend étaient les rockstars il y a quelque temps
margabit
2
La création d'histoires back-end distinctes implique que le travail back-end peut être hiérarchisé séparément du front-end. Cela présente le risque que les priorités soient attribuées de telle sorte que le travail principal soit relégué au bas de l'arriéré jusqu'à ce qu'il soit réintégré dans les histoires frontales. Pour le problème avec le manque d'appréciation de la direction, je vous recommande de vous renseigner à ce sujet sur Workplace.SE.
Bart van Ingen Schenau
Ma solution fantastique implique des gifles occasionnelles de toutes les parties. gifle Arrête de pleurnicher. slap Arrêtez d'ignorer le rôle extrêmement important que les données et la logique métier contribuent au succès de l'entreprise qui paie notre loyer. slap Arrêtez de manger les déjeuners des autres. Ce n'est pas le réfrigérateur de ta maman.
Erik Reppen
1
découpez les sujets verticalement, puis découpez les histoires résultantes en tâches horizontales.
jwenting

Réponses:

4

Il y a quelques petites choses qui ne vont pas dans la situation décrite, le problème évident étant le manque de respect accordé aux développeurs back-end. Comme cette question est étiquetée agile, je vais repousser d'autres réponses suggérant que ce n'est qu'un problème social. Il y a plusieurs mauvaises odeurs et anti-schémas possibles dans votre histoire, dont aucun n'a à voir avec une gestion ignorante ou même comment vous découpez les histoires.

Le fait qu'un groupe d'individus de l'équipe se sentent lésés de ne pas avoir obtenu la gloire du travail achevé fait penser à plusieurs problèmes possibles.

  • Il ne devrait pas y avoir de personnes qui ne font que du développement back-end. Une approche Agile commune consiste à avoir des équipes interfonctionnelles composées de spécialistes de la généralisation qui pratiquent la propriété partagée du code. Les individus ne devraient pas se concentrer exclusivement sur le développement back-end ou front-end, bien qu'ils soient certainement mieux plus expérimentés ou meilleurs dans certaines choses que dans d'autres.
  • L'architecture ne gagne pas de valeur. Du point de vue d'un utilisateur - la seule perspective qui compte vraiment - peu importe si vous avez des couches ou des langues de domaine ou même si la solution est programmée. La seule chose qui compte est de savoir si vous avez créé de la valeur pour les utilisateurs. L '«histoire» proposée par le développeur principal est une exigence absurde - c'est un résumé des décisions de conception qui, du point de vue d'un utilisateur / client, ne font rien pour atteindre la fonctionnalité souhaitée. En d'autres termes, toute histoire d'utilisateur donnée peut être réalisée par un certain nombre de conceptions d'architecture différentes. Il est possible qu'une user story puisse être complétée sans aucune modification du back-end. Cela n'en fait pas une histoire invalide.
  • La pensée systémique est toujours critique. Bien que l'architecture ne gagne pas de valeur, elle est toujours essentielle au succès. Le développeur principal a des préoccupations valables. Vous devriez penser à la façon dont vous allez construire le système. Vous devriez écrire ces décisions. L'ensemble du système est important même si seules les fonctionnalités frontales sont les choses qui obtiendront toute la gloire.

Ma recommandation est de traiter l'architecture comme un citoyen de première classe - mais faites-le de la bonne façon. Organisez un atelier sur les attributs de qualité avec les parties prenantes . Impliquez les principales parties prenantes dans les revues d'architecture , ou du moins résumez les décisions de conception essentielles à des étapes importantes. Dessinez l'architecture sur un grand papier et rendez-la visible pour que toute l'équipe puisse la voir.

Exigez que tout le monde se développe partout dans le système (front-end et back-end), programmez les paires si vous en avez besoin pour que cela puisse se produire efficacement. Continuez à créer des user stories centrées sur l'utilisateur. Mais identifiez également les principaux scénarios d'attributs de qualité qui montrent pourquoi le système est conçu tel qu'il est et guide la prise de décision concernant la conception «dorsale». Élevez la conception de l'architecture afin qu'elle ne soit plus invisible.

Michael
la source
1
Merci pour une réponse concrète! Je voudrais clarifier un peu la compréhension causée par ma mauvaise formulation. Il n'est pas seulement un "développeur backend", il travaille partout dans la pile, même dans le firmware. Son problème est que l'architecture du backend n'est pas correctement reconnue. Et tandis que l'architecture ne gagne pas de valeur par elle-même, une architecture bâclée peut casser des systèmes ou du moins les rendre très coûteux à entretenir. Mon plan était de faciliter plus de discussions sur l'architecture lors des réunions d'examen et de planification, et l'atelier de qualité ressemble également à un excellent outil!
Szili
FWIW, il n'est pas toujours pratique de faire travailler la pile complète par un développeur. Une exigence dans mon entreprise actuelle pourrait impliquer le développement CICS sur un ordinateur central IBM, MQ, Java dans Mule ESB, Datapower, puis enfin une interface utilisateur Web riche avec jquery et d'autres modèles. Une autre user story peut impliquer CORBA de parler VMS COBOL, et un autre backend est écrit en Gupta.
Alan Shutko
@AlanShutko - exactement. "L'avant d'une personne est l'arrière d'une autre personne", n'est-ce pas? C'est l'une des raisons pour lesquelles je n'aime pas l'argot comme "back end" et "front end", surtout quand on parle de plusieurs composants dans un système. Votre point est extrêmement important! Même «pile complète» est un terme relatif qui peut signifier différentes choses dans différentes parties d'un système!
Michael
11

Cela semble être un problème social, il faudra donc une solution sociale.

Si (si je vous comprends bien) les développeurs d'arrière-plan se sentent ignorés et méprisés, et estiment que leur travail n'est pas suffisamment valorisé, alors le processus de développement ne peut pas faire grand-chose pour changer cela.

Si je comprends bien, j'ai l'impression que les développeurs estiment qu'ils devraient au moins avoir leurs "propres" user stories, afin qu'ils puissent pointer du doigt vers eux et dire "C'est ce que nous avons fait, juste nous backend les gars / filles". Cependant, avoir des histoires tranchées "horizontalement" comme ceci est une mauvaise idée, et je suis d'accord avec vous pour les trancher verticalement.

La meilleure solution est probablement d'avoir une conversation silencieuse avec le (s) développeur (s) en question (individuellement ou en groupe), et d'aborder le problème sous-jacent, qui semble être un problème de respect. À un certain point, cela devra probablement être transmis à la direction.

sleske
la source
Merci pour vos réponses. Le problème est en effet social. Aujourd'hui, nous avons discuté de l'argument d'hier, et le développeur en question m'a dit qu'il s'agissait davantage d'années de manque de respect systématique de son travail d'arrière-plan que de sa vision de notre projet actuel et de sa compréhension du processus Scrum. Nous avons convenu d'aller de l'avant avec des histoires tranchées verticalement.
Szili
1
@Szili: Le travail back-end est-il si mauvais qu'il ne mérite aucun respect, ou est-il simplement coché qu'il n'est pas reconnu?
Blrfl
Son travail backend est excellent. Une bonne reconnaissance et même l'intimidation de la direction sont le problème.
Szili
4

La racine du problème est que notre direction considère systématiquement le travail de backend comme invisible et appelle les mineurs de développement soutenus, ou d'autres termes péjoratifs.

En effet, c'est le problème. Il est évident que vous ne le résoudrez pas avec des histoires!

En général, l'une des caractéristiques du développement agile est la transparence. Cela signifie également que cela rend vos problèmes d'organisation plus manifestes .

La solution agile standard à ce problème consiste à adopter une approche plus "verticale" ou "full-stack" du développement, où vos développeurs backend prennent les histoires de haut en bas au lieu de simplement travailler dans leur zone de confort du niveau back end, et les développeurs frontend s'étendent également vers le backend (*).

En d'autres termes: faites en sorte que tout le monde produise de la valeur pour vos utilisateurs finaux.

(*) Remarque: toutes les histoires n'ont pas besoin d'avoir un composant frontal ou un composant principal. Les éléments de l'interface utilisateur peuvent être remaniés sans travail d'arrière-plan supplémentaire, et les performances sont une fonctionnalité .

Sklivvz
la source
3
On dirait que vous n'avez aucune compréhension du développement backend. Voyez à quel point un bon gars du backend a peu de valeur lorsque les gars du front-end font toute la modélisation des données et l'implémentation de la logique dans le front-end, puis attendent six mois. La plupart des bonnes techniques ne sont pas bonnes pour produire de la valeur immédiate, c'est pour produire des dividendes à long terme. Votre approche appliquée à la construction de ponts ferait que chaque pont ne durerait qu'une semaine et n'aurait pas de plan ou d'architecte, car ceux-ci ne sont pas de valeur immédiate.
Jimmy Hoffa
1
Non @JimmyHoffa Je connais très bien le développement back-end. Ma réponse est à peu près agile. Comme vous le remarquerez peut-être, je ne préconise pas d'avoir des personnes frontales uniquement. Si vous n'aimez pas l'agilité, ne l'utilisez pas, mais je décris simplement comment fonctionne une méthodologie, alors ne présumez rien de moi ou quoi que ce soit d'autre.
Sklivvz
2
La partie où elle s'éloigne est que vous dites que les gars du back-end ne produisent pas de valeur et devraient simplement faire du travail frontal, si ce n'est pas votre intention dans cette réponse, vous devriez vraiment le reformuler pour être plus clair ce que tu veux dire ici.
Jimmy Hoffa
1
@JimmyHoffa Mais ils ne produisent aucune valeur pour l'utilisateur final. S'il s'agissait d'une équipe de développeurs back-end uniquement, les utilisateurs seraient les développeurs front-end. Dans ce cas, votre raisonnement aurait du sens, mais cela ne semble pas être le cas.
Sklivvz
1
Si dans votre monde, la valeur n'est produite que par la création d'un produit interactif par l'utilisateur et que les développeurs back-end ne sont pas nécessaires à cela, alors dans votre monde, les architectes et les chefs de projet, les analystes commerciaux, les RH et tout le monde ne sont pas pertinents non plus. Dans mon monde, la valeur est produite par la qualité de la conception et de la mise en œuvre de systèmes, de sorte que le développement de fonctionnalités futures n'implique pas de se promener à travers la toile d'araignée d'une base de données d'accès, car seul le produit interactif par l'utilisateur a été valorisé ... La mise en œuvre de la qualité est une valeur . Peut-être pas immédiatement, mais à long terme.
Jimmy Hoffa
1

Vos problèmes sont:

  • Vous avez des couches de gestion dans votre entreprise où elles ne servent à rien. Scrum, agile, je m'en fiche. La gestion et le développement doivent être isolés des préoccupations commerciales gérées par un chef de produit qui a un indice! @ # $ Ing sur la technologie. Peut-être que cela a fonctionné pour Steve Jobs, mais je n'ai jamais été dans une situation où les gestionnaires non adeptes de la technologie étant proches du développement étaient une chose saine ou, finalement, servaient à produire le meilleur produit de qualité qu'une équipe aurait pu fabriquer.

  • Certains développeurs sont plus préoccupés par les apparences que par la résolution de problèmes. C'est soit un problème de culture très grave (semble probable étant donné tout ce phénomène de "mineur") et / ou vous avez un problème de qualité de développement, ce qui ne me choquerait pas non plus étant donné le manque de confiance.

Éloignez les personnes qui n'ont pas besoin d'être présentes de la planification et du stand-up. Quiconque pense que le back-end est moins important que le front-end est quelqu'un qui n'a pas besoin d'être là et qui, en fait, entrave le processus en étant là.

Histoires de fossé. Oui. Je suis sérieux. S'ils causent ce genre de problèmes, jetez-les dans le sas. Dans mon travail actuel, nous nous en tenons simplement aux critères "terminés" pour une tâche donnée, qui restent généralement plus concentrés sur l'application que l'utilisateur de celle-ci, ce qui peut offenser ceux qui pensent que l'agilité (qui change constamment depuis 20 ans) a gagné " t fonctionne si vous ne le suivez pas à la lettre, mais vraiment si nous sommes des pros, nous n'avons besoin de rien qui nous cause des problèmes. Froissez-les, jetez-les sur votre épaule.

Et vous voudrez peut-être rappeler à ce développeur que les personnes dont il a vraiment besoin de s'inquiéter sont ses pairs immédiats, pas les gens qui sont trop ignorants pour participer à la planification du sprint.

Erik Reppen
la source
Bon conseil. Gardez à l'esprit qu'il n'y a rien dans le manifeste agile à propos des «user stories» et qu'elles ne sont qu'une pratique populaire née avec des processus spécifiques. Vous pouvez être aussi agile avec les user stories que vous pouvez sans ..
Michael
C'est vrai. Je ne suis pas sûr que le manifeste agile soit considéré comme suffisant pour "bien faire les choses" selon de nombreuses normes de l'industrie de la formation qui se sont construites autour de lui, mais comme toujours, les idées et celles qui ont du sens pour vous et votre équipe doit avoir la priorité sur les affectations, OMI. De plus, vous obtiendrez autant de réponses de ce front sur la façon de "faire agile" correctement que vous demanderiez aux étudiants quelles sont les règles de la datation. Rien ne remplace la pensée critique.
Erik Reppen
Je n'abandonnerais pas les histoires d'utilisateurs. En fait, je travaille dur pour les présenter car nous avons une tradition de ne pas tenir compte des utilisateurs finaux. L'analogie avec Steve Jobs est très pertinente, car notre PDG est un gars technique brillant qui a démarré une société de plusieurs millions de dollars. La seule chose à laquelle il a échoué est de créer une couche de gestion, il est donc resté très impliqué dans le travail accompli. Cela a cédé la place à l'émergence de la culture des étoiles qui se traduit par des soucis d'apparence. Pour résumer: nous avons un problème culturel. Mais en le considérant comme donné, j'ai besoin d'outils comme ceux de la réponse pour faire les pas de bébé nécessaires.
Szili
Quoi qu'il en soit, je recommanderais un développeur d'interface utilisateur expérimental rétentif si vous rencontrez des problèmes UX. Il n'y a pas de substitut à l'exception de quelques géniaux géniaux dont peu voudraient jamais payer une équipe complète.
Erik Reppen