Si vous vous souciez d'au moins certaines choses utiles:
a. discipline de base
b. la formation de processus d'interaction convenus entre eux et alliés
c. une explication de ce que font et comment les sous-traitants
d. flexibilité dans la gestion des processus
e. réponse rapide aux problèmes émergents
puis ils amélioreront le climat de travail dans l'équipe de développement.
Si vous voulez vous développer calmement, vous devez vous réunir, vous mettre d'accord et écrire des règles transparentes pour interagir les uns avec les autres. Du moins le plus basique.
Tous les processus et accords devraient être élaborés avec la participation de toutes les parties intéressées, et les processus affectant négativement devraient être détruits.
Je veux peindre sur l'exemple du flux de travail d'un sprint quels avantages ses éléments apportent: quelles actions sont effectuées, quels artefacts sont présents, et pourquoi chacun d'eux est nécessaire. Vous devez d'abord vous familiariser avec les définitions des événements et des artefacts de mêlée.
Sprint N-1 : préparatoire. Ce qui n'est pas exactement un sprint.
Avant le début du sprint N du développement lui-même, une partie de l'équipe est engagée dans des travaux préparatoires: tests, homologation, développement, visualisation, etc.
Signification : Afin que les développeurs soient en mesure d'effectuer la tâche de manière qualitative, d'atteindre les paramètres requis ou de résoudre le problème de quelqu'un, avant le début du développement lui-même:
a. faire à fond tout le travail préparatoire,
b. réduire les écarts,
c. tester sur les utilisateurs ou obtenir l'approbation des parties prenantes,
d. créer une visualisation détaillée.
Sortie : un ensemble d'artefacts et de données qui satisfont à la liste de contrôle Definition Of Ready.
Si vous souhaitez améliorer l'interaction entre les codeurs et tous les autres participants directs au processus de développement, il sera utile de familiariser et d'expliquer les fonctions et processus de base de tous les participants. Parmi les codeurs, il y a suffisamment d'introvertis qui n'aiment pas quand ils perturbent leur processus, mais ils doivent également comprendre comment fonctionnent les autres afin de ne pas obtenir l'effet inverse. Nous commençons:
Départ Sprint N-1 :
OKR, KPI, exigences des parties prenantes , etc. - Un ensemble de conditions externes entrantes qui guident le développement.
But du sprint N.Selon les conditions entrantes, où le développement devrait se déplacer, quels paramètres doivent être atteints, qui et pourquoi aider, l'objectif du prochain sprint de développement est formé.
Signification : l'objectif du sprint agit comme une motivation pour l'équipe, une explication de la signification de ses activités, la fixation d'indicateurs.
En l'absence : les codeurs non motivés sont principalement contrôlés avec un fouet, un tapis, des fines.
Toute équipe a besoin de motivation pour que le développement ne se transforme pas en une série sans fin de tâches insignifiantes dont on ne sait pas si quelqu'un a besoin. Surtout dans les entreprises où le développement n'est pas la base de l'entreprise, un problème survient souvent lorsque le département n'est pas apprécié, c'est pourquoi leur estime de soi et leur motivation diminuent. Nous avons besoin d'un objectif transparent et compréhensible - aider quelqu'un à résoudre le problème, améliorer certains paramètres de l'entreprise, améliorer la vie de quelqu'un. Même dans l'entreprise la plus misérable, il est bon d'avoir une conscience de la signification de leurs activités.
Toilettage de l'arriéré - rallye ou activité continue. Gérer l'arriéré d'une partie limitée de l'équipe.
Signification : Chaque sprint a lieu une réunion avec une composition limitée pour le nettoyage, l'étude de base, l'évaluation initiale de la complexité et de la faisabilité, la décomposition, la hiérarchisation des tâches dans le backlog.
Quitter : une liste des tâches pertinentes et réalisables.
Sinon : Une énorme liste de liste de souhaits dans le backlog, que personne ne lit, où les tâches sont oubliées depuis des années.
Planification du sprint N-1 - un rallye au cours duquel une partie de l'équipe d'entraînement, en fonction de l'objectif et de la portée du prochain sprint N, sélectionne, pré-évalue et hiérarchise les tâches.
Sens : la préparation du sprint nécessite également un certain ordre. La gestion des ressources est simplifiée.
Sortie : sprint N. backlog
Développement de testDépend du style de développement et de la présence de testeurs dans l'équipe.
Signification : Il vaut la peine d'avoir des plans prêts à l'emploi pour vérifier la santé du code.
Je suggère d'envisager 2 options:
En l'absence de testeurs, il est possible de transférer la création des tests à l'équipe de développement. Dans ce cas, cette activité est réalisée dans le cadre du développement de tâches dans le sprint N. Selon certaines revues, cette approche améliore la qualité du code écrit par les développeurs.
Si vous avez des testeurs, vous pouvez utiliser l'approche lorsque les tests sont écrits avant le code. L'un des avantages est que le développement de la tâche se termine chez le développeur et réduit les chances de renvoyer la tâche terminée des testeurs lorsque le développeur est déjà passé à une autre tâche.
Étude du cas d'utilisation - étude détaillée des scénarios d'interaction et des résultats de la tâche.
Signification : une description des scénarios d'interaction des tâches avec du texte ou des diagrammes améliore la compréhension du problème par toutes les parties intéressées. La solution à faible coût peut être utilisée pour créer des cas de test et du prototypage.
En l'absence : une faible élaboration conduit à une divergence de compréhension de ce qui est réellement requis de la tâche, la perte de cas d'utilisation alternatifs est possible.
Le wireframing, la maquette et le prototypage sont, dans l'ensemble, un processus itératif de développement de la visualisation de l'interface, avec des détails toujours plus nombreux. En commençant par l'option la plus simple et la moins chère, les utilisateurs / parties prenantes sont testés pour voir si l'option proposée répond à l'attente de résoudre le problème. Les tests visuels sont si utiles pour réduire l'incohérence des descriptions textuelles et très bon marché par rapport au codage que dans les entreprises dotées d'un solide lobby de conception et de produits, ils ont commencé à le séparer en une méthodologie distincte avec leurs processus, artefacts et calendrier.
Wireframing - croquis approximatif des éléments d'interface. Un stylo sur une feuille de papier ou dans un logiciel sans fioritures.
Sens : test / approbation rapide et bon marché par les parties prenantes de la tâche. Une démonstration supplémentaire de visualisation améliore considérablement la perception qu'un simple texte descriptif.
En l'absence : une divergence de compréhension de ce qui se crée réellement. Augmentation des coûts de développement.
En l’absence d’approbation : obtenir une approbation documentaire lors du développement pour une partie prenante, afin de minimiser le risque de «je ne l’ai pas demandé».
Sortie : projet de filaire approuvé / testé.
La maquette est la deuxième étape de la visualisation de votre interface. L'augmentation en détail.
Signification et absence : similaire au wireframing. Préparation du contenu pour la mise en page.
Sortie : maquette et mise en page approuvées / testées.
Le prototypage est la troisième étape du développement de la visualisation de votre interface. À la visualisation très détaillée est ajoutée une démonstration de l'imitation de l'interaction de l'utilisateur avec le produit.
Signification et absence : similaire au wireframing et à la maquette.
Sortie : nous avons un prototype détaillé du produit et la visualisation de l'interaction. Plus l'approbation documentaire par les parties prenantes ou le résultat des tests sur les utilisateurs.
DoReady =
Definition of Ready - une liste de contrôle des conditions convenues par l'équipe de développement et de pré-formation selon laquelle elle sera vérifiée: l'étude des tâches a-t-elle un niveau suffisant, la présence de tous les artefacts requis, afin que la tâche puisse être acceptée dans le développement.
Signification : Le fait d'avoir une liste de contrôle officielle acceptée par toutes les parties intéressées améliore la compréhension et l'interaction au sein de l'équipe. Tout le monde sait quoi et comment passer. Vous pouvez vous piquer le nez sur la liste de contrôle et envoyer pour finir les travailleurs négligents.
En l'absence : "Oh, j'ai presque fini, c'est fait à 95%." et ... il ne sera jamais terminé.
À mon humble avis, c'est l'artefact le plus important pour résoudre les conflits de base entre les encodeurs et tout le monde. Il est immédiatement clair qui et comment n'ont pas terminé leur travail, ce qu'ils ont violé et comment cela affectera les autres. Il est beaucoup plus difficile de contester les règles établies que dans le cas où il y a un différend fondé sur des opinions ou des pressions exercées par l'autorité / la position. Bien que le modérateur PM qui pique sur l'élément souhaité soit toujours utile.
Passé tous plus loin:
Sprint N. Nous commençons le développement.
Sprint Start N :
Définition de prêt, objectif de sprint, liste des tâches initialement évaluées - les conditions (et artefacts) nécessaires pour démarrer le sprint.
Planification du Sprint N - un rallye au cours duquel l'équipe de développement, en fonction de l'objectif et de la portée du sprint N, sélectionne, évalue, hiérarchise et décompose les tâches. Selon la vitesse moyenne de l'équipe, une certaine quantité de tâches est gagnée.
Sens : la réunion principale au cours de laquelle l'équipe vérifie si les tâches sont correctement exécutées. Comprennent-ils correctement l'ensemble des tâches, les critères d'acceptation. Les développeurs évaluent enfin le coût des tâches.
En l'absence de : chaos, les tâches seront fixées à tout moment, par toute personne incompréhensible, même en train d'effectuer d'autres tâches.
Sortie : sprint N. backlog
Remarque: selon la vitesse de l'équipe, les sprints prennent souvent 70 à 80% des tâches pour l'objectif de sprint et 20 à 30% des tâches pour les bugs, les dettes techniques ou les tâches critiques soudaines.
La décomposition et l'attribution des tâches est souvent une mini-réunion pour une équipe de développement sans personne supplémentaire.
Signification : une équipe avec un chef d'équipe décompose les tâches de sprint en sous-tâches pour une période ne dépassant pas 1 jour (bord 2). Les sous-tâches sont attribuées par les développeurs en fonction de leur spécialisation ou de leurs préférences.
En l'absence : cela dépend de la participation de l'équipe au processus si les développeurs recevront des tâches intéressantes qui contribuent à leur développement.
Sortie : détaillant le backlog de sprint N à 1 sous-tâches d'un jour.
Réunion quotidienne - courte réunion quotidienne de l'équipe de développement.
Signification : Chaque jour, les développeurs doivent se synchroniser: qui a fait quoi la veille, ce qu'ils prévoient de faire la journée en cours et quels problèmes les empêchent de terminer la tâche.
En l'absence : personne ne sait sur quoi les autres travaillent, leurs problèmes de mise en œuvre. Les délais de développement sont perturbés.
Résultat : la progression est enregistrée dans le tableau de gravure - le calendrier des tâches.
Mon opinion est que l'une des principales significations de l'existence de rallyes quotidiens est l'introduction de la discipline. Les codeurs ont de nombreux introvertis qui ne veulent pas communiquer, ne veulent pas savoir ce que font les autres, ne veulent pas passer de temps sur les rallyes. D'où les règles pour exercer la fonction debout, brièvement.
En fait, si l'équipe a bien travaillé ensemble, communique bien dans un chat et partage immédiatement tout problème, le nombre de réunions peut être réduit en restructurant les réunions en un processus continu. Mais vous ne devriez pas le couper complètement.
La discussion et la résolution des interférences sont une continuation directe de la réunion quotidienne.
Signification : après que les développeurs ont exprimé des problèmes avec la mise en œuvre des tâches, une discussion est tenue sur les tâches que l'équipe peut résoudre en interne, puis elle va aux participants et l'interférence avec la solution externe va à PM.
Sinon : les problèmes de mise en œuvre doivent être résolus ensemble, le plus rapidement possible afin que personne ne retarde artificiellement les progrès.
Lorsque les introvertis se sont enfuis dans leurs coins, vous pouvez déjà discuter des problèmes et de leurs solutions.
Commits / Code Review - vérification du code par les autres membres de l'équipe.
Signification : 1-2 autres membres de l'équipe devraient examiner le nouveau code et approuver la qualité, le style, etc.
Sinon : augmentez le nombre d'erreurs dans le code, la faible qualité et le style.
Ils proposent d'effectuer la révision de code 2 par d'autres développeurs de différents niveaux, même pour les juniors, c'est un bon moyen d'apprendre. D'une manière ou d'une autre, l'équipe obtient un style acceptable, qui sait quand et qui devra revenir au code de travail.
Déployer sur le serveur de développement / pré-démonstration - télécharger le code sur l'environnement / serveur de développement.
Signification : toute mise en œuvre de la tâche peut être téléchargée dans l'environnement de développement et inviter les personnes intéressées pour les tests et l'approbation préliminaire du travail effectué.
Sinon : lors du dernier sprint de démonstration, vous pouvez vous retrouver dans une position inconfortable en démontrant une implémentation cassée ou incorrecte.
Sortie : approbation informelle de la tâche.
Quoi qu'il en soit, des interprétations incorrectes de la tâche, ou les critères de lecture de la tâche obliquement, arrivent parfois à ce stade. Plus tôt la tâche sera vérifiée et testée, moins il sera nécessaire d'y revenir.
Définition de Terminé - Semblable à Définition de Prêt, il s'agit d'une liste de contrôle des principes selon lesquels le PM / PO accepte les tâches terminées.
Sens : créé par l'équipe de développement en collaboration avec PM / PO pour la prévisibilité des paramètres d'acceptation du travail. Chacun sait quel est le critère de la tâche et ce qui ne l'est pas.
En l'absence : sans critères clairs, le «raffinement» des tâches apparaît après les tentatives de les réussir. Ou les tâches restent inachevées jusqu'aux exigences finales.
Un accord documentaire par lequel le PM / PO accepte la tâche et ses critères, approuvé par les deux parties. Eh bien réduit la quantité de points controversés.
Empêche les PM / PO d'écraser insolemment le poteau. Réduit les tâches «terminées» de 95%. Les développeurs ne doivent pas terminer les tâches terminées après le sprint, si la tâche ne répond clairement pas à la liste de contrôle, elle ne doit pas être considérée comme acceptée et passe au futur sprint.
Examen et démonstration de l'incrément de produit - un rassemblement au cours duquel les développeurs démontrent aux parties intéressées la mise en œuvre de l'objectif de sprint.
Signification : les développeurs eux-mêmes démontrent un incrément de nouveau produit réalisable. Le PM / PO vérifie formellement les critères de performance des tâches et la conformité du DoD. Les parties prenantes décident si le nouvel incrément du produit correspond aux objectifs de sprint.
En l'absence : l'absence de démonstration formelle et d'acceptation du travail effectué réduit la valeur des critères d'acceptation, la qualité du travail effectué.
Sortie : Le travail de l'équipe est terminé. Les parties prenantes décident si le prochain sprint aura lieu.
La démonstration par le développeur de la tâche terminée est plus utile et compréhensible que la fourniture impersonnelle de nouvelles fonctionnalités à un intervenant pour une auto-analyse. Et la partie prenante voit qui a fait le travail pour lui, et les développeurs voient pour qui ils ont résolu le problème.
Recueil d'examens - suite Examen du rallye.
Signification : la présence en un seul endroit de toutes les parties intéressées, l'équipe et le produit lui-même permettent une communication informelle, de recueillir des idées, des suggestions, etc. Obtenez des commentaires sur la qualité de l'équipe.
En l'absence : le temps formel alloué réduit les contacts inutiles entre l'équipe et les parties prenantes pendant les autres heures de travail.
Sortie : nouvelles données, feedback.
Les commentaires sont généralement utiles, même les commentaires des parties prenantes sur leur expérience avec les développeurs. Raison de modifier les processus d'interaction avec les acteurs externes. L'amélioration des relations avec les parties prenantes actuelles et futures peut toujours être exploitée - commandes, budget, concessions, etc.
Sprint Retrospective N - Un rallye pour l'équipe de développement et PM / PO.
Signification : discussion des processus et des problèmes de l'équipe lors du dernier sprint, tentative de changer les processus de travail pour améliorer l'équipe. Quels processus ont été couronnés de succès, qui n'ont pas apporté d'avantages ou ont été endommagés, quels nouveaux problèmes sont apparus et comment ils peuvent être résolus.
Résultat : le plan de l'expérience du processus. Les processus sont modifiés au prochain sprint pour évaluer quelles modifications sont utiles et lesquelles doivent être rejetées.
En l'absence : planter les processus de développement de l'équipe par le haut ou en manquer réduit la convivialité, la productivité et la prévisibilité du développement de l'équipe.
En plus de la discussion banale des problèmes et de la manière de les résoudre, je veux prêter attention au «Plan de l'expérience du processus». Ne traitez pas les processus enregistrés comme gravés dans la pierre - immuables et constants. Ajouter un nouveau - test, n'a pas aimé - coupez-le.
Fin du sprint N
Sprint N + 1 . Versez un nouvel incrément dans la production
Signification : en raison de l'achèvement fréquent du sprint à la fin de la semaine de travail, le déploiement sur le serveur de production et l'accès aux utilisateurs se produisent déjà dans le sprint suivant, de sorte que les problèmes potentiels ne surviennent pas le week-end.
L'incrément est allé surveiller les paramètres.