35 votes

Quel type de processus de développement logiciel un développeur isolé devrait-il avoir?

Je travaille en tant que développeur solitaire dans une très petite entreprise. Mon travail est assez chaotique et je suis à la recherche de façons de le rendre plus organisé.

Un problème est que mes projets n'ont pratiquement pas de gestion. Rarement quelqu'un me demande ce que je fais, ou si j'ai des problèmes. À un certain moment, on a parlé de situation hebdomadaire des réunions, mais il y a quelque temps. Semble que si je veux quelque chose comme ça, je dois organiser ces moi-même.. Parfois je suis un peu perdu sur ce que je dois faire parce que je n'ai pas de tâches ou un calendrier clair défini.

À partir de livres et d'articles que j'ai trouvé beaucoup de choses qui pourraient être utiles. Comme avoir une bonne norme de codage (il n'existe qu'un rough guide de style qui est un peu obsolète à mon avis), les inspections de code, TDD, tests unitaires, base de données de bogues... Mais dans une petite société, il semble qu'il y a absence de ressources ou de temps pour quoi que ce soit qui n'est pas essentiel. Le fait que je travaille dans le domaine incorporé semble rendre les choses plus compliquées.

Je me sens il ya aussi une coutume de couper les coins et faire rapidement des hacks sur court préavis. Cela conduit à inachevé et le professionnalisme des produits et des bugs en attente de sortir à une date ultérieure. J'imagine qu'ils sont aussi une douleur à maintenir. Donc, je suis sur le point d'hériter d'un stimulant à base de code, faire de nouvelles développement que nécessite l'apprentissage de beaucoup de nouvelles choses et je pense que d'essayer de mettre en place un processus tout à la fois. Il peut être gratifiant en fin de compte, mais ne pas trop connu, je ne suis pas sûr si je peux le retirer.

Dans une petite boutique comme ce l'environnement est loin d'être optimale pour la programmation. Il y a beaucoup d'autres choses nécessaires à faire parfois comme support à la clientèle, répondre au téléphone, de la signature des colis, des tests matériels, d'assemblage et de ce que les tâches diverses, peuvent apparaître. Ainsi, vous obtenez l'idée sur les ressources. C'est pas mal du tout (parfois, il est instructif de résoudre certains problèmes des clients) et je crois qu'il peut être amélioré, mais c'est autres choses que je suis vraiment intéressé.

Est-il possible d'avoir un processus de développement dans un endroit pareil?

Serait-il utile d'avoir une sorte de gestion? Ce genre de?

Est-il possible de fabriquer des produits de qualité avec de petites ressources?

Comment puis-je convaincre moi-même et d'autres personnes que la société qui a fonctionné pendant des décennies a besoin de changer? Ce qui serait essentiel?

Peut-être il y a quelqu'un qui travaille dans un même magasin?

17voto

lod3n Points 2475
  1. Utilisez le contrôle de code source pour TOUT
  2. Élaborez les spécifications et obtenez l'autorisation avant de commencer - il y aura de la résistance, mais expliquez que c'est pour leur bien.
  3. Tests unitaires! Ça fait mal parce que vous voulez juste le faire, mais cela vous sauvera à long terme.
  4. Utilisez le suivi des bogues - Bugzilla ou FogBugz si vous pouvez vous le permettre.

7voto

NawaMan Points 10266

Mon conseil est de ne pas être extrême. De mon expérience, de la pure agile ou plus pure tradition ne fonctionnera pas. Avant l'utilisation de tout processus, de savoir ce que cela signifie pour les résoudre.

Personnellement, j'utilise une variation de Agile RUP. Je fais un peu d'avance effort comme enquêter sur les besoins réels, ne conception de haut niveau avec possibilité de prolongation. Et demandez au client de signer certains grands de haut niveau, exigences.

Si vous avez un travail en petit groupe, les détails de la conception ou les spécifications peuvent pas la peine. Bien sûr, si il y a un certain nombre de bibliothèques qui sont partagées par de nombreuses, il sera en vaut la peine.

Décider d'investir dans du front en fonction de son risque (probabilité et de l'effet).

En outre, de nombreux SW meilleure pratique est vraiment "meilleur", comme le contrôle de version d'essai automatique (pour moi j'ai seulement utilisé pour la détection précoce de la régression comme je ne crois pas en TDD comme force motrice du développement). Je vous suggère de lire"pragmatic programmer", il présente de nombreux de ces techines.

