Salut à tous!
Je vais attaquer 2010 en vous présentant quelquechose de tout nouveau tout beau!
Beaucoup de programmeurs connaissent déjà les méthodes agiles. Mais si vous savez.. ces methodes de programmation/production/management modernes.. qui maximisent la satisfaction du client, la productivité et rendent vos programmeurs plus efficaces mais un peu snob! .. (si vous connaissez pas, renseignez-vous, snobisez-vous et reviendez lire ce post seulement après.. espèce de coder 0.1)
Et bien moi je vais vous présenter encore mieux, encore plus fort que les méthodes agiles!
J’ai nommé: Les méthodes habiles!
« Quèksé? » me direz-vous, avec vos petits yeux irrités par vos écrans, et votre très significatif filet de bave au coin des lèvres?
C’est tout ce que voudraient être les methodes agiles, mais qu’elles peuvent pas parce qu’elles sont trop rigides!
Les methode habiles, c’est un peu l’utopie de la production de logiciel, le nirvana du programming!
Cela passe par l’acomplissement de plusieurs buts, et de concepts forts. Tout d’abord, focalisons nous sur l’esprit d’équipe!
My name is Tim.. Tim Spirit!
Avoir une équipe de programmeurs soudé est très important. Pour arriver à ce but voici quelques conseils à suivre:
1- L’équipe devra se murger la gueule ensemble au moins une fois par semaine! Bien entendu, une fois par semaine est le minimum requis, sachant qu’une moyenne de 3 cuites/semaine est recommandé.
2- Pour plus de cohésion, ne pas hésiter à programmer tout nus! Même si dans un premier temps cela augmentera vos factures de chauffage, le gain en Tim Spirit est proportionel à la nudité de l’équipe (ou inversement proportionel au taux d’habillage)!
3- La où les méthodes agiles préconisent de programmer en binôme, les méthodes habiles proposent de programmer à quatre (soit en quadrinôme)! En effet deux codeurs pourront programmer aisément pendant que les 2 autres leurs masseront successivement le dos et les pieds. Il conviendra d’effectuer des rotations toutes les 1/2 heure. Le Tim Spirit est bien sur exponentiel lorsque les programmeurs sont également nus.
4- Faire bruler de l’encens peut également un très bon catalyseur (de même que l’utilisation de monoï pour les massages, bougies et autres accessoires de détente…)
Change is my choice
L’équipe ne devra pas avoir peur du changement! Pour cela plusieurs solutions se proposent à vous:
1- Ne pas hésiter à reconcevoir et recoder votre software juste après la sortie d’une release. Changer tout est une bonne idée. Ceci est encore plus efficace couplé à la règle 1 du Tim Spirit.
2- Le courage est très important: pourquoi mettre un integer en clée primaire alors qu’on peut mettre une chaîne de caractère? Laisser des chances à l’application de rester dans une boucle infini, prenez des risques nom de diou!
3- Organiser vos cycles de développement de manière à changer d’IDE toutes les semaines. Programmez ainsi une semaine sur Eclipse puis Netbeans, puis Visual et ainsi de suite. Ceci vous fera developper une application complètement générique, et (dé)formera tout les développeurs!
4- Changer de coupe de cheveux/look vestimentaire au moins une fois par mois. Un programmeur qui change est un programmeur nouveau! Cela fonctionne également avec votre voiture, votre telephone portable ou tout autre appendice phallique.
5- La convention de nommage? Quelquechose de simple. Les noms masculins commenceront par un « olr_ » et les noms féminins par « dtg_ », mais ceci avant midi et après 17h00, puisque sinon cela s’inversera.
Feed me back
Comment votre software est-il perçu? Pour avoir du retour sur votre application, il vous sera utile de:
1- Satisfaire votre client, avec tout ce que cela peut engager. Mettez votre amour propre de coté et pliez vous à ses exigences! Vous pourrez ensuite lui demander ce qu’il pense de votre produit.
2- Sortez dans la rue et demandez à des personnes prises au hasard ce qu’elles pensent de votre application. Ne pas hésiter à leur expliquer, et si possible leur transmettre les méthodes habiles (et oui, c’est viral).
3- Faites un skyblog tournant autour de votre software, vous devrez vite avoir des retours sous forme de « commz ».
Vous pouvez combiner toutes ces methodes avec des techniques comme DRY:
Don’t Rush Yourself: Programmons doucement.. prenez votre temps, et appréciez chaque instanciation de variable à sa juste valeur!
Intégration continue: Vive le temps réel, recompilez votre projet après chaque point-virgule!
Voila pour les principes de base des methodes habiles! A vous désormais de répandre les bonnes pratiques, et distribuer les méthodes habiles!
Bon programming les Habilistes!