SyntaxHighlighter

Showing posts with label Technology. Show all posts
Showing posts with label Technology. Show all posts

2010/12/03

Agile... ou pas

Nous sommes dans une époque où être dans un environnement de développement de logiciel de type "Agile" est un mot magique, comme les expressions "lean manufacturing" ou "just in time" le sont dans le domaine de la production, par exemple. C'est tendance, comme on le dit dans les émissions télé qui transforment un salon grotesque en un salon à la mode mais qui deviendra aussi grotesque dans quelques années.

Être "Agile" est un concept qui met l'emphase sur le fait que le développement de logiciel doit pouvoir s'adapter aux besoins des clients. Ces besoins sont complexes et peuvent parfois mal se déclamer de manière succinte; ils sont clarifiés au fur et à mesure qu'un logiciel se développe, se précise. L'esprit d'équipe est au coeur des méthodes agiles: scrum (inspirée du rugby) et la méthode XP (Extreme programming) entre autres. Tout cela est louable et a prouvé ses mérites. Mais ce n'est qu'un concept cependant...

Dans certains cas, c'est une raison à portée de la main qui vise à justifier le fait que les documents nécessaires dans le contexte de développement logiciel ne sont pas maintenus ou simplement produits.

Par opposition à Agile, il y a la méthode "waterfall" (chute d'eau, en anglais) qui dit que toute la conception, l'analyse, la documentation, doivent être produites avant même de taper la plus solitaire ligne de code. C'est une autre extrême et il y a un juste milieu entre les deux.

Personnellement, j'ai travaillé dans une entreprise qui se réclamait de suivre des méthodes de développement dites Agile. Jamais je n'ai vu une entreprise où la documentation était aussi bâclée. J'ai même eu à consulter de la documentation sur des modules existants lors de mon entrée en fonction dans la compagnie. Plusieurs phrases étaient même incomplètes sur l'un de ces documents, pourtant enregistré comme version officielle dans le système de documentation ISO. Preuve que ce ne sont pas là des gages de qualité...

Par opposition, j'ai travaillé dans une entreprise qui se dit ne pas suivre les méthodes Agiles. Pourquoi? Tout d'abord pour des raisons historiques: cette entreprise a commencé à développer du code il y a environ quinze ans. À ce moment, les méthodes Agiles n'étaient pas tendance.

Ensuite, il y a des contraintes de respect de budget: les clients s'attendent à payer un certain prix, pré-déterminé, pour une modification à du code existant ou des nouvelles fonctionnalités. Pour évaluer convenablement ces coûts, il faut qu'une analyse soit faite au préalable afin de déterminer les embûches potentielles, les implications, les tests à effectuer, la traduction de certaines informations, etc. Mais Être Agile rend cette évaluation plutôt difficile, du moins du point de vue de la première entreprises décrite ci-haut, car

1) on ne peut se fier à documentation existante: on répète les erreurs déjà observées mais dont les solutions sont non-documentées.

2) on néglige l'aspect analyse du travail et on s'engage sur un terrain inconnu.

Notons que la mauvaise documentation peut être compensée par la formation croisée: au lieu de consigner l'information dans des documents, on la consigne dans le savoir collectif. Mais une entreprise qui se dit Agile souhaite réduire ses coûts. Et si elle mets de côté la production de documentation sur le code existant (mettons de côté les documents d'analyse pour l'instant), alors il y a fort à penser que les ressources humaines sont limitées...

Il faut se méfier de méthodes "à la mode"; elles peuvent représenter plusieurs aspects qui sont intéressants mais qui tentent de cacher l'essentiel. Dans le cas présent, il faut produire du logiciel. Le lecteur intrigué pourra lire l'essai de Paul Graham intitulé The Revenge of the Nerds qui parle aussi du problème de langages de programmation qui sont "à la mode".

2009/05/04

When "security" does not mean "security for long"...

According to this article, it seems like WEP secured WiFi networks are not so secure at all... finally.

Most security mechanisms are safe until they are not safe anymore. But for the time being, one should rely on WPA2 for securing a WiFi network. Even more specifically at home.

I remember commuting by train with a laptop on my knees, trying to fix a bug in my source code. I did not notice but found my WiFi antenna was on. I was impressed to see so many WiFi networks popping-up on my radar screen as the train was rolling towards downtown. I would say about 50% of the networks were not secured at all.

Later on, I will try to tell more about this, even if I am not a network specialist. But for now, I just wanted to point this out.

Be told.

- Eric

2009/04/14

Are the cell phones comany asking for too much?

Accidentally, when looking for a contact at Verizon for a satellite dish that would enable me to download weather data, I've found a strange article.

A former Verizon representative was somehow frustrated of his old job, probably due to too much pression, and met a journalist for telling how to get more from a cell phone company, namely Verizon Wireless.

This company does not run any business in province of Quebec (Canada) but, still, this is more-than-interesting.

Follow this link: http://consumerist.com/consumer/verizon/8-confessions-of-a-former-verizon-sales-rep-241665.php

Enjoy!