Que voulez-vous ajouter dans cette liste de contrôle de projet de développement logiciel? [fermé]


14

Je suis un grand fan des listes de contrôle. Il y a Liste de contrôle Voyage , déménagement Liste de contrôle et même une liste de vérification Scrum .

Contexte : vous avez été embauché par une grande entreprise et vous avez pour mission de mettre en place tout l'environnement de développement logiciel, les processus, l'équipe, etc. Vous avez «carte blanche». Vous serez responsable de la création des incréments de travail du logiciel. Taille du projet: 2000 hommes / jours.

Quels éléments ajouteriez-vous à la liste de contrôle suivante (intentionnellement petite et incomplète):

  • Installer un serveur d'intégration continue
  • Écrire un DoD
  • Rédiger des directives de codage d'une page
  • Créer un backlog produit
  • Installer un système de suivi des bogues
  • Planifier un temps de visage régulier

Réponses:


10

* 1.) Parlez aux développeurs pour voir ce dont ils ont vraiment besoin! *

2.) Envisagez une solution pour mettre en place plusieurs environnements très rapidement (pensez aux instances de cloud public ou privé ou aux machines virtuelles à l'ancienne si vous n'êtes pas conforme au mot à la mode)

3.) Contrôle de source / version

4.) Système de révision du code (Crucbile / Fisheye comme exemple)

5.) Mur Kanban (ou quelque chose de similaire)

6.) Protocoles de communication (le chat en temps réel est un gros plus), les wikis encouragent également la collaboration. Cela couvre également les relations publiques en interne - comment allez-vous vous engager avec vos propriétaires d'entreprise, le personnel de support technique et d'autres groupes?

7.) Tableaux blancs électroniques

8.) Environnement confortable pour les développeurs (canapés, tables, zones de détente, bon WiFi, etc.)

9.) Super café !!!


cofee fait la différence:) + 1
RBA

Quels sont les tableaux blancs électroniques que vous utilisez?

@Pierre 303 - Imprimer les résultats d'une session de tableau blanc a (une photo de haute qualité fera le même tour je suppose).
Martijn Verburg du

8
  • Configuration de la chaîne d'outils - IDE, serveur CI, serveur de qualité de code, contrôle de source, serveur Web, bases de données, suivi des problèmes, etc.
  • Sauvegardes - Quel rôle joue chaque membre de l'équipe? Quels processus / modules possède-t-il et qui est sa sauvegarde?
  • (Acceptation par l'utilisateur) Configuration de l' environnement de test - Pas seulement l'intégration continue w. des tests unitaires, mais des tests d'intégration pour couvrir les choses vraiment mauvaises, les plates-formes multiples, les serveurs d'applications, les machines virtuelles, etc.
  • Configuration des tests de performances - Le plus tôt sera le mieux, car vous aurez besoin de données historiques pour répondre «Avec quelle fonctionnalité / étape les performances ont-elles chuté si mal?
  • (Utilisateur final) Présentation de la documentation - Que contiendra la documentation? Quel (s) type (s) de documentation est nécessaire?
  • Canaux de marketing - Comment les jalons internes et les versions externes sont-ils annoncés? Avez-vous un nom sympa pour le logiciel, un logo, des couleurs, des mots, etc.?
  • Communication interne - Comment les pairs des autres équipes seront-ils informés des changements? Comment se fait la collaboration? Wiki? Des droits d'accès?
  • Personnes et processus d' assurance qualité - Qui va tester quoi, à quelle fréquence et avec quels critères?
  • Processus de libération - Quand, à quelle fréquence, comment, qui le fait, qui reçoit la libération, etc.
  • Gestion des risques - Scénario le plus défavorable (à partir d'un pov de gestion de projet et d'un pov d'exécution, par exemple «le client perd de l'argent parce que le logiciel a échoué au module X, quel est le plan de sauvegarde?)
  • Sécurisation de l'environnement de développement principal, par exemple en le virtualisant pour l'engagement
  • Lieux des réunions formelles et informelles
  • Formation ou intros pour toutes les personnes, afin qu'elles sachent quelle est la configuration, à quoi sert chaque pièce et comment elles l'utilisent.
  • Identifier le gardien et lui donner toutes les choses (par exemple, les autorisations) dont il a réellement besoin pour prendre soin des problèmes

+1 pour les sauvegardes et la formation
Liviu T.

sauvegardes, bien que je pense que certaines de ces choses sont extravagantes.
BlackICE

5

Examens post mortem - Puisque vous travaillez sur des choses en blocs, je planifierais un examen d'une à deux heures (selon la taille de l'équipe) pour avoir une réunion en face à face (si possible) où tout le monde fait le tour et dit ce qui a été bien fait, ce que pourrait être mieux fait, et ce qui n'était pas nécessaire. Être capable de tirer des leçons de vos erreurs dans le processus de développement au début signifie que vous pouvez éviter de les faire plus tard lorsque vous n'avez pas autant de temps pour travailler avec.


