Ahah, si vous lisez ce post, c’est que la fibre optique vous titille. Vous hésitez, vous recherchez des informations pour sauter le pas. Et vous faites bien de lire cet article.

Alors venons en vite au fait.

Je venais juste de m’installer sur la région de Lille et j’avais choisi Free en ADSL, un bon opérateur qui m’a malheureusement servi du 4 Mbits/s, car je me trouvais en bout de ligne donc avec pas mal de perte. J’avais donc le choix entre surfer sur Internet, regarder la télé en bas débit ou enregistrer une émission. Choix difficile, voire cruel.

J’ai cherché un peu ce que je pouvais faire pour améliorer tout ca, mais un concurrent toujours dans l’ADSL ne m’aurait rien apporté de plus.

Il y avait bien Numéricable, mais avec sa réputation, visiblement toujours de vigueur, je ne voulais pas payer plus pour ne plus rien avoir. Petite anecdote : Je vais dans une boutique Numéricable et j’attends avec 4 clients mécontents devant moi (pas bon) et un vendeur absolument pas motivé, qui donne des renseignements différents de ceux donnés par téléphone. Et pas de décodeur en stock. Ca ne donne vraiment pas envie.

Mais 4Mbits/s, je ne pouvais pas rester sans rien faire. Et en cherchant, j’ai vu que Darty proposait le THD avec sa DartyBox.

Contacter Darty par téléphone

Alors j’appelle Darty un vendredi soir sur un numéro au tarif local, c’est raisonnable. Et là on me dit, faut prendre RDV pour avoir des infos sur les offres DartyBox. Je me dis bizarre, mais pourquoi pas. Alors je donne mon tel et je leur demande de me rappeler le lendemain. Et le lendemain (samedi donc), pas d’appel. Dommage. Bon, motivé, je rappelle et je tombe sur une charmante opératrice du maghreb qui ne comprend pas vraiment pourquoi je devais prendre RDV, mais on ne cherche pas. Je lance donc mon inscription, même si je ne sais pas vraiment quel sera mon débit réel, 30Mb/s ou 100Mb/s. Je me dis que même 30, c’est déjà pas mal. L’inscription se fait assez rapidement avec une confirmation par email. Je dois récupérer ma DartyBox à mon Darty le plus proche le lundi, pas de souci. Et avec résiliation Free automatique, que demande le peuple…?

Récupérer sa DartyBox

Le lundi, je vais à mon magasin et je dis que je viens prendre ma DartyBox. On me regarde avec de gros yeux, comme si c’était la première fois que quelqu’un venait pour prendre ce type de matériel. C’est récent certes, mais quand même.

Je donne donc ma référence et on essaie de chercher mon contrat, mais ca n’a pas l’air de fonctionner comme il faut. Mon vendeur décide donc d’annuler le premier contrat et d’en refaire un. Pourquoi pas, si je peux avoir mon THD. Une heure quand même pour tout faire, plus que par téléphone, mais ce n’est pas grave, je sors avec mes boites et j’ai une date pour l’installation gratos.

L’installation

Le vendredi, donc, pour cause de dispo perso, l’installateur vient et fait son travail, nickel. J’ai donc le THD. Excellent.

Voici maintenant 15 jours que j’ai le THD et je ne regrette pas son choix. Cependant…

Sur le long terme

Je n’ai “que” du 30 Mbits/s, qui avec les différents tests faits sur Internet s’avère plus proche de 15 MBits/s, voire 12MBits/s. C’est bien, mais bien loin de la réalité.

En appelant Darty, on comprend que les débits qui sont vendus ne sont jamais ceux que vous aurez réellement. En effet, 4 à 7 MBits/s sont utilisés pour gérer le réseau (ce qui permet par la même occasion à Darty de suivre votre consommation, quantité de download/upload, connexion…). J’espère quand même que tout n’est pas tracé, mais ca commence à faire peur…

Et surtout on essaie de vous expliquer que vous ne partagez pas vos 30Mbits/s avec vos voisins, mais que si ceux-ci utilisent beaucoup Internet, ca a quand même un impact pour vous. Ah c’est dommage quand même.

Alors quel est mon conseil ?

• Si vous avez Internet par ADSL et que vous êtes près du DSLAM, soit dans les 16Mbits/s de download, allez sur le site de Numéricable et voyez si la fibre qu’il propose est à 30 ou 100 Mbits/s. Darty utilisant leur réseau, vous saurez à l’avance quel sera le votre. S’il s’agit de 30Mbits, ne passez pas à la fibre, ca ne vous apportera rien sauf si vous n’êtes pas satisfait de votre FAI actuel, bien sur.

• Si vous êtes loin du DSLAM, avec des réseaux bas, genre 4 à 7 Mbits, jetez-vous sur l’offre Darty (allez sur le site de Numéricable, si vous voulez connaitre votre futur débit).

Quid des autres services ?

• Pour le téléphone, rien à dire de particulier. Ca marche, c’est de bonne qualité.

• Pour la télévision, de la HD de bonne qualité, moins de chaines que sur l’ADSL, mais ce ne sont que des chaines que je ne regardais pas de toute facon. Cependant un guide des programmes vraiment très très (très) mal pensé. Et j’insiste sur ce point. L’interface est jolie mais absolument pas pratique, tout le contraire de celle de Free, très moche mais très facile pour surfer d’une chaine à l’autre ou d’une journée à l’autre.

Les faux prix

S’il y a bien un truc qui me fait marrer, mais qui devrait plutôt me faire pleurer, c’est les prix affichés. On vous annonce des tarifs à 29,90€/mois. Sauf que le décodeur est obligatoire à louer tous les mois pour 5 € et le modem est lui aussi obligatoire pour 3 €. Donc de 29,90€/mois on passe à 37,90€/mois. Si c’est pas de la publicité mensongère ca… M’enfin tous les concurrents sont à peu près pareils, c’est de bonne guerre.

Conclusion

Darty est très compétent dans les services, tant le conseil, les contrats, l’installation que le support, un peu moins dans la maitrise de son réseau (qui n’est pas le sien d’ailleurs) et c’est dommage.

Astuce

Si vous arrivez à prouver que votre débit est à 50% de sa valeur vendue, <15MBits/s au lieu de 30MBits/s, alors c’est possible qu’ils interviennent, mais ca reste à prouver. Je vais tenter l’expérience. Qui ne tente rien n’a rien.

L’heure du tout numérique est arrivée !

Les utilisateurs d’Internet, presque 30 millions en France, sont habitués à gérer des fichiers numériques, que ce soit de simples documents, des photos ou des vidéos. Ceux-ci gèrent leur recherche d’informations, achètent, vendent, louent, réservent, payent.

Les entreprise en avance