Comme pour répondre à vous questions:

(1). Est-il possible d'avoir un processus de développement dans un endroit pareil?

Oui, mais comme je l'ai dit, de la remorque pour l'adapter à votre organisation.

(2). Serait-il utile d'avoir une sorte de gestion? Ce genre de?

Gestion de l'aide, mais pas maniaque du contrôle. Plan de que faire quand: intégrer, à résoudre des conflits, la ligne morte de quelques milles de la pierre. Et à peu près les garder à temps (j'aime particulièrement Scrum sprint).

(3). Est-il possible de fabriquer des produits de qualité avec de petites ressources?

Certainement dès que la taille de l'œuvre, le temps de se développer et la taille de l'équipe, c'est l'équilibre. Si vous avez une définition de la Qualité est la même chose avec moi. Pour moi, la Qualité signifie: résoudre le problème à une utilisation efficace et fiable de la mode.

(4). Comment puis-je convaincre moi-même et d'autres personnes que la société qui a fonctionné pendant des décennies a besoin de changer? Ce qui serait essentiel?

Les problèmes. Si il n'en existe pas, pourquoi en changer? Si vous voulez changer, vous devez être en mesure d'identifier le problème OU les problèmes potentiels. Signaler le problème.

Certains gros sont:

  • Sans tout processus, il est plus difficile pour les nouveaux recrutés fondre dans la masse, comme ils doivent apprendre à partir de l'observation d'autres façon de traiter avec les choses.

  • Sans processus, il est plus difficile de travailler dans le stress.

  • Sans horaire, il est difficile de déterminer le progrès.

  • Sans test automatique, il faut plus de temps pour identifier les problèmes et de régression.

  • Sans contrôle de version, il sera plus difficile de revenir erreur et à la séparation du travail de chaque membre de l'équipe sera la pagaille.

Juste mon bien.

2voto

Byron Whitlock Points 29863

Vous avez besoin de travailler avec le propriétaire et d'installation court, à moyen et à long terme des objectifs. Vous voulez leur faire savoir progrès, même si uniquement par e-mail.

Vous aurez besoin de mettre un peu d'ordre dans votre journée de travail ou vous n'obtiendrez jamais rien fait (ces objectifs à long terme).

Diviser votre journée en morceaux quand vous pouvez, lorsque vous travaillez sur des hacks pour le garder en collaboration, lorsque vous répondez aux e-mails, etc.

Certainement l'installation d'un bug tracker. Cela peut aider à garder votre e-mail propre. Vous pouvez créer une adresse e-mail à l'avant de bugs pour être classé plus tard. C'est bien parce que le bug journalistes finiront par lasser de le bug tracker et voulez juste vous envoyer les bugs de toute façon.

modifier

Et comme lod3n dit, le contrôle de code source, mais vous utilisez déjà le droit???!!?!

2voto

TrueWill Points 14855

Été là, fait cela.

Le livre de la Planification de l'Extreme Programming a beaucoup aidé. J'ai utilisé des cartes de 3x5 collées sur un mur. Cette gardé mon patron au courant de mes progrès, a contribué au budget des dépenses et la planification, et m'a gardé sur la bonne voie. Le Jeu de Planification donne de bonnes munitions si votre patron attentes sont irréalistes.

Les tests unitaires, comme d'autres l'ont dit, aide, même si vous êtes un seul développeur. Je trouve le TDD style précieux.

lod3n est absolument droit sur Contrôle de code Source.

Je suis allé avec style XP itérations avant; vous pouvez établir un carnet de commandes d'articles (même quelque chose de simple comme une feuille de calcul ou des cartes de 3x5) ainsi.

Éviter deathmarches. Stick à 40 heures dans le sens de ne pas travailler des heures supplémentaires 2 semaines dans une rangée. Passer plus de temps en dehors du travail d'apprentissage de nouvelles compétences, et pas seulement des technologies, mais les principes et les meilleures pratiques.

1voto

duffymo Points 188155

Avoir un système de suivi des bogues, à la fois pour les défauts et les nouvelles fonctionnalités. Ne comptez pas sur votre mémoire.

Une intégration continue et une construction automatisée peuvent aider même un seul développeur.

Je ne saurais trop insister sur la recommandation relative au contrôle de source.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X