Un pigiste peut-il utiliser le développement agile?

Je veux améliorer la façon dont je développe des logiciels. Je veux développer plus rapidement et un excellent code! Aujourd'hui, j'utilise la méthode de la cascade en tant que pigiste, écrivant des trucs Web (sites, systèmes, etc.). Existe-t-il un moyen d'utiliser le développement agile (XP, SCRUM, etc.) de cette manière? Je ne connais rien au développement agile, par où commencer? Merci beaucoup.

... Autre que la programmation par paires, bien sûr. ;-)

Sérieusement, je suis aussi pigiste et j'utilise autant que possible des techniques agiles. Cela fonctionne très bien pour moi. J'utilise énormément le TDD,

Personne n'utilise nulle part 100% d'XP ou Scrum, mais tout le monde en utilise des parties, essayant d'en adopter autant qu'il fonctionne pour eux. À mon avis, plus vous en adoptez, mieux vous vous portez.

La chose qui me manque le plus est la programmation par paires. La façon dont vous surmontez cela est

1. Accédez à de nombreuses réunions de groupes d'utilisateurs.
2. Trouvez quelques personnes que vous respectez en tant que développeurs.
3. Demandez-leur de vous rencontrer autour d'un café ou quelque chose pour écrire du code. Donnez-leur occasionnellement une partie de votre salaire horaire si vous le jugez nécessaire ou répondez simplement en nature à l'élaboration de leur code.
4. Participez ou créez un Hack Club comme celui-ci: http://www.DallasHackClub.org .

Voici quelques ressources que j'utilise:

• Extreme Programming -un guide rapide mais complet en ligne sur XP.
• Un excellent aperçu de Scrum .
• Livre fantastique et court . Parfait pour toi!

Je dirais donc qu'il y a trois principaux "points impressionnants" à utiliser Agile en tant que pigiste:

1. Pour les gros clients, Travail / facture en itérations. À la fin de l'itération, le client peut continuer à travailler sur le projet ou terminer le projet (c'est-à-dire qu'il a atteint son objectif). Je sais (par expérience) que je ne peux pas estimer bien plus que quelques semaines, et le paiement par itération maintient également la trésorerie. Ce n'est pas amusant d'être au mois 6 d'un projet de 3 mois et d'attendre pour terminer le projet afin que vous puissiez bil ...

2. Agile signifie que le changement se produit. J'ai fait une tonne de projets d'enchères fixes (que vous pensez pouvoir faire avec la cascade) qui m'ont fait perdre de l'argent, à cause d'une demande d'un client au milieu du cycle. Le changement se produit: le client peut déprioriser un ticket pour effectuer un autre travail plus rapidement, ou peut-être vous avez mal prévu et n'avez pas fait autant que vous l'auriez espéré.

3. Bons outils de collaboration client. Mon estimation standard (pour quelque chose de plus petit que la valeur de travail d'une itération) est en fait une série d'étapes de développement axé sur le comportement dérivées des attentes du client. J'envoie ceci au client et dis "Est-ce correct?". Il s'assure que tout le monde est sur la même page.

4. Chose la plus simple qui pourrait éventuellement fonctionner. C'est quelque chose à garder à l'esprit pendant que vous travaillez: n'ayez pas peur de retourner vers le client et de dire: "Ce serait beaucoup plus simple (ou plus puissant, ou autre) si nous le faisions de cette façon ... "

5. Scrum est important. J'aime envoyer un email à mes clients chaque jour où je travaille sur leur projet. C'est comme ma mêlée pour eux: «ce sur quoi j'ai travaillé aujourd'hui», «quoi / quand je vais travailler sur leur projet ensuite?», «Y a-t-il quelque chose sur mon chemin? ? "

6. Le développement piloté par les tests est également très utile, même en tant que programmeur unique. Mes «estimations contenant des histoires BDD» m'aident à alimenter ce processus.

Une excellente façon de commencer votre voyage Agile est de configurer votre flux de travail à l'aide d'un système KANBAN.

Nous avons simplement 3 couloirs:

1. Nos tâches ou notre carnet de commandes
2. Sur quoi nous travaillons ou EN COURS
3. Choses que nous complétons ou FAITES.

Ce flux de travail Agile simple est une excellente façon de commencer.

En termes de codage, je recommanderais d'utiliser le développement piloté par les tests (TDD). Nous avons inclus de nombreux liens intéressants décrivant TDD dans notre article, mais nous les recopierons ici:

Pour plus d'informations, consultez les ressources suivantes:

• AgileData.org - Une excellente ressource pour le développement piloté par les tests.
• JamesShore.com - Une autre grande panne pour TDD
• Net Tuts - Une introduction amusante au TDD que j'aime!
• Artima - Entretien avec Martin Fowler
• Games From Within - Une bonne étude de cas de TDD
• DaniWeb - Introduction à TDD pour les développeurs
• Mark Levison - Article sur TDD

Étant donné que votre une personne, il est préférable que vous approchez des méthodologies agiles comme quelque chose qui est là pour vous aider GROK-ce qui fonctionne le mieux pour vous . Ils sont là pour vous aider à atteindre ce plateau «il n'y a pas de cuillère», mais comment cela se passera-t-il à vous de décider et ce que vous proposerez finira par chevaucher considérablement certaines méthodologies à différents niveaux, mais ce sera quelque chose de complètement vôtre.

Puisque vous essayez de trouver votre propre façon de faire pour améliorer votre efficacité globale, voici quelques conseils qui peuvent vous aider au moins à ne pas faire les mêmes erreurs que moi:

Oubliez toutes les solutions logicielles ciblant exclusivement les méthodologies agiles, aussi longtemps que vous le pouvez.

Le fait qu'ils soient plus adaptés pour faciliter la collaboration d'équipe n'est pas pertinent. Résister à la tentation. Vous ne vous mettez pas dans une manière de faire les choses et espérez ensuite que son adoption fonctionnera pour le mieux. Ce n'est pas le cas, cela vous frustre simplement. Vous commencez par trouver votre façon de faire, puis vous recherchez une solution logicielle appropriée. J'ai fini par utiliser des tableaux blancs (à commencer par un, mais maintenant j'en ai deux dans ma chambre) pour suivre / développer des histoires et la technique Pomodoro | To Do Today list pour suivre mes tâches de développement et c'est friggin 2011. Restez aux bases jusqu'à ce que nous obtenions des interfaces telles que celles d'Iron Man 2 ou que des voitures volantes commencent à apparaître.