Les entreprises, elles, fonctionnent maintenant surtout avec Internet, elles communiquent avec les emails, les calendriers, les pièces jointes et la téléphonie IP en interne et avec leur site Web en externe. Bien souvent, même si ceci se caractérise principalement chez les plus grosses d’entre elles ou les plus baignées dans le contexte d’Internet, elles ont déjà commencé à dématérialiser. Les recherches de postes, la gestion des congés, les achats de transport, les conférences, les formations, la gestion des heures facturées… Certaines ont même déjà dématérialisé les salaires, factures et/ou contrats.

L’état fait bonne figure

L’état lui-même, bien souvent en retard dans les grandes transitions, s’est mis à l’heure du numérique. Car en effet, il y a vu tout son intérêt. Une disponibilité 24/7 de l’information et du service, une baisse des besoins en personnel, une plus grande rapidité de gestion et une baisse des coûts non négligeable. Ainsi tout un chacun peut maintenant communiquer avec l’état via email, s’informer sur l’ensemble des sites Internet proposés pour des horaires, des conseils, des procédures, des formulaires… Nous pouvons payer en ligne, réclamer, déclarer…

Le citoyen, maillon faible ?

Dans toute cette chaine numérique, il reste cependant un maillon faible, le citoyen, qui n’est pour l’instant qu’à la marge du numérique et qui ne le suit que parce qu’il y est poussé par les sociétés et l’état. Mais tout ceci doit changer, tout ceci va changer.

Citoyen, il te faut maintenant passer à l’heure du numérique dans son intégralité. Préférez les documents numériques aux documents papier, que ce soit pour vos factures, pour vos salaires, pour vos contrats, pour vos déclarations.

Prenez l’ensemble de vos documents importants existants et utilisez l’une des nombreuses super imprimantes 4 en 1, qui va vous permettre de tout numériser en un clic de bouton.

Ensuite, triez, classez, sauvegardez et archivez vos documents pour vous en servir le jour où vous en aurez besoin. Mais faites attention, certains documents peuvent être sensibles, ne les égarez pas.

Liste de documents importants

Dans cette revue de documents, nous pouvons citer :

• Les factures : Telecom, Electricité, Gaz, services à la personne, gros paiements (voiture, maison)…
• Les documents personnels : Carte d’identité, Passeport, Permis de conduire, Carte Vitale…
• Les bulletins de salaire,
• Les actes notarials,
• Les documents émanants de l’état.

Comment gérer cette masse de données ?

Avec une masse d’informations si importante, il va falloir apprendre à tout gérer, selon certaines contraintes :

• Une sécurisation optimale des données : pour ne pas les fournir au premier inconnu qui passe, mais également pour ne pas les perdre,
• Un acces à tout instant de partout : car c’est également l’objectif de la dématérialisation,
• Une mise à jour rapide et facile : car de nouveaux documents et besoins apparaissent chaque jour.

Internet ou clé USB ?

Si la clé USB possède des avantages non négligeables, elle a un gros inconvenient, elle a de grosses probabilites d’être perdue ou cassée. Ce qui peut s’avérer catastrophique.

Concernant Internet, il va vous falloir un site répondant à toutes les contraintes et ici la sécurite peut restreindre l’utilisation d’un grand nombre de sites. Il vous faut un gros espace de stockage, environ 1 Go, voire un peu plus (et peut-être beaucoup plus dans 5 ans). Un espace facile d’accès mais bien sécurisé, une sorte de coffre-fort, et surtout simple d’utilisation pour l’ajout de nouveaux documents. Et c’est ici que nous retrouvons les entreprises et plus particulierement les banques, qui ont déjà réfléchi à la question et qui commencent à proposer leurs offres.

Un coffre-fort numérique

Puisqu’elles savent que vous avez ce type de besoin (elles l’ont également) et que vous avez un accès Internet vers votre compte en ligne, celles-ci proposent des coffres-forts numériques pour y stocker toutes vos données. Un moyen simple et peu coûteux (pour elles) d’engranger plus d’argent en élargissant un peu leur business.

Vous pourrez ainsi, de partout dans le monde, récupérer une photocopie de votre passeport ou de votre permis de conduire si vous l’avez perdu (ce qui n’est pas une preuve suffisante, mais peu vous aider dans de nombreux cas). Vous pourrez aussi envoyer une copie de votre diplôme a votre nouvel employeur, même si vous êtes au bord de la plage pour les vacances.

Notre vie numérique n’est qu’à son commencement, préparez-vous à entrer dans un autre monde.

Voici quelques astuces pour La Fonera 2, qui seront utiles à toutes personnes souhaitant profiter au mieux de sa petite boite blanche.

Changer le mot de passe pour activer les services d’accès

La Fonera 2 contient un petit bug peu connu qui ne permet pas d’activer les services tels le WebGUI ou le FTP vers l’extérieur si le mot de passe ne contient pas 8 caractères dont un chiffre. Changer le mot de passe pour suivre ces recommandations et rebooter la Fonera 2. Si vous avez deja activé les services en question, désactivez-les, validez et réactivez. Ceux-ci devraient alors être disponible de l’extérieur.

Passer en mode développeur pour obtenir la connexion SSH

Si vous souhaitez accéder via SSH à votre Fonera 2, vous devez impérativement passer en mode développeur, présent sur la page plugin du dashboard. Votre interface Fonera 2 passera alors en vert. Vous pourrez même fournir un accès SSH depuis l’extérieur a votre Fonera 2. A utiliser avec précaution. L’accès se fait avec le compte ‘root’ et votre mot de passe d’administration.

Interface Fonera 2 en mode developpeur

Accéder aux fichiers via un réseau partagé avec Vista

Vista a changé son implementation de Samba pour accéder aux fichiers via un réseau partagé. A cause d’un petit bug, celui-ci n’est plus disponible directement. Vous devez modifier la clé de registre suivante pour y accéder.

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel = 3 -> passez sa valeur a 0, le deblocage devrait être immediat. J’ai le même souci sous XP, mais cette astuce ne fonctionne pas. Si l’un de vous a plus d’info, qu’il m’en fasse part dans les commentaires. Je tiens mes infos de cette page.

Plugin Firefox pour ajouter des torrents et fichiers RapidShare/MegaUpload

L’équipe de la Fonera 2 a développé un petit plugin qui permet d’envoyer les torrents et fichiers RapidShare/MegaUpload en téléchargement sur sa Fonera 2 en un clic. Je vous le conseille fortement. C’est particulièrement utile.

• FoneraDownloader (ne fonctionne qu’avec le firmware 2.2.6 de la Fonera, une mise à jour est nécessaire)

Plugin Firefox pour Fonera 2

Liens à suivre pour tout connaitre de La Fonera 2

• Le blog Fon officiel en anglais
• Le blog Fon officiel en francais
• Le blog du principal développeur de la Fonera 2 en anglais
• Le forum Fon sur la Fonera

Logo FonShare

