Archives par mot-clé : Développement

Demander l’avis du dev

Je déjeunais, tranquillement (Jardin du Palais Royal, il y a pire), assis sur un banc.

S’assoie juste derrière moi une jeune fille et un garçon.

La fille parle fort, donc je l’entends :

Bon tu vois, machin, je l’aime pas. Il est dev, il doit rester à sa place.

Nous on a passé des heures à définir une fonction, on va pas tout remettre en question parce qu’il se pose des questions.

On a défini le besoin, à lui de le développer, point.

Le « dev » n’a qu’à s’exécuter, et développer la magnifique fonction définie par les équipes marketing, ou métier, ou produit (suivant les organisations).

Quelle erreur !

Si vous faites ça, vous vous privez de beaucoup de choses :

Il est très démotivant d’être traité comme un simple exécutant. Vous risquez de faire partir les meilleurs, vous risquez des postures d’oppositions systématiques, vous risquez la montée de tensions entre les équipes, chacune positionnée en sniper vis à vis de l’autre ;
Vous perdez une bonne partie du « cerveau » de l’équipe technique. Vous ne lui demandez pas son avis ? Très bien, elle va développer en suivant les spécifications. Mais attention, j’espère que vous aurez bien pensé à tout…

Il faut bien comprendre que, certe, vous avez passé du temps à définir, analyser une fonction. Mais l’équipe technique va passer encore plus de temps à la développer.

Il est fondamental qu’elle s’approprie le besoin et la solution.

Les « devs » peuvent remettre en question les choix ? Et pourquoi pas ? Si votre travail est très bien préparé, les fondamentaux doivent résister. Et si l’équipe technique propose des améliorations, c’est parfait ! Ils se sentiront complètement intégrés dans le processus, et seront bien plus motivés pour faire un « truc qui marche », et la solution sera meilleure que ce qui était prévu au début.

C’est une des raisons qui font qu’on doit bosser en méthode agile. L’équipe métier n’est pas séparée de l’équipe technique. Les équipes bossent ensemble, de manière itérative.

Alors, ça se passe comment chez vous ?

Le processus de développement agile

Quand je faisais du conseil, je parlais de l’intérêt de l’agilité.

Depuis que j’ai lancé Target2Sell, je le vis 🙂

L’équipe de développement est au taquet sur ces questions.

On fait plusieurs mises en productions par semaine.

Les mises en production ne font pas d’interruption de service.

Le processus est complètement automatisé, et met à jour une trentaine de serveurs, avec un mécanisme de rotation de manière à assurer la continuité de service.

2000 tests sont exécutés automatiquement à chaque « build ». Un build est lancé automatiquement à chaque « commit » poussé sur la branche principale de développement.

Avec un rythme aussi rapide, le risque de bug majeur est extrêmement réduit en fait. J’étais bien plus nerveux quand on faisait une mise en production par Sprint de 15 jours.

On est en mode Devops, il n’y a pas d’équipe dédié opérationnel, chaque développeur est responsable, depuis la conception jusqu’à l’exploitation.

Pas de territoire réservé non plus, chaque développeur peut agir sur n’importe quelle partie du code. Bien sûr, chacun se spécialise quand même en fonction de ses affinités Florent a pris en main Spark, Cyrille et JP ont bien investi Cassandra…

Tout cela permet d’avancer vite et bien, avec de bons échanges : le développement, c’est en permanence de la négociation, entre aller vite, et ne pas accumuler trop de dette.

Faire du logiciel, du développement, c’est de l’artisanat

Je déjeunais ce midi avec un ami de longue date.

On échange souvent sur le développement logiciel (entre autre sujets, je vous rassure 😉 )

Notre conviction commune, c’est que faire du logiciel, du développement, c’est un processus artisanal et pas industriel.

Je me suis déjà exprimé là dessus.

Dans la pratique, dans mon (mes ?) métier(s), quand je dis ça, je sens bien que c’est « contre productif » :

Les boites qui vendent du « processus industriel » à tour de plaquettes commerciales se sentent agressées, et se défendent en m’agressant à leur tour ;
Les clients qui connaissent mal tout ça (et c’est bien normal, ce n’est pas leur métier) se disent que l’artisanat, ça fait moins pro que « processus industriel ».

D’un point de vue rationnel, pourtant, c’est assez basique :

Un processus industriel, cela consiste à fabriquer un produit, avec un processus bien défini, qui permet d’accélérer la production, et de multiplier le nombre de produits fabriqués, en garantissant que tous les produits sont bien conforme au cahier des charges, tout cela avec un coût maîtrisé.

