Agile oblige-t-il les développeurs à passer plus de temps à travailler?

En regardant les pratiques Agiles courantes, il me semble qu'elles (intentionnellement ou non?) Obligent les développeurs à passer plus de temps à travailler que à lire des blogs / articles, à discuter, à prendre des pauses-café et à simplement tergiverser.

En particulier:

1) Programmation en binôme - le plus gros forceur de travail, juste parce qu'il n'est pas pratique de faire toute cette procrastination quand vous êtes deux assis ensemble.

2) Histoires courtes - lorsque vous avez un énorme travail à faire, par exemple dans un mois, il est assez courant de se relâcher au cours des trois premières semaines et de passer en mode OMG DEADLINE pour la dernière.

Et avec les petits morceaux (qui doivent être faits en un jour ou moins), c'est exactement le contraire - vous sentez que le temps est serré, il n'y a pas d'espace pour manœuvrer, et vous serez tenu pour responsable de la tâche très bientôt, alors vous commencez travailler immédiatement.

3) Communication et cohésion d'équipe - lorsque vous sous-performez dans un environnement lent, éloigné et silencieux, cela peut sembler correct, mais quand à la fin de la journée à la réunion Scrum, tout le monde se vante de ce qu'il a accompli et vous n'avez rien à dire que vous pouvez réellement ressentir honteux.

4) Tests et rétroaction - encore une fois, cela vous empêche de garder les tâches «prêtes à 99%» (alors qu'elles sont en fait autour de 20%) jusqu'à ce que la date limite arrive soudainement.

Pensez-vous que sous Agile vous travaillez plus qu'avec des méthodologies "conventionnelles"? Cette pression est-elle compensée par l'environnement plus confortable et par le sentiment de faire les bonnes choses rapidement?

L'idée principale derrière les méthodes agiles est de vous aider à être productif - dans un sens positif. Personne ne se soucie si vous passez une heure à surfer tous les jours si vous respectez la date limite. Tout le monde devient fou si vous surfez une demi-heure tous les jours mais manquez votre date limite. La solution: simplifiez le respect de l'échéance.

Comme vous l'avez remarqué, la programmation par paires vous assure de rester concentré (parmi tous les autres avantages comme l'amélioration de la diffusion des compétences / connaissances, un meilleur code, moins de bugs, une conception uniforme, etc.).