Retrouvez également sur CodePlex le projet FonShare, qui permet de partager des fichiers via FTP sur des groupes de Fonera 2 en toute sécurité.

I created the Killer App to share and download files in private networks.

FonShare : Cloud Downloading

Cloud Concept of groups between servers

Please find all about this project in my project Web Site on CodePlex.

• FonShare on CodePlex

Il y a quelques temps, j’avais posté un article sur l’arme ultime anti-Hadopi.

Apres mûre réflexion, j’ai abouti a un concept qui commence à prendre forme et qui devrait concrétiser les dires de mon précédent post.

Pour marier téléchargements privés et réseaux sociaux, il faut impérativement un serveur personnel fournissant du contenu. Un serveur FTP fait parfaitement l’affaire mais la fonera 2 semble être l’outil idéal pour valider le concept.

• Prenez donc une fonera 2, branchez un disque dur et fournissez quelques fichiers a votre serveur FTP accessible sur le web.

• Inscrivez-vous au service FonShare (pas encore déployé, prenez patience) et remplissez les informations concernant votre fonera.

• Créez un groupe ou rejoignez un groupe existant.

• Visualisez les fichiers de ce groupe et choisissez ceux que vous souhaitez télécharger,

• Patientez pendant le téléchargement entre les foneras, puis profitez de vos nouveaux fichiers téléchargés.

• Partagez avec vos autres groupes les nouveaux fichiers téléchargés.

Voici quelques schémas décrivant les détails techniques du projet.

Cloud Concept of groups between servers

Le service FonShare permet de créer des groupes de serveurs et de partager les fichiers entre ces serveurs.

File Sharing Concept between groups

Ainsi comme on le voit sur le schéma précédent, l’utilisateur de la Fonera 1, par l’intermédiaire du service FonShare,  a accès à l’ensemble des  fichiers des serveurs des groupes 1 et 2. Soit dans  l’exemple, 6 serveurs.

File Download Concept from one server to another one

Lorsque l’utilisateur souhaite télécharger un fichier, il sélectionne le dit fichier a partir du service FonShare et lance le téléchargement. FonShare envoie une commande FTP aux 2 serveurs. Le premier pour envoyer le fichier au deuxième serveur, le second pour le recevoir. Le fichier transite alors d’une fonera à une autre, il n’y a aucun intermédiaire.

File Transfer Concept between servers

Ainsi un fichier transite d’un serveur privé à un autre, uniquement par des connexions privés, point a point. En fonction du nombre de groupes, du nombre d’utilisateurs dans chaque groupe et du nombre de fichiers sur chaque serveur, un utilisateur peut avoir accès à un très grand nombre de fichiers.

Prenons maintenant une hypothèse. Vous êtes utilisateur de FonShare et vous avez rejoint 3 groupes de 4 personnes en moyenne,  chacun mettant environ 50 Gigaoctets de données en partage. Vous avez alors un accès direct à une base de 3 x 4 x 50 Go de fichiers, soit quelques 600 Go tout de même. Rejoignez un groupe plus important et vous démultipliez la quantité de données accessibles.

Points positifs du service :

• Connexion privée entre 2 serveurs, non visible de l’extérieur,
• Les fichiers résident uniquement sur les serveurs personnels et ne sont transférés qu’entre les serveurs,
• Les utilisateurs d’un groupe ne connaissent pas les informations de connexion des serveurs personnels des autres membres du groupe et n’ont aucun moyen de les connaitre,
• Les accès aux autres serveurs personnels sont en lecture seulement, l’écriture est disponible uniquement sur son propre serveur,
• Les transferts entre serveurs ftp sont rapides. Un fichier de 700 Mo est théoriquement transférables en moins de 2 heures à 100 Ko/s, moins de 25 minutes à 500 Ko / s.
• Vous pouvez à tout instant rajouté un groupe ou supprimé un groupe.
• Pas de trace.

Points negatifs :

• Les transferts sont limités à la capacité d’upload des utilisateurs,
• Le système est encore assez technique et ne peut pas etre utilisé par le quidam moyen,
• Il faut avoir des amis et des amis de confiance,
• Il faut des sources extérieures pour alimenter les serveurs personnels.

Les Web Services REST avec le format JSON sont devenus en peu de temps un nouveau moyen d’implémenter des Web Services de manière simple (sans formatage XML et parsing) et orientés données.

Si la procédure de création de Web Services RPC ou REST et SOAP ou JSON en .Net est simplifiée grâce à WCF, et que l’appel d’un Web Service RPC/SOAP est quasi transparent pour le développeur, il n’en est pas de même pour la création du client en REST/JSON.

Ce petit post va vous permettre de mettre en place rapidement un client Web Service .NET avec REST/JSON. Je fais l’impasse sur l’implémentation serveur, je vous laisse vous référer aux différents liens placés en fin de billet.

• Ajoutez une référence a votre Web Service dans votre projet VS et pointez sur votre URL de type : www.monsite.com/monservice.svc
  • Cet étape va générer votre client Web Service, mais surtout ce qui nous intéresse, les objets en transit,
• Ajoutez JSON.NET dans votre projet afin de déserialiser vos données automatiquement,
• Implémentez le code suivant :

Uri requestUri = new Uri("www.monsite.com/monservice.svc/users/5474");
WebRequest webRequest = WebRequest.Create(requestUri);
WebResponse webResponse = webRequest.GetResponse();
Stream response = webResponse.GetResponseStream();
StreamReader reader = new StreamReader(response);
Newtonsoft.Json.JsonSerializer jsonSer = new Newtonsoft.Json.JsonSerializer();
MyUser user = (MyUser) jsonSer.Deserialize(reader, typeof(MyUser));

• Vous obtenez ainsi votre objet côté client, il ne vous reste plus qu’à en faire bon usage,
• Vous pouvez également récuperer une liste ou un tableau d’objets avec le code suivant :

List<MyUser> usersList = (List<MyUser>)jsonSer.Deserialize(reader, typeof(List<MyUser>));

Je vous conseille fortement de créer une méthode générique avec 3 parametres (URL, type de résultat et résultat) afin de pouvoir réutiliser ce code a loisirs.

• REST sur Wikipedia,
• Introduction à REST avec WCF sur MSDN,
• Introduction à JSON sur Wikipedia,
• Construire un Web Service REST/JSON avec WCF,
• Projet JSON.NET sur CodePlex.

Update : Vous avez également la possibilité de ne pas utiliser JSON.NET avec le Serializer intégré dans .Net 3.5

DataContractJsonSerializer jsonSer = new DataContractJsonSerializer(typeof(List<MyUser>));
List<MyUser> usersList = (List<MyUser>)jsonSer.ReadObject(response);

Après quelques tests, il semblerait que le parser de MS soit le plus rapide. Cependant cette page semble donner plus d’informations concrètes :

• Performance entre DataContractJsonSerializer et JSON.NET (en)

pas une destination.

