web-dev-qa-db-fra.com

Comment décomposer un projet de programmation en tâches pour d'autres développeurs?

J'ai récemment rejoint un projet de développement et j'ai soudainement obtenu le poste de développeur principal. Ma responsabilité principale est de diviser la partie programmation du projet en tâches, de confier ces tâches aux autres développeurs, puis de m'assurer que les pièces fonctionnent ensemble.

Le problème est que je n'ai aucune idée de la façon de procéder. J'ai passé mon week-end avec un crayon et du papier à essayer de le comprendre, mais je continue à proposer une liste de tâches à travailler séquentiellement plutôt qu'en parallèle. J'ai pensé à peut-être le diviser en fonctionnalités, mais vous vous retrouvez avec des tâches qui nécessitent la modification des mêmes fichiers, ce qui pourrait nécessiter la réécriture complète d'une tâche en raison du début du développement. Je pourrais demander à certains développeurs d'attendre que le programme soit un peu plus complet et plus facile à créer pour des tâches, mais alors j'aurais des gens assis sur leurs mains pendant qui sait combien de semaines.

J'ai eu une conversation avec mon patron sur mes qualifications pour le faire et je n'ai pas eu le choix en la matière. Je n'ai aucune idée de ce que je fais, donc tous les conseils et coups de pouce dans la bonne direction seraient grandement appréciés.

