Category : Développement logiciel

in Agile, Développement logiciel, Scrum

“a working proposal” : semaine 3/3

C’est toujours émouvant pour moi d’arriver à ce qui semble être la “fin” d’une aventure. Depuis 3 semaines nous avons eu cette journée en point de mire. La construction de cette offre autour d’un logiciel qui fonctionne chaque semaine a été le fil rouge qui m’a guidé dans une foule d’autres activités.

Ce que j’ai aimé dans cette expérience:

  • binômer avec Xavier
  • avoir un fil rouge parmi une foule d’autres activités

Pour que cela soit parfait, faudrait-il que notre prospect décide de poursuivre ou bien est-ce que cela va chercher ailleurs ? Cette idée de “gagner la propale” dans le future rend-elle meilleure l’expérience passée ?

Comme on nous l’a dit souvent, c’est plus l’aventure, le parcours qui nous rend heureux, moins que la destination. Alors je n’ai pas d’idée pour améliorer l’aventure ; le logiciel oui ;)

in Architecture, Développement logiciel

La réussite du Samedi.NET 2011

Samedi le 12 mars 2011 avait lieu le Samedi.NET sur les patterns de présentation organisée par la Communauté .NET de Montréal. Lors de cette conférence d’une journée plus de 100 personnes se sont déplacés pour entendre parler d’architecture. Les 5 conférenciers se sont succéder pour faire de cette journée une réussite.

En introduction, Mario Cardinal et Erik Renaud ont mis la table en mettant en perspective l’importance de prendre les bonnes décisions au bon moment. Il faut retenir que certaines décisions sont parfois irréversibles ou très couteuse à changer plus tard.

Pascal Laurin nous a présenté la base de réflexion de la programmation orienté objet en parlant des 5 principes SOLID. Ces principes sont la fondation des patrons de conception popularisés par plusieurs auteurs dont la fameuse « gang of four ».

Eric de Carufel démontré à l’aide d’exemple de code la façon d’injecter des dépendances pour faciliter les tests unitaires. Il a même profité de l’occasion pour démystifier le concept de conteneur d’inversion de contrôle (genre Unity) avec une implémentation fonctionnelle d’une cinquantaine de lignes de code.

Ensuite Maxime Rouiller nous a introduits au patron de décorateur. Sa métaphore avec le concept des poupées russes a été aussi efficace que le code qu’il a écrit pour nous le démontrer.

Après le dîner, Mario Cardinal nous a démystifiés de patron MVP et ses deux saveurs, la vue passive et le contrôleur superviseur. Comme toujours ses anecdotes ont été très pertinentes pour faire comprendre ce qui arrive quand on ne fait pas attention à ce que l’on fait.

Maxime a suivi avec une version express de sa légendaire présentation sur le patron MVC. Il en connait tellement les recoins qu’il peut la faire sans filet.

Eric nous a ensuite parlé rapidement du patron MVVM introduit et principalement utilisé pour le développement d’application Silverlight et WPF. Encore une fois, il a utilisé les concepts ce de patron pour amener les tests unitaires dans le décor.

Erik Renaud a brillamment conclu la journée avec une comparaison des trois patrons de présentation. Il en a fait ressortir les similarités ainsi que les différences.
Vous pouvez trouver la matériel de cette journée dans la section “Communauté –> Documents” du site de la Communauté .NET Montréal.

in Agile, Développement logiciel, Scrum, Tutoriel

“a working proposal” : semaine 2/3

Deuxième semaine de notre aventure de construction logiciel en parallèle de la mise au point de notre offre de développement. Bien sûr cette semaine s’achève avec une revue d’itération et une rétrospective.

C’est l’occasion pour nous de faire le point sur notre incrément, le produit dans son ensemble, notre compréhension actuelle d’une stratégie incrémentale pertinente pour atteindre les objectifs visés. Pour cela nous nous sommes retrouvés autour du second incrément déployé sur Heroku, autour de notre Product Backlog et de notre propale.