Cela passe par une séparation très forte, entre différents métiers.

L’ingénieur, qui conçoit le processus, décompose la chaîne de fabrication, et conçoit des machines, qui permettront de reproduire les mêmes actions, rapidement et sans faute.

De l’autre côté de la chaîne (c’est le cas de le dire), l’ouvrier derrière la machine a un travail répétitif, travail qui est d’ailleurs de plus en plus souvent remplacé par des machines, des robots.

Dans le monde du logiciel, cela n’existe pas, et, pire, quand on tente d’appliquer de telles méthodes, on arrive à des catastrophes.

Au final, ce qui marche, au contraire, c’est le recrutement des meilleurs développeurs, et de leur confier des missions ou ils pourront avoir le maximum d’autonomie.

On est donc bien dans un processus artisanal, ou ce qui compte, c’est la qualité de l’artisan.

Un exemple parmi des centaines :

Apple a eu besoin de 60 personnes pour créer iOS.

Motorola, qui essayait de faire la même chose, avait mis sur les rang 1500 personnes.

Qui a réussi ?

On est donc dans une industrie ou ce qui compte, c’est la grande qualité de quelques personnes clés. Et je ne parle pas des managers, mais bien des développeurs !

Quand tu veux Yves, pour poursuivre ce passionnant sujet 😉

Mais comment ça se passe dans les équipes techniques d’Amazon ?

Je viens de parcourir un long billet, sur Google+, publié par un gars qui a commencé par travailler plus de 6 ans chez Amazon, puis a peu près le même temps chez Google.

C’est passionnant, parce qu’on n’a pas si souvent que ça une telle vision, un peu « brut de décoffrage », sur ce qui se passe en interne chez Amazon et Google.

On y apprend que, du point de vue de ce développeur, Amazon et très loin derrière Google :

« Amazon does everything wrong, and Google does everything right »

On y apprend également des choses intéressantes sur le management de Jeff Bezos, son obsession de « chaque pixel » du site, son incapacité à « lacher », son « micro management », jugé parfois brutal.

On y parle également architecture, pour très grosses plateformes.

Le gars donne son point de vue sur Google+, par rapport à Facebook.

A lire donc. J’en ferais peut être un article un peu plus fouillé ;).

(via pieroxy)

Les métiers du développement

Le e-commerce s’appuie sur le logiciel.

Il s’agit donc de bien maîtriser ce métier… Ces métiers en fait !

Comment un développeur peut évoluer ?

En fait, il peut évoluer de plusieurs façons.

Il peut poursuivre dans une voie technique, prendre de la hauteur de vue, et devenir un architecte.

Un architecte, c’est un gars qui a une culture technique très large, et qui, à l’écoute des différents besoins et contraintes techniques, propose des solutions adaptées. C’est un rôle tout à fait fondamental.

L’architecte garde donc une maîtrise technique, il doit coder. Vis à vis des autres développeurs, il est un « référent ». Pas de relation hiérarchique, mais un rôle d’expert, que l’on consulte.

L’autre voie, c’est le chef de projet bien sûr. Il s’agit d’une évolution moins technique, pour aller vers le fonctionnel et le management. Le chef de projet encadre, gère le planning, et est en « tête de pont » pour les relations avec le client, interne ou externe.

Le métier de chef de projet est souvent bien compris, bien reconnu, et présent sur les projets.

C’est moins le cas pour l’architecte, et, de mon point de vue, cela fragilise bien des projets.

La folie Javascript

Si, au début, Javascript est arrivé discrètement, pour « égailler » un peu les pages, aujourd’hui, c’est un vrai feu d’artifice !

Bien souvent, les sites chargent plus de 15 scripts, qui représentent souvent plusieurs centaines de Ko.

Sans oublier le code javascript ajouté directement dans les pages…

Le résultat est que les pages sont lourdes : lourdes à charger, et lourdes à exécuter.

En fait, bien souvent, on importe des librairies, et on en utilise une petite sous partie.

Quel dommage, surtout quand on connait l’importance d’avoir des sites qui répondent vite…

Comment en est on arrivé là ?

En fait, c’est une dérive, largement encouragée par pas mal de boites du secteur.

Je m’explique.

Pour la plupart des entreprises, la partie technique du site e-commerce est un centre de cout, pas un centre d’investissement (dommage 😉 ).

Dans un tel contexte, l’ajout de fonctions au site est toujours une négociation difficile.

La parade ? Le Javascript !

Les boites viennent vous voir, et vous explique que leur solution est « non intrusive », et qu’il suffit d’ajouter « un petit script de rien du tout ».