C’est par ces mots que se termine la conférence Qualité du code source et l’intégration continue des collaborateurs de Xebia. Il est bon de rappeler que la qualité ne peut pas être quelque chose qui s’enclenche en un geste, ni même qu’elle se termine.

Au cours de ma carrière, j’ai souvent été surpris par le peu de qualité fournie sur les projets, tant au niveau du code source que de la documentation. Et ne parlons pas des tests ou de l’intégration continue, concepts encore trop souvent inconnus chez certains éditeurs.

Mais instaurer la qualité sur un projet existant ou dans une société n’est pas chose aisée. Xebia le détaille d’ailleurs très bien sur les dernières diapositives de son exposé.

Pour ma part, je dirais que la plus grosse difficulté n’est pas sur la technique, puisque qu’après tout, si d’autres sociétés le font, tout le monde peut le faire, mais sur les individus et la motivation.

En effet, si les participants au changement ne connaissent pas ces pratiques, ils peuvent douter de leurs biens fondés, de la facilité de mise en place, des gains de productivité et qualité et de l’impact direct sur leur travail.

Imaginez, vous demandez à des développeurs, souvent en place depuis plusieurs années de :

• changer leur façon de développer, cela pourrait laisser penser qu’ils ne savent pas développer,
• écrire des tests unitaires et d’intégration, ce qui va leur demander plus de temps, et donc faire baisser leur productivité,
• suivre leur projet sur un serveur d’intégration et corriger toute erreur en priorité si le cas se présente, ce qui signifie que corriger un serveur de build est plus important qu’une fonctionnalité métier,

Il est clair que si l’on évoque ces trois points, la qualité du code source et l’intégration continue ne semblent pas apporter de productivité aux développements, bien au contraire.

Mais lorsqu’on connait les 3 points suivants, les premiers commentaires semblent bien négligeables, face aux avantages accumulés :

• Un développeur passe 80% de son temps à lire du code et 20% à en écrire, il a donc tout intérêt à avoir un code lisible et rapidement compréhensible, pour diminuer son temps de lecture et augmenter son temps d’écriture,
• Les tests permettent d’être informé de la moindre régression dans le code et de modifier à loisirs et sans doute du code existant afin de l’améliorer,
• Le serveur de build informe, en temps quasi-réel, de l’état du projet et des tests pour l’ensemble des acteurs du projet, afin de corriger une erreur au plus tôt et de ne pas attendre d’être en production pour corriger une faille passée au travers des tests métiers,

Pour une société qui ne maitrise aucun des points cités précédemment, les gains de productivité peuvent atteindre 300%, voire plus si le code est réellement catastrophique ou si l’intégration de nouveaux développeurs est importante. Vous me direz alors, 300%, c’est énorme. En fait à y réfléchir, ces 300% ne sont pas très important, c’est principalement la productivité de départ qui est très faible. Car bien souvent, si vous n’avez pas de qualité du source code ou d’intégration continue, vous empilez les bugs, vous multipliez les copier-coller de peur de modifier l’existant, vous passez votre temps à lire et vérifier une implémentation…

Mais rappelez-vous, pour mettre en place les bons process de développements, le plus important n’est pas la technique, c’est l’accompagnement au changement. Soyez sur d’avoir les bonnes personnes pour vous aider.

• How TDD and Pairing Increase Production

Et oui, encore 2 petits plugin firefox. Enfin pas tout à fait. Le premier est un plugin firefox, le second un script greasemonkey. Dans tous les cas cependant, il vous faudra firefox.

Greasefire : Découvrez les scripts GreaseMonkey

Greasefire est un plugin firefox qui permet au fil des sites sur lesquels vous surfez, de vous informer des scripts disponibles pour ceux-ci. Vous pouvez donc surfer normalement et si le site sur lequel vous vous trouvez permet d’utiliser des scripts GreaseMonkey, greasefire vous l’indiquera et vous fournira directement dans Firefox une petite interface pour découvrir le script et l’installer. Un must lorsqu’on souhaite personnaliser son surf.

Affichage des scripts disponibles sur le site courant

Google Fx : Personnaliser votre recherche Google

Google Fx quant à lui est un script GreaseMonkey, qui vous permet de personnaliser la page de résultat Google afin d’afficher plus que la simple recherche de site proposée par Google. Vous y retrouverez Wikipedia, Google Images, Google Video, des liens vers d’autres moteurs de recherche, triés par catégorie, filtrable sur le titre, le contenu, la date… Un vrai bonheur pour celui qui souhaite voir organiser ses résultats. Mais attention cependant, ce petit script ralentira légèrement l’affichage des résultats. C’est perceptible mais pas réellement gênant.

Affichage de la page de résultat Google avec le script Google Fx

Pour la forme, je vous rappelle mes propres scripts GreaseMonkey :

• Netvibes SubTab : pour ajouter des subtabs à Netvibes,

• LinkYourViadeoContact : pour afficher vos contacts sans abonnement premium,

Il y a un très bon article dans le magazine Programmez du mois de Juin 2009 qui décrit Scrum, XP et la journée d’un développeur agile.

Formé à l’ancienne sur des méthodes de cycle en V, et ayant appliqué XP de manière intensive, j’étais dubitatif mais enthousiaste et intéressé par les nouvelles méthodes agiles, Scrum plus particulièrement. Je ne pensais cependant pas que la nature des concepts était si révolutionnaire que cela.

Pratiquant Scrum depuis maintenant 6 mois dans ma nouvelle entreprise, je dois dire que l’ensemble de mes concepts a été remis à zéro, sur de nouvelles bases, et de nouvelles méthodes. Et après ces 6 mois, je peux dire que mon opinion est faite. Scrum est une des meilleures méthodes de développement logiciel actuelles. Il était temps que l’informatique innove pour s’améliorer. Maintenant les entreprises vont devoir intégrer les méthodes, c’est un point plus difficile.

Mais revenons au titre de mon sujet. A qui profite l’agilité ?

Vraisemblablement, pour Programmez, la personne bénéficiaire est le développeur, et puisqu’il est plus productif, par conséquent, son employeur l’est également. Mais commençons avec le développeur.

Le développeur

Par un développement progressif, auxquels se succèdent tests unitaires, tests d’intégration et couverture de code, puis compilation sur un serveur de référence, le développeur gagne en retour, positif ou négatif, sur son travail. Il est alors mieux à même de connaître les impacts de ses nouveaux développements sur le code existant. Il est plus sûr de lui, plus confiant et donc plus à même de modifier, d’améliorer et progresser dans son travail. Le gain de productivité est très important. Avec la démonstration de son travail à la fin de chaque itération, les progrès sont concrets et perceptibles immédiatement par le métier, une relation de confiance s’instaure, la compréhension des partenaires métier et technique s’intensifie. La qualité des développement s’améliore.

L’architecte

