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 contact avec le client

Je me souviens d’avoir lu une thèse sur le développement de Cowboy, qui est essentielle 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érerais ce qui suit:

• Garder un carnet de produit
  Un carnet de produit est essentiellement une liste de tous les éléments que vous avez l'intention de terminer à un moment donné pour ce produit.
• Maintien d'un burndown de sprint et d'un productdown
  Un burndown de sprint commence par une liste de toutes les tâches que vous avez décidé de réaliser dans ce sprint (un sous-ensemble de votre carnet de produit à terminer sur une période donnée, par exemple 2 semaines), ainsi que l'estimation du travail requis. En marquant les choses, vous les marquez comme faites; réduisant ainsi (ou brûlant) le travail restant pour ce sprint.
  De la même manière, un épuisement de produit suit le travail restant pour l’ensemble du carnet de produit.
• Adopter les 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 devez vous assurer que les "points" de la tâche A sont corrects par rapport à ces attentes.
  L'accent n'est pas mis sur l'estimation exacte 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 assure la cohérence, cette vélocité peut être utilisée pour estimer les tâches que vous allez probablement accomplir dans les prochains sprints. Notez bien que cette vélocité doit être constamment révisée.

• Limiter les travaux en cours (en plus de la box-time). Même si vous utilisez une méthode itérative (par opposition à Kanban), supposons que votre vélocité soit de 8 points par itération. Ne commencez pas à travailler sur tous les 8 en même temps. Limiter WIP par le nombre d'histoires ou de points d'histoire est acceptable.
• Ayez des tests d'acceptation automatisés pour toutes vos histoires d'utilisateurs. Automatisez autant que vous pouvez en général.
• Err du côté de rendre les histoires d'utilisateurs trop petites. En règle générale, établissez un rapport de 3: 1 entre l'histoire la plus grande et la plus petite . Si vous sous-estimez une histoire dans Scrum et qu'elle s'avère trop volumineuse, plusieurs développeurs peuvent l'essayer pour la remettre sur les rails. Mais tu n'as pas assez de monde.
• Si, dans le contexte d’une équipe de taille normale, vous hésiteriez à diviser un épisode en une histoire d’utilisateur, que ce soit en solo ou en petit groupe, faites-le sans hésiter. Cela aide à garder les histoires plus petites et plus prévisibles.
• Les rétrospectives sont importantes dans l'agilité en général, de sorte que Kanban (qui serait Personal Kanban) marque des points supplémentaires ici, car son processus rétrospectif est davantage basé sur les données. C'est difficile de jouer à Triple Nickels quand on n'a pas assez de monde.

Ces choses s’appliquent probablement aussi bien en solo que dans les petites équipes (2 ou 3 développeurs).

AJOUT: un peu après avoir écrit cette réponse, j'ai trouvé cette conférence et j'ai été très impressionné: Kanban personnel: optimiser le codeur individuel

• Soit travailler à des sprints bien définis, soit choisir délibérément une approche Kanban. Ne vous retrouvez pas accidentellement en kanban
• Bugs d'abord, caractéristiques ensuite.
• Gardez toujours le cap sur la valeur et les fonctionnalités. (YAGNI sur Gold Plating)
• Les rétrospectives sont tout aussi valables. Et tout aussi important, modifiez les processus par petits morceaux. Ne décidez pas qu'aujourd'hui, vous allez commencer à utiliser TDD, Mock et IoC d'un coup, à moins que vous n'ayez vraiment aucune fonctionnalité externe permettant de fournir des GAB. Amenez-en un à la fois.

En fin de compte, je définis vraiment Agile comme "faire ce qui est logique pour votre équipe et vos clients et ne pas adhérer à d'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à démarré. 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 très itératifs. Le travail est fait en bref TimeBoxes / sprints / cycles / itérations. Certains travaux de conception peuvent être requis au début, mais peuvent être modifiés pour vous en apprendre davantage sur ce que vous avez besoin d'un système. Les tests unitaires sont la colonne vertébrale de presque toutes les méthodes de développement Agile. Ils vous indiquent si votre logiciel fonctionne correctement et si des ajouts / modifications à votre logiciel vont briser la base de code existante.

Si vous adhérez à BDD / TDD, laissez vos exigences évoluer avec le vent et ajustez les priorités de vos fonctionnalités en conséquence, si vous construisez votre système entier et exécutez souvent tous les tests, et si vous livrez un code fonctionnel à la fin de chaque sprint. , vous êtes déjà agile.

Sensationnel. J'essayais de garder un ami raccroché que je pouvais appeler quand j'avais des problèmes - et je parlais du problème de codage. Vous savez ce que je veux dire ... le simple fait d'expliquer un problème à voix haute apporte une solution dans mon esprit 90% du temps.