Réflexion, réflexion, réflexion

C'est ce que j'ai compris comme étant la partie la plus importante de toute méthodologie pour un individu. Il s'agit de développer ce flux de travail qui vous donne une vue globale de votre projet afin que vous puissiez suivre ce qui doit être fait et quand d'une manière facilement gérable et où les mauvaises décisions sont rarement prises et se démarquer afin qu'elles puissent être rapidement modifiées avant qu'ils ne causent des dommages ... mais vous ne pouvez pas simplement le retirer de l'étagère. Commencez quelque part, n'importe où. Vous restez avec lui aussi longtemps que cela fonctionne. Investissez dans le suivi des bons, des mauvais et des moyens. Améliorez vos hypothèses, puis ajustez votre façon de faire en conséquence. C'est la seule façon de vous améliorer.

Concentrez-vous sur les délais, concentrez-vous sur la rapidité avec laquelle vous faites avancer les choses

J'étais probablement comme le prochain gars quand j'ai commencé, à courir après les rendez-vous. Graphiques de burnout? J'avais l'habitude de les considérer comme un moyen de visualiser mon suivi de développement par rapport aux délais. C'est une performance, pas un modèle d'estimation. Le temps est là pour mesurer votre efficacité en réfléchissant au travail que vous avez fait dans un certain laps de temps, pas seulement une valeur stupide pour représenter la distance avant d'entraver les délais. La réalité est que tout est fait quand c'est fait et votre méthodologie devrait en tenir compte.

Déviez en conséquence

Au final, qui a dit que vous deviez utiliser des user stories, ou quoi que ce soit que nous sachions d'ailleurs? Ne pense pas comme ça. Si vous êtes plus à l'aise avec la réflexion sur les fonctionnalités, alors défiez la communauté mondiale du développement et faites-le à votre façon, car tout est important à la fin de la journée. Si vous vous sentez comme si vous faisiez quelque chose de mal, félicitations - vous venez de conclure qu'il est temps de passer à autre chose. Il s'agit du quoi, pas du comment.

Je répondrais "comment voulez-vous améliorer la façon dont vous développez les logiciels?". Pour votre modèle d'entreprise, quels sont les principaux problèmes que vous avez rencontrés avec la méthodologie de la cascade?

Votre objectif est-il un développement plus rapide, un code plus robuste, une plus grande réutilisation, une réunion / adaptation aux exigences changeantes, etc.? Différentes méthodologies existent pour surmonter différents problèmes.

Bien sûr, l'adoption d'une méthodologie de conception autre que Waterfall peut être très utile pour gérer efficacement le cycle de vie d'un projet en fonction des besoins de votre entreprise. Pour le développement agile, il existe un grand nombre de ressources en ligne. Je regarderais en AUP (Agile Unified Process) qui intègre TDD (Test Driven Development). Cela peut être extrêmement utile lors de la construction / gestion de grands systèmes évolutifs.

Il n'y a pas de méthodologie «taille unique» et c'est la principale raison du grand nombre d'approches différentes. Je commencerais à réfléchir à l'endroit où vous pensez que les goulots d'étranglement se trouvent actuellement dans votre processus de développement, puis j'essaierais d'adopter une nouvelle méthodologie pour surmonter cela.

Par exemple, ne respectez-vous pas souvent les délais? Les nouvelles fonctionnalités introduisent-elles un grand nombre de bogues? Les nouvelles exigences entraînent-elles un réaménagement majeur? L'entreprise a-t-elle besoin de présenter des systèmes de travail réguliers? Découvrez: Agile , Iterative et Agile Intro .