Je suis désolé si c'est un doublon, mais les termes de recherche de question sont assez génériques. Je travaille dans une petite entreprise de développement (ish). Je dis petit, mais la société est en fait une taille juste; Cependant, je ne suis que le deuxième développeur à temps plein, car la plupart des travaux passés ont été organisés autour des entrepreneurs.Ma chance de façonner notre processus de développement/politique
Je suis en mesure de définir des processus de projet interne et des éléments stratégiques, tels que le SCM et les tests unitaires. La méthodologie est en dehors de la portée du document que je prépare, mais j'aimerais vraiment nous pousser dans une direction plus maigre (et peut-être même Agile?). J'ai l'impression d'avoir de nombreuses recommandations de bonnes pratiques, mais pas assez de motivation pour faire de mon document le guide spirituel que je voudrais qu'il soit. J'ai séparé le document en "principes" et "recommandations". Les recommandations ont été faciles à trouver. Utilisez SCM, cherchez des versions en une étape, planifiées régulièrement, un test unitaire en premier, un document en cours ... L'énumération des principes qui sont supposés informer ces recommandations a cependant été rude. Je suis venu avec des "outils qui fonctionnent pour nous, nous ne devrions jamais travailler pour des outils" et une clause floue visant à notre QA (qui a été trop manuel) que je voudrais lire "tedium est la racine de tous les maux ".
Je ne veux pas manquer une occasion avec ce document pour nous donner un bon début en interne et peut-être même nous pousser vers Agile. Quels sont les principes qui me manquent?
EDIT 4/15 -
j'aurais été ambiguë sur la portée de ce document. Pour l'instant, c'est la politique que mon co-dev et moi prévoyons de suivre. Jusqu'ici, nous avons été libres de choisir l'outil local, le contrôle de source, etc., et le processus général que nous suivons en développement (par exemple, construire, déployer, si utiliser l'intégration continue ...).
Idéalement, j'aimerais aussi que ce document soit un modèle sur lequel baser d'autres améliorations de processus. Je pense principalement à l'assurance qualité, et peut-être pousser notre gestion de projet vers quelque chose de plus léger et itératif.
Je ne comprends parfaitement la portée de votre document, mais j'ai une recommandation forte: « Code complet » par Steve Mcconnell. Je pense que c'est une source inestimable pour les principes et les recommandations, et vous pourriez y trouver les principes que vous recherchez. –
Au niveau méta, nous devons connaître les exigences de stabilité et d'auditabilité de votre entreprise avant de pouvoir vous conseiller sur le processus. –
@Paul Exigences de stabilité/auditabilité? Si vous voulez dire la stabilité de nos projets, nous ne construisons pas de roquettes. Nous faisons des logiciels de type entreprise, du développement Web et une variété d'autres choses. Nous devons être aussi stables que satisfait un client individuel, et cela change par produit. J'ai remarqué que nous avons parfois des problèmes avec les attentes des clients, mais d'autres fois, nous ne le faisons pas. Je ne suis pas sûr de la vérifiabilité, mais je n'ai pas entendu parler de la vérification par un tiers. Si vous voulez dire en interne, nous sommes un peu trop petits pour cela, je pense. –