Et ça marche ! En quelques heures, le site a intégré une nouvelle fonction, et cela n’a presque rien couté en intégration…

Mais voilà, tout cela à un prix : le « petit code javascript » inclus un autre fichier, bien plus gros, qui lui même fait appel à des fonctions externes… et la page a pris 20, 30% de temps de chargement en plus, sans compter les bugs « qui viennent avec » parce que certaines fonctions sont incompatibles, les unes avec les autres.

Tout cela se corrigera avec le temps, quand la qualité deviendra un critère de performance (ce qu’il est vraiment !).

La qualité, cela doit aller jusqu’au bout, jusqu’au contenu qu’on envoie sur le poste du client.

Le pire, c’est qu’il n’est pas très compliqué de faire le ménage là dedans : ~~compiler~~ regrouper les fichier javascript, supprimer les fonctions inutiles, compresser tout ça… Et gagner de précieuses secondes en temps de chargement !

500 fois plus rapide…

Je lisais dans un doc qu’entre un programme écrit en PHP et un programme écrit en C, il y avait une différence d’un facteur 500 : le programme écrit en C est 500 fois plus rapide que le même programme écrit en PHP.

C’est, comment dire, énorme, monstrueux, incroyable… Bon, vous avez compris l’idée ;).

C’est avec ce type d’infrastructure qu’on se retrouve à devoir aligner des serveurs, comme les petits pains chez le boulanger… Sauf que le prix d’un petit pain n’est pas exactement celui d’un serveur…

Je suis pragmatique, et le PHP est bien souvent un bon choix pour l’entreprise… Mais cela me conforte dans l’idée qu’il y a un vrai chaînon manquant, un système de développement d’application Web réellement efficace, un environnement « green » et économique, parce que très performant.

Bon, de gros acteurs travaillent sur ce type de sujets : Google, Facebook…

2 ans avec Magento, l’expérience Brand Online Commerce

Cet article est écrit par Christophe Davy, dirigeant de Brand Online Commerce, qui est « l’invité permanent » de François sur ce blog.

La plateforme e-commerce Magento est un véritable phénomène (de mode ?) sur le marché, tout le monde en veut, tout le monde en fait.

J’entends le mot « magento » dans la bouche de tout le monde, y compris parfois chez des dirigeants qui ne sont pas censés en connaître l’existence. Toutes proportions gardées, je trouve des similitudes avec la façon dont est vu SAP dans les entreprises. Pour plagier l’ami Seguela, « si tu ne diriges pas une entreprise utilisant SAP avant 50 ans, c’est que tu as raté ta vie ». Et maintenant, « si tu n’as pas mis en place un e-commerce avec Magento avant 50 ans, c’est que tu as raté ta vie ».

J’ai donc voulu apporter un témoignage concret et issu d’un vécu quotidien, en l’occurrence celui de mon entreprise Brand Online Commerce. Brand Online Commerce est sur le marché du e-commerce délégué, elle opère la chaîne de valeur du e-commerce pour le compte de marques haut-de-gamme (beauté, mode, luxe). Des sites comme narscosmetics.co.uk, sequoiaparis-usa.com, sergelutens.com ont été créés et sont gérés au quotidien par Brand Online Commerce.

Tous nos sites ont un point commun, ils tournent sous Magento.

Nous avons choisi Magento à l’été 2008, à la création de l’entreprise. Ce choix, que je considère comme très judicieux, a été réalisé avec l’ami François (le taulier du blog sur lequel vous êtes en train de me lire).

Pourquoi judicieux ? Parce que nous avons systématiquement une problématique internationale dans tous nos contrats. Nous gérons ainsi 3 boutiques en Europe pour les cosmétiques Nars avec 2 langues et 2 devises, 5 boutiques pour Sequoia Paris (4 langues et 1 devise en Europe, 1 langue et 1 devise aux US), etc…, etc…

Dans un tel contexte, Magento répond efficacement à notre besoin. Une fois le set-up technique bien fait, on peut facilement (oui, le set-up est « long », mais après la maintenance est « facile ») gérer le catalogue produit en lui appliquant toutes les contraintes inhérentes à un e-commerce international, et notamment :
– une gestion de prix différents pour un même produit par langue et/ou par pays,
– dans une ou plusieurs devises,
– une gestion de l’affichage du catalogue par langue et/ou par pays (tel produit disponible au UK ne l’est pas en France),
– des listes de best-sellers différentes par langue et/ou par pays,
– des règles de discount, gift with purchase, free shipping différentes selon des critères classiques (liste de SKU, seuil de commande, offre ciblée sur une référence,…) croisés avec les langues et/ou les pays (free shipping à 80£ sur telle boutique, et à 100 € sur telle autre, et pas de free shipping sur une troisième).