L’architecte n’ayant “qu’à” dessiner les bases de l’application sur des besoins réels immédiats, en préservant tout de même des choix en cas de modifications ou d’améliorations importantes, il évite un travail d’approfondissement contraignant, souvent inutile et trop abstrait, et couteux en temps. Cette agilité lui permet donc de s’économiser pour travailler sur des tâches réellement importantes et à retour sur investissement court. Il gagne beaucoup en productivité. Le logiciel perd en complexité inutile et préméditée.

Le chef de projet

Il est difficile de définir un chef de projet en utilisant des méthodes agiles comme Scrum. On peut le confondre avec un ScrumMaster et/ou un chef d’équipe. Il peut également être assimilé à l’architecte. Cependant en faisant interagir les membres de son équipe comme un tout, directement avec le métier, la transmission de la connaissance et la fluidité de la communication lui permettent de diminuer les risques d’erreur ou d’incompréhension métier et/ou technique. Toutes questions étant posées lors des réunions quotidiennes et/ou lors des réunions de planning. Les temps morts, retours en arrière, frustation sont diminués, l’équipe gagne en productivité et connaissance métier, le chef de projet gagne en sérénité.

Le chef de produit

Celui-ci s’exprime directement avec les développeurs lors des plannings et démonstrations. Il est a même d’expliquer ce qu’il attend, ce qui va et ce qui ne va pas dans ce qui a été produit. Il fournit ainsi un dialogue direct qui permet aux développeurs de comprendre plus facilement ce qui doit être fait et comment. Avec des déploiement fréquent, il reçoit également son logiciel dans des délais plus courts et en fonction de besoins réels immédiat. Son équipe gagne en productivité, par l’utilisation de fonctions développées en priorité, selon ses propres recommandations. Il gère mieux son travail, celui de son équipe et le futur de son organisation. La productivité métier est accrue.

Les décideurs

Le premier objectif des décideurs dans l’application des méthodes agiles est d’augmenter la productivité des développeurs pour que ceux-ci augmentent la productivité du métier, et afin que ces derniers augmentent le chiffre d’affaire et surtout le bénéfice de l’entreprise. Si la productivité des développeurs est assurée, celle du métier sera alors encore plus importante, le pari est donc gagné.

Mais revenons sur le terme de l’agilité. Le fait que le retour sur investissement (ROI) avec les méthodes agiles soit court, 2 à 3 semaines, va permettre aux décideurs de pouvoir décider (c’est leur métier après tout) et faire appliquer leur décision sur des cycles plus courts, vraisemblablement une à deux itérations. Ils pourront ainsi s’adapter plus rapidement aux marchés et emprunter des chemins aujourd’hui impossibles sur des méthodes traditionnelles, type cycle en V.

Reprenons le schéma que j’avais fourni lors d’un précédent post : Scrum : De l’intérêt des méthodes agiles

Comparaison des coûts de production et productivité entre Scrum et méthode standard

Ce schéma montre les coûts de production logiciel et la productivité du métier.

Dans le cas de développement avec la méthode de cycle en V (ligne verte), le décideur n’a d’autres choix que d’attendre le déploiement du logiciel en production avant de placer ses équipes sur un autre développement, plus stratégique (sauf à retirer quelques ressources, mais en impactant le planning de déploiement de son logiciel en cours).

Avec les méthodes agiles, le métier est plus productif dès la seconde itération (ligne rouge). Si le décideur choisit d’interrompre les développements logiciels, il peut le faire, premier point, mais il peut également calculer le gap entre la productivité actuelle et maximum du métier avec les développements restants et choisir de réorienter une partie ou l’ensemble de son équipe sur des points plus stratégiques.

En définitive, s’il est un acteur de l’entreprise qui gagne en agilité avec les méthodes agiles, c’est le décideur. Des décisions en connaissance de cause, moins pénalisante, plus stratégique, plus rapide et plus efficace.

L’agilité est aux décideurs. A eux de faire les bons choix.

J’ai lu dernièrement un article très intéressant parlant de la dette technique d’une application sur le blog de Claude Aubry :

• Dette technique, nique nique,

• Symptômes de la dette technique,

Ces deux liens donnent une définition plutôt claire de la dette technique et des moyens de la reconnaitre.

Je me permets cependant de compléter ces articles, puisque je suis actuellement dans un cas similaire où j’ai pour mission d’améliorer la qualité et la productivité d’un projet qui supporte une dette technique particulièrement importante.

S’il y a dette technique sur un projet, l’équipe projet ne sera pas à même de la reconnaitre, sinon celle-ci n’aurait pas de dette technique (ou alors minime) à moins d’avoir un éclair de génie et de se dire, “Mais nous avons une grosse dette technique !!!”. Sur le projet que j’encadre actuellement, les développeurs n’ont absolument aucune conscience de la mauvaise qualité des développements et considèrent que les difficultés qu’ils rencontrent sont essentiellement dû à l’environnement particulier de développement (du javascript sur un serveur NetSuite). Le code n’est pas formaté, n’a aucune convention de nommage, ne réutilise pas ces composants, et pire les développeurs font du copier-coller de code à outrance, car ils ne veulent pas casser du code existant de peur d’engendrer des bugs en série. Et bien évidemment, ils ne connaissent pas les tests unitaires et d’intégration. Dans ces conditions, comment voulez-vous que cette équipe soit à même de reconnaitre la dette technique de son projet ?

Capacité à voir la dette technique

Pour reconnaitre la dette technique d’un projet, il est nécessaire de faire appel à une personne extérieure au projet. Cette personne peut être de la même entreprise, mais si tous les projets sont fondés sur les mêmes principes (pas de formatage, pas de convention de nommage, pas de réutilisation de code et pas de tests unitaires), alors il est préférable de faire appel à une personne extérieure, nouvellement embauchée ou intervenant extérieur.

Cette personne devra avoir les capacités techniques et fonctionnelles nécessaires à l’acquisition des bases d’un projet mal ficelé (autant dire de très bonnes compétences) et comprendre ce qui a amené les développeurs à se retrouver dans une telle situation. Compétences et/ou connaissances techniques insuffisantes, pression du business pour avancer toujours plus vite sans réfléchir sur ses actes pour réorganiser le projet au fur et à mesure de son accroissement… Cette personne devra également avoir de gros talents de persuasion et de négociation pour que les développeurs eux-mêmes reconnaissent que quelque chose doit être fait. En effet une personne extérieure au projet et plus spécialement extérieure à l’entreprise aura toujours plus de mal à convaincre, surtout si elle doit faire les preuves de ses capacités.

Mais le plus important n’est pas de reconnaitre cette dette technique, de la faire reconnaitre aux développeurs ou de trouver une solution afin de la réduire.

Volonté à réduire la dette technique