La semaine dernière nous n’avions pas partagé avec notre prospect l’incrément réalisé. Cette semaine c’est différent. Maintenant que nous avons deux incréments, nous avons de quoi démontrer ce que veut dire “construire un logiciel par incréments successifs”. Il se trouve que notre prospect n’a jamais travaillé de cette manière. La semaine dernière nous avions décidé de déployer certes mais sans le lui dire. Notre sentiment était que la notion d’incrément risquait d’être très théorique à ce stade. Maintenant nous avons deux incréments, avec des adresses distinctes. On peut donc voir concrètement l’ajout de fonctionnalités entre les deux versions. Quel sera son feedback ? Suspence…

in Développement logiciel, Scrum

Une belle réussite de Pyxis à CAE Santé

Dernièrement, CAE Santé annonçait le déploiement d’un système de gestion de centre d’entraînement médical avec le CHU Sainte-Justine.

Saviez-vous que Pyxis a collaboré à ce projet?
Pyxis est très fière des résultats de la mise en place de Scrum pour la réalisation de ce projet. Trois collaborateurs ont participé au projet. Marc-André Filion-Pilon occupait le rôle de Scrum Master, veillait à la gestion du projet et agissait à titre de facilitateur. Erik Lebel et Éric de Carufel ont agi à titre de développeurs .NET. Leur expérience a permis d’aider l’équipe dans l’application de pratiques Agiles d’ingénierie logicielle.

Ce que Scrum a permis à l’équipe de CAE Santé
L’emploi de la méthode Scrum pour la réalisation du projet a permis d’atténuer plusieurs risques, notamment en favorisant des cycles courts de développement (sprints de 2 semaines). Ceci a permis la révision en continu des priorités et l’adaptation du processus en fonction des succès et problèmes rencontrés. De plus, nous avons utilisé plusieurs artefacts simples et efficaces de Scrum pour assurer la visibilité relativement à l’avancement du projet (carnet de tâches du sprint et de la livraison, graphiques d’avancement, etc.).

Au niveau des besoins, il était essentiel de les clarifier et de les prioriser conjointement avec le client et les utilisateurs finaux. Le rapprochement avec les utilisateurs et une plus grande implication de leur part ont permis de gérer les attentes tout en assurant une grande transparence.

Défis techniques
Un des plus grands défis d’un projet de développement ayant un délai très court et un important périmètre est de ne pas couper dans la qualité (perçue ou interne). Or, ce risque a été pris en compte en favorisant des déploiements rapides, ce qui a permis de faire des tests et de recevoir du feed-back rapidement. De plus, l’utilisation de patrons et de cadres transversaux dans l’application permet du développement plus rapide, uniforme et fiable.

Bravo à toute l’équipe qui a réalisé ce beau projet!

Voir le système en action

in Développement logiciel, Innovation, Team, Vie @ Pyxis

L’équipe nSemble au codapalooza

La fin de semaine dernière (26-27 novembre), l’équipe nSemble a participé au codapalooza pour développer AgileRoom v1.0. Un peu de café, quelques séances de modélisation Agile,  un objectif à atteindre sous forme de tests automatisés de bout en bout et hop … on est parti pour un 32 heures de développement en se relayant au sein de l’équipe.

À l’aide des technologies comme ASP.NET MVC et Entity Framework 4.0, nous avons réussi à démontrer un premier prototype qui a répondu aux attentes de notre PO malgré la durée relativement courte de l’itération. On se dit à l’année prochaine pour le prochain codapalooza.

in Android, Développement logiciel

Codapalooza – Mes impressions

La première édition de codapalooza est terminée… et après 15 heures de sommeil et deux jours de calmes, je peux enfin donner mes impressions. Pour ce faire voici en gros le déroulement de mes 32 heures de développement.

Vendredi 9h