4

Commençons par embaucher une bonne équipe de bons professionnels pour votre projet. Dans une application d'entreprise typique, vous devez embaucher un développeur de base de données et un administrateur de base de données, une personne chargée de l'assurance qualité, un administrateur système, des analystes commerciaux, des développeurs d'applications, un spécialiste de l'interface utilisateur et des chefs d'équipe au minimum. Le DBA, l'administrateur système, les analystes commerciaux et le contrôle qualité doivent faire partie d'une chaîne de reporting distincte de l'équipe de développement. Le spécialiste de la base de données de développement doit relever du même responsable technique que les développeurs d'applications et le spécialiste de l'interface utilisateur.

Configurez l'espace de bureau. Les bureaux privés sont parfaits si vous pouvez les obtenir (je vous souhaite beaucoup de chance avec cela), mais au minimum, vous avez besoin de bureaux, téléphones, ordinateurs, tableaux blancs et quelques salles de conférence dédiées. Assurez-vous qu'il y a un endroit pour les pauses déjeuner, un réfrigérateur, des boissons gazeuses, des collations et du café disponibles. Boissons gazeuses et café gratuits encore meilleurs.

Configurez les serveurs dev / qa / staging et prod pour l'application et les bases de données. Les bases de données ne doivent jamais être sur le même serveur que les applications. Selon la taille et la portée du projet, vous pouvez avoir besoin de plusieurs serveurs ou SAN, etc. pour chaque environnement.

Dès que les serveurs sont configurés, planifiez des sauvegardes du système de fichiers, de la base de données et des journaux de transactions de la base de données. Faites-le dès le premier jour où les choses sont mises en place. Embauchez une entreprise comme Iron Mountain pour effectuer des sauvegardes hors site chaque semaine.

Mettre en place un système de contrôle des sources et créer un document décrivant comment il sera utilisé. N'oubliez pas d'insister pour que TOUS les changements de structure de la base de données et les insertions de données pour les tables de types de recherche soient dans des scripts dans le contrôle de code source. Cela facilitera le déploiement.

Achetez un logiciel commercial ou téléchargez un logiciel open source pour l'ensemble d'outils que vous avez décidé d'utiliser avec des licences pour tous les utilisateurs concernés.

Achetez des machines de développeur qui crient vite et qui ont deux moniteurs. Achetez au moins une machine utilisateur de test qui gémit lentement et est typique de ce que les utilisateurs auront sur leur bureau.

Formez vos nouveaux développeurs à la façon dont vous voulez que les choses se fassent. Si vous avez une équipe suffisamment nombreuse pour avoir des développeurs juniors, planifiez une formation supplémentaire pour eux et incluez le temps dans la planification de votre projet. Surveillez les juniors de très près pendant au moins trois mois. Surveillez de près tous les nouveaux employés pendant le premier mois. Débarrassez-vous des développeurs de bois mort et de voyous dès que possible.

Déterminez ce qui doit être fait dans quel ordre (le chemin critique). N'affectez pas de tâches à la fin du chemin critique tant que les tâches dont elles dépendent ne sont pas terminées.

Créez des plans de test et des exigences.

Organisez régulièrement des réunions d'avancement avec les clients. Ils méritent de savoir ce que vous faites et quels sont les obstacles. Ne manquez pas de leur dire quand les choses seront en retard. Si vous êtes à trois semaines d'un délai et que vous savez déjà que vous allez le manquer, ce déficit ne disparaîtra pas comme par magie avant de devoir le dire au client. Assurez-vous que le client sait que les exigences supplémentaires signifient des coûts et du temps supplémentaires et que chaque exigence ajoutée devra soit supprimer d'autres tâches, soit la date limite changera en fonction du nombre d'heures dans les nouvelles tâches. En clarifiant cela dès le départ, vous économiserez beaucoup de douleur et d'heures supplémentaires et des dépassements de coûts absorbés par votre groupe et non par le client.

