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
project-management
development-process
Thomas Owens
la source
la source
la source
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.
la source
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.
la source
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.
la source
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 ...]
la source
Étant donné que j'ai eu le plus de problèmes avec les bibliothèques tierces et leur utilisation:
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?"
la source
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.
la source
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.
la source