Agile pour le développeur solo
Comment quelqu'un implémenterait-il les concepts de processus Agile en tant que développeur solo? Agile semble utile pour développer des applications à un rythme plus rapide, mais il semble également très axé sur l'équipe ...
- En faisant du développement piloté par les tests
- En se développant en petits sprints
- En ayant beaucoup de contacts avec le client
Je me souviens d'avoir lu une thèse sur Cowboy Development, qui est essentiellement Agile pour les développeurs solo, mais je ne me souviens pas où je l'ai trouvée.
Suite à la réponse de klez (toutes les bonnes suggestions), je suggère ce qui suit:
- Tenir un backlog de produit
Un backlog de produit est essentiellement une liste de tous les éléments que vous avez l'intention de compléter à un moment donné pour ce produit. - Maintenir un burndown de sprint et un burndown de produit
. le travail requis. Lorsque vous marquez des choses, vous les marquez comme terminées; réduisant ainsi (ou brûlant) le travail restant pour ce sprint.
De la même manière, une analyse du produit suit le travail restant pour l'ensemble du backlog de produit - Adoption des concepts d'estimation relative et de vitesse
L'estimation relative est une technique d'estimation qui utilise les autres tâches (ou histoires) comme guide. Par exemple, si vous savez que la tâche A est plus facile que la tâche B et environ deux fois plus complexe que la tâche C, vous vous assurez que les "points" de la tâche A sont corrects par rapport à ces attentes.
L'accent n'est pas mis sur une estimation correcte de la quantité de travail requise, mais sur la cohérence des estimations.
La vélocité est une mesure du nombre de "points" que vous obtenez dans un sprint. Si votre estimation relative garantit la cohérence, cette vitesse peut être utilisée pour estimer les tâches que vous êtes susceptible d'effectuer dans les sprints à venir. Notez cependant que la vitesse doit être constamment révisée.
- Limiter le travail en cours (en plus du time-boxing). Même si vous utilisez une méthode itérative (par opposition à Kanban), disons que votre vitesse est de 8 points par itération. Ne commencez pas à travailler sur les 8 à la fois. Limiter WIP par le nombre d'histoires ou de points d'histoire est très bien.
- Ayez des tests d'acceptation automatisés pour toutes vos histoires d'utilisateurs. Automatisez autant que possible en général.
- Partez du côté de rendre les user stories trop petites. En règle générale, faites le rapport du plus grand au plus petit article 3: 1 . Si vous sous-estimez une histoire dans Scrum et qu'elle s'avère trop grande, plusieurs développeurs peuvent l'essayer pour la remettre sur la bonne voie. Mais vous n'avez pas assez de monde.
- Si, dans un contexte d'équipe de taille régulière, vous hésitiez à séparer un pic d'une histoire d'utilisateur - dans le contexte d'un solo ou d'une petite équipe, faites le pic sans hésitation. Cela aide à garder les histoires plus petites et plus prévisibles.
- Les rétrospectives sont importantes dans l'agile en général, donc Kanban (qui serait Personal Kanban) marque des points supplémentaires ici, car son processus rétrospectif est davantage axé sur les données. Il est difficile de jouer à Triple Nickels lorsque vous n'avez pas assez de monde.
Ces choses s'appliquent probablement aux situations en solo et en petite équipe (2 ou 3 développeurs).
AJOUT: quelque temps après avoir écrit cette réponse, j'ai trouvé cette conférence et j'ai été très impressionné: Kanban personnel: optimisation du codeur individuel
- Soit vous travaillez sur des sprints bien définis, soit vous choisissez délibérément une approche Kanban. Ne vous retrouvez pas accidentellement dans Kanban
- Les bugs d'abord, les fonctionnalités en second.
- Gardez toujours l'accent sur le rapport valeur/fonctionnalité. (YAGNI sur placage d'or)
- Les rétrospectives sont tout aussi précieuses. Et tout aussi important, apportez des modifications de processus en petits morceaux. Ne décidez pas qu'aujourd'hui vous allez commencer à utiliser TDD, Mock et IoC en une seule fois, à moins que vous n'ayez vraiment aucune fonctionnalité externe pour fournir ATM. Apportez un à la fois.
En fin de compte, je définis vraiment Agile comme "faire ce qui a du sens pour votre équipe et vos clients et ne pas adhérer aux anciennes pratiques car elles semblaient avoir fonctionné dans le passé".
Agile fonctionne aussi bien pour les individus que pour les équipes. Il s'agit de trouver un processus qui fonctionne pour vous et de vous permettre de vous adapter aux circonstances changeantes une fois que votre projet a déjà commencé. Il s'agit également de fournir régulièrement de la valeur à votre client, que le logiciel soit réellement "terminé" ou non.
Les processus agiles sont hautement itératifs. Le travail se fait en courtes TimeBoxes/sprints/cycles/itérations. Certains travaux de conception peuvent être nécessaires à l'avance, mais peuvent être refactorisés à mesure que vous en apprenez davantage sur ce que vous avez besoin d'un système. Les tests unitaires sont l'épine dorsale de presque toutes les méthodes de développement Agile, vous donnant une indication sur le fonctionnement de votre logiciel et si des ajouts/modifications à votre logiciel cassent la base de code existante.
Si vous adhérez à BDD/TDD, permettez à vos exigences de changer avec le vent et pouvez ajuster vos priorités de fonctionnalités en conséquence, si vous construisez l'ensemble de votre système et exécutez tous les tests souvent, et si vous fournissez du code de travail à la fin de chaque sprint , vous êtes déjà Agile.
Sensationnel. J'essayais de garder un ami sur le crochet que je pouvais appeler lorsque j'avais des problèmes - et de parler du problème de codage. Vous savez ce que je veux dire ... le simple fait d'expliquer un problème à haute voix apporte une solution à mon esprit 90% du temps.