Comment créez-vous un processus logiciel pour un projet?

13

Comme je l'ai écrit dans d'autres questions ici, le projet sur lequel je travaille n'a actuellement aucun processus logiciel. Cela signifie qu'aucune documentation (y compris les exigences de copie papier ou les spécifications) , aucun contrôle de source , aucune base de données de bogues, les bogues ne sont "corrigés" (espérons-le) et un nouveau code est ajouté en même temps, et aucun testeur formel - nous échouerions le test Joel si mauvais, ce n'est même pas drôle.

Hier, mon manager m'a demandé d'écrire un document sur la façon de commencer à corriger ces lacunes. Notez que je ne suis qu'un stagiaire, ici depuis 6 mois. Je partirai aux alentours de Thanksgiving en novembre pour retourner à l'école. Cependant, je pense que je peux peut-être faire avancer ce projet dans la bonne direction, mais je ne sais même pas par où commencer. J'utilise actuellement CiteSeer et Wikipedia pour tenter de trouver des articles et autres qui décrivent les processus logiciels et les mettent en œuvre, mais tout conseil, expérience personnelle ou lien vers des blogs, des articles, des articles wiki ou toute autre chose serait grandement apprécié.

development-process specifications

— Thomas Owens
source

Bon processus rapide et bon marché - lorsqu'un projet prend du retard, réduisez le processus.

— ChuckCottrill

2

Comment cela s'est-il passé?

— Robert Harvey

10

Je vous suggère de vous pencher sur la programmation Agile.

Il existe de nombreuses variantes, mais elles ont tendance à avoir quelques points communs:

Revue et priorisation régulières des fonctionnalités.
Intégration continue et tests unitaires automatisés.
Concentrez-vous sur la communication plutôt que sur la documentation (en pratique, cela signifie une documentation de style wiki lorsque vous passez en revue d'énormes spécifications inflexibles écrites à l'avance).
Estimations flexibles entraînant des graphiques de brûlage et des mesures de vitesse.
Prototypes réguliers qui sont examinés sur plus de 200 pages avec des signatures.
Qualité à la source, ou au plus près.
Examen régulier des parties prenantes - une extension de la compréhension de vos clients.
Mettez les logiciels sur le marché (et gagnez de l'argent) dès que possible.
Communication directe autant que possible.

Un bon point de départ serait MSF Agile ou Scrum .

— Keith
source

7

Étant donné la situation, vous étant parti en 6 mois et l'équipe partant d'aucun processus, je limiterais la portée de ce que vous introduisez à une ou deux choses qui peuvent être raisonnablement mises en œuvre et prendre racine pendant votre séjour. Si c'était moi, j'examinerais un outil de contrôle de code source et un outil de suivi des bogues.

La raison pour laquelle je commencerais là-bas est que la mise en place de ces outils vous aidera à établir une base de référence pour les performances actuelles des équipes et éventuellement à identifier les problèmes récurrents. Les changements de processus sont agréables mais ce sont des éléments de base de base qui doivent être en place en premier.

Oui, je prévois de limiter la portée de ce que je fais, mais je veux aussi leur laisser une feuille de route afin qu'ils ne se demandent pas quoi faire ensuite, surtout si les choses commencent à aller mieux.

— Thomas Owens

@Thomas Owens Je pense qu'il est louable que vous souhaitiez laisser à l'équipe une feuille de route après votre départ. Cependant, il est peu probable que quiconque se réfère à une feuille de route construite par un stagiaire. Ce n'est pas une réflexion sur vos compétences et capacités. Cela étant, je consacrerais autant d'efforts que possible à la mise en place des premiers pas. Ne sous-estimez pas l'effort qu'il faudra pour changer les habitudes et les processus d'une équipe existante. En fait, essayer d'obtenir à la fois le contrôle des sources et un suivi des bogues implémenté en six mois peut être plus que ce qui peut être raisonnablement fait.

Je pense que cela peut être fait. Il s'agit d'une équipe de 5 personnes, hors moi. Deux sont des développeurs à temps plein, un est un développeur à temps partiel sur ce projet et à temps partiel sur d'autres projets, un est un gestionnaire et un est de type marketing. Les deux développeurs à temps plein sont à bord pour un processus et le gestionnaire souhaite voir des améliorations pour les performances de l'équipe. Ce n'est pas comme s'il était forcé contre leur volonté.

— Thomas Owens

1

Nous utilisons Prince2 pour les processus de gestion de projet, et cela fonctionne très bien. Je dirais que cela semble tortueux pour une entreprise sans gestion de projet en place!

— ColinYounger
source

1

Nous avons adapté le pipeline de développement décrit dans cette vidéo à nos propres besoins, en utilisant TeamCity comme serveur CI.

http://channel9.msdn.com/shows/ARCast.TV/ARCastTV-Tuning-The-Development-Process-at-Spot-Runner/

TC est le seul système CI que je connaisse qui effectue un dépôt-push plutôt qu'un pull, ce qui signifie (théoriquement) plus de builds cassés jamais!

1

Juste pour faire écho aux sentiments de certains des éléments ci-dessus, les équipes qui n'ont pas de structure s'adapteront mieux à une structure agile. Obtenez le contrôle des sources aujourd'hui, commencez simplement à mettre vos modifications dans SVN et montrez à certains de vos développeurs une différence lorsque vous recherchez des bogues. Commencez à ajouter des journaux de révision. S'ils ne peuvent pas voir les avantages et la facilité d'utilisation de SVN, ils sont condamnés.

— Johnno Nolan
source

0

Consultez ces articles sur l'intégration continue pour la programmation .NET à l'aide de MSBuild, CruiseControl.NET, FxCop, NUnit, NCover et Subversion ...

Des tranchées de développement logiciel

— Zack Peterson
source

1

@Zack: Nous n'utilisons pas de programmation .NET. Je recherche des conseils généraux pouvant être utilisés sur n'importe quel projet utilisant n'importe quelle pile technologique. Des choses comme le choix d'un modèle, l'implémentation de ce modèle, etc.

— Thomas Owens