Notre monde est très étrange. Et plus vous allez loin, plus c'est étrange. Et vous comprendrez quoi diable.
Il y a des ingénieurs et des programmeurs dans le monde. Parfois, tout se confondait. Les gens qui comprennent ce qu'est un algorithme. De plus, les gens qui créent ces algorithmes. Ils savent bien que l'algorithme créé convient à la résolution d'un problème, mais pas à un autre. Comprendre que si l'algorithme est légèrement modifié, il pourra résoudre les problèmes associés. N'hésitez pas à jeter la moitié de l'algorithme de quelqu'un d'autre pour qu'il résout mieux le problème actuel.
Les programmeurs créent une solution pour une tâche ou pour une classe de tâches. C'est l'essence même de la profession. Dans la mesure du possible, utilisez des morceaux prêts à l'emploi de leur propre code ou du code de quelqu'un d'autre. Et tout va bien.
Mais, dès qu'il s'agit de créer des algorithmes en dehors de l'ordinateur, les programmeurs perdent soudain la tête. Je ne parle pas de dessiner des diagrammes d'algorithmes sur papier, comme c'était le cas à l'examen universitaire - ici, chacun d'entre nous peut le gérer.
Je parle de "mise en œuvre de techniques", "travail sur le framework", "utilisation obligatoire de tous les artefacts". À propos des sectes, en bref.
Un peu d'idiotie
Tout le monde sait ce qu'est un opérateur conditionnel. Il n'y a pas de vie sans lui. Aucun algorithme décent ne fonctionnera. Ni dans l'ordinateur, ni dans la vie.
Imaginez maintenant: une certaine personne est apparue, par exemple, John, et a remarqué qu'il existe une instruction conditionnelle dans BASIC. Je l'ai ramassé, je l'ai compris, je me suis assuré - ça marche, ça marche sans rien.
Disons que John est stupide. Mais il a décidé de conquérir le monde. Je suis allé vendre BASIC. Pas le langage lui-même, mais une sorte de «technique de développement logiciel la plus cool», dont le lien central est ... Et John ne le dira pas avant d'avoir terminé le cours.
D'accord, il y avait des amateurs de cours, d'autant plus que le prix n'est pas élevé. Ils sont venus, écoutés, haletants. L'élément principal de la méthodologie de développement de logiciels la plus cool est l'opérateur conditionnel. Nous avons beaucoup écouté la déclaration conditionnelle. Par exemple, comment le transformer en opérateur à choix multiples. Ils haletèrent à nouveau - quel puissant opérateur conditionnel.
La moitié du public était des programmeurs. Hennissant, rentra chez lui. Un autre quart étaient des gestionnaires. Ils sont devenus réfléchis, ont posé des questions, quelqu'un a décidé de mettre en œuvre cette technique cool dans leur maison. Le dernier trimestre était le même que John. Ils ont persuadé le gars de créer une franchise, une communauté, une autorité de certification et une université contingente.
Les programmeurs du cours ont repris le travail, ne se souvenant plus de l'opérateur conditionnel. Mais une heure plus tard, les gestionnaires sont venus et ont annoncé que maintenant le développement de logiciels sera effectué selon la méthode la plus cool. Oui, qui concerne l'opérateur conditionnel. En général, il vaut mieux écrire en basique.
Les objections timides, sinon timides des programmeurs ont été ignorées. Des expressions telles que «bon sang c'est un opérateur conditionnel, c'est partout» ont été perçues comme des tentatives de se montrer. La roue tourna.
Et John s'est vite rendu compte qu'un seul opérateur conditionnel ne suffisait pas. Il devrait également y avoir une boucle, une sous-routine, une variable, un tableau, etc. Nous devrions en quelque sorte appeler tout cela ... En un mot ... Oh, que ce soit des artefacts! Ni plus ni moins!
L'essentiel est resté: pour ajouter à la méthodologie une clause selon laquelle la méthodologie de développement logiciel la plus cool est la connaissance holistique et holistique. Ainsi, aucune pièce ne peut en être jetée. Et vous ne pouvez rien y ajouter - cela cessera de fonctionner. Comme il est écrit, faites-le.
Grâce à l'enthousiasme de John et de ses amis, le monde entier utilise désormais non pas un opérateur conditionnel, mais un opérateur conditionnel, non pas un cycle, mais un cycle, etc., selon la liste. Ceux qui ont compris l'idiotie de la situation ont depuis longtemps pris leur retraite ou se sont tus. Ceux qui sont venus récemment croient fermement que l'opérateur conditionnel fait partie de la technique de développement logiciel la plus cool créée par John. Et tous les autres opérateurs conditionnels sont un misérable semblant, une copie fanée et un morceau de Connaissance arraché à son contexte.
Quiconque ose voter sur Internet (ou, Dieu nous en préserve, au sein de l'équipe) sera soumis à une condamnation féroce et à une minusculation en colère - vous, bottes, ne voyez pas les avantages de l'opérateur conditionnel! Et si le malheureux demande d'expliquer quelle est la signification et la différence de l'opérateur conditionnel en C ++, javascript ou même 1C, il obtiendra la réponse «il est impossible d'expliquer», «vous ne comprenez pas» ou «allez lire le guide».
Outils et algorithmes
Tout le monde comprend ce qu'est un opérateur conditionnel et comment l'utiliser dans des algorithmes. De la même manière, tout le monde comprend ce qu'est, par exemple, un autocollant avec une tâche enregistrée. Des autocollants sont apparus devant la mêlée et vivent à l'extérieur. Regardez l'ordinateur d'un comptable, d'un fournisseur ou d'un vendeur. Ils n'ont pas encore éliminé l'habitude de suspendre un tas d'autocollants avec des tâches urgentes sur le moniteur. Un mot de passe sera inscrit sur l'un des autocollants.
Toute technique peut être facilement démontée en outils, principes et relations. Tout comme n'importe quel algorithme est désassemblé en figures de différentes formes et fins - le début et la fin de l'algorithme, l'action, la condition, le sous-programme.
Toute technique a une portée. Tout n'est pas absolument là - il y a un environnement plus adapté, il y en a moins. Identique aux algorithmes.
Toute technique peut être modifiée. Jetez des pièces, ajoutez-en de nouvelles, modifiez des outils spécifiques. Tout comme les algorithmes.
Toutes les techniques peuvent être mélangées, en totalité ou en morceaux. Prenez la moitié de l'un, le quart de l'autre, un autre quart - inventez-vous. Lorsque vous créez une application ou un service, c'est évident pour vous.
Certes, la question demeure - la méthodologie sera-t-elle une méthodologie si elle est modifiée?
Voici comment répondre à cette question, par exemple, le célèbre guide Scrum:
«Les rôles, artefacts, règles et événements de Scrum ne sont pas sujets à changement. Bien que l'utilisation d'éléments individuels de ce cadre soit acceptable, le résultat ne peut pas être appelé Scrum. Scrum n'existe que dans son ensemble, mais il peut accueillir d'autres techniques, méthodologies et pratiques. »
Un peu comme John et son opérateur conditionnel, n'est-ce pas? Il semble que, changez si vous voulez, seulement ce ne sera pas une mêlée. Et quel sera le résultat - l'enfer sait. Au cas où, ils ont noté que vous pouvez essayer de pousser quelque chose à l'intérieur. Mais l'épine dorsale doit rester. Sinon ... C'est même effrayant d'imaginer.
Est-ce vraiment effrayant? Que se passera-t-il si certains des artefacts sont jetés ou remplacés? Et de toute façon, à quoi ça sert? D'où venaient-ils? Pourquoi croit-on qu'ils ne fonctionnent que dans une telle combinaison, comme l'ont décidé les auteurs?
Essayons de comprendre les pièces.
Sprint et Backlog Sprint
Excellent outil, au fait. Inventé, probablement, il y a mille ans. Il a toujours été appelé différemment, mais le plus courant est probablement le «Plan». Et humainement - "pour faire une certaine quantité de travail pendant une certaine période de temps."
Pour moi, en tant que 1Sniku, il est mieux connu sous le nom de planification du calendrier spatial (OKP). Il est largement utilisé dans la planification de la production et des ventes. Par exemple, un plan de vente d'un manager d'un million de roubles par mois est un carnet de commandes et un sprint. Parfois, un chiffre suffit, parfois il y a une ventilation par groupe de produits, ou des restrictions sur le marché, ou même une liste spécifique d'articles, si la stratégie de l'entreprise l'exige.
La production est encore plus facile. Coussinets - 1000 pièces, Arbres - 2000 pièces, Rotors - 500 pièces C'est, disons, un plan hebdomadaire. Il est l'arriéré du sprint hebdomadaire du site de production. Certes, les travailleurs ne peuvent pas être expliqués que ce n'est pas un plan, mais un sprint.
L'outil est bon par rapport à la gestion du temps répandue, lorsque le pool de tâches du programmeur est estimé par les coûts de main-d'œuvre, triés par un certain critère, et chaque tâche a une échéance. Dans la production, cela s'appelle la planification des équipes ou la planification des ateliers, à partir de laquelle des tâches de production sont ensuite créées qui contiennent une liste de pièces et de produits semi-finis, les opérations techniques, les matériaux, les entrées et les sorties (où obtenir quoi et où transférer le résultat).
Pour les programmeurs, la planification des ateliers ne fonctionne pas bien, et il n'y a rien à discuter ici. Le temps de traitement d'une pièce sur un modèle de machine spécifique est connu depuis longtemps et assez précisément. Fréquence du service - aussi. Évaluation de la suffisance des matériaux. Prenez et faites. Les variations qui interfèrent avec la mise en œuvre du plan dans la production de masse n'ont généralement pas d'effet significatif. Et s'ils le font, il existe d'excellentes méthodes pour les analyser et les éliminer.
Les variations du programmeur sont beaucoup plus fortes. Il n'est pas une machine-outil, comme certains managers venus des métiers de la vente ou de la production ne le souhaiteraient pas. Par conséquent, la planification d'un atelier (tâche + échéance) ne convient pas à un programmeur. Donc, des gens sensés sont venus - vous devez vous élever à un niveau supérieur, ne pas planifier la performance en quelques minutes, mais donner du volume pour une période. Seulement, ils ont trouvé un autre nom - sprint et backlog.
Le remplissage du plan de production du calendrier volumétrique est basé sur des principes similaires à la formation d'un backlog de sprint. Même il y a une telle chose - «choisissez un plan». Il y a des besoins du même département des ventes (= grand carnet de commandes), il y a un débit de production (= les capacités de l'équipe en nombre), ainsi que des critères de sélection clairs - le montant des ventes, la rentabilité de chaque poste, les paramètres client (par exemple, les conditions de paiement). A marqué un plan de production - et voyez immédiatement quel résultat financier approximatif vous obtenez. Ce n'est pas une "libération" éphémère.
Y a-t-il des inconvénients à cet outil? Bien sûr, comme tout autre.
Si vous comprenez, le backlog de sprint est la même planification d'atelier, mais sans une séquence bien organisée de résolution de problèmes. Par conséquent, toutes les tâches ont une seule échéance - la fin du sprint. Une fois que les tâches ont une échéance, un effet désagréable apparaît - au début du sprint, l'activité peut être significativement plus faible qu'à la fin.
C'est ainsi que fonctionne toute psychologie humaine. Vous voulez toujours rester au début de la période d'exécution, que ce soit une tâche ou un backlog. Faites une pause de la période passée, surtout - de sa dernière partie, quand il fallait donner un résultat "énorme". Bien sûr, il y a des gens qui sont stables et rythmés, qui travaillent toute la semaine à la même vitesse, mais la plupart commencent à "travailler normalement" quelque part mercredi.
Est-il possible de se passer du sprint et de son backlog? C'est facile.
Par exemple, appliquer l'outil "dès que possible". En général, ce n'est pas une manière Praporsky, mais une stratégie tout à fait normale pour la même planification d'atelier (dès que possible, dès que possible). Cela signifie que les problèmes «colleront» au début de l'intervalle de temps, c'est-à-dire Lundi et non vendredi, comme pour la stratégie «En dernier lieu, ALAP».
La planification en tant que telle n'est pas nécessaire dans ce cas. Il y a un arriéré de produits, il y a des priorités, il y a une règle "dès que possible". Vous prenez le premier et le faites. Terminé - vous prenez le second. Et ainsi - de la clôture au dîner. Sprint, ou plutôt son essence, c'est-à-dire le temps que vous pouvez laisser pour comprendre et analyser la productivité (semaine en semaine, mois en mois, etc.).
Y a-t-il des lacunes dans la stratégie "dès que possible"? Bien sûr, un million. Tout d'abord, une personne peut se fatiguer rapidement. Deuxièmement, il se sentira comme une machine-outil. Troisièmement, il s'enfuira très probablement - là où les sprints ordinaires avec un carnet de commandes sont utilisés. Ou ils se contentent de définir des tâches et attendent le résultat. En général, là où il fait plus calme. Mais la pratique montre que "dès que possible" est tout à fait possible de vivre pendant des années, s'il est de bon sens qu'il s'agit d'une stratégie de planification, et non d'un sweat-shirt.
Est-il possible de lancer un sprint et son backlog? Non. Non pas parce que ce sont des notions uniques de la même mêlée, mais parce que c'est une méthode de planification naturelle que tout le monde, sous une forme ou une autre, utilise. Il existe de nombreuses variantes, un principe - vous devez effectuer une certaine quantité de travail pendant une certaine période de temps.
Un outil comme un sprint est-il un élément unique et clé d'une technique? Non. Cela revient à dire que taper du code sur le clavier est une notion unique d'une certaine technique. Presque tous les textes sont saisis au clavier.
Planche de mêlée
Formellement, une planche n'est pas un artefact ou une règle, mais je pense que cela vaut la peine d'en parler aussi, car il y a un schéma assez évident parmi les gens: une mêlée est une planche avec des autocollants.
Ici, en général, vous comprenez vous-même tout. Un tableau avec des autocollants sur lesquels les tâches sont écrites n'est pas unique. Il s'agit en gros d'un outil multiplateforme. Ma femme sur le réfrigérateur sculpte parfois des autocollants avec des listes de choses à faire, même si elle ne sait rien de la mêlée.
Cet outil est-il bon? Cela dépend de ce qu'il faut comparer. Oui, peut-être une bonne.
Par exemple, il vous permet d'évaluer rapidement, de parcourir le pool de tâches. Dans un ordinateur ou tout autre appareil électronique, les tâches doivent être inversées - tout ne tient généralement pas sur un seul écran. Par conséquent, en un coup d'œil - aussi.
Un autre avantage important est la disponibilité globale de l'équipe. A tout moment, vous pouvez venir voir, ne pas aller dans aucun système, rechercher, faire une sélection, etc.
Beaucoup de gens aiment la nature non virtuelle de la carte. Après tout, tout est virtuel dans un ordinateur, vous ne le touchez pas avec vos mains. Et ici - s'il vous plaît, au moins lécher. Certains, à cet égard, adorent les planches de liège. La différence est quelque chose comme entre le papier et les livres électroniques.
Spécifiquement pour une planche de mêlée, on peut noter un avantage tel que la séparation en deux parties - cela se fait au travail. La manipulation des autocollants par les ménages implique de jeter ceux qui sont déjà terminés - pas très bien, car le progrès est pire.
Y a-t-il des inconvénients aux planches Scrum? Bien sûr. Comme n'importe quelle planche.
Pour commencer avec le ménage - brouillons, autocollants de mauvaise qualité, mauvaise écriture, sabotage. En conséquence, des tâches perdues et une confusion dans la gestion.
Au tableau, les progrès sont peu visibles. En général, pour le sprint - oui. Aujourd'hui, hier - non. D'où la nécessité d'une discussion quotidienne.
Plus précisément, l'état des tâches n'est pas visible sur la planche de mêlée, si la vie est plus compliquée que «planifiée» - «terminée». Le tableau Kanban semble préférable.
Le conseil d'administration ne permet pas un travail normal si l'équipe est géographiquement répartie. Par conséquent, des cartes électroniques apparaissent.
La carte électronique, me semble-t-il, est un signe certain de sectarisme. Elle a perdu tous les avantages de l'habituel, mais, pour une raison inconnue, elle continue de l'utiliser. Probablement juste parce que c'est une planche. Fait partie de la méthodologie.
En général, un outil est comme un outil. Dans certaines situations - bien. Dans certains, c'est terrible.
La mêlée fonctionnera-t-elle sans planche? C'est facile. Et prouvé par la pratique. Et il semble que, puisque le plateau n'est pas un artefact obligatoire, il sera possible de continuer à appeler scrum - scrum.
Scrum master
Qui est ce rôle miracle? À quoi ça ressemble?
Il existe de nombreuses options. Par exemple, un Scrum Master est comme un entraîneur sportif. Il y a, disons, un club de football. Le propriétaire des produits est un manager qui définit les objectifs de l'équipe. Un entraîneur est celui qui aide une équipe à atteindre ces objectifs.
Dans l'environnement de production habituel, il n'y a pas d'entraîneurs - si le club de football fonctionnait comme ça, le patron viendrait simplement dans les vestiaires avant le match et dirait: "allez gagner". Et quand ils perdent, il serait content de l'arnaque. Il a viré quelqu'un, menacé quelqu'un, etc. Comme une usine.
Et l'entraîneur, comme le Scrum Master, sert de fournisseur entre l'équipe et le manager. Bien sûr, l'entraîneur a plus de pouvoir - il n'est pas un serviteur leader. Mais le résultat est également exigé de lui plus rapidement et plus facilement - personne n'attendra qu'il y facilite quelqu'un. L'entraîneur, comme le Scrum Master, comprend comment l'équipe doit fonctionner, c'est-à-dire il définit simplement les tâches et explique comment les résoudre. Établit des liens, motive, crée et maintient une atmosphère, etc.
Une autre analogie est le commandant de peloton, certaines forces spéciales. Ceci est un coach de jeu. Va sur des tâches avec des subordonnés, résout les missions de combat de la même manière. Pendant son temps libre, il supervise la préparation et l'amélioration des compétences, le développement de nouveaux équipements et l'entraînement physique. Bien sûr, il travaille constamment avec l'équipe en termes de psychologie - cela motive, soutient, aide. Par des méthodes particulières, bien sûr, parfois, mais le but est un - l'efficacité maximale au combat du peloton.
Scrum master, comparé à ces gars, un freeloader. Car le résultat n'est pas particulièrement responsable. Le manque d'autorité formelle, semble-t-il, est perçu comme un avantage - il est un leader-serviteur, mais en fait, il peut devenir irresponsable. Peut-on sans cesse faciliter, sans exercer aucune influence sur le résultat? Et quand ils les expulsent, cherchez une autre équipe pour y faciliter.
Est-il possible de changer ou supprimer le rôle d'un Scrum Master? Bien sûr. Par exemple, combinez ce rôle avec le propriétaire du produit. Je sais que dans la méthodologie, il est écrit qu'il vaut mieux ne pas le faire - cela empêchera le maître de faciliter. Mais, d'un autre côté, cela ajoutera des objectifs et des responsabilités clairs. Lorsque l'objectif est compréhensible et mesurable, la facilitation passe d'une merde facultative et incompréhensible à un devoir très spécifique et tangible qui affecte directement le résultat. Comme un entraîneur ou une équipe.
Certes, alors le sens de l'appeler un maître de mêlée est perdu. Ce sera probablement un chef d'équipe - n'oubliez pas que le "leader" est le leader. Un leader n'est pas seulement un drapeau entre ses mains, mais il travaille également avec la motivation, les objectifs, la capacité de continuer, l'introduction de nouvelles méthodes de travail, la formation des compétences, etc. Le pilote de la commande, en bref. Et dans le sens du développement interne, et dans le sens de l'obtention de résultats.
Si vous remplacez le maître par timlida en mêlée, que se passera-t-il? Cela ne peut plus être appelé mêlée - l'un des rôles clés a été supprimé. Et comment cela affectera-t-il le résultat? Et si pas du tout sans scrum master? Si ses fonctions sont effacées sur commande, comment Belbin a-t-il été recommandé? L'un facilite, l'autre motive, le troisième surveille la mise en œuvre des règles.
Il est tout à fait possible pour vous de vivre comme ça.Total
Eh bien, tout, alors le principe est clair. Scrum, comme toute autre technique, est un algorithme tissé à partir de composants ou d'outils. Qui l'a tissé? Eh bien, disons Jeff Sutherland et Ken Schwaber.Imaginez que deux gars, Jeff et Ken, ont créé un composant qui apporte de bons avantages dans le développement d'applications Web. Vous l'avez creusé dans un github, vous l'avez installé, vous l'avez essayé - wow, c'est cool! Ça marche! Et la vérité est que c'est devenu meilleur!Et puis, à un moment donné, quelque chose a commencé à vous ennuyer dans ce composant. Par exemple, appeler ses méthodes ne semble pas assez polymorphe. Vous allez dans le code source et découvrez ...Que pouvez-vous y trouver? Oui, n'importe quoi. Par exemple, emprunter que vous n'aimez pas. Ou les composants empruntés seront corrects, mais utilisés de manière tordue. Ou une version spécifique d'un bon composant est directement indiquée, mais elle se développe bien et est devenue beaucoup plus cool il y a longtemps, mais les développeurs ne veulent pas adapter un composant de niveau supérieur. Ou vous trouvez dans l'algorithme un morceau d'une taille décente qui mange bien les ressources, mais n'apporte aucun avantage particulier à votre projet.Que ferez-vous? Bien sûr, chacun répondra à quelque chose de différent. Quelqu'un ne va même pas entrer. Quelqu'un va bifurquer et réparer ce qu'il n'aime pas. Bien sûr, cela entraînera des problèmes de mise à jour. Bien que ce ne soit pas un fait - des choses comme la mêlée ne changent pas pendant des années. Quelqu'un écrira aux développeurs. Je ne sais pas ce qu’ils vont répondre.Quelqu'un prend simplement les composants source et les réassemble à sa manière - selon les besoins dans un projet ou un produit particulier.Vous pouvez faire de même avec n'importe quelle technique. Je voulais écrire «c'est possible et nécessaire», mais je n'ai pas imposé mon opinion - tout le monde décide après tout.Je veux terminer avec une citation Goldratt. C'est peut-être le seul des sommités à avoir développé certaines méthodes, parlant honnêtement de la nécessité de leur changement, adaptation, mise en page et, surtout, compréhension des principes de fonctionnement., . , – . , , . – ( — ) . , , . , .