En effet, une fois les premiers acteurs du projet acquis, il va vous falloir convaincre les décideurs, c’est à dire le métier, qu’il y a une grosse dette technique (qu’ils n’ont jamais vu d’ailleurs) que celle-ci est pénalisante pour le projet et que réduire cette dette technique va permettre d’accroitre la productivité par 2 voire 3 fois.

Mais surtout il va falloir leur expliquer que pour combler cette dette technique, vous allez devoir pénaliser la production pendant une période plus ou moins courte (3 mois dans mon cas, mais la dette technique est vraiment très importante) afin de mettre en place un process de développement et/ou une architecture digne de ce nom. Et c’est sur ce dernier point que vous allez rencontrer les plus grosses difficultés.

Rien ne garantit en effet que vous aurez les gains de productivité attendus, qui paraissent tout de même extraordinaire. Le business est bien évidemment dans une phase critique et réduire les développements est inimaginable. Alors vous allez expliquer et négocier, mais si le business a réellement besoin de ces développements, vous pouvez être sur que le planning de votre refactoring va s’allonger dans le temps ou être décalé jusqu’à des temps plus sereins (ce qui d’après mon expérience existe rarement).

Bonne chance pour réussir sur ce dernier point.

PS : La décision de mon example sera prise dans les jours prochains, nous verrons ce qu’en aura décidé le business. (Je crains le pire).

L’architecture et la gestion de projet informatique ont en commun de prendre tous les blâmes lorsqu’un projet ou une architecture échoue et de partager le succès avec l’ensemble de l’équipe lorsqu’ils réussissent. Si ceci est vrai pour beaucoup de métiers, cette réalité doit bien nous rappeler à quel point nous sommes tributaires d’une équipe et que nous en faisons donc partie.

J’ai eu l’occasion il y a quelques mois de parcourir quelques vérités sur le métier d’architecte dont je me permets de retranscrire quelques pages. Réfléchissez sur ces quelques points.

Lorsque vous travaillez sur une architecture :

Ne placez votre CV dans le top des priorités : Une architecture n’est pas faite pour élargir vos connaissances, vous faire découvrir de nouvelles technologies ou faire des expériences. Il s’agit de répondre à un problème et une demande par une infrastructure et une organisation.

Simplifiez la complexité, limitez la complexité accidentelle : Pensez simple, vérifiez ce qui est fait, prévenez ce qui va être fait pour que ce soit fait simplement.

La communication est reine, la clareté et le Leadership sont ses serviteurs : La communication est le point le plus important d’un projet. Sans communication, vous courez à votre perte. Et restez simple dans votre communication et investissez-vous dans les tâches que vous confiez.

Recherchez la valeur dans ce que vous dessinez : Si ce que vous proposez n’a pas de valeur, alors il ne sert à rien de l’implémenter. Et il est fort probable que ceci sera refusé, mis de côté ou pénalisera votre planning. Oubliez ce qui n’a pas de valeur ou pas assez dans vos architectures.

Restez debout : Lorsque vous présentez votre architecture, restez debout. Ceci montre votre motivation, votre implication dans votre travail. Ceci rend votre message plus efficace. Vous mettez alors toutes les chances de votre côté pour valider votre conception.

Visualisez l’échaffaudage de votre architecture lorsque vous en parlez : Lorsque vous discutez du design de votre architecture, vous devez être à même de discuter de chaque partie, même si vous n’avez pas encore tous les détails en tête et surtout de combler les lacunes qui pourraient apparaitre dans vos premiers dessins.

Vous négociez plus que vous ne réfléchissez : Eh oui, une fois une architecture dessinée, il vous faut la discuter, l’expliquer et surtout la négocier, pour bien faire comprendre les points importants, ceux que l’on peut adapter et le timing de mise en place. Un vrai travail de négociateur.

Quantifiez : Pour votre architecture, il vous faut quantifier la charge, le planning, les impacts, les risques… Un vrai travail de fourmi.

Une ligne de code a plus de valeur que 500 lignes de spécifications : Effectivement, dans la grande majorité des cas, cette ligne de code sera exécutée plusieurs milliers de fois lorsque votre application sera en à être production. Et elle aura valeur de preuve lorsqu’il va s’agir de savoir ce que fait réellement votre programme. Elle a donc intérêt à être juste, bien écrite et compréhensible. Cette ligne est bien plus importante que vos spécifications. Et c’est d’autant plus vrai avec des méthodologies agiles type Scrum.

Il n’y a pas de solution miracle : Il n’est pas possible d’appliquer les mêmes recettes sur deux projets différents. Chaque projet, chaque application a ses spécificités. Le secteur, les technologies, l’équipe, les connaissances. Il vous faut adapter votre architecture.

Il n’est jamais trop tôt pour parler performances : Si les performances ne sont pas la première priorité dans la construction d’une architecture, elles ne doivent pas être mises de côté, puisque tôt au tard, il y aura des questions de performances auxquelles il faudra répondre. Il vous mieux y avoir réfléchi lors des premières phases de design.

L’architecture de l’application détermine les performances de l’application : Lorsque vous contruisez votre architecture, réfléchissez bien aux performances de votre application. En effet, de mauvais choix d’architecture peuvent avoir des impacts forts sur des performances attendues comme des prérequis à l’application.

Il n’y a pas qu’une seule solution à un problème : La solution unique sans autre alternative n’existe pas. N’essayez donc même pas de le faire croire à vos interlocuteurs.

C’est le business qui décide : Pensez bien que tout ce que vous faites est conduit par le business pour le business. C’est lui qu’il faut séduire, c’est lui qu’il faut satisfaire.

La simplicité avant la généricité; L’utilisation avant la réutilisation : Avant de penser générique, pensez d’abord simple et voyez ensuite si vous pouvez appliquer un modèle générique. Avant de penser réutilisation, pensez déjà à utiliser et vous verrez ensuite si vous pouvez réutiliser.

Mettez les mains dans le camboui : Si vous voulez être crédibles auprès de vos développeurs et de vos managers, il va falloir vous investir sur le plan technique. Supportez vos développeurs lorsqu’ils ont un problème, le résoudre vous-même si besoin.

Intégrez en continu : L’ensemble du travail de l’équipe et le votre doivent être intégré en continu. N’imaginez pas pouvoir assembler toutes les pièces en fin de parcours comme si de rien n’était si vous n’avez pas tout testé ensemble au fur et à mesure des développements du projet. Les méthodes XP d’intégration continue fournissent tous les outils dont vous avez besoin et vous assurent une qualité continue et un risque minimum sur votre projet.

La base de données est une forteresse : une fois le schéma de la base de données défini et les premières lignes de code intégrées, comprenez bien que tout changement sur la base de données aura des impacts forts sur le projet. Cette base de données devrait donc être considérée comme inviolable, sauf quelques mineures, au risque d’impacter la qualité de votre projet et surtout votre planning.