- Arrivée au bureau, je suis le seul de mon équipe, mais ce n’est pas grave, car ça me laisse le temps de parler aux autres équipes… et déjà la compétition amicale commence entre moi et rankinternationalgirl (mon équipe initiale, que j’ai quittée, car je voulais apprendre android) …

Vendredi 9h14

- Oh non la machine à café est en réparation, comment allons nous faire pour survivre… Je pars au Tim Hortons acheter 20 tasses de café… la madame du Tim n’était pas contente, car il y avait beaucoup de client et je vide toutes ses cruches.

Vendredi 9h45

- Ouverture officielle du codapalooza, le reste de mon équipe arrive et on commence la première activité de création … soit décorer notre salle ou pendant 32heures nous allons coder et s’amuser. Merci à Simon, Monsieur Poteau notre médiateur en cas de conflit prend naissance.

Vendredi 10h15

- On commence à coder et manger des cochonneries. On divise l’équipe en deux pour faire du binôme. Carl Létouneau joue le rôle du professeur, car c’est lui qui a le plus d’expérience avec Android. On commence à coder le Timebox.

Vendredi 12h30

- Même si on n’a pas faim, on se commande de la bonne bouffe grasse pour notre pause.

Vendredi 13h30

- On recommence à coder. Notre mission terminer le Timebox pour pouvoir le mettre sur le market d’Android pour le démo au groupe à 18h30.

Vendredi 18h18

- On génère l’apk avec la clé pour pouvoir mettre l’application sur le market.

Vendredi 18h22

-  On Upload l’apk sur le Market, mais problème on n’a pas rentré le numéro de version et on n’a pas une image 512×512 qui est obligatoire sur le market. On demande à notre maitre graphiste Guillaume de nous fournir une image. On refait l’apk

Vendredi 18h27

- Notre application est sur le market High-Fives de l’équipe on peut respirer.

Vendredi 18h30

- Démonstration de notre application aux autres équipes… Yes, rankinternationalgirl a pas de démo à faire… mais j’ai vu ce qu’ils ont commencé et ça promet d’être vraiment beau.  Apres la demo on se remet a coder.

Vendredi 22h

-  On code toujours, l’équipe du site web codapolooza décide de mettre de la bonne musique, mais voila que l’équipe Pyxis Sosoft viens chialer, car ils ne sont pas capables de se concentrer puisque la musique est trop forte. La guerre entre les vieux et les jeunes commence :) …

Samedi 2h

- Y a personne qui veut aller au Paintball ou go-kart ouvert 24h. Sniff Sniff…

Samedi 9h

- Je suis pu capable c’est l’heure de la power sieste.

Samedi 10h

- C’est le réveille et on recommence a coder.

Samedi 16h

- L’énergie n’y est plus je décide de quitter pour la maison… je roule un peu, mon char fait un drôle de bruit.. ce n’est pas vraiment grave, car il s’agit d’une poubelle. Mais oups voilà que j’ai presque pu de frein. Je tire donc mon brake a bras. Ouf ça brake … Codapalooza coder comme si c’était votre dernière ligne de code, je crois que dans mon cas cela aurait pu être vrai…

En conclusion

Durant deux jours, je me suis vraiment amusé. Je crois que cette activité a permis de renforcer l’esprit d’équipe de Pyxis. Mais aussi dans mon cas, cela m’a donné un regain d’énergie et de passion. J’ai pu apprendre à développer une application Android, mais surtout renforcer mon sentiment d’appartenance à cette merveilleuse compagnie qu’est Pyxis. De plus, ça m’a permis de réaliser qu’il est possible de toujours coder comme si c’est notre dernière ligne de code et ce même dans des moments de stress.

in Développement logiciel

How to change things when change is hard?

