La flexibilité est sans aucun doute une bonne chose, et le manifeste Agile a du sens. Par rapport à la pratique fragile appelée cascade, Agile est nettement meilleure. Cependant, dans la pratique, les approches flexibles font souvent de gros dégâts, et en réalité, la dichotomie Agile / Waterfall n'est guère appropriée ici.

J'ai vu combien de variantes Agile appelées Scrum tuent vraiment l'entreprise. Par «tuer», je ne veux pas dire «détérioration culturelle», mais plutôt lorsque les actions de l'entreprise chutent de près de 90% en deux ans.

Qu'est-ce que l'Agile?

Agile est né d'un environnement de consultation Web où il a apporté certains avantages: lorsque vous travaillez avec des clients exigeants qui ne savent pas ce qu'ils veulent, vous devez généralement choisir entre deux options. Ou pour vaincre le client: établir des attentes, un paiement approprié pour les modifications et maintenir des relations d'égalité, pas de subordination. Ou acceptez le comportement incorrect du client (comme, disons, de nombreux concepteurs le doivent) et orientez le flux de travail autour du dysfonctionnement du client.

Les programmeurs ne travaillent généralement pas très bien avec les clients. Nous sommes des gens trop littéraux. Nous aimons les systèmes au comportement bien défini. Cela complique notre interaction avec les sciences humaines, car nous avons tendance à prendre chaque demande au pied de la lettre, plutôt que de déterminer ce qu'ils veulent vraiment. Au niveau de l'entreprise, les méthodes agiles (en dehors de l'environnement de conseil) vont plus loin et suggèrent que les ingénieurs ne sont pas assez intelligents pour comprendre ce que veulent leurs «clients» internes. Cela signifie que le travail est pulvérisé sur des «user stories» et des «itérations», ce qui nous prive souvent de satisfaction du travail accompli, ainsi que de tout espoir d'une vision à long terme de ce qui se passe.

En général, deux types de travaux sont généralement créés, que ce soit au sein de l'entreprise ou pour l'entrepreneur. À un niveau élevé, des spécialistes hautement qualifiés sont embauchés. En bas - tout le travail qu'ils ne veulent pas faire est jeté sur le côté. De toute évidence, une catégorie de consultants est respectée, tandis que l'autre non. Les sociétés de conseil mal gérées se retrouvent souvent comme des chutes à ordures pour les emplois peu qualifiés. Scrum semble avoir été créé pour les organisations où les relations avec les clients sont si mauvaises que les ingénieurs doivent être surveillés quotidiennement, car ils sont devenus un réservoir de sédimentation pour le travail de base, inutile pour une carrière que personne ne veut faire (et ce n'est probablement pas un travail très important , donc taux bas et respect).

Transparence violente

Il existe de nombreuses tendances dans le milieu de travail informatique qui rendent une carrière en programmation extrêmement peu attrayante, en particulier pour les personnes créatives et intelligentes.

L'exemple le plus flagrant est celui des bureaux à aire ouverte. Ils ne sont pas productifs. Il est difficile de se concentrer en eux. Ils sont anti-intellectuels, car les gens ont peur d'être surpris en train de lire des livres (ou simplement de penser) au travail. Lorsque vous faites croire que les gens sont productifs, ils perdent en fait la productivité. Les bureaux à aire ouverte ne sont généralement pas destinés à la productivité. Il s'agit d'une image d'entreprise. Les startups financées par le capital-risque utilisent ces dispositions pour démontrer aux investisseurs que le bureau a l' air occupé. (Autrement dit, un programmeur open-space est plus apprécié comme mobilier de bureau, plutôt que comme le code qui écrit). Pour diverses raisons culturelles, cela a rendu l'option ouverte «cool» et «sale», et maintenant elle infecte le monde des affaires dans son ensemble.

Il est bien connu que les personnes créatives perdent leur créativité si on leur demande d'expliquer pendant le travail. Même chose avec le logiciel. Les programmeurs doivent souvent travailler dans une transparence unilatérale. Ces systèmes Agiles sont souvent mal utilisés et nécessitent une transparence de fonctionnement humiliante, malgré le manque de réciprocité. Au lieu de travailler sur de véritables projets à long terme sur lesquels une personne pourrait être intéressée, ils sont réduits à travailler sur des «user stories» atomisées et fonctionnelles et sont souvent empêchés de travailler sur des améliorations qui ne sont pas liées aux besoins immédiats et à court terme de l'entreprise (souvent de bas en haut). Cette version incorrecte mais courante d'Agile exclut le concept de propriété et considère les programmeurs comme des composants interchangeables et identiques.

Scrum est la pire option, avec la stupidité des «itérations» de deux semaines. Cela provoque des inquiétudes inutiles concernant les microfluctuations des performances humaines. Il n'y a absolument aucune preuve que cette approche accélère ou améliore vraiment le développement à long terme. Cela rend les gens nerveux. Beaucoup dans l'entreprise pensent que c'est une bonne approche, car le travail "va plus vite". Je travaille dans l'industrie informatique depuis dix ans, en tant que manager et en tant qu'abeille de travail. Ce n'est pas vrai.

Défauts spécifiques Agile et Scrum

1. Développement orienté entreprise.

Agile est souvent servi par rapport à une «cascade». Qu'est-ce qu'une cascade?

L'approche Waterfall est vraiment terrible. Dans ce document, le «travail se déroule», où chaque niveau de la hiérarchie organisationnelle sélectionne ce qu'il considère comme du «matériel intéressant» et le transmet. Les projets sont déterminés par les gestionnaires, l'architecture est conçue par les architectes, les délais personnels sont fixés par les cadres intermédiaires, la mise en œuvre est effectuée par des chevaux de bataille de haut niveau (programmeurs), puis les opérations et les tests sont transférés aux chevaux de niveau inférieur. Il s'agit d'un schéma extrêmement non fonctionnel. Lorsque les gens sentent que toutes les décisions importantes ont déjà été prises, ils n'ont aucune motivation pour travailler le mieux possible.

La cascade reproduit le modèle social d'une organisation dysfonctionnelle avec une certaine hiérarchie. À son tour, Agile reproduit assez souvent le modèle social d'une organisation dysfonctionnelle sans hiérarchie clairement définie.

J'ai des opinions mitigées sur les titres de poste comme «senior» et «director», etc. Ils importent, et moi-même je n’accepterai probablement pas un poste en dessous du niveau du réalisateur, mais je déteste leur importance. Si vous regardez Scrum, cela prive spécifiquement les droits des ingénieurs les plus compétents, car ici, ils sont obligés d'adhérer aux processus établis (travailler uniquement sur les tâches créées, 5 à 10 heures par semaine sur les planeurs). Ces processus sont conçus pour les personnes qui ont commencé à programmer il y a un mois.

Comme l'État communiste en faillite, qui égalise les gens en propageant la pauvreté, Scrum, dans sa forme la plus pure, place l'ensemble du développement au même niveau bas: pas clairement défini, mais clairement en dessous du niveau des hommes d'affaires qui ont le pouvoir de décider sur quoi travailler.

Agile, dans sa mise en œuvre habituelle, augmente la fréquence du feedback, sans donner aux ingénieurs une réelle puissance. C'est une affaire perdante car cela signifie que les programmeurs sont plus susceptibles d'être tirés ou punis lorsque le travail prend plus de temps qu'il ne devrait le prendre. Cela crée beaucoup d'anxiété et de hâte, mais en fait, cela n'a pas grand-chose à voir avec ce qui compte vraiment: créer de bons produits.

La Silicon Valley a commis de nombreuses erreurs, en particulier au cours des cinq dernières années, mais a fait quelque chose de bien. Y compris introduit le concept d'entreprise "d'ingénierie". Il n’est pas toujours préférable pour les ingénieurs de gérer l’ensemble de l’entreprise, mais lorsque les ingénieurs gèrent le développement et fixent des priorités, tout le monde y gagne: les ingénieurs sont satisfaits du travail auquel ils sont affectés (ou, mieux encore, ils sont assignés à eux-mêmes), et l’entreprise obtient une qualité de développement beaucoup plus élevée.

Mais vous avez une "entreprise commerciale", ça va. N'embauchez donc pas d'ingénieurs si vous avez besoin de talent. Vous pouvez trouver les meilleures personnes en tant que consultants (à partir de 200 $ de l'heure et en forte augmentation à partir de ce niveau), mais pas en tant qu'employés à temps plein d'une «entreprise commerciale». Les bons ingénieurs veulent travailler dans des entreprises dirigées par des ingénieurs, où ils participeront à la planification du travail sans avoir à s'excuser auprès des «scrum masters», des «chefs de produit» et de plusieurs niveaux de directeurs des sciences humaines.

En fin de compte, Agile (tel que pratiqué) et Waterfall sont des formes de développement orienté métier, et par conséquent, aucun d'entre eux ne convient pour développer des logiciels de qualité ou motiver les employés.

2. La position subordonnée des jeunes.

Malheureusement, dans le développement de logiciels, une culture de la subordination des jeunes s'est développée avec le concept (extrêmement erroné) de programmation en tant que «jouets de jeunes hommes», bien que presque aucun des meilleurs ingénieurs ne soit jeune et que bon nombre des meilleurs ne soient pas du tout des hommes.

Le problème avec les itérations (ou sprints) Agile de deux semaines et les user stories est qu'il n'y a pas de stratégie de sortie. Il n'y a pas d'option "Nous n'aurons plus à faire cela lorsque nous atteindrons [X]". Ce système est censé durer éternellement: les rassemblements axés sur les affaires ne disparaîtront jamais. L'architecture, la R&D et le développement de produits quittent le travail du programmeur car ils ne rentrent pas dans les «user stories» atomisées et les sprints de deux semaines.

Par conséquent, pour les programmeurs plus ou moins expérimentés, il est inconfortable de travailler de cette façon, car ils veulent s'attaquer aux types de projets qui sont ignorés dans cette structure, et ces projets sont difficiles à justifier en termes de valeur commerciale à court terme. L'excellence technique est importante, mais il est très difficile de convaincre les gens de ce fait s'ils ne veulent pas obstinément être convaincus.

J'ai déjà travaillé pour une entreprise où un chef de produit a déclaré que la différence entre un ingénieur senior et un ingénieur junior était la capacité de donner des estimations de temps plus précises. Eh bien, non. Et c'est même insultant. Je déteste les évaluations parce qu'elles génèrent des politiques et ne font pas le travail plus rapidement ou mieux (en fait, généralement le contraire).

Le pire des évaluations est qu'elles stimulent la performance des travaux qui peuvent être évalués. Cela fait que les programmeurs préfèrent les choses simples de bas niveau dont les entreprises n'ont pas vraiment besoin (même si les cadres moyens maladroits pensent différemment), mais c'est «sûr». Tout ce qui vaut vraiment la peine a une chance d'échec non nulle et trop de paramètres inconnus pour une estimation raisonnable du délai. L'accent mis par Agile sur la valeur commerciale à court terme éloigne finalement les gens du travail dont l'entreprise a vraiment besoin, afin de gérer la réputation de chaque programmeur en temps réel.

Une telle culture suggère que la programmation est un enfantillage, dont vous devez vous débarrasser avant l'âge de 35 ans. Je ne suis pas d'accord avec cette opinion. En fait, je pense que c'est une mauvaise pensée. J'ai plus de 30 ans et j'ai l'impression de commencer à bien programmer. Harceler les programmeurs seniors simplement parce qu'ils sont suffisamment expérimentés pour savoir que ce processus flexible / scrum n'a rien à voir avec l'informatique et qu'il n'ajoute pas de valeur est une idée terrible.

3. Une approche à trop court terme, qui est stupide et dangereuse.

Agile est destiné aux cabinets de conseil secondaires qui n'ont pas assez de crédit pour faire confiance à négocier avec des pairs sur un pied d'égalité, et qui font face à des délais serrés, et chaque projet client est un risque existentiel. Il est pour les étrangers "marginaux". Mais voici le problème: Scrum est souvent déployé dans de grandes entreprises et des startups financées. Mais les gens vont dans ces entreprises parce qu'ils ne veulent pas être des étrangers . Ils veulent de la sécurité. C'est pourquoi ils travaillent dans ces entreprises, plutôt que de créer les leurs. Personne ne veut être en retard s'il n'y a aucun avantage personnel significatif. Agile dans une entreprise signifie douleur et risque sans récompense.

Lorsque chaque projet client comporte un risque de réputation existentiel ou sérieux, Agile peut être la solution appropriée, car se concentrer sur les itérations à court terme est utile lorsque l'entreprise est à risque et peut disparaître à long terme. Une gestion de projet agressive a du sens en cas d'urgence. Cela n'a pas de sens en tant qu'arrangement permanent; du moins pas pour les programmeurs talentueux qui ont des options moins stressantes et plus agréables.

Dans le cadre d'Agile, la dette technique s'accumule et n'est pas résolue car les hommes d'affaires qui attribuent des tâches ne verront le problème que trop tard ou au moins trop cher pour le résoudre. De plus, les ingénieurs individuels sont récompensés ou punis uniquement sur la base des «sprints» de deux semaines actuels, c'est-à-dire que personne ne regarde cinq «sprints» à l'avance. Agile n'est qu'un «sprint» inutile et à courte vue: aucun progrès, aucune amélioration, juste ticket par ticket, par ticket.

Les gens qui sont d'accord avec le brassage de tâches dénuées de sens peuvent le supporter, mais les très bons ingénieurs détestent aller travailler lundi matin, ne sachant pas ce qu'ils travailleront ce jour-là.

4. Il n'a rien à voir avec la construction d'une carrière.

Les user stories individuelles ne sont pas bonnes pour une carrière d'ingénieur. À l'âge de 30 ans, vous êtes censé être en mesure de travailler au niveau de l'ensemble du projet et que vous êtes au moins prêt à dépasser ce niveau en infrastructure, architecture, recherche ou leadership.

En cas d'urgence, que ce soit une consultation qui cherche à rassurer un client important ou une «salle de guerre» d'entreprise, les réflexions sur un CV peuvent attendre. Peu de gens abandonnent quelques semaines de travail désagréable ou autre qui n'est pas lié au développement de carrière, si c'est vraiment important pour l'entreprise. L'importance du travail est ici prioritaire. Si vous pouvez dire: «Je me suis assis au siège social et j'ai parlé avec le PDG pendant 20 minutes par jour», cela justifie de faire un travail stupide.

Mais s'il n'y a pas d'urgence, les programmeurs s'attendent à ce que leur carrière soit prise au sérieux. Sinon, ils partiront. «J'étais dans l'équipe Scrum» signifie que vous êtes un sac de boxe. C'est une chose de faire un travail stupide, car le PDG a reconnu qu'une tâche désagréable ajoutera des millions de dollars en valeur (et il la récompensera en conséquence). Mais si on vous a simplement attribué des «user stories» et des tickets Jira, alors vous êtes considéré comme un perdant.

5. L'objectif est de déterminer des taux faibles, mais le niveau de faux positifs est inacceptablement élevé.

Scrum est proposé comme un bon moyen d'identifier les «employés en retard». Le problème est qu'il crée des programmeurs plus inefficaces qu'il n'en révèle. Il s'agit d'un système de suivi complet dans lequel les ingénieurs individuels montrent en détail l'avancement de leur travail, avec une évaluation de la productivité.

Dans un débat sur les libertés civiles, une erreur courante est souvent évoquée: l'argument "rien à cacher". Certaines personnes aiment faire valoir que l'invasion de la vie privée, par exemple par les forces de l'ordre, n'est pas un problème, car elles-mêmes ne sont pas des criminels. Ces gens manquent quelques éléments clés. Par exemple, ces lois changent. Demandez à quiconque était juif en Europe centrale dans les années 1930. Même pour les personnes respectables, l'état de surveillance est un état d'anxiété.

Le fait de l'observation change la façon dont les gens travaillent. Dans les zones créatives, ça fait mal. Il est presque impossible de travailler de manière créative si vous devez faire un rapport sur le travail tous les jours.

Un autre sujet me vient à l'esprit: la sensibilité au statut . Les programmeurs aiment prétendre avoir surmonté plusieurs millions d'années d'évolution des primates liés au statut social, mais le fait est que le statut social est important, et ce n'est pas gênant d'admettre ce fait. Les personnes âgées, les femmes, les minorités raciales et les personnes handicapées sont généralement sensibles au statut professionnel car c'est une question de survie pour elles. Un suivi constant du travail indique un manque de confiance et un statut social bas, et les plus sensibles au statut (même s'ils sont les meilleurs employés) sont les premiers à souffrir d'un suivi accru. S'ils sentent qu'on ne leur fait pas confiance (et quoi d'autre est transmis par la culture, où chaque élément du travail devrait être approuvé?), Alors ils perdent rapidement leur motivation.

Agile et surtout Scrum sont vulnérables à l'erreur «rien à cacher». Si vous n'êtes pas un «mauvais travailleur», vous n'êtes pas contre la glisse quotidienne, non? Les seules personnes qui s'opposeront aux rapports quotidiens sur leur travail en termes de valeur commerciale à court terme sont des «flâneurs» qui veulent voler de l'argent à l'entreprise, non? Et bien non. Evidemment non.

Une culture de la transparence violente est conçue pour les plus insensibles au statut: des jeunes privilégiés, généralement blancs ou asiatiques, qui n'ont jamais été pressés au travail. Pour ceux qui pensent que les ressources humaines et la gestion sont une perte de temps, et l'employé devrait simplement avaler humiliation et insultes.

Souvent, les meilleurs employés souffrent de l'implémentation Agile / Scrum, car la R&D est effectivement éliminée. L'obsession des "itérations" à court terme ou des sprints signifie l'incapacité d'essayer quelque chose de nouveau, risqué.

La vérité sur les employés en retard est que vous pouvez les identifier sans aucun Agile. Les gens savent qui ils sont. La raison pour laquelle certaines équipes sont remplies de mocassins, de personnes incompétentes ou toxiques, parce que personne ne fait rien avec elles. Il s'agit d'un problème de gestion au niveau du personnel et non au niveau du flux de travail.

6. L'effet ivre.

Il semble qu'une gestion agressive puisse rendre certaines personnes légèrement incompétentes tout à fait capables de travailler. Je l'appelle l'effet ivre: lorsque les filles deviennent tellement en forme, mais vraiment mignonnes, elles ne veulent plus rien avoir à faire avec vous. — , , -.

, , , : «» 7+ Scrum, 3- 4- 5-. , 7 5 , 5 3. ( ), , Scrum, .

Scrum Agile , . , , . 5 3 ( ) , .

Agile/Scrum , . , , , ( 50% , 10-30 ).

, , «» — . 22- 6, , 3 Scrum, 50- 9, , , 9 8,5, 3 6. , , . . , . , 5- , ( ) 4, 8 8.

7. .

Scrum. , Scrum « Agile», — Agile. (, : , Agile).

Scrum : , . , .

Scrum

, Agile , Scrum « » « ». , , .

, (, “Scrum Master”) . , « » ( ). , . «», , , , , , . , , . .

, , . , « », . . . , , , , , , , .

, . — « ». ( ) 4 , - , . -, , , .

, Scrum , «» : , , , . . .

, . , , . , , . , . , , .

(-?) , . Scrum - , (« ») ( «»), .

Agile Scrum . . , «-». . , , — , . , , .

, . , «» . , . , , « » ( ). , , Scrum — .

Agile Scrum, . , , , , . Scrum , — , , — «» , Agile . ( «-», ) .

, . . , -, , . , - , - « » — . : . Agile, , , , , — , , , . - — . , .