Utilisez l’incertain pour vous guider : Lorsque vous discutez de votre conception, réfléchissez toujours à ce que vous ne savez pas ou ne comprenez pas. Ceci doit vous guider pour définir les bases de votre architecture. Ce que vous ne savez pas présente un risque. Il vous incombe donc de savoir pour diminuer ce risque. Si vous vous apercevez durant votre projet qu’il y a quelque chose que vous ne connaissez pas, vous avez pour tâche de le découvrir afin de limiter ou d’annuler le risque que cette non-connaissance a sur votre projet.

Une vue trop long terme est l’ennemi du succès : Lorsque vous travaillez sur votre architecture, ne pensez pas trop au long terme, ceci pourrait avoir un impact négatif sur le succès de votre projet. Vous empêchant de voir les besoins immédiats et de choisir ce qui est bon.

La réutilisation est une question de personne et d’éducation, pas d’architecture : Il ne suffit pas d’avoir une architecture qui permet la réutilisation de composants, encore faut-il avoir les bonnes personnes avec les bonnes connaissances pour permettre cette réutilisation. Et il faut expliquer la réutilisation pour qu’elle soit effective.

Il n’y a pas de “Je” en architecture : Vous ne pouvez pas vous permettre de dire “je” en tant qu’architecte. Car si certes vous dessinez l’architecture, c’est avec l’aide de beaucoup de collègues de votre entourage, avec des négociations et surtout ce sont les développeurs qui vont l’implémenter.

Prenez du recul : Il est bon de prendre du recul lorsqu’on travaille sur une architecture. Ne pas toujours être “dedans”. Mais attention, il faut savoir ajuster ce recul. Prendre la vue des développeurs, des utilisateurs, managers, sur du court, moyen et long terme.

Essayez avant de choisir : Les choix d’architecture ou de technologie ne doivent jamais être fait sans en avoir fait des essais de ceux-ci. Les risques encourus sont beaucoup trop importants. Et plus les choix sont importants, plus les essais doivent être faits avec soin.

Comprendre le métier : Un architecte se doit de comprendre le métier s’il veut faire une architecture réussie. Et plus l’architecture est importante et plus la connaissance du métier doit être approfondie. Ne négligez jamais cette étape.

Le temps change tout : Dans un projet tout est une question de timing. Il faut laisser le temps au temps et savoir lorsqu’il est temps d’intervenir. Laisser le temps aux managers d’assimiler vos choix et ses impacts, laisser aux développeurs le temps d’intégrer vos concepts et leurs avantages… Et ce qui était vrai hier, n’est pas forcément vrai aujourd’hui et ce qui est vrai aujourd’hui ne le sera pas forcément demain.

Donnez de l’autonomie aux développeurs : Avec l’expérience l’architecte sait que son architecture ne peut être parfaite et qu’elle est sujette à modifications. Celui qui ne l’accepte pas et se veut rigide avec ses développeurs court à sa perte. Ceux-ci n’accepteront pas l’architecture ou l’architecte ou les deux, et soit le projet, soit l’architecture, soit les deux vont échouer. Laisser les développeurs proposer des solutions, discuter avec eux de ce qu’il est envisageable de faire lorsqu’ils se retrouvent confronter à des problèmes que votre architecture ne peut résoudre d’elle-même et adapter.

Le contexte est Roi : Des règles d’architecture qui s’appliquent dans un contexte ne s’appliqueront pas dans un autre. Tout est fonction du contexte. Vous ne pouvez pas créer une architecture ultra-performante et complexe si vous n’avez de développeurs aptes pour la comprendre par exemple. Prenez en compte le contexte lorsque vous dessinez votre architecture.

Voici une vidéo de la méthodologie Scrum en pratique. Très sympa.

Les utilisateurs de Scrum reconnaitront les différentes phases, les autres se demanderont bien ce que peuvent faire ces gugus avec leurs post-its et leurs jeux de cartes.

• Scrum Methodology,
• Scrum : De l’intérêt des méthodes agiles,
• Acheter votre jeu de cartes Planning Poker, livraison rapide et de qualité.

Et voila un autre script GreaseMonkey dans la bibliothèque, LinkYourViadeoContact.

Ce script GreaseMonkey que votre humble serviteur a créé en une petite soirée vous permet de vous rendre directement sur la page de contacts qui ne sont pas dans votre réseau en cliquant simplement sur leur photo.

Ce script fait suite à une news de blog que j’ai lu récemment, qui mettait à jour une faille sur Viadeo.

Le script était tellement simple à faire et j’utilise souvent Viadeo en me demandant à chaque fois qui sont ces personnes qui viennent voir mon profil que j’avais envie d’avoir ce script.

C’est fait.

Installez-le et faites moi part de vos commentaires.

• GreaseMonkey : YourViadeoContactLink

Je rajoute un lien vers l’autre script GreaseMonkey que j’ai développé, histoire de me refaire un peu de pub.

• GreaseMonkey : NetvibesSubTab
• Sur mon blog

Update (2009.07.15) : Pour utiliser ce script, voici la procédure à suivre :

• Avoir Firefox

• Installer le plugin GreaseMonkey, disponible ici : Plugin GreaseMonkey

• Aller sur la page GreaseMonkey : YourViadeoContactLink et cliquer sur “Install”

• Recharger votre page Viadeo et vous devriez pouvoir cliquer sur les images des contacts.

Depuis l’année dernière je m’intéressais beaucoup aux méthodes dites agiles dans la gestion de projet, comme Scrum, par exemple.

J’ai l’occasion grâce à mon emploi actuel de m’initier à ces principes qui sont aux antipodes des méthodes dites traditionnelles de gestion de project que nous pouvons pratiquer en France et qui sont enseignées dans nos universités.

Il n’est pas simple pour un manager de passer de l’un à l’autre. Beaucoup de principes et concepts sont à revoir, réapprendre et le faire seul est une étape difficile. Heureusement pour moi, j’ai la chance d’être initié (sur la pratique tout au moins) par une collègue canadienne, devenue Scrum Master récemment.

Avec ces principes, vous ne devez plus penser long terme, mais court terme, et surtout retour sur investissement (ROI). Les premiers mois ont été plutôt difficiles. En effet, l’envie de faire des projets et des plannings restent forts. Surtout lorsque vous disposez de MS Project 2007 et que vous avez envie de faire “joujou” avec.

Et puis le temps passe, vous faites des réunions et des itérations (planning, développements, tests, bugs, démo et déploiments) et vous vous sentez tout à coup envahi par ces principes qui remettent en question tout ce que vous avez pu faire avant.