That’s the question the Heath brothers address in Switch. I had great expectations before reading the latest book from the authors of best-seller Made to Stick, and man, I was not disappointed. Switch delivers some very solid advice on the subject of change. It’s simple and powerful. It made me wonder why no-one had explained change to me that way before.

Switch presents the change challenge around an analogy borrowed from Jonathan Haidt in his book The Happiness Hypothesis. We have an emotional side, the Elephant, and a rational one, the Rider. Perched on top of the Elephant, the Rider seems to lead the way. But the Rider’s control is an illusion or at best precarious, for when the Elephant decides to go its own way, it easily overpowers the small Rider.

Change efforts often fail for a simple reason: the Rider cannot keep the Elephant on the Path of change long enough to reach the destination. When the Elephant stops moving forward, change fails. I can recall tons of personal examples when this occurred.

For change to occur, we need to appeal to both the Rider and the Elephant and shape the Path. Our Rider is logical, responds well to reason and facts and is useful for long-term planning and direction. Our Elephant looks for short-term gains and instant gratification. We need the Elephant to provide the energy and passion to get things done. If the Rider can keep the Elephant moving down a well prepared Path then there is a good chance for change.

Switch proposes a framework to guide us in situations where we need change to occur. The framework addresses each of the three parts of the change challenge:

  1. Direct the rider

    Provide clear direction to the analytical self, the Rider, to prevent over-thinking and wheel spinning. What looks like change resistance is often lack of clarity.

    Use the following tactics:

    • Find the bright spots

      Focus on the success stories around the change you wish to see; duplicate the things that are working.

    • Script the critical moves

      Make the key steps clear. Describe specific expected behaviors; don’t talk in terms of big picture.

    • Point to the destination

      Describe a compelling purpose and paint an inspiring picture of the future. Change will be easier if people know where they’re going and understand why it’s worth it. People will start thinking about how to make it happen.

  2. Motivate the Elephant

    The Rider will rapidly get exhausted if controlling the Elephant, the emotional side, against its will. For action to take place you need to bring the Elephant onboard. The Elephant might be slow to get going, but once in motion, it goes a long way!

    The tactics are:

    • Find the feeling

      Knowing we need to change is not enough for change to occur. We need to feel something to take action.

    • Shrink the change

      Make the change looks smaller. Big changes feel unattainable and spook the Elephant.

    • Grow your people

      Help people relate to an identity and shift to a growth mindset.

  3.  Shape the Path

    Most change problems are about situations and not people. Instead of trying to change people, change situations to make the process of change easier.

    Use the following tactics:

    • Tweak the environment

      Make the change as easy as possible by changing the situation. Situation changes result in behavior changes.

    • Build habits

      Encourage new habits that reinforce the change. Automatic behaviors do no tax the Rider. Set triggers for change in the environment.

    • Rally the herd

      Use group dynamics to your advantage. Help new behavior spread.

After reading Kotter’s Heart of Change and Bridges’ Managing Transitions, I find that Switch addresses change management in a clear, practical and engaging way. The book is full of stories that illustrate the behavior leaders need to adopt for sucessful change to occur.

If you’re a ScrumMaster in an organisation, I recommend you read the book. It will serve you well. And don’t forget to drop some copies on your high-level managers’ desks.

in Développement logiciel

Are your skills up to date ?

If you are a software developer and are not actively working on improving your skill set, chances are that your skills are already outdated and are part of the legacy world ;-) So, unless you are proud to stay a monkey coder, it’s a pretty smart move to stay aware of the latest trends and the modern engineering principles.

However, what I have noticed while doing technical coaching in various teams is that there are tons of motivated, intelligent developers who just do not upgrade their skills because their environment does not embrace continuous improvement. For these people, it makes a huge difference to bring them a list of important references to read.

The current trend in software development is Agile, which relies on a set of Software Engineering Practices to make a real difference.