Configurez un environnement pour tester les performances, non seulement la vitesse d'un utilisateur, mais un environnement où vous pouvez tester le nombre attendu d'utilisateurs simultanés. N'attendez pas pour faire ce test jusqu'à la veille de votre mise en ligne.

Dans la planification du projet, supposez que le contrôle qualité trouvera des bogues et qu'il faudra du temps pour les corriger. Ne planifiez pas le contrôle qualité pour une seule journée à la fin.

Créez des données de test qui sont à peu près de la taille que vous pensez que la base de données sera. Demandez à tous les développeurs de tester leur code par rapport à la base de données de cette taille. Ne permettez pas aux développeurs de développer uniquement sur une petite base de données sur leurs machines personnelles. Il s'agit d'une cause fréquente de code qui fonctionne bien jusqu'à ce qu'il atteigne la production.

Prévoyez des récompenses dans le budget. Il démotive les gens lorsqu'ils travaillent leurs mégots pendant des mois et seuls les managers reçoivent des bonus. Merci aussi fréquemment et par écrit.

Vous devrez peut-être un système de gestion de projet ou au moins mettre en place des feuilles de calcul pour suivre ce que vous devez suivre. Lors de la planification du projet, ne supposez pas plus de six heures par jour dans votre plan. Cela permet de prendre en compte le temps qui ne sera pas consacré au projet, comme les vacances, les congés de maladie, les vacances, les réunions RH, les évaluations des performances, etc. Si vous savez que le projet se trouve dans une période d'indisponibilité élevée (par exemple, un projet qui s'exécute du 1er novembre au 1er janvier aux États-Unis), vous devrez peut-être faire des allocations supplémentaires pour plus de congés et de vacances. Il n'est pas juste de s'attendre à ce que les développeurs abandonnent leurs congés et vacances et personne ne peut prédire quand des choses comme les congés de maladie, les fonctions de juré, les temps de deuil, etc. Supposons qu'ils arriveront à votre équipe sur ce projet.


Je pense que la machine utilisateur de test devrait être "gémissant lentement", pas "hurlant lentement";) très belle liste.
BlackICE

@david, j'aime votre suggestion et je l'ai modifiée dans le texte.
HLGEM

Excellente réponse - les puces ou les noms de section peuvent aider un peu.
JBRWilkinson

3

Certaines choses que je ne vois pas dans la question et les réponses suivantes:

  • Plan de reprise après sinistre. Comment sauvegardez-vous les boîtes de développement, la mise en scène, les tests, etc.? Chaque développeur a-t-il ce dont il a besoin pour travailler à domicile le jour de neige occasionnel? Etc.

  • Plan de formation. De combien de semaines d'année de formation vos développeurs ont-ils besoin pour rester précis? Quelqu'un le suit-il? (Une feuille de calcul peut suffire pour la plupart des équipes.) Avoir un mécanisme pour les signaler (envoyer à quelqu'un un e-mail disant qu'ils ont regardé 2 heures de webémissions sur "quoi que ce soit" est probablement suffisant) et pour que la direction planifie - par exemple, qui devrions-nous envoyer à quoi conférence cette année.

  • une position d'outil. S'agit-il d'un "nous vous donnons tous un abonnement MSDN; veuillez ne rien installer d'autre sur vos machines de travail" ou "nous voulons votre code mais peu nous importe ce que vous utilisez pour le modifier, le compiler et le tester " Genre d'endroit. Prenez et enregistrez la décision.

  • autant d'ALM intégré que vous pouvez le supporter ou vous le permettre. Habituellement, la raison de la "non-concordance d'impédance", de la double entrée, du chevauchement des outils et de l'intégration de l'application du fauteuil pivotant est que le système a grandi par morceaux. En partant de zéro, vous voulez montrer que votre personnel peut rester dans un seul outil tout au long du cycle. Ne pas taper le code dans X, compiler avec Y, tester avec Z, changer le statut de l'élément de travail / tâche avec A, signaler son temps passé avec B, dire à la personne qui attendait qu'elle peut maintenant continuer avec C, essayer de comprendre ce qu'il faut faire ensuite avec D, garantissant la progression globale avec E, etc.


2

Négociez plus de jours-homme.

C'est un événement rare lorsque les gens allouent suffisamment au départ.

[Plus tard ... renégocier encore plus ...]


Étant donné que plus de jours-homme doivent toujours être négociés n'est pas quelque chose que je recommanderais, je préférerais fournir des estimations précises et fiables de la durée d'un travail ou d'un projet.
NimChimpsky

