J'ai récemment rejoint un projet de développement et on m'a soudainement confié le poste de développeur principal. Ma principale responsabilité consiste à scinder la partie programmation du projet en tâches, à confier ces tâches aux autres développeurs, puis à vérifier que les pièces fonctionnent ensemble.

Le problème est que je ne sais pas comment faire cela. J'ai passé le week-end avec un crayon et du papier à essayer de comprendre, mais je continue à dresser une liste de tâches sur lesquelles il convient de travailler de manière séquentielle plutôt qu'en parallèle. Je pensais peut-être à le scinder en fonctionnalités, mais vous vous retrouvez avec des tâches nécessitant l'édition des mêmes fichiers, ce qui peut nécessiter la réécriture complète d'une tâche en raison de l'avancement du développement. Certains développeurs pourraient attendre que le programme soit un peu plus complet et plus facile à créer, mais j'aurais alors des personnes assises sur leurs mains pour savoir combien de semaines.

J'ai eu une conversation avec mon patron à propos de mes qualifications pour le faire et je n'ai pas eu le choix. Je n'ai aucune idée de ce que je fais, alors des conseils et des coups de pouce dans la bonne direction seraient grandement appréciés.

Une bonne réponse à votre question remplit plusieurs livres . Je proposerai une liste de mots à la mode qui me viennent à l’esprit, Google et les livres feront le reste à votre place.

1. Les bases

   • Ne partez pas seul . Essayez d'impliquer vos coéquipiers autant que possible.
   • Voyage léger .
   • La démocratie, mais pas trop. Parfois, il ne s'agit pas de ce qui satisfait le plus grand nombre de personnes, mais de ce qui fait le moins mal.
   • Gardez ce qui doit être fait et comment (c'est fait) séparément .
   • En savoir plus sur Scrum ("quoi"), XP (programmation extrême, "comment"), Kanban ("combien"), Lean ("quoi pas") et DevOps ("avec qui").
   • Lean concerne également le débit : pour l'efficacité globale, l'efficacité du débit est généralement plus importante que l'efficacité individuelle.
   • En savoir plus sur les savoir-faire logiciels , le code propre et la programmation pragmatique .
   • Une bonne architecture consiste à maximiser le nombre de décisions non prises .
   • Scrum / XP / Lean / Agile consiste à maximiser la quantité de travail non effectué : YAGNI .
   • La principale valeur du logiciel est que vous pouvez facilement le changer . Qu'il fasse ce qu'il devrait faire est important, mais ce n'est que sa valeur secondaire.
   • Préférez une approche itérative et incrémentale , utilisez des créneaux horaires pour presque tout, en particulier les réunions, faites de la loi de Parkinson votre ami parce que la loi de Hofstadter s'applique.
   • Structure d'équipe équilibrée avec une compréhension de la loi de Conway et des étapes de développement d'équipe de Tuckman .
   • La programmation est une quaternité, c'est à la fois la science , l' ingénierie , l' art et l' artisanat , et ceux-ci doivent être en équilibre.
   • Le fait que Scrum / XP / XYZ soit bon pour quelqu'un (y compris moi) ne signifie pas nécessairement que c'est bon pour vous / convient à votre environnement. Ne suivez pas aveuglément le battage publicitaire, comprenez-le d'abord.
   • Inspectez et adaptez! (Scrum Mantra)
   • Évitez les doubles emplois - une fois et une fois! (XP Mantra) aka DRY - Ne vous répétez pas aka SPOT - Un seul point de vérité

2. "Quel monde" processus de répartition du travail

   • Rassemblez les exigences en tant que user stories / jobs dans un backlog de produit .
   • User (of User Story) similaire à Actor (en UML) similaire à Persona similaire à Role .
   • Affinez les histoires d'utilisateurs jusqu'à ce qu'elles répondent à la définition de Ready de votre équipe basée sur INVEST (indépendant, négociable, précieux, estimable, petit, testable). (Scrum Meeting: Affinement de l'arriéré )
   • Triez le backlog du produit par valeur commerciale .
   • Ne commencez pas à travailler sur une histoire avant qu'elle soit prête, prête (selon la définition de prêt).
   • Utilisez Planning Poker pour estimer l’effort d’histoires en points d’histoire . Utilisez la comparaison par triangulation pour assurer la cohérence des estimations.
   • La météo d'hier est la meilleure estimation, espérons le pire.
   • Histoires divisées si elles sont trop grandes.
   • Améliorer la culture de diffusion avec une définition de fait .
   • Ne pas accepter la mise en œuvre d'une histoire de l' utilisateur avant qu'il ne soit Terminé Terminé (fait selon la définition de DONE).
   • Plusieurs équipes sur la même base de code doivent s'accorder et partager la même définition de «fait» (en particulier les normes de codage ).
   • Vérifiez vos progrès avec les graphiques de Burndown .
   • Vérifiez régulièrement avec vos parties prenantes si ce que l'équipe fournit est vraiment nécessaire. (Scrum Meeting: Revue de Sprint )