J'ai trouvé que la discipline est toujours une lutte pour moi. Si je fais équipe avec quelqu'un, il y a de fortes chances que l'un d'entre nous veuille faire du travail aujourd'hui et entraîne l'autre. Ainsi, le «travail pendant un mois» se transforme souvent en «travail ensemble pendant une semaine», étant surpris de voir comment cette énorme quantité de travail a été résolue à la fin, passer une journée à récupérer (refactoring, correction des TODO dans le code, ajout d'un quelques tests, surfer en toute conscience), puis saisir le mois suivant de travail.

Résultat net: je suis beaucoup plus détendu (plus parce que malgré la supervision constante), la cohésion de l'équipe est bien meilleure, le travail se fait plus rapidement, les gens ne traînent pas un problème mineur pendant des heures voire des jours (parce que quelqu'un d'autre peut repérer le problème beaucoup plus rapidement).

Quand vous dites "vous pouvez avoir honte", n'est-ce pas une bonne chose? Cela signifie que vous sentez que vous avez mal agi et que vous devriez. Vous n'êtes pas payé pour ne rien faire. Ne rien faire vous fait vous sentir impuissant, malheureux, indigne, misérable. Au lieu d'avoir honte, prenez du recul et pensez "Pourquoi n'ai-je rien accompli aujourd'hui?" As-tu besoin d'aide? Y a-t-il quelque chose que vous ne comprenez pas? La tâche actuelle est-elle trop difficile? Vous ne l'aimez pas? Vous pouvez peut-être échanger la tâche avec quelqu'un d'autre. Peut-être que quelqu'un d'autre peut vous aider à passer. Agile signifie: Assumer la responsabilité au lieu d'être micro-géré comme une marionnette sur des cordes. Vous avez besoin d'un outil? Allez voir votre patron et demandez-le. Apprenez à argumenter. Apprenez à vous lever et à crier quand vous le devez.

En ce qui concerne les tests, il y a un point idéal lorsque votre code s'effondre soudainement de "agréable" à "parfait". C'est le moment où vous remarquez que vous devez implémenter la fonctionnalité X et que vous pensez que ce sera un cauchemar et que vous réalisez soudain que le code est presque là. Juste un petit refactoring ici et là. Une nouvelle classe et c'est fait. Quatre semaines de travail sont soudainement devenues une journée. La victoire! Triomphe!

Je suis d'accord.

Programmation en binôme

Est une façon de travailler très intense et exhaustive, et je ne l'applique jamais à moins d'avoir des développeurs qui doivent être coachés par d'autres (nouveaux venus par exemple)

Histoires courtes

Communication et cohésion d'équipe

Tests et rétroaction

Oui Agile et spécifiquement Scrum est un énorme booster de productivité. Lorsqu'il est appliqué correctement, le turn over peut aller jusqu'à 20% (1 développeur sur 5 quitte l'entreprise).

La raison est simple: Scrum n'apporte pas plus de productivité it provides the whole company with much more visibility on what's going on(y compris dans la gestion bien sûr).

• Il est impossible pour un développeur de faire le strict minimum. Le minium nu est maintenant la moyenne de l'équipe!

• Il est impossible pour la direction de ne pas collaborer correctement.

C'est pourquoi j'ai dit (dans mes autres réponses dans des questions similaires), que l' Agile n'est PAS pour chaque organisation (et pour tout le monde).

Par exemple, le secteur public n'est vraiment pas adapté à Agile.

Agile utilisé comme outil de pression? Bien sûr, je l'ai vu plusieurs fois. Cela ne fait qu'empirer les choses.

Pensez-vous que sous Agile vous travaillez plus qu'avec des méthodologies "conventionnelles"? Cette pression est-elle compensée par l'environnement plus confortable et par le sentiment de faire les bonnes choses rapidement?

Ça me fait travailler plus, mais surtout ça me fait travailler la bonne chose. À tout moment, je sais ce que je dois faire .

C'est une sorte de pression positive. C'est assez différent de certains externes "vous êtes déjà en retard, travaillez plus, codez les heures supplémentaires!" -sens de la pression.

En fait, je suis beaucoup plus productif lorsque j'utilise les méthodes conventionnelles. Avec la méthode conventionnelle, je crée par exemple une analyse détaillée des besoins, une étude de faisabilité, une spécification fonctionnelle, une spécification technique et de nombreux protocoles de réunion, le tout en quelques mois seulement! Je pourrais même créer des lignes de code une fois l'analyse d'impact terminée!

Agile, je ne crée que quelques livrables.

Dans notre entreprise,

Programmation par paires - Lorsque quelque chose de vraiment complexe et nécessite une analyse approfondie, même nous rassemblerions deux personnes excellentes et ferions la tâche en un temps RAPIDE. Ici, la complexité de la tâche décide du besoin de programmation par paires.

Histoires courtes - Puis je me relâche pendant 3 semaines (environ 5-6 heures par jour) et je me précipite au dernier moment (environ 12 à 14 heures par jour) en tant que développeur, je n'aime pas avoir une oscillation dans ma charge de travail. Travaillez environ 8 heures par jour et gardez votre emploi du temps stable et cela semble toujours COOL.

Communication et cohésion d'équipe - Lors d'une réunion de mêlée, nous partageons non seulement le statut de la tâche mais aussi les obstacles. Ici, lorsque quelqu'un a vraiment besoin d'aide, d'autres membres proposent leurs idées pour l'aider. Mais vous avez certainement besoin d'une excellente équipe pour cela et nous le sommes :)

Tests et commentaires - En tant que développeur, je ne veux certainement pas être enfin accablé de bugs, le moment suivant après avoir trouvé un bug devait le corriger et encore, cela me permettrait d'avoir une bonne prévision de ce qui devrait / peut être fait ensuite et reporter la date limite (si nécessaire) en conséquence.

Donc, en tant que développeur, je suis très satisfait du type de tâche que je prends et sacrément sûr de pouvoir dire que je n'ai jamais ressenti la VRAIE pression du délai.

Pensez-vous que sous Agile vous travaillez plus qu'avec des méthodologies "conventionnelles"?

• Si vous voulez dire que je me sens plus productif sous Agile, je dirais que cela dépend .
   
  _{Je pense généralement à cela en termes de Ferrari (comme conventionnel) vs Landrover (comme Scrum). Lorsque vous conduisez sur une autoroute, Ferrari bat l'enfer de Landrover.
   
  C'est le tout-terrain quand on a besoin d'une jeep et non d'une voiture de sport - je veux dire si vos exigences sont irrégulières et / ou si le travail d'équipe et l'expérience de gestion ne sont pas si bons, vous devrez choisir Scrum - tout simplement parce que l'essayage conventionnel vous êtes coincé - comme Ferrari restera coincé hors route.}

En ce qui concerne "travailler plus" , je pense que celui qui attend des choses comme cela sous-estime probablement le QI du programmeur et sa capacité à s'adapter à diverses formes de démence de gestion .

Jusqu'à présent, j'ai participé à deux équipes Scrum réalisant des projets assez différents dans différentes entreprises. Dans les deux équipes, je n'ai remarqué aucun changement dans mes habitudes par rapport, par exemple, à une cascade / itérative.

Je serais fier de prétendre que c'est parce que je suis si spécial et invincible mais franchement, j'ai vu que les habitudes de tous les autres gars de l'équipe étaient invincibles aussi.

Agile oblige les programmeurs à faire un travail plus utile, car les diverses techniques de développement agile éliminent le travail chargé et le travail qui n'est tout simplement pas nécessaire.

il n'est pas commode de faire toute cette procrastination quand vous êtes deux assis ensemble.

Je ne suis pas d'accord. J'ai travaillé avec un groupe de fumeurs et ils ont tous réussi à prendre leur pause ensemble pendant de longues périodes parce que "tout le monde le faisait".

commun de se relâcher au cours des trois premières semaines

C'est un signe de mauvaise gestion quelle que soit la méthodologie. Même si un gros morceau est dû dans un mois, je m'attendrais à voir quelque chose à la fin de la première semaine.

vous n'avez rien à dire, vous pourriez avoir honte.

Si vous êtes prêt à vous branler pendant trois semaines, vous penserez à des conneries à dire.

4) Tests et rétroaction - encore une fois, cela vous empêche de garder les tâches «prêtes à 99%» (alors qu'elles sont en fait autour de 20%) jusqu'à ce que la date limite arrive soudainement.

Les projets en cascade peuvent avoir des tests et des constructions quotidiennes.

Personnellement, je détesterais écrire du code sans rien faire pendant un mois. Je préfère la boucle de rétroaction plus courte sur mon code, qu'il s'agisse d'une révision codée ou d'une approbation de l'utilisateur. Le fait que d'autres approuvent mon travail est gratifiant. C'est comme le chat qui laisse tomber une souris sur le pas de votre porte juste pour vous faire savoir qu'elle fait son travail.

Agile n'oblige pas les développeurs à travailler plus , mais à travailler plus efficacement

Formuler la question `` forcer les développeurs à travailler plus '' est un peu négatif, mais est-il certainement positif si nous en faisons réellement plus et procrastinons moins?

Cela dit, c'est un bon point. Je me sentais un peu blasé par l'agilité cette année, mais c'est un énorme avantage non écrit que je n'avais pas reconnu.

Je conviens que l'agilité peut conduire les développeurs à être plus productifs. Vos points sur la visibilité, la responsabilité et la tendance à tergiverser moins sont tous très vrais.

Mais l'agilité peut et devrait également conduire les développeurs à travailler plus dur pour des raisons positives - la carotte contre le bâton. Bien fait, l'agile donnera aux développeurs plus d'interaction avec les utilisateurs, moins de beuracratie, plus de contrôle sur leur travail, ce qui peut conduire à obtenir plus de votre équipe.

plus de travail n'est toujours pas sémantiquement correct ou pertinent pour Agile, le but est d'être plus productif . Il se concentre spécifiquement sur le fait de travailler moins sur la mauvaise chose et plus sur le travail normal sur la bonne chose; ce qui ne signifie pas travailler plus , mais de manière plus productive .

Un effet secondaire, c'est qu'il expose très rapidement les slackers et ceux qui sont inefficaces ou peu compétents. Ce qui ressemble plus à ce que vous voulez dire.

La méthodologie n'a pas d'importance si un développeur ne fonctionne pas ou non . Le processus est, même en cascade, les revues de gestion et les revues de code peuvent également exposer ces choses inutiles, mais pas de manière aussi transparente que la plupart des méthodologies Agiles.

"Les armes à feu ne tuent pas les gens. Les gens tuent les gens!" C'est la même chose avec Agile. Agile ne fait pas travailler les gens plus, les managers font travailler les gens plus.