Venez voir les photos de l’Agile Tour à Montréal sur www.SeDevelopperAgilement.com. C’est aussi à cette adresse que vous retrouverez les présentations de François Beauregard et Léo Lachance.
Find pictures of Agile Tour in Montreal and presentation of Leo and François (Quebec and Montreal) on www.sedevelopperagilement.com
I just discovered how easy it is to get rid of those silly ids in your URLs.
Just install friendly_id with
sudo gem install friendly_id
then run a little script/generate friendly_id to get your migration. Following that, just add this in your model(s) you need slugs for :
has_friendly_id :attribnute_you_wanna_slug, :use_slug => true
Rake some of this:
rake friendly_id:make_slugs MODEL=ModelName
And Voilà ! you’ve got a friendly ID which can be used in your URLs…
Isn’t it fun ??
Retrouvez-nous dans le journal des Affaires “Quand une méthode de travail devient philosophie de gestion” et lisez sur notre organisation du travail guidée par la méthode Agile.
Quelques évenements récents me rendent fier d’être à Pyxis et de travailler avec la superbe équipe que nous avons assemblée au cours des 9 dernières années.
Tout cela donne envi de rêver quand je pense aux années à venir.
~françois
Tim came over to Chris’ house the other morning. Chris is a professional fishing guide. He actually gets paid to do what men work all year round to get to do for a single week. They both packed their gear before the sun had even lifted.
By 5:30 they were hitting the water. The lake was so calm you could the see the the reflection of the mountains as clear as in a mirror while the morning fog lifted off the ground. As they arrived to their first spot, it looked as though the boat was cutting waves through a sea of mercury.
By 7h30 they both had caught their quotas and started chilling in the back of the boat looking for catfish.
“Man is that the life or what ?” – said Tim.
“You betcha!”
“Man can you believe I actually get payed to do this ?”
“Yeah, ain’t that a shame ?”
“So are you still the Master at your job?”
“If you mean, SCRUM master then yes, I still am.”
“Oh excuse me, oh master of scrum”
“So when are you getting promoted to being God ?” Chris laughed.
“Oh you mean just like Peter right ?”
Peter was their former boss when they both were working in a warehouse back in college. The guy had no manners, no formal education but a truckload of ambitions.He went from broom-boy to foreman on the night shift within his first year. Within five years, he was in charge of the entire shipping department.
Before he hit age thirty, he was in charge of the entire regional section of the now multi-national enterprise. He used to have the following saying : “When I wake up, I tell God He can go back to sleep. I’m in charge now.”.He repeated this phrase so often that he started believing his own hype.
“Actually, I’m not in charge of anyone” said Tim.
“Really ? ”
“Actually, I don’t even have what you’d call a superior ? ”
“You’re serious?”
“Yeah. In scrum all you have are self-organizing teams where each members has a crucial role in the entire process.”
“Actually, baring similar talent experience and other qualities, not a single one member is more important than the other one. ”
“Wow, if Peter heard of this idea he you blow a gasket!”
“Damn straight.”
Tim went on explaining the finer advantages of self-organizing teams :
-> Members are more committed to the success of the project since they were all deeply involved in the decisions process. Feeling they have a certain amount of control of the projects destiny they gradually get more and more deeply involved and connected to the project.
-> No hierarchy means the people accountable for the success of the project are the ones working on it. This removes the pressure sent on the teams superior who’s usually the person that’s usually accountable for the teams success yet is the person who has the less influence on the actual day-today work being done.
-> Self-organizing teams lets creative mind break loose, whereas in teams where the job in imposed, the creative people in a team are stuck waiting for their boss to tell them how to do things instead of letting the ideas emerge from the most imaginative people of the group, whoever that may be.
-> In a traditional team, communication is centered around the superior. He/she is the communication bottleneck of the entire team.
He also went on explaining how scrum as a process is so well suited for self-organizing teams:
-> Frequent inspections means the members skill progress more rapidly and by doing so the members build more confidence in themselves and do so at a much faster rate.
-> Frequent releases means rapid adjustments. Teams do experience failures. But they are short lived and since they come from a short investment do not take as long to recover from.
-> The roles are well defined and the development team is at center stage.
-> Communication is encouraged through daily stand up meetings, sprint reviews. Also open space working areas and pairing is heavily promoted from many scrum praticionners through XP engineering methods.
“Wow that looks great said Chris. Too bad I never experienced self-organized teams when I was working … I mean when I had a real j…You know what I mean.”
“You think it would of made things different”
“Maybe. Wonder how a guy like Peter would fare in such an environment. That guy must have been promotted to King of the free world by now”
“Actually Peter got fired the other week”
“REALLY?!”
“Yeah saw his profile on LinkedIn. He was looking for a new job.”
“Wow. Must of stepped on too many toes.”
“Hehehe. Ever heard of the Peter principle?”
“Can’t say I have.”
“It came from a guy named DR Laurence J Peters. He wrote a book about the subject. It can actually be summed up to this: “In a Hierarchy Every Employee Tends to Rise to His Level of Incompetence” meaning that in a hierarchy, the best member of a certain level are usually promoted to a superior level. Thus someone will keep on getting promoted until he his no longer good enough to be promoted any further. Thus reaching his own level of incompetence.
“Damn, Peter sure did have the right name.”
“Indeed he did, indeed he did” said Tim laughing.
-Nicholas Lemay
Le MTC Paris, Pyxis, et Access it inaugurent un nouvel atelier ALM dédié à l’application de de la méthode Scrum sur la plateforme Visual Studio Team System.
Mathieu Szablowski animera un nouvel atelier d’une demi-journée pour éclairer chefs de projet, architectes ou développeurs sénior sur :
Quel lien peut-il donc exister entre une société informatique s’occupant de gestion Agile de projets de développement logiciel et une ONG internationale des droits de l’Homme travaillant sur le droit à l’alimentation? A priori aucun, mais il suffit parfois de deux personnes (imaginons un couple où Madame travaille à Pyxis et où Monsieur travaille à FIAN, par exemple…) pour que la relation devienne possible et pour que l’on se rende compte que si les activités sont évidemment très différentes, Pyxis et FIAN œuvrent à mettre l’humain au centre des préoccupations, dans une recherche de dignité et d’amélioration des conditions de vie ou de travail.
Voici la raison d’être de Pyxis : « Pyxis aide les organisations de développement logiciel à devenir des endroits où les résultats, la qualité de vie et le plaisir coexistent de façon durable en étant en premier lieu un exemple de ce qu’elle propose à ses clients et en accompagnant ceux-ci. » De plus, Pyxis affiche publiquement dans son blogue sa volonté de faire croître l’organisation de manière profitable tout en améliorant la vie des gens et en s’amusant.
FIAN pour sa part travaille au respect et à la réalisation du droit à l’alimentation en lançant notamment des campagnes de lettres adressées aux autorités responsables d’une violation de ce droit. Ainsi, quand des petits paysans sont expulsés sans qu’aucune compensation ne leur soit donnée ou encore quand des peuples autochtones sont chassés de leurs territoires ancestraux pour laisser place à des projets agricoles ou d’exploitation des ressources naturelles, FIAN intervient afin de mettre fin à des situations qui menacent l’alimentation quotidienne de milliers, voire de millions de personnes. Mais l’action de FIAN ne se limite pas seulement à cela puisque FIAN est très active dans les forums internationaux (Organisation des Nations Unies pour l’alimentation et l’agriculture ou FAO) afin que le droit à l’alimentation soit défini comme l’un des piliers des politiques de développement et de coopération des pays du « Nord », dont le but est depuis plus de quarante ans l’éradication de la faim dans le monde. Et nous en sommes loin puisqu’en 2009, l’humanité a dépassé pour la première fois le seuil symbolique du milliard de personnes touchées par la faim et la malnutrition (1,02 milliard selon les chiffres de la FAO de juin 2009). Cette situation est tout simplement inacceptable sur une planète qui pourrait nourrir 12 milliards de personnes si les ressources alimentaires étaient justement réparties.
En juillet 2009, j’ai eu l’opportunité de rencontrer plusieurs employés de Pyxis à Laval (Québec) et j’ai été véritablement surpris de leur intérêt pour FIAN et son travail. De mon côté, je voulais profiter de cette rencontre pour leur expliquer les difficultés de communication au sein de notre structure, entre les différentes composantes (salariés, conseil d’administration, bénévoles, traducteurs, collègues européens…). Rapidement, des ébauches de solution sont apparues parce que les difficultés de communication au sein d’une ONG sont les mêmes que celles rencontrées au sein d’une équipe d’ingénieurs en informatique. Dans ces cas-là, l’installation (et surtout l’utilisation) d’un wiki apparaît comme une première étape visant à ne plus perdre cette ressource si précieuse qu’on appelle temps. J’imagine que les Pyxissiens doivent encore se demander comment une ONG comme FIAN parvient à travailler avec aussi peu d’outils efficaces de partage d’information… Et pourtant, cela se fait parce que les gens qui y travaillent sont des passionnés, de la même manière que les Pyxissiens le sont aussi dans leur domaine.
Cette passion et cet idéal communs de mettre l’humain au centre des préoccupations font que Pyxis a décidé de soutenir FIAN financièrement en reversant l’ensemble des revenus de la vente d’une application iPhone développée par Pyxis.
Xavier Papet – FIAN.org
Pendant un planning d’itération, il est commun de demander à l’Equipe de fixer/choisir/établir son “engagement”. Et la plupart du temps, le comportement attendu consiste à choisir un ensemble de fonctionnalités à livrer au client à la fin de l’itération qui commence ce jour là.
Dans Scrum, ce rituel de planning se répète à chaque commencement d’itération.
Pendant l’itération, c’est le temps de la réalisation. C’est là que les artistes-artisans informaticiens réalisent le miracle de leur art pour livrer un morceau de logiciel d’une qualité exceptionnelle. Hum… Mais au fait, c’est quoi pour vous la Qualité ? Autour d’un café on devrait probablement s’entendre sur le fait que des professionnels de l’informatique devraient livrer des logiciels de qualité. Voire, que leur “engagement” a quelque chose à voir avec “livrer un logiciel de qualité”.
Durant les dix dernières années, une technique appelée TDD s’est développée. J’imagine que vous connaissez ça très bien, ainsi que sa représentation la plus populaire :
La couleur pour le côté du refactoring est parfois le vert pour exprimer que pendant une opération de refactoring, “les tests passent toujours”. J’ai pris ici le gris surtout parce que sur ma magnifique casquette tdd, le refactoring est en gris.
Mais au fait : quelle est la vocation du refactoring ? Parce que si le test passe, je pourrais livrer le code et n’en parlons plus ! Bien sûr la plupart du temps le logiciel n’est pas fini ; il faut continuer. Pour pouvoir continuer, on met à profit ce temps de refactoring pour transformer le code que l’on a écrit à la va-vite pour faire passer le test en un “code de qualité”. L’objectif semble donc être la qualité. Autrement dit, l’artiste-artisan informaticien professionnel construit un code de qualité pendant le refactoring. Encore autrement dit : l’artiste-artisan informaticien respecte son engagement de qualité pendant le refactoring.
Maintenant si je dessine le cycle du TDD plutôt comme ça, est-ce que vous me voyez venir ?
En mélangeant les notions d’engagement du planning d’itération et de refactoring du tdd, on pourrait vivre la situation suivante : pendant un planning d’itération, l’Equipe considère les premiers éléments de carnet de produit, écrit les tests et les fausses implémentations qui font passer les test, et réfléchit à son engagement : quel part du code écrit pendant le planning pouvons-nous transformer en code de qualité pendant l’itération ? Par exemple pendant le planning on a fait passer 4 tests mais notre engagement ne couvre que la livraison du code faisant passer les 3 premiers.
Cette approche met au premier plan les notions de qualité et de professionnalisme des équipes on affichant que la valeur des professionnels de l’informatique va se chercher pendant le refactoring. “Pisser du code” ne s’appliquerait plus qu’au code écrit le plus vite possible pendant le planning pour faire passer les tests, pas au code que l’on livre.
En y pensant un moment, il nous est apparu que dans beaucoup de sociétés autour de nous, sociétés de services entre autres, il y avait des consultant en inter-contrat et que « gérer » ces personnes était pour certaines un petit casse-tête. Une des préoccupations souvent évoquée est comment profiter du passage en inter-contrat pour améliorer les compétences des personnes concernées ?
Il y a quelques temps j’ai appelé un ami dans une de ces sociétés et je lui ai proposé de venir animer un coding-dojo pour tous les consultants en inter-contrat de son service. Je me rappelle que lorsque que je lui proposé cela, il a tout de suite été emballé et m’a dit « demain ? ».
Ils m’ont accueilli fin septembre pour animer un coding-dojo randori chez eux et les participants en redemandent. C’était la première fois qu’ils participaient à un coding-dojo alors nous avons dédié 30 minutes, sur les 4 heures, à en parcourir les principes et le fonctionnement. Je me suis limité au rôle d’animateur et de coach TDD. Le soir cela me manquait de ne pas avoir touché le clavier 
.
Si vous aussi vous avez des inter-contrat et que l’expérience vous intéresse, appelez-nous !