3. Répartition de l'histoire

   • Lister et décrire les utilisateurs / Personas / Acteurs / Rôles (Product Owner)
   • Epic -> Stories (User Story ou Job Story) (Product Owner)
   • Histoire -> Critères d'acceptation (Product Owner)
   • Histoire -> Sous-tâches (Équipe de développement)
   • Critères d'acceptation -> Tests d'acceptation (Spec: Product Owner, Impl: Dev Team)
   • Commencez avec un squelette ambulant qui est un demi-bout minimaliste .
   • Créer un MVP - Produit minimum viable .
   • Développez le MVP en utilisant SMURFS - Ensembles de fonctionnalités spécifiquement commercialisables, utiles et diffusables .

4. "Comment le monde" réalisation

   • Utilisez les cartes OOA / D , UML et CRC , mais évitez les grandes tailles initiales .
   • Implémentez autant que possible des objets , structurés et fonctionnels en même temps, quel que soit le langage de programmation.
   • Utilisez le contrôle de version (de préférence distribué ).
   • Commencez avec les tests d'acceptation .
   • Appliquez le TDD en laissant les trois lois du TDD vous guider à travers le cycle rouge-vert-refactor , avec une règle d’assert unique , 4 A , GWT (Étant donné quand) de BDD .
   • " Les tests unitaires sont des tests rapides ." - Michael Feathers
   • Appliquez les principes SOLID et package pour gérer le couplage et la cohésion . Exemple: S dans SOLID est SRP = Principe de responsabilité unique, réduit considérablement le nombre de modifications / resp. fusionner les conflits en équipes.
   • Connaître la loi de Demeter / Tell, Don't Ask .
   • Utilisez l’ intégration continue , le cas échéant, voire la livraison continue (DevOps).
   • Utilisez la propriété collective du code sur la base d'une norme de codage commune convenue (qui devrait faire partie de la définition de terme ).
   • Appliquer une amélioration continue de la conception (refactorisation continue fka).
   • Le code source est la conception . Une réflexion initiale est indispensable et personne ne s’opposera à quelques bons diagrammes UML clarifiant.
   • XP ne veut pas dire qu’aucun jour n’est un jour d’architecture, cela signifie que chaque jour est un jour d’architecture. C'est un focus sur l'architecture, pas un flou, et le focus est dans le code.
   • Limitez votre dette technique et évitez les quatre odeurs de conception Fragilité , Rigidité , Immobilité et Viscosité .
   • L'architecture concerne la logique métier et non les mécanismes de persistance et de livraison.
   • L'architecture est un sport d'équipe ( il n'y a pas de «je» dans l'architecture ).
   • Schémas de conception , refactorisation et principe de priorité de la transformation .
   • Le code de projet est l' ATP-Trinity avec les priorités suivantes: 1. Code d'automatisation , 2. Code de test , 3. Code de production .
   • Vérifiez régulièrement auprès de vos pairs si des améliorations peuvent être apportées à l’équipe. (Scrum Meeting: Rétrospective Sprint )
   • Les tests doivent être FIRST - rapides, indépendants, répétables, auto-validants et rapides.