team-leadertask-organization
168
khm

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

  1. Bases

    • Ne partez pas seul. Essayez d'impliquer autant que possible vos coéquipiers.
    • 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 blesse le moins de personnes.
    • Gardez quoi (doit être fait) et comment (c'est fait) séparé.
    • En savoir plus sur Scrum ("quoi"), [~ # ~] xp [~ # ~] (Programmation extrême, "comment"), Kanban ("combien"), Lean ("quoi pas") et DevOps ("avec qui").
    • Lean c'est aussi environ flow: Pour une efficacité globale, flow efficance est généralement plus important que l'efficacité individuelle.
    • En savoir plus sur Artisanat du logiciel, Code propre et Programmation pragmatique.
    • Une bonne architecture consiste à maximiser le nombre de décisions non prises.
    • Scrum/XP/Lean/Agile représente environ maximisant la quantité de travail non effectué: [~ # ~] yagni [~ # ~] .
    • Le Valeur principale du logiciel est que vous pouvez changer facilement. 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émentielle, utilisez boîtes de temps pour presque tout, en particulier les réunions, faites la loi de Parkinson votre ami parce que la loi de Hofstadter s'applique.
    • Équilibrez la structure de l'équipe en comprenant la loi de Conway et Les étapes du développement de l'équipe de Tuckman.
    • La programmation est une quaternité, c'est science, ingénierie, art et artisanat tous en même temps, et ceux-ci doivent être en équilibre.
    • Tout simplement parce que Scrum/ [~ # ~] xp [~ # ~]/XYZ est bon pour quelqu'un (y compris moi) ne signifie pas nécessairement qu'il est bon pour vous/convient à votre environnement. Ne suivez pas aveuglément le battage médiatique, comprenez-le d'abord.
    • Inspectez et adaptez ! (Scrum Mantra)
    • Évitez les doublons - Une seule fois ! (XP Mantra) aka SEC - Ne vous répétez pas aka SPOT - Point de vérité unique

  2. Processus de répartition du travail "What world"

    • Collectez les exigences sous la forme User Stories/ Job Stories dans un Product Backlog.
    • Utilisateur (de User Story) similaire à Acteur (en UML) similaire à Persona similaire à Rôle.
    • Affiner les histoires d'utilisateurs jusqu'à ce qu'ils rencontrent votre équipe Définition de Ready basé sur [~ # ~] investir [~ # ~] = (Indépendant, négociable, précieux, estimable, petit, testable). (Scrum Meeting: Backlog Refinement)
    • Triez le Product Backlog par Business Value.
    • Ne commencez pas à travailler sur une histoire avant qu'elle ne soit Ready Ready (prête selon la définition de prêt).
    • Utilisez Planning Poker pour estimer l'effort de Stories dans Story Points. Utilisez Comparaison de triangulation pour assurer la cohérence des estimations.
    • La météo d'hier est la meilleure estimation, espérons le pire.
    • Split Stories s'ils sont trop gros.
    • Améliorez la culture de livraison avec une Définition de Terminé.
    • N'acceptez pas la mise en œuvre d'une User Story avant qu'elle ne soit Terminé (fait selon la Définition de Terminé).
    • Plusieurs équipes sur la même base de code devraient s'entendre et partager la même Définition de Terminé (en particulier les Normes de codage).
    • Vérifiez vos progrès avec Burndown Charts.
    • Vérifiez régulièrement auprès de vos parties prenantes si ce que l'équipe offre est vraiment ce dont vous avez besoin. (Scrum Meeting: Sprint Review)

  3. Répartition de l'histoire

  4. Réalisation "How world"

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, car cela devrait vous faire peur! Réussir des projets de développement de logiciels en équipe n'est pas une tâche facile, et les gens sont rarement correctement formés et éduqués dans cet art. Si cela vous fait peur, votre intuition fonctionne correctement, écoutez-la. Tu veux être préparé. Parlez à votre patron, obtenez du temps et de la formation.

Voir aussi

Lectures complémentaires (en ligne)

Lectures complémentaires (livres)

  • Clean Code par Robert C. Martin
  • Développement de logiciels agiles: principes, modèles et pratiques par Robert C. Martin
  • Le programmeur pragmatique - Du compagnon au maître par Andrew Hunt et David Thomas
  • Travailler efficacement avec Legacy Code par Michael Feathers
  • Refactoring - Améliorer la conception du code existant par Martin Fowler
  • Refactoring aux modèles par Joshua Kerievsky
  • Le MBA de dix jours par Steven Silbiger (sic!)
  • Conception pilotée par 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
  • Motifs de conception par le Gang of Four
  • Développement piloté par les tests par Kent Beck
  • Programmation extrême par Kent Beck
  • [si Java] Effectif Java par Joshua Bloch
217
Christian Hujer

Soyez agile

Je suggérerais ce qui suit:

Modification des mêmes fichiers

Tout d'abord, utilisez Git (ou un système de version simultané similaire). Tant que vous éditez différentes parties des mêmes fichiers, vous n'aurez pas de conflits. Si vous rencontrez des conflits, ils seront clairement signalés comme tels.

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

Comme cela a été souligné dans les commentaires, Git n'est pas une panacée, mais combiné avec des tests automatisés, il aide certainement beaucoup.

Liste toutes les fonctionnalités

Deuxièmement, divisez le projet en fonctionnalités visibles par l'utilisateur. Par exemple, "lorsque l'utilisateur s'inscrit, il doit recevoir un e-mail" ou "L'utilisateur peut ajouter un élément". Impliquez toutes les parties prenantes ici. Obtenez tout le monde dans une pièce et demandez à tout le monde de crier ses caractéristiques.

Ces fonctionnalités doivent être visibles par l'utilisateur, vous pourrez parler de stratégie d'implémentation plus tard.

Écrivez toutes les suggestions sur les fiches, même les idiotes. Rationalisez rapidement la liste pour supprimer les doublons et disposez toutes les cartes sur une grande table ou même au sol.

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

Maintenant, triez vos cartes en groupes, mélangez-les, obtenez un sentir pour elles. C'est la portée de votre projet.

Planifier le poker

Essayez de planifier le poker. Toujours avec tout le monde ensemble, donnez à toutes les cartes de développeurs qui disent "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 par une. Lorsque vous lisez une fonctionnalité, tout le monde doit jouer une carte. Si une personne joue 1 et une autre personne joue 4, il y a un problème de communication. Une personne comprend que la fonction signifie quelque chose de différent de l'autre personne. Discutez et déterminez ce que cela signifiait réellement et notez-le sur la carte.

Si vous acceptez qu'une fonctionnalité est un "plus", cette fonctionnalité est trop volumineuse. Vous devez décomposer cette fonctionnalité. Faites-le de la même manière qu'auparavant.

Comme vous êtes d'accord, écrivez les numéros sur les cartes dans un stylo de couleur différente.

Les points valent mieux que des heures

Utiliser des points au lieu d'heures enlève le macho "regardez à quelle vitesse je peux coder" ce que nous, développeurs, faisons souvent. C'est une différence subtile, mais j'ai trouvé que cela fonctionne plutôt bien.

Composez maintenant un sprint

Un sprint est une rafale 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. Il s'agit d'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, choisissez des fonctionnalités dans la liste, jusqu'à 150 points. Voilà votre sprint.

Ne soyez jamais tenté d'en serrer plus que ce qui convient. Trop prometteur nuit à tout le monde à long terme, y compris vous.

Vous devrez prendre en compte les 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 lorsque tout le monde est présent. Vous avez 6 cerveaux dans la salle, tous disant "cela dépend de cela", 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é pendant 5 jours. Le fluage des fonctionnalités stressera l'équipe, endommagera le moral et ralentira tout le monde. Finalement, le fluage bloquera 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 sprint suivant. SI le prochain sprint est déjà complet, quelque chose d'autre doit être retiré.

Ne soyez jamais tenté de presser des extras. La promesse excessive vous donne environ 1 jour de client heureux, suivi de 4 jours de stress d'équipe et, éventuellement, plusieurs clients mécontents lorsque l'équipe ne peut pas livrer à temps.

Allez-y maintenant.

Distribuez des cartes, demandez qui veut faire quoi. Vous avez une visibilité complète sur ce qui est en train de se faire et vous pouvez compter les points jusqu'à 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.

5 ou 6 développeurs motivés décents travaillant ensemble en tant qu'unité sur des objectifs gérables clairement définis peuvent atteindre une quantité assez importante de choses en un sprint de 5 jours.

Maintenir la visibilité

Assurez-vous que tout le monde peut voir l'état du projet. Bluetack toutes les cartes au mur. À gauche, des cartes qui n'ont pas encore été travaillées. A droite se trouvent les cartes.

Lorsqu'un développeur travaille sur une carte, il la retire du mur et la pose sur son bureau. Cela maintient la visibilité et empêche les gens de trop marcher l'un sur l'autre.

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, ayez tout le monde dans la même pièce pendant la durée du projet. Ayez les parties prenantes 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 passe à zéro avant d'atteindre votre limite de temps, vous êtes probablement sur la bonne voie. Sinon, vous devrez peut-être en informer votre client maintenant, avant de vous approcher trop près de la date limite.

Si vous échouez, échouez tôt.

Vous pouvez faire un burndown en utilisant un logiciel, mais je préfère juste un gros morceau de papier sur le mur. Dessinez et écrivez dessus.

Test automatisé

Lorsque vous avez plusieurs développeurs travaillant sur la même chose en même temps, ils vont probablement casser le code de l'autre de temps en temps. La communication et la visibilité y contribuent, mais vous souhaiterez probablement 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 vous y aider, par exemple Karma ou Rspec.

Le test de bout en bout implique de tester votre projet dans son ensemble, en traitant les composants internes comme une boîte noire. Basez ces tests sur vos exigences commerciales de haut niveau, par exemple: "L'utilisateur peut s'inscrire" ou "L'utilisateur peut voir une liste d'articles". Protractor est un bel exemple d'un cadre de test basé sur le Web de bout en bout.

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

Éviter la dette technique et faire le fait

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

Ne cochez pas vos fonctionnalités jusqu'à ce qu'elles soient terminées. Ne massez jamais le graphique. Encore une fois, cela nuit à tout le monde à long terme, y compris vous.

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

35
superluminary

Ce qui revient à dire que vous devez décomposer 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 entre eux.

Assurez-vous d'appliquer TDD sur les développeurs, afin de garantir que tous les modules fonctionnent individuellement.

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

Imaginons que vous souhaitiez qu'un de vos développeurs crée 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 souhaitez un enregistreur SQL spécifique selon la spécification suivante:

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

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

  1. L'implémentation spécifique à SQL pour l'enregistreur

    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 en fonction de ce qui a été demandé. Un test simulé dans le cas ci-dessus (où nous avons d'autres dépendances externes), ou si c'est par exemple une fonction utilitaire simple telle que String.ReverseCharacters(string input), alors je voudrais simplement voir des tests unitaires qui testent quelques scénarios différents.

Cela signifie que:

Vous et votre équipe pouvez désormais poursuivre le développement à l'aide de 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 que le SqlLogger soit 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 en attendant (je suggère de regarder un ICO pour l'injection de dépendance)

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

Résumé

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

Je vous suggère également fortement de lire sur le design et le paradigme orienté objet. Vous comptez beaucoup sur OOP pour ce projet.

10
z0mbi3

La modification des mêmes fichiers n'est pas en soi un problème. Ce n'est un problème que si vous éditez la même fonction pour faire deux choses différentes.

Fondamentalement, ce que je ferais, c'est de diviser le projet en "fonctionnalités" distinctes. L'une pourrait être liée à la gestion du protocole réseau et une autre à un fichier de configuration et une autre à 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 (histoires). Il doit s'agir de choses simples, comme "lorsque l'utilisateur clique sur un bouton, le programme charge le fichier", "lorsque le programme démarre, il charge le fichier de configuration", etc.

Certaines tâches devront être complétées séquentiellement ("le programme analysera tous les champs du fichier de configuration" devra venir après "le programme chargera le fichier de configuration"). D'autres non (vous pouvez travailler sur la base de données et le réseau en même temps).

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), vous vous tromperez d'estimation de temps et votre projet prendra un peu plus de temps qu'il ne devrait. La prochaine fois, tu iras mieux.

Je suggère également de lire "Extreme Programming" de Kent Beck. Excellent livre qui m'a aidé quand j'étais sur le point d'être chef de projet.

10
Erez Eshkol

Les autres réponses ont parlé des aspects de programmation, mais je voulais juste mentionner l'aspect de gestion de programme. Je vais commencer par un avertissement: je ne suis pas un gestionnaire de programme. J'ai suivi un cours de deuxième cycle en gestion de programme et mon expérience de travail implique des heures de soumission pour de petits projets qui sont généralement inférieurs à 500 heures et jamais supérieures à 1000 heures.

Mais j'ai dû aider à définir les tâches d'un laboratoire où j'ai dû occuper 2 à 3 personnes pendant 2 à 4 mois (à temps partiel et à temps plein). Une chose qui m'a vraiment aidé était d'utiliser un logiciel de gestion de projet comme Microsoft Project (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é dans votre entreprise). En particulier, j'utilise beaucoup les diagrammes de Gantt, qui est la vue par défaut dans Microsoft Project. En définissant toutes les tâches et le temps que vous pensez qu'elles prendront, vous pouvez obtenir une visualisation avec laquelle jouer.

Le diagramme de Gantt m'aide le plus en raison de sa visualisation. Voir des tâches sur papier ne m'aide pas beaucoup, mais voir de jolies photos et un tableau le fait certainement. Microsoft Project vous permet également de définir des prédécesseurs et des dates de début, l'idée principale étant "Rechercher la quantité minimale de tâches à exécuter pour que la tâche X démarre". Au moins dans mes petits projets, le nombre de "vrais" prédécesseurs est assez faible. En fait, sur un projet, j'ai eu le problème que presque tout pouvait être fait simultanément, et j'ai dû synthétiser deux chemins simultanés qui étaient quelque peu cohérents. Par exemple. J'ai essayé de m'assurer que si le développeur A touchait l'interface graphique, il travaillait également sur des tâches proches de l'interface graphique.

Il semble que vous fassiez déjà beaucoup de choses en ce qui concerne le stylo et le papier, mais je trouve toujours très utile de voir les diagrammes de Gantt. Regarder les tâches alignées séquentiellement me fait vraiment penser "Attendez, la tâche X doit-elle vraiment être effectuée avant la tâche Y? (Selon mon expérience jusqu'à présent, j'ai été surpris de voir combien de fois la réponse est en fait" non ")"

2
Shaz

Il semble que vous soyez passé de développeur à ingénieur logiciel. Sachez que la gestion du travail n'est pas un exercice de conception, mais les deux vont de pair. Vous devez gérer le travail en cours, et cela dépend de la façon dont votre entreprise effectue le développement. Si vous avez le temps et les ressources, envisagez d'adopter une méthodologie agile - il y a des montagnes de documents écrits sur Internet. Trouvez-en un qui vous convient, mais sachez que, comme tout le reste, il n'est pas gratuit. L'adoption de toute technique implique une formation, un apprentissage et un échec avant de réussir. Si vous n'avez pas la bande passante pour gérer l'adoption d'une technique plus complète, la planification d'é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 qui peuvent être parallélisées. 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 ne résout pas à lui seul le problème du reporting, 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 correspond au travail effectué par des personnes est appelée une structure de répartition du travail.

Il y a beaucoup de bonnes suggestions que d'autres personnes ont proposées, mais rappelez-vous que vous gérez le travail. Parfois, vous pouvez mapper des concepts de travail dans la conception/l'architecture, parfois vous ne pouvez pas le faire si facilement. Il y a toujours un moyen de structurer le travail pour qu'il soit traçable. Je suggère de revenir à 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. S'il s'agit d'un calendrier, vous souhaitez vous concentrer sur les rapports de progression. Si c'est de la qualité, vous voulez faire rapport sur une suite de métriques que vous devrez trouver. Si cela coûte, alors vous voudrez probablement regarder l'effort. Toutes ces choses peuvent également correspondre aux tâches ou en sortir.

1
Scott Pavetti