J'ai beaucoup réfléchi récemment à la façon de créer une équipe de développement allégée. En fin de compte, j'aimerais ouvrir ma propre petite maison de logiciels avec un petit nombre de personnes partageant les mêmes idées. L'objectif n'est pas de devenir riche, mais plutôt d'avoir un environnement de travail sain.
Jusqu'à présent, je définis une équipe allégée comme suit:
- Petit;
- Auto-organisation;
- Tous les membres doivent avoir l'AQ à l'esprit;
- Les membres doivent être capables de jouer plusieurs rôles
Le dernier point est celui où je m'inquiète un peu car, comme le dit le mantra ...
Les développeurs font de mauvais testeurs.
Bien que je comprenne que, souvent, les développeurs sont «trop proches» de leur code ou du code de leurs collègues pour effectuer des évaluations de qualité de niveau supérieur, je ne suis pas convaincu qu'ils soient de mauvais testeurs de facto . Au contraire, je suis d'avis que les qualités d'un bon développeur se chevauchent grandement avec les qualités d'un bon testeur.
En supposant que cela soit correct, j'ai pensé à différentes façons de contourner le problème dev / tester et je pense avoir trouvé un modèle viable.
Mon modèle nécessite:
- Une petite maison de logiciel avec 2+ projets
- Une approche agile (itérative) du développement et de la livraison
- 1 équipe par projet
- Tous les membres de l'équipe seront des développeurs de logiciels
- Leur description de travail indiquera clairement le développement , l'assurance qualité , les tests et la livraison comme responsabilités
Si toutes ces conditions préalables sont remplies, les projets peuvent être organisés de la manière suivante (cet exemple fera référence à deux projets, A et B ):
- Chaque membre de l'équipe alternera entre le rôle de développeur et le rôle de testeur
- Si un membre de l'équipe est développeur sur le projet A , il sera testeur sur le projet B
- Les membres travailleront sur seulement 1 projet à la fois, et par conséquent devraient agir comme soit un Dev ou un testeur.
- Un cycle de rôle se compose de 3 itérations en tant que développeur et 2 itérations en tant que testeur (encore une fois, sur deux projets différents)
- Les équipes de projet auraient à tout moment 3 développeurs et 2 testeurs.
- Les cycles de rôle des membres doivent être déphasés par 1 itération.
- Cela minimise la brutalité des changements d'équipe. Pour chaque itération, 2 devs et 1 testeur resteront les mêmes que l'itération précédente.
Compte tenu de ce qui précède, je vois les avantages et les inconvénients suivants:
Avantages
- Distribue la connaissance du projet dans toute l'entreprise.
- Garantit que les membres de l'équipe ne testent pas le code qu'ils ont aidé à écrire.
- Les cycles de rôle hors phase signifient qu'aucun projet n'a jamais un commutateur de membre à 100%.
- L'alternance des rôles rompt la monotonie des projets ennuyeux.
Les inconvénients
- Les itérations des deux projets sont étroitement liées. Si un projet devait annuler une itération à mi-parcours et recommencer, les deux projets seraient désynchronisés. Cela rendrait le cycle de rôles difficile à gérer.
- Cela dépend de l'embauche de développeurs qui travaillent également en tant que testeurs.
J'ai reçu des critiques mitigées lorsque j'ai discuté de cette approche avec des amis et des collègues. Certains croient que peu de développeurs voudraient jamais alterner des rôles comme celui-ci, tandis que d'autres me disent qu'ils aimeraient personnellement l'essayer.
Ma question est donc la suivante: un tel modèle pourrait-il fonctionner dans la pratique? Sinon, pourrait-il être modifié en un modèle fonctionnel?
Remarque: Par souci de concision, je ne me suis concentré que sur les rôles de développeur et de testeur. Je développerai d'autres rôles si nécessaire.