La liste ci-dessus est certainement incomplète et certaines parties pourraient même être contestables!

Si tout cela vous fait peur - ne vous inquiétez pas, cela devrait vous faire peur! Réussir des projets de développement de logiciels en équipe n’est pas une tâche facile et il est rare que les gens soient correctement formés et éduqués à cet art. Si cela vous fait peur, votre intuition fonctionne correctement, écoutez-la. Vous voulez être préparé. Parlez à votre patron, prenez du temps et formez-vous.

Voir également

• Qui écrit les 'user stories' techniques dans Scrum

Lectures complémentaires (en ligne)

• Portland Pattern Repository par Ward Cunningham et al
• Principes d'OOD par Robert "Oncle Bob" C. Martin
• Conseils du programmeur pragmatique

Lectures complémentaires (livres)

• Clean Code de Robert C. Martin
• Développement logiciel agile: principes, modèles et pratiques par Robert C. Martin
• Le programmeur pragmatique - De compagnon à maître par Andrew Hunt et David Thomas
• Travailler efficacement avec le code hérité de Michael Feathers
• Refactoring - Améliorer la conception du code existant par Martin Fowler
• Refactoring à Patterns par Joshua Kerievsky
• Le MBA Dix Jours par Steven Silbiger (sic!)
• Conception axée sur le domaine par Eric Evans
• Histoires d'utilisateurs appliquées par Mike Cohn
• Analyse et conception orientées objet avec applications par Gray Booch et al.
• Modèles de conception par la bande de quatre
• Test Driven Development par Kent Beck
• Extreme Programming par Kent Beck
• [si Java] Effective Java par Joshua Bloch

Devenir Agile

Je suggérerais ce qui suit:

Éditer les mêmes fichiers

Tout d’abord, utilisez Git (ou un système de gestion de versions simultané similaire). Tant que vous éditez différentes parties des mêmes fichiers, vous ne rencontrerez pas de conflits. Si vous obtenez des conflits, ils seront clairement identifiés comme tels.

Essayer de gérer un projet multi-développeurs sans Git, c'est comme essayer de faire un pudding sans bol de pudding. C'est possible, mais ça va devenir assez compliqué.

Comme il a été souligné dans les commentaires, Git n’est pas une panacée, mais combiné à des tests automatisés, il est certainement très utile.

Lister toutes les fonctionnalités

Deuxièmement, divisez le projet en fonctionnalités visibles par l'utilisateur. Par exemple, "lorsque l'utilisateur s'inscrit, il devrait recevoir un courrier électronique" ou "L'utilisateur peut ajouter un élément". Impliquez toutes les parties prenantes ici. Rassemblez tout le monde dans une pièce et invitez tout le monde à crier ses traits.

Celles-ci doivent être des fonctionnalités visibles par l'utilisateur, vous pouvez parler de la stratégie de mise en œuvre plus tard.

Ecrivez toutes les suggestions sur des fiches, même les plus stupides. Rationalisez rapidement la liste pour supprimer les doublons et disposez toutes les cartes sur une grande table, voire au sol.

Ajoutez toutes les cartes supplémentaires nécessaires. Supposons que votre application envoie des alertes par SMS. Vous ne savez peut-être pas comment faire cela, alors vous avez une question. Ecrivez "Enquêter sur les portails SMS" sur une carte. De même pour toutes les autres grandes inconnues. Vous devrez les décompresser plus tard. Ces fonctionnalités ne feront probablement pas partie de votre premier sprint.

Maintenant, triez vos cartes en groupes, mélangez-les, essayez -les. Ceci est la portée de votre projet.

