Équipe de développement Web Leadership et normes

Question

Je travaille dans une petite firme de développement Web, et gère tous les PHP/MySQL/etc. pour un moment. Je cherche à améliorer nos pratiques afin de faciliter la collaboration à mesure que nous grandissons. Certaines choses que j'ai à l'esprit sont:

• La mise en œuvre d'un système de versionnage
• normes de codage pour l'équipe (à moins que mandaté par un certain cadre , etc.)
• Faire respecter une structure répertoire commun pour notre Ordinateurs de bureau (pour fins de sauvegarde, etc.)
• tâche Web /projet/heure/fichier/mot de passe/gestion des contacts et application de collaboration (nous avons essayé un tas, je peux juste créer un)

Qu'est-ce que plus expérimenté Lead/Sr. Les développeurs considèrent comme les premières étapes nécessaires dans ce domaine? Recommandez-vous des livres? Une chose à considérer est que l'essentiel de nos tâches quotidiennes implique la maintenance et l'ajout de fonctionnalités mineures plutôt que de nouveaux projets, et la taille de l'équipe sera entre 3 et 5.

Je suis surpris de ne pas avoir trouvé une question similaire en cherchant SO ... Y a-t-il un endroit plus approprié?

Answer 1

1) Mettre en place un contrôle de révision

je suggère faire des amis avec Git. C'est un système de contrôle de révision distribué. Vous n'avez besoin d'aucune "unité centrale" et chaque copie de travail contient un historique de développement complet (et donc une copie de sauvegarde). Il y a "Git Magic" - un excellent tutoriel pour ceux qui ne connaissent pas les systèmes de contrôle de révision.

• http://crypto.stanford.edu/~blynn/gitmagic/

Révision des systèmes de contrôle de l'aide à l'évaluation des progrès. Vous travaillez donc vous vous engagez. Un simple diff peut vous donner beaucoup d'informations utiles sur les progrès, les problèmes et le code réel en un rien de temps. Un diff est comme une image: vaut mille mots.

2) Normes de codage

Il est pas réinvention, il est seulement la mise en œuvre. Comme vous travaillez avec PHP, j'implémenterais le Zend Framework Coding Standard pour PHP.

Pour la documentation, vous pouvez utiliser phpDocumentor. Il n'y aura jamais assez de temps pour tout documenter. Mais beaucoup de choses sont évidentes et n'ont pas besoin d'explication. Discutez des autres choses avec les autres membres de l'équipe, faites des commentaires à ce sujet.

3) postes de travail

Il est préférable d'utiliser un système de contrôle de révision ou d'un répertoire partagé qu'une solution de poste de travail unifié. Un système de contrôle de révision distribué est très bon pour les sauvegardes. Non seulement pour la sortie (le code, vous faites), mais aussi pour l'entrée (le truc, vous obtenez des clients). Pensez-y comme une chose, vous ne voulez pas consommer le temps.

4) Application de collaboration

C'est difficile. Il n'y a pas d'application parfaite. Et tout est question de discipline. Comme je l'ai déjà mentionné, un système de contrôle des révisions vous aide à surveiller les progrès et à identifier les problèmes. Avez-vous, en tant que chef de projet, besoin d'une application de planification? Est-ce qu'un crayon et un morceau de papier fonctionnent? Si oui, alors un wiki. Contribuez-y et laissez votre équipe contribuer. ça marche bien pour moi.

5) Livres

Joel Spolsky est votre ami en matière de gestion de projet.

6) Conseils supplémentaires

• la vie est trop courte pour ne pas aimer votre travail - et cela vaut non seulement pour vous, mais à tout le monde, y compris les membres de votre équipe;
• Il est important de laisser/dire aux gens de faire, ce qu'ils font de mieux - découvrir les talents des membres de votre équipe, découvrir leurs forces et leurs faiblesses, les rendre comme leurs emplois et leurs tâches;
• avoir un gars, qui défiera toute opinion, vous auriez - vous n'êtes pas parfait, ni lui non plus - lui apprendre à défendre ses opinions, apprendre à défendre le vôtre;
• soyez un gars de votre équipe, soyez l'un d'entre eux, pas celui des «autres» - il ne s'agit pas de se faire des amis, mais plutôt de les représenter et de leur permettre de faire ce qu'ils sont censés faire; Gardez à l'esprit que les gens qui vous entourent sont des humains, pas des machines - ils ont des «bons jours» et des «mauvais jours» - être un chef, c'est être capitaine d'un navire, c'est prendre des décisions plutôt que de faire des demandes ou donner des ordres. Ils doivent sentir, que vous menez le projet, ne sont pas juste un "gars dans le commandement". Ils doivent sentir, qu'ils sont importants. Personne ne veut être «une ressource humaine» et une équipe n'est pas construite à partir de «ressources humaines». La pire chose que vous pouvez faire est de donner des ordres mais pas de prendre la responsabilité des échecs; Dites-leur, quand ils réussissent bien, les motivent à mieux performer, à se développer;
• de boire de temps en temps: encore une fois, il ne s'agit pas de se faire des amis, il s'agit de relations humaines normales.

7) En cas de doute ...

• demander
• communiquer

Answer 2

Je recommanderais d'avoir un consultant avec une expertise reconnue dans la gestion du changement dans le domaine informatique - quelqu'un qui peut fournir une direction stratégique, pas les tâches administratives/administratives comme vous l'avez mentionné.