En effet, dans une démarche standard, vous avez l’étape de spécifications, pendant laquelle vous réfléchissez avec votre client ou votre MOA. Les idées sont souvent vagues, il est difficile de se faire une idée concrète du produit final, vous êtes seul ou dans une équipe réduite à son minimum. Pas de développeur. Ensuite vous attaquez les devs et tests et suivez avec fidélité les spécifications qui sont très souvent vagues et pour lesquelles vous devez retourner voir le client car vous avez besoin d’éclaircissements. Puis vient le jour du déploiement et des formations utilisateurs. Et comme bien souvent, à cette étape, l’équipe est à nouveau réduite et vous êtes le seul à recevoir les remerciements (ou les blâmes, cela dépend). Et puisqu’à cette date, vous quittez vous-même le projet, vous ne savez pas ce qui va réellement être utilisé et ce qui convient et ne convient pas. Grosso modo, quel est le travail réellement intéressant et qui apporte une réelle plus value au métier. Les manques sont considérables.

Dans l’autre cas, méthode Scrum, par exemple, vous êtes au contact direct du métier. L’équipe complète se forme très rapidement et les premiers développements apparaissent après la première ou deuxième itération (après un mois environ). Vous avez donc des retours client quasi immédiatement. Les choix de développement se font itération après itération, l’ensemble de l’équipe est impliqué et le client vous félicite (ou vous blâme) tous ensemble. Vous avez donc un retour instantané sur ce qui est “bien” et ce qui ne l’est pas, vous comprenez mieux le métier, plus rapidement. Le client a également une plus grande réactivité dans ses choix de développement, en choisissant d’annuler ou refaire un développement, si la première version qu’il a reçu n’apparait finalement pas convenir à ses besoins.

Si les principes de Scrum sont bien respectés, et si donc, l’équipe projet a suffisamment d’expérience dans ce domaine, les projets utilisant cette méthodologie sont plus à même de répondre aux besoins réels du métier.

Cependant il ne faut pas se leurrer. Cette méthodologie comporte des pièges que seules des personnes expérimentées sont à même d’éviter ou prévenir. Car la complexité projet ne disparait pas pour autant.

• Premièrement le métier doit savoir de quoi il parle et doit se tenir à la disposition de l’équipe de développement tout au long du projet et pas uniquement sur le début comme dans un développement standard.
• Deuxièmement, le chef de projet ou ScrumMaster, doit être conscient des limites de son équipe de développement et s’assure les conseils d’un senior en architecture/développement, histoire de ne pas revoir toute l’implémentation au moindre changement de conception.
• Troisièmement, l’agilité ne concerne pas que la partie Scrum, mais toutes les phases de développement. eXtreme Programing pour un transfert de connaissance fluide, des tests et un serveur d’intégration continue, afin de pouvoir faire des modifications rapidement, facilement et sans crainte, un processus de déploiement simplifié, pour le répéter à chaque itération sans difficulté.

En suivant ces quelques principes, les projets suivant la méthodologie Scrum ont plus de chance d’aboutir et d’être à même de satisfaire le métier en fournissant des logiciels qui correspondent réellement à leurs attentes du moment (et pas à celles d’il y a 10 mois, déjà mises à l’oubli pour cause de crise, réorg ou perte de marché)

Le tableau suivant présente une comparaison des coûts de production des équipes de développement et la productivité du métier entre la méthodologie Scrum et les méthodes standards.

Comparaison des coûts de production et productivité entre Scrum et méthode standard

Dans le cas standard, on retrouve ce qui fait le principe d’un projet dit classique. Des coûts de production bas sur le début, lors des phases de spécifications, une intensification lors des développements et une baisse progressive sur la fin de projet lorsqu’il ne reste que la livraison, la correction des bugs et les formations utilisateurs. La productivité quant à elle ne débute qu’après la livraison et fournit son plein potentiel quelques mois après la livraison.

Pour Scrum, les coûts de production sont rapidement à leur maximum, puisque l’équipe intervient très rapidement sur le développement du produit. Ces coûts s’arrêtent d’ailleurs quasi immédiatement après la fin du projet, puisque l’application est livrée, les bugs sont déjà corrigés et les utilisateurs déjà formés. La productivité cependant débute juste quelques mois après les premiers développements. Cette productivité, timide sur le début, s’accélère rapidement puisque les fonctionnalités les plus importantes sont développées en priorité. Et la productivité est plus importante sur la fin, car elle correspond exactement à ce que demande le client au moment où il le demande (et non à ce que avait été défini dans les spécifications 10 mois avant, comme c’est le cas avec le méthode standard). Les gains de productivité sont d’ailleurs beaucoup moins important sur la fin de projet. C’est à ce moment que le client devra se demander s’il est légitime de poursuivre les développements, puisque ceux-ci n’apportent plus réellement de valeur ajoutée. On pourra alors stopper net le projet ou réorienter les développements vers d’autres objectifs.

Ce graphique montre tout le potentiel de Scrum.

• Scrum sur Wikipedia,
• Manifesto for Agile Software Development,
• Scrum et XP depuis les tranchées.

Il y a environ un an, j’avais découvert un plugin plutôt fun; nommé Cooliris, qui permet d’afficher sur un mur l’ensemble des images d’une recherche et de faire défiler ses images sur la gauche ou sur la droite.

Ce plugin est particulièrement bien soigné et montre les capacités  de Firefox et de l’équipe de développement. Mais passé le premier effet fun, on s’aperçoit très rapidement que celui-ci n’est absolument pas utilisable pour de la recherche d’image, puisque le mur apparait en premier plan et que le bouton du milieu pour ouvrir l’image d’un site dans un nouvel onglet est désactivé. Cela signifie globalement que si vous choisissez une image, vous allez sur le site contenant l’image et vous perdez, non seulement le mur mais également votre recherche. Il est ainsi impossible de revenir à votre recherche initiale rapidement si l’image sélectionnée ne vous convient pas.

J’ai donc très rapidement cessé d’utiliser ce plugin.

Et voici qu’au détour du Web, hier soir, je suis tombé sur un autre plug-in, qui est surement moins cool, mais beaucoup plus efficace.

AutoPager permet de charger automatique la page suivante d’une recherche, que celle-ci soit textuelle, image ou video, pour des sites variés comme Google, Google Images, YouTube ou Facebook.

Chargement automatique de la page suivante sur Google

Arrivé en bas de page, la page suivante se charge automatiquement, et vous pouvez ainsi poursuivre votre recherche sans cliquer sur le moindre bouton ou patienter quelques secondes. Et rien ne vous empêche de remonter dans votre page ou d’ouvrir des onglets. La recherche d’images est alors grandement accélérée.

Petit défaut de jeunesse, les sites internationaux ne sont pas configurés d’origine, outre Google.com et Google.cn, vous aurez donc à rentrer dans la configuration du plugin, copier une configuration existante, comme celle de Google.cn et renommer les liens Google.fr pour faire fonctionner ceux-ci.

Mais une fois cette courte et simple étape passée, profitez d’un plug-in à fort potentiel. Devenez plus efficient encore dans vos recherches.

Update : Une nouvelle version est arrivée, beaucoup de sites fonctionnent de manière automatique et plus rapidement. Un vrai plaisir.