Planification du poker

Essayez de planifier le poker. Toujours avec tout le monde, donnez à tous les développeurs des cartes indiquant "1 point", "2 points", etc., jusqu'à "4 points". Aussi une carte "plus". Un point équivaut à peu près à une heure.

Parcourez la liste des fonctionnalités une à une. Lorsque vous lisez une fonctionnalité, tout le monde doit jouer une carte. Si une personne joue à 1 et une autre personne à 4, il y a un problème de communication. Une personne comprend que la fonctionnalité signifie quelque chose de différent de l'autre personne. Ayez une discussion, déterminez ce que vous voulez réellement dire et notez-le sur la carte.

Si vous convenez qu'une fonctionnalité est un "plus", cette fonctionnalité est trop grande. Vous devez décomposer cette fonctionnalité. Faites cela de la même manière que précédemment.

Avec votre accord, écrivez les numéros sur les cartes dans un stylo de couleur différente.

Les points valent mieux que les heures

Utiliser des points au lieu de plusieurs heures enlève au macho ce que nous, les développeurs, faisons souvent dans le code. C'est une différence subtile, mais j'ai trouvé que cela fonctionnait plutôt bien.

Maintenant, composez un sprint

Un sprint est un coup d'éclat rapide vers un but. Décidez de la durée du sprint, peut-être 5 ou 10 jours. Multipliez le nombre de jours par le nombre de développeurs par le nombre de points par jour.

Supposons initialement 6 points par jour et par développeur. C'est un nombre réalisable. Si vous avez 5 personnes, cela fait 5 * 5 * 6 = 150 points. En collaboration avec tous les développeurs et la direction, sélectionnez des fonctionnalités dans la liste, jusqu'à 150 points. C'est ton sprint.

Ne soyez jamais tenté de faire plus que ce qui convient. Une promesse excessive nuit à tout le monde, y compris à vous.

Vous devrez tenir compte des dépendances ici. Par exemple, la configuration de l'environnement doit évidemment être incluse dans le premier sprint. C'est en fait relativement facile à faire quand tout le monde est présent. Vous avez 6 cerveaux dans la pièce, tous disant "ça dépend de ça", etc. Vous pouvez ensuite mélanger les cartes pour démontrer les dépendances.

Une fois que vous avez votre sprint, rien ne peut y être ajouté, il est verrouillé pour les 5 jours. Le glissement de fonctionnalités va stresser l’équipe, nuire au moral et ralentir tout le monde. Finalement, le fluage va bloquer un projet. En tant que chef d'équipe, vous devez protéger votre équipe contre le glissement des fonctionnalités. Si une nouvelle demande de fonctionnalité arrive, elle doit être ajoutée au prochain sprint. Si le prochain sprint est déjà complet, quelque chose d'autre doit être retiré.

Ne jamais être tenté de serrer dans les extras. Une promesse trop longue vous donne environ 1 jour de client heureux, suivi de 4 jours de stress pour l’équipe et, éventuellement, de plusieurs clients mécontents lorsque l’équipe ne peut pas livrer à temps.

Maintenant, allez-y.

Distribuez des cartes, demandez qui veut faire quoi. Vous avez une visibilité totale sur ce qui se fait et vous pouvez compter les points à zéro. Ayez un stand up au début de chaque journée pour que tout le monde sache qui travaille sur quoi et ce qui a été fait.

Cinq ou six développeurs motivés qui travaillent ensemble pour former des objectifs gérables clairement définis peuvent réaliser une quantité assez importante de choses en un sprint de cinq jours.

Maintenir la visibilité

Assurez-vous que tout le monde peut voir quel est le statut du projet. Bluetack toutes les cartes au mur. Sur la gauche sont des cartes qui ne sont pas encore travaillées. A droite sont faites les cartes.

Lorsqu'un développeur travaille sur une carte, il la décolle et la pose sur son bureau. Cela préserve la visibilité et empêche les gens de marcher trop lourdement sur les pieds.