A titre d’illustration, on retrouve une partie de ces contraintes exprimées dans les blocs promotionnels actuellement en place sur les site Nars Cosmetics en Europe :

Ma comparaison avec SAP, encore une fois toutes proportions gardées, vaut aussi sur un autre point : un programmeur met beaucoup de temps à faire le tour de Magento, et il lui faut plusieurs mois (mois, pas semaines) pour être vraiment opérationnel. Magento est tellement complet et paramétrable, que la montée en puissance d’un programmeur se fait nécessairement module par module. Je ne parle pas du simple fait d’apprendre comment cela marche en théorie, mais d’être compétent jusque dans la maintenance et dans le fonctionnement au day-to-day des différentes mécaniques techniques.

Par exemple, la maîtrise des règles de gestion des promotions est en soi déjà une compétence longue à acquérir. Il ne m’étonnerait donc pas de voir, avec la montée en maturité de l’écosystème Magento, les programmeurs Magento se spécialiser sur tels ou tels modules de Magento. Exactement comme pour SAP, où les experts sont toujours spécialisés sur des modules, jamais sur la totalité de la solution.

Quant à « l’Apple Store » de Magento, Magento Connect, il contient aujourd’hui 2500 applications… Qui peut dire « je les ai toutes auditées, et je sais ce dont j’ai besoin » ? Chez Brand Online Commerce, comme je pense chez tout le monde, on ne passe pas assez de temps à regarder ce qui est proposé sur Magento Connect. Là aussi, je me demande si l’on ne verra pas émerger prochainement un nouveau type d’acteur dans l’écosystème Magento, le consultant-programmeur chargé d’auditer les besoins et de repérer les modules Magento déjà disponibles pour ce besoin ; ses honoraires étant plus que financés par la réduction de la charge de développement technique de la solution.

Les idées innovantes de Aspectize

Ce qui est intéressant, à mon avis, dans cette solution, c’est la « remise à plat » des concepts, pour bien programmer.

L’équipe s’est libérée des dogmes et paradigmes actuels, pour proposer ce qui leur semble le mieux.

Ainsi, la solution n’est pas « purement » objet, puisque la partie programmation est décorellée de la partie données.

Finalement, le modèle proposé est assez critique par rapport à l’approche objet…

Par contre, la solution part d’un modèle « MVC » : Modèle / Vue / Contrôleur, c’est à dire un modèle ou on sépare les activités de développement en trois couches distinctes :

Modèle : représentation des données ;
Vue : programmation de l’interface ;
Contrôleur : tout le reste 😉 .

La petite équipe qui refait le monde

J’ai croisé l’équipe de aspectize.

Ces deux gars (!) sont, tranquillement, en train de refaire le monde… du développement logiciel.

Ces deux anciens de Winwise, avec une très bonne expérience des besoins et des projets informatiques, ont réécrit un environnement de développement.

Leur approche est la suivante :

Vous commencez par modéliser les données dont vous avez besoin, avec un modèle spécifique « entité association ». Donc, vous n’êtes pas dans le monde du relationnel. Le modèle est plus riche parce qu’il permet par exemple de modéliser des relations multi-valués (un client achète plusieurs produit, et un produit est acheté par plusieurs clients).

Ensuite, vous dessiner vos interfaces, qui peuvent soit être des vues web (html) soit des vues pour applications natives windows.

Enfin, vous programmez les fonctions « métiers ».

Dernière étapes, vous utilisez leur « binder » pour faire le lien entre tout ça : lien entre les éléments de l’interface et les fonctions, lien entre les fonctions et les données.

Et c’est fini : leur système est un « run time » qui assure l’exécution de l’application, et appellera les bonnes fonctions au bon moment.

En fait, il y a deux run time : un pour les applications natives windows, et l’autre pour le Web.

Cette solution permet de réduire considérablement le nombre de lignes de codes à écrire, pour développer une application donnée.

Aspectize Techdays 2008
envoyé par aspectize.

Après, il reste à mon humble avis des points à traiter :

L’application est complètement « stateless », cela veut dire que le système ne gère pas la notion de session. C’est au programmeur de sauvegarder toutes les données pour gérer la cohérence de l’application entre les pages.
Les applications web sont bien 100% dynamiques, il faut donc « rajouter une couche » pour que le contenu soit bien vu par notre amis Google.

A suivre !