At pyxis, we have compiled a set of book references, blogs, twitter accounts, frameworks and libraries that we consider an important part of the Technical Agile landscape. We called it the Agile Expertise Center, and even though some sections are still incomplete (yes, we do apply the release early, release often principle), it provides a good start for anyone interested in :

  • Learning more about the software engineering practices that support iterative and incremental development ;
  • Adopting a Team Skill Acquisition Strategy ;
  • Evaluating how up to date your skills are.

We want this initiative to be useful for everyone :

  • While performing technical coaching, it is of great help when people ask for books and other references
  • It is a foundation to encourage our own employees to learn more about the practices
  • It gives visibility for our clients on what kind of technical help they can expect from us

Oh, and even better, the content is released under the Creative Commons BY-SA 3.0, so do not hesitate to either contact us to add references, or fork the content to create your own expertise center.

in Développement logiciel

Python One Liner

I keep forgetting this simple way to start a HTTP server to serve files from the current directory… Now it’s going to be here for eternity

python -m SimpleHTTPServer

Then point browser to http://localhost:8000

This blog shall become an extension of my brain…

in Agile, Développement logiciel, Scrum, Vie @ Pyxis

De la théorie à la pratique

Cela fait maintenant 4 mois que je travaille à Pyxis et les bancs de l’Université me semblent déjà bien loin. Pas forcément en terme de temps, mais plutôt d’un point de vue pratique.  Lors de mes études en management et communication j’ai trouvé la transition entre la théorie et la pratique évidente et facile mais en ce qui concerne cette transition dans le domaine de l’informatique, c’est une autre paire de manche.

Qu’est ce qu’on nous apprend au département informatique de l’université? Des langages de programmation majoritairement, des mathématiques, de l’algorithmie, des notions de sécurité ainsi qu’une approche du montage vidéo et des outils de DAO. Évidemment c’est un passage obligé et comme la plupart de ces concepts étaient nouveaux pour moi, j’ai pris beaucoup de plaisir à me plonger dans ce milieu qui m’avait toujours attiré. Je buvais donc les paroles des professeurs qui me disait que Java était un langage émergent, que l’abondance de commentaires dans du code était synonyme de qualité et que de prévoir la conception d’un projet sur le long terme évitait les surprises désagréables.

Étape numéro 2 : j’arrive à Pyxis. Tiens, c’est bizarre les gens autour de moi parlent de concepts légèrement opposés à ce que j’ai appris précédemment. “Java? C’est dépassé, trop lourd et pas assez élégant! Oriente toi plutôt vers Ruby, d’ailleurs apprend le on en a besoin pour le store d’Urban Turtle :) “. D’accord, c’est parti pour la programmation artistique alors. “Des commentaires dans ton code? Ca veut dire que ce que tu écris n’est pas clair, epic fail!” Oui c’est vrai en fait, ça parait logique. On va faire des micros classes et fonctions et du code ultra explicite. “Préparer et prévoir des projets sur le long terme? Va falloir que tu t’intéresses de près à Scrum!” En effet, le concept est fascinant. “D’ailleurs le TDD tu connais?” A moins que tu parles de Tranches De Dinde fumées non pas vraiment, mais je vais m’y intéresser!

Actuellement je baigne dans ces nouveaux dogmes, et en apprends tous les jours sur ces sujets passionnants. Notamment grâce aux cours de ScrumMaster et ScrumProfessional Developer offert par Pyxis qui m’ont permis de beaucoup progresser. Néanmoins, appliquer et intégrer tous ces schémas demandent du temps et du travail et il aurait été souhaitable qu’ils fassent partie d’une manière ou d’une autre des formations informatiques proposées à l’Université. Dans un domaine autant versatile que le développement logiciel, je pense qu’il est nécessaire d’adapter les formations proposées à la réalité du marché et que les responsables de programmes devraient se remettre en question régulièrement pour fournir à leurs étudiants un bagage complet correspondant aux attentes des entreprises les plus avant-gardistes comme Pyxis.

Gaël Luisier