Il existe des alternatives technologiques aux fiches, mais rien ne vaut un affichage papier massif de l'état du projet sur le mur.

Si possible, placez tout le monde dans la même pièce pendant toute la durée du projet. Avoir les parties prenantes autour autant que possible, idéalement tous les jours.

Incendier

Vous pouvez représenter graphiquement vos points progressant vers zéro sur un graphique de burndown. Si votre ligne de meilleur ajustement dépasse zéro avant de respecter votre limite de temps, vous êtes probablement sur la bonne voie. Sinon, vous devrez peut-être informer votre client maintenant avant de vous approcher trop près de la date limite.

Si vous échouez, échouez tôt.

Vous pouvez créer un burndown à l'aide d'un logiciel, mais je préfère un gros morceau de papier au mur. Dessine et écris partout.

Test automatisé

Lorsque plusieurs développeurs travaillent simultanément sur le même matériel, ils vont probablement se casser le code les uns des autres de temps à autre. La communication et la visibilité aident à cela, mais vous allez probablement vouloir introduire une technologie pour vous aider à trouver des problèmes.

Le test unitaire est le processus d'écriture de tests pour chaque partie individuelle de votre base de code (idéalement pour chaque méthode). Vos tests unitaires doivent être exécutés souvent, avec chaque sauvegarde si possible. Il existe de nombreux outils qui peuvent aider à cela, par exemple Karma ou Rspec.

Les tests de bout en bout consistent à tester votre projet dans son ensemble, en traitant les éléments internes comme une boîte noire. Basez ces tests sur vos exigences professionnelles de haut niveau, par exemple: "L'utilisateur peut s'inscrire" ou "L'utilisateur peut voir une liste d'éléments". Protractor est un bel exemple de framework de test basé sur le Web.

Il existe des livres entiers sur les tests, mais la mise en place d'au moins quelques tests d'acceptation peut vous aider à vous assurer que rien ne se brise pendant que vous travaillez sur votre projet.

Éviter la dette technique et se faire fini

La dette technique est un concept qui décrit des choses qui devront être nettoyées plus tard. Une source commune d’endettement est constituée de caractéristiques qui ont été marquées comme étant terminées, mais qui n’ont jamais été "réalisées". Une fonctionnalité terminée est vérifiée dans Git, approuvée par la partie prenante et soumise à un test.

Ne cochez pas vos fonctions jusqu'à ce qu'elles soient terminées. Ne jamais masser le graphique. Encore une fois, cela fait mal à tout le monde à long terme, y compris à vous.

C'est l'une des raisons pour lesquelles nous ne citons initialement que 6 points par développeur et par jour. Done-done demande un travail supplémentaire, mais se sent bien et donne un coup de pouce à l'équipe.

Éditer les mêmes fichiers n'est pas un problème en soi. Ce n'est un problème que si vous modifiez la même fonction pour faire deux choses différentes.

Fondamentalement, je diviserais le projet en «fonctionnalités» distinctes. L’un pourrait être lié à la gestion du protocole réseau, l’autre à un fichier de configuration et un autre encore à la gestion de la base de données. Les fonctionnalités sont de grandes choses.

Ensuite, vous souhaitez diviser ces fonctionnalités en tâches (récits). Celles-ci doivent être simples, comme "lorsque l'utilisateur clique sur un bouton, le programme charge le fichier", "au démarrage du programme, il charge le fichier de configuration", etc.

Certaines tâches devront être complétées de manière séquentielle ("le programme analysera tous les champs du fichier de configuration" devra être placé après "le programme chargera le fichier de configuration"). Les autres ne le feront pas (vous pouvez travailler à la fois sur la base de données et sur le réseau).

Mais très probablement, vous le ferez mal, et c'est là que l'expérience se met en place. Vous échouerez un tout petit peu (ou beaucoup), obtiendrez une mauvaise estimation du temps et votre projet prendra un peu plus de temps qu'il ne l'aurait dû. La prochaine fois, ça ira mieux.

