Comment un développeur unique peut-il utiliser les méthodes agiles?
Je suis pigiste et travaille comme développeur unique. Dans tous les cas, je suis la personne qui porte des chapeaux différents. Je suis le Scrum Master et je suis la seule personne dans le développement. Ce que je ne suis pas, c'est le Product Owner?
Existe-t-il des méthodes agiles et des outils gratuits qu'un pigiste peut utiliser?
Le but d'Agile est de ...
minimiser autant que possible toutes les boucles de rétroaction
minimiser les frais généraux du projet en termes de documents/formulaires produits et le remplacer par un support à bande passante beaucoup plus élevée, qui est des communications en temps réel (de préférence en face à face) entre les membres de l'équipe.
Si vous faites plus de recherches sur l'agilité, beaucoup d'entre elles parleront des équipes et de l'interaction entre les membres. En effet, avec chaque Nième membre, le nombre de lignes de communication à l'intérieur du N augmente. Au fur et à mesure que N augmente, vous faites face à des défis supplémentaires tels que la formation/la diffusion des connaissances, la coordination des efforts ...
Beaucoup de problèmes auxquels une équipe agile serait confrontée, vous n'auriez certainement pas à vous inquiéter, mais le principal domaine sur lequel je me concentrerais est (1) - minimiser les boucles de rétroaction. Même en tant que développeur unique, cela est très pratique car plus tôt vous identifiez les problèmes (qu'il s'agisse d'exigences, de conception ou d'implémentation), moins il sera coûteux de résoudre ces problèmes.
Voici ce que je ferais:
Faites en sorte de rencontrer régulièrement vos clients et assurez-vous qu'ils ...
- savoir exactement ce que vous avez fait et vous faire part de vos commentaires dès que possible
- sachez sur quoi vous travaillez ensuite et confirmez que ce sont les fonctionnalités qu'ils souhaitent réellement étant donné ce qu'ils considèrent déjà comme terminé
Passez un peu de temps à repasser le déploiement/l'empaquetage. Un peu de coût initial garantira qu'en un seul clic, vous pourrez déployer une version entièrement déployable de votre application qui pourra être testée instantanément. Je ne sais pas combien de serveurs d'intégration continue bénéficieraient à une équipe composée d'une seule personne - curieux de savoir ce que les autres en diraient.
Vous pouvez gérer votre backlog de produits de la même manière que les équipes agiles le font. Cependant, puisque vous travaillez par vous-même, je sauterais d'utiliser n'importe quel type de logiciel de fantaisie et même un tableau blanc avec des notes publiées et irais directement à un fichier texte (peut-être une feuille Excel) qui répertorie les éléments de travail. Donnez-leur la priorité et revoyez-les régulièrement pour vous assurer que vous ne manquez rien et que les choses importantes sont prises en charge en premier. Si vous voulez essayer quelque chose d'un peu plus sophistiqué, Trello , pourrait être une bonne option
Pensez à passer au TDD. Il y a un an, j'étais un peu sceptique et je considérais que TDD n'était utile que pour les utilitaires de bas niveau qui ne dépendent d'aucune autre chose. Mais l'année dernière, j'ai essayé l'approche à plusieurs reprises et à chaque fois, j'ai été extrêmement surpris des résultats. Oui, c'est un gros morceau de coût initial, mais il semble que les avantages d'avoir votre code facilement testable/vérifiable finissent par vous rembourser rapidement.
- TDD vous indiquera instantanément si vous avez fait une erreur dans le code et vous pouvez facilement vérifier que vos classes/fonctions se comportent correctement dans les conditions aux limites. L'alternative consiste généralement à "faire de votre mieux", mais vous finissez par trouver des bogues pendant les tests, puis vous passez des heures à isoler et à déboguer le problème.
- Avec les tests unitaires en place, vous n'aurez pas autant peur de refactoriser et de modifier considérablement la conception que de nouvelles fonctionnalités sont ajoutées. J'ai remarqué que sans TDD, la plupart des gens ont tendance à avoir peur de toucher du code qui a déjà été testé (et à juste titre). Dans de nombreux cas, ils continuent d'ajouter de plus en plus, tout en ayant peur de modifier ce qui existe déjà et le code finit par ressembler à un désordre de spaghetti hérité avant même que la version 1.0 ne soit expédiée.
- Avec des tests en place et être en mesure de refactoriser à volonté, vous donne également l'avantage de ne pas avoir à insister autant sur la bonne conception du premier coup, car il devient plus facile de modifier le design au besoin plus tard.
Effectuez vos propres rétrospectives. L'un des messages clés de l'agilité est que le changement doit être accueilli et que nous ne devons jamais nous installer dans un rythme où la même chose se fait à plusieurs reprises. Évaluez périodiquement ce que vous faites et essayez d'identifier les domaines où vous pensez qu'une approche différente pourrait rendre votre efficacité plus grande. N'ayez pas peur d'ajuster le processus (ou parfois de changer radicalement quelque chose, si pour l'instant pour une autre raison, alors juste pour voir ce qui se passerait) et d'adapter vos pratiques à votre situation spécifique.
Les conseils que j'ai fournis sont basés sur le type de travail que j'ai effectué, qui consiste principalement à travailler sur une application vendue en tant que produit. Nous travaillons sur la même base de code et continuons à étendre/améliorer la même application à chaque nouvelle version. Les conseils peuvent être différents si votre principale source de revenu est le codage en tant que service (c'est-à-dire écrire du code, le vendre, ne plus jamais le revoir). J'ai l'impression que les développeurs dans le domaine des services ont tendance à ignorer TDD et de nombreuses autres pratiques, car le code extensible/maintenable n'est pas leur priorité. Au lieu de cela, ils se concentrent sur le délai de réalisation (c'est-à-dire la réduction des coûts) et s'assurent que la version 1.0 (qui est la première et la dernière version) satisfait aux critères d'acceptation du client.
Peut-être que la programmation personnelle eXtreme pourrait être quelque chose que vous voudrez peut-être examiner?
https://www.google.nl/search?q=personal+extreme+programming
C'est une méthode qui est une combinaison entre des pratiques de programmation extrêmes et les pratiques du processus logiciel personnel (PSP) conçu par Watts S. Humphrey de l'Université Carnegie Mellon. PSP est assez rigide dans son approche et pas agile. PXP est une adaptation plus agile du développement de logiciels personnels. Le PXP n'est pas vraiment quelque chose que vous appelleriez grand public, mais je l'ai utilisé dans le passé et cela a fonctionné pour moi. J'ai adapté une approche PXP basée sur certains articles que j'ai lus sur le sujet:
https://research.uni-sofia.bg/bitstream/10506/647/1/S3T2009_37_YDzhurov_IKrasteva_SIlieva.pdf
http://dl.acm.org/citation.cfm?id=1593127
PXP implique les pratiques PSP suivantes:
• Enregistrement du temps: Fondamentalement, votre feuille de temps. Ceci est utile pour déterminer votre taux de progression.
• Mesure de la taille: vous devez disposer d'une sorte de mesure pour mesurer la quantité de travail que vous avez effectuée. Habituellement, cela se résume à des lignes de code (LoC)
• Standard de type de défaut: liste avec laquelle vous catagorisez les types de bogues que vous rencontrez.
• Proposition d'amélioration du processus: vous devez avoir une sorte de plan pour améliorer votre propre processus. Fondamentalement, vous devrez planifier certaines activités pour une auto-évaluation et un examen. Vous devrez faire un plan avant de le mettre en œuvre. (Et revoyez le plan de temps en temps pour le modifier)
• Enregistrement des défauts: vous devez garder une trace des bogues que vous avez trouvés afin que vous puissiez analyser votre comportement par la suite.
• Revues de code: c'est un peu délicat, mais vous devez en quelque sorte revoir votre code. Je ne trouverai pas cela particulièrement intéressant avant d'avoir réussi à me détacher mentalement de mon propre travail. Pourtant, vous ne repérez généralement pas vos propres défauts aussi facilement que les autres.
Il y a aussi quelques activités liées à XP:
• Intégration continue: PXP inclut les pratiques de contrôle de version des versions, de builds automatisées, d'exécutions de test automatisées et de soumission automatisée des défauts. Je trouve cette pratique très utile. (Je préfère l'approche d'enregistrement sécurisé, mais cela nécessite un script pour la configuration, vous pourriez trouver cela trop difficile)
• Conception simple: KISS! Vous savez probablement de quoi je parle. (sinon, google)
• Petites versions: réduisez suffisamment les jalons de vos sprints pour garder les choses en perspective et ne courez pas le risque de consacrer énormément de temps aux fonctionnalités auxquelles vous vous êtes engagé, mais ne pouvez pas les respecter à temps.
• Refactoring: pratique agile standard, vraiment.
• Développement piloté par les tests: cela ne devrait pas non plus être trop familier.
• Spike Solutions: si vous avez un problème nouveau ou difficile à résoudre, prenez du recul et essayez de le résoudre de manière autonome avant d'essayer de l'intégrer dans votre grand projet.
TL; DR: cela se résume à la rigueur de suivi présente dans le style PSP/TSP (CMMi) combinée à des pratiques courantes de XP moins les efforts d'équipe requis pour XP.
En ce qui concerne l'outillage, jetez un œil à https://www.flying-donut.com . C'est un nouveau produit en ligne, et je l'ai utilisé pour mes projets solo et projets d'équipe avec beaucoup de succès. Il est inspiré de la mêlée et pourrait facilement héberger n'importe quel projet itératif. Dans Flying Donut, vous travaillez sur des itérations et des éléments. Les éléments sont ensuite décomposés en tâches.Il existe une bonne façon d'organiser votre backlog et son interface graphique est propre avec des temps de réponse rapides.
En ce qui concerne la méthodologie, je pense que Scrum convient aux indépendants car la méthodologie a un chemin de communication clair avec le client. Et oui, vous serez le propriétaire du produit. Le propriétaire du produit est celui qui s'assure que le client obtient ce qu'il veut. Et vous serez l'équipe qui fournira le code fonctionnel. Et enfin, vous serez le maître de mêlée pour vous assurer que vous êtes dans les délais et supprimez tous les obstacles que l'équipe (vous) a. Cela semble plus difficile que ça. Le mode itératif vient à la rescousse. Si vous faites des sprints hebdomadaires ou toutes les deux semaines et que vous avez un chemin de communication clair avec le client et que le client voit ce qu'il obtient, vous pouvez rapidement répondre aux nouvelles exigences potentielles auxquelles le client n'a jamais pensé.
Avertissement : J'utilise Flying Donut depuis de nombreux mois, depuis que j'ai aidé à le construire.