@NimChimpsky Il y a eu récemment une discussion sur la question de savoir si la capacité d'estimer de manière fiable était un mythe dans les projets informatiques. À moins que l'œuvre ne soit très bien connue et ne contienne aucune recherche, il est intrinsèquement difficile de prédire l'heure. Même si vous pouvez prévoir le calendrier de votre propre équipe, il est presque impossible de prévoir les facteurs externes et les retards. Les estimations "précises et fiables" ne sont donc pas, je pense, une réalité générale.
Orbling du

@Orbling, ils existent là où je travaille. Un détaillant national répertorié par ftse 250 au Royaume-Uni. Certains projets sont en retard, mais pas si tard, et ils sont l'exception.
NimChimpsky

@NimChimpsky Il est possible d'obtenir une estimation relativement précise si vous avez le contrôle total de tous les livrables d'un projet, que vous n'êtes pas bloqué par des externes et que la tâche à accomplir n'implique aucune recherche. Fournir votre budget s'étend à une analyse approfondie avant estimation du temps. Dans la plupart des entreprises, le budget n'est tout simplement pas là pour enquêter pleinement avant le début.
Orbling du

@orbling Il est possible que demander toujours plus de temps soit purement arbitraire et pas du tout basé sur des preuves, des livrables, une analyse ou un budget.
NimChimpsky du

2

Étant donné que j'ai eu le plus de problèmes avec les bibliothèques tierces et leur utilisation:

  1. Déterminez les bibliothèques et les versions que vous allez utiliser.
  2. Créez le processus d'intégration des mises à jour de la bibliothèque à votre projet.
  3. Assurez-vous que les développeurs sont tous à bord des choix de bibliothèque.
  4. Créez un canal utile pour une discussion ouverte sur les technologies utilisées.

Pourquoi? Je ne peux pas vous dire combien de fois des bibliothèques tierces (propriétaires) ont eu des bogues énormes qui nous ont renvoyé des semaines de temps de développement parce que nous n'avions aucun processus pour monter ou descendre. Ou face à des développeurs qui se disaient "quelle version avez-vous utilisée? Pourquoi avez-vous utilisé des fonctions marquées obsolètes?"


1

Un coût élevé pour les organisations n'attribue pas de budget à la sécurité tout au long du cycle de développement, ce qui signifie que la sécurité finit généralement par être après coup un ensemble inefficace et coûteux d'activités ou de contrôles mis en place trop tard pour faire beaucoup de bien.

Intégrez la sécurité à partir du plan de projet initial, avec des étapes clés, comme vous le feriez avec tous les autres aspects du développement, et utilisez un processus itératif pour maintenir les conseils de sécurité à jour. L'approbation finale de la sécurité devrait être une vérification sans surprise que tous les contrôles de sécurité ont été mis en œuvre conformément à la conception.

Sinon, vous finirez par exécuter la sécurité après la mise en œuvre - où cela pourrait coûter 8 à 10 fois plus (chiffres de Gartner, IBM et autres), bouleversera les gens car les fonctionnalités sont susceptibles d'être affectées et il peut être trop tard pour empêcher l'exploitation et les dommages.


Je suis curieux, cela devrait faire partie de la liste de contrôle de configuration du projet? Je l'aurais intégré dans le cadre du développement logiciel, mais je ne connais pas la configuration du projet. Je l'avais mis avec des étapes de développement, mais je ne pense pas que c'est ce que le PO demandait, je peux me tromper.
BlackICE

David - vous avez peut-être raison de dire que ce niveau de détail ne devrait pas être là, mais je pense qu'il devrait au moins y avoir un élément de ligne pour la sécurité. Mieux?
Rory Alsop

1

1. Apportez-le à l'équipe

Demandez aux programmeurs! Vraiment, c'est la chose la plus importante. Vous rencontrerez beaucoup de résistance si les développeurs ne sont pas directement impliqués dans ce changement. Après tout, il s'agit de leur fonctionnement, pas de vous. Cela va sans dire, mais essayer d'imposer des méthodes et des outils aux gens se retourne généralement horriblement.

2. Inspecter et adapter

Demandez à l'équipe de trouver la meilleure façon de travailler, en utilisant votre expérience pour l'aider doucement sur la piste choisie. Ensuite, régulièrement et en collaboration, revoyez comment vous (ils) allez et adaptez le processus pour l'améliorer.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.