Je suggérerais également de lire "Extreme Programming" de Kent Beck. Excellent livre qui m'a aidé quand j'étais sur le point de devenir chef de projet.

En résumé, vous devez diviser votre application en modules fonctionnels, puis introduire des contrats (interfaces et contrats de données) entre les différents modules. Chaque module peut ensuite être remis à un développeur différent. Lorsque vous remettez tout en place, les contrats garantissent que ces modules communiquent correctement les uns avec les autres.

Veillez à appliquer TDD aux développeurs afin de garantir que les modules fonctionnent tous individuellement.

Pour vous donner un exemple de ce que je veux dire:

Supposons que vous souhaitiez qu'un de vos développeurs construise un enregistreur SQL.

Vous définissez une interface et demandez à l'un de vos développeurs ( ou créez une histoire si vous utilisez Agile ) que vous souhaitiez un enregistreur spécifique à SQL selon la spécification suivante:

interface ILogger
{
    void Log(string message, int level);
}

Ce que j'attends alors d'un développeur est le suivant:

1. L'implémentation spécifique à SQL pour le consignateur

   class SqlLogger : ILogger
   {
       private readonly SqlLogRepository _logRepository;
   
       public SqlLogger(SqlLogRepository _logRepository)
       {
           this._logRepository = _logRepository;
       }
   
       public void Log(string message, int level)
       {
           _logRepository.CreateLog(message,level);
       }
   }

2. Tout code dépendant, tel qu'une implémentation pour SqlLogRepository

3. Tests unitaires ou simulés selon ce qui a été demandé. Un test fictif dans le cas ci-dessus (où nous avons d'autres dépendances externes), ou s'il s'agit par exemple d'une fonction utilitaire simple telle que String.ReverseCharacters(string input), alors j'aimerais simplement voir des tests unitaires qui testent plusieurs scénarios différents.

Cela signifie que:

Vous et votre équipe pouvez maintenant poursuivre le développement en utilisant cette interface. par exemple

class SomeModuleThatUsesLogging
{
    private readonly ILogger logger;

    public SomeModuleThatUsesLogging(ILogger logger)
    {
        this.logger = logger;
    }

    public void DeleteFiles()
    {
        logger.Log("user deleted files",1);
    }
}

et si vous devez exécuter votre code avant qu'il ne SqlLoggersoit en place, vous pouvez simplement créer un NullLogger:

class NullLogger : ILogger
{
    public void Log(string message, int level)
    {
    }
}

Et voici comment vous pouvez le tester entre-temps (je suggère de regarder un ICO pour une injection de dépendance)

void Run()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging(new NullLogger());
    someModuleThatUsesLogging.DeleteFiles();
}

Sommaire

Je n'ai aucune idée de la taille de votre projet, mais cela pourrait être une tâche ardue et si vous n'aviez jamais dirigé le développement auparavant, je vous suggérerais de prendre cette tâche très au sérieux et de passer les prochaines semaines à lire autant que vous le voudrez. peut sur la conception de logiciel et l'architecture. Et soyez très transparent sur votre travail ( qualité logicielle, etc. ), sinon vous vous retrouverez rapidement dans un gâchis profond que vous ne savez pas comment vous en sortir.

Je suggère également fortement que vous lisiez sur le design et le paradigme orienté objet. Vous comptez beaucoup sur la programmation orientée objet pour ce projet.

Les autres réponses ont parlé des aspects liés à la programmation, mais je voulais simplement mentionner l’aspect gestion des programmes. Je vais commencer par un disclaimer: je ne suis pas un responsable de programme. J'ai suivi un cours de deuxième cycle en gestion de programme et mon expérience professionnelle implique de passer des heures à soumissionner pour de petits projets d'une durée inférieure à 500 heures et jamais supérieure à 1 000 heures.

Mais j'ai dû aider à définir les tâches d'un laboratoire où je devais occuper 2 à 3 personnes pendant 2 à 4 mois (à temps partiel et à temps plein). L’utilisation de logiciels de gestion de projets tels que Microsoft Project est une chose qui m’a vraiment aidée (je ne sais pas s’il existe une version gratuite, mais votre employeur a probablement quelque chose comme ça ... demandez à votre superviseur quel type de logiciel de gestion de programme est utilisé chez vous). En particulier, j'utilise assez souvent les diagrammes de Gantt, qui sont la vue par défaut dans Microsoft Project. En définissant toutes les tâches et leur durée, vous pouvez obtenir une visualisation pour jouer.

Le diagramme de Gantt m'aide le plus en raison de sa visualisation. Voir des tâches sur du papier ne m'aide pas beaucoup, mais voir de jolies images et un graphique, c'est certain. Microsoft Project vous permet également de définir les prédécesseurs et les dates de début. L’idée principale est "Trouvez le nombre minimal de tâches à exécuter pour que la tâche X puisse démarrer". Au moins dans mes petits projets, la quantité de «vrais» prédécesseurs est assez petite. En fait, sur un projet, j’avais le problème que presque tout pouvait être fait en même temps et que je devais synthétiser deux chemins simultanés quelque peu cohésifs. Par exemple, j'ai essayé de m'assurer que si le développeur A touchait l'interface graphique, ils travaillaient également sur des tâches proches de l'interface graphique.

On dirait que vous avez déjà beaucoup travaillé sur ce sujet, mais je trouve toujours très utile de voir les diagrammes de Gantt. En regardant les tâches alignées les unes après les autres, cela me fait vraiment penser: "Attendez, est-ce que la tâche X doit vraiment être accomplie avant la tâche Y?

On dirait que votre développeur est devenu un ingénieur en logiciel. Réalisez que la gestion du travail n'est pas un exercice de conception, mais que les deux vont de pair. Vous devez gérer le travail effectué, et cela dépend de la façon dont votre entreprise se développe. Si vous avez le temps et les ressources, envisagez d'adopter une méthodologie agile - il existe une multitude de documents écrits sur Internet. Trouvez-en un qui fonctionne pour vous, mais sachez que, comme tout le reste, ce n'est pas gratuit. L’adoption de toute technique implique la formation, l’apprentissage et l’échec avant de réussir. Si vous ne disposez pas de la bande passante nécessaire pour adopter une technique plus complète, la planification par étapes peut être la solution pour vous. Si vous avez une liste de tâches séquentielles, il se peut que vous n’ayez pas trouvé de séquences pouvantêtre parallélisé. Il se peut également que vous souhaitiez segmenter votre développement en tâches plus générales telles que les tests et la mise en œuvre. Cela, en soi, ne résout pas le problème des rapports, mais vous gérez la qualité. Votre progression peut être une liste séquentielle, mais vos rôles sont parallèles. Juste une suggestion. Une conception qui intègre le travail effectué par des personnes s'appelle une structure de répartition du travail.

D'autres personnes ont fait de bonnes suggestions, mais souvenez-vous que vous gérez du travail. Parfois, vous pouvez intégrer des concepts de travail dans la conception / architecture, parfois vous ne pouvez pas le faire aussi facilement. Il y a toujours un moyen de structurer le travail pour le rendre traçable. Je suggère de contacter votre responsable et de lui demander ce qui est important pour lui lorsqu'il s'agit de communiquer l'état du projet. Cela va commencer à vous dire comment aborder ce que vous faites. Si c'est prévu, vous voulez vous concentrer sur le rapport d'avancement. Si c'est de la qualité, vous voulez créer un rapport sur une série de métriques que vous devrez établir. Si ses coûts, alors vous voudrez probablement regarder l'effort. Toutes ces choses peuvent également être liées ou non aux tâches.