Journal Réduire les temps de développement sans sacrifier la qualité

Posté par LeBouquetin (site web personnel, Mastodon) le 21 février 2017 à 15:26. Licence CC By‑SA.

Étiquettes :

fév.

2017

Sommaire

Avant‐propos
Introduction
Comment réduire les temps de développement ?
Réduction de temps de développement avec perte de qualité
Réduction de temps de développement sans perte de qualité
- Quel intérêt ?
- Quelques techniques
Conclusion

Avant‐propos

Ce journal parle de développement logiciel, de coûts, de qualité. Il est question de méthode et méthodologie plutôt que de technologies.

Ce journal est un peu long… vous êtes averti(e)s. ;)

Introduction

Je dirige une entreprise dont l’activité principale (en termes de chiffre d’affaires) est de faire de la prestation de services : développements techniques, développements d’applications distribuées et applications Web sur mesure.

Régulièrement les prospects et clients trouvent que les coûts sont élevés et cherchent à les réduire. C’est naturel.

Le métier de la prestation de service est de vendre des jours/homme. Lorsqu’on veut réduire les coûts, le premier réflexe est donc de réduire le nombre de jours/homme.

La problématique que j’essaie d’adresser ici est donc d’être capable de répondre à ces attentes et, si possible, sans que ce soit au détriment de la qualité.

client : dans cet article, le client est soit un client de l’entreprise soit un client interne — responsable produit, équipe marketing, utilisateur de l’outil interne, etc.

anglicismes : par avance, merci de ne pas me tenir rigueur des anglicismes présents dans ce journal. Le quotidien du développeur est fait d’anglicismes — pour le meilleur et pour le pire.

Comment réduire les temps de développement ?

La manière la plus simple de réduire les temps de développement est d’adopter une stratégie de développement « agressive ». Cette stratégie « agressive » signifie avec perte de qualité.

Analogie : on pourrait faire un parallèle avec la compression d’images. Selon les algorithmes, la compression sera avec ou sans perte d’information. De la même manière, on pourra réduire les temps de développement avec ou sans perte de qualité — mais avec des niveaux de « compression » différents.

Réduction de temps de développement avec perte de qualité

Chez algoo, nous proposons 3 stratégies de développement qui essaient d’adresser différentes attentes en termes de temps de développement (mais également de qualité) :

le développement de « prototypes ». On développe un démonstrateur, qui sera jetable. Ça permet de valider un concept, faire des démos rapidement, mais sans pérennité du code. Le coût en temps est réduit au maximum puisqu’aucune réflexion sur la pérennité n’est menée ;
le développement de mvp — produit minimum viable. C’est un concept très prisé par les start‐ups ; pour simplifier, il s’agit d’implémenter le minimum de fonctionnalités dans un produit pour le rendre commercialisable. Dans ce type de développement, les principales problématiques de pérennité seront prises en compte, mais pas les autres. On aura alors un logiciel « moyennement évolutif » ;
le développement en mode « ingénierie logicielle ». C’est la stratégie de développement long terme : on fait de l’architecture, de la conception, des tests et de l’intégration continue — tests unitaires, tests d’intégration, tests fonctionnels, etc. C’est la stratégie que l’on favorise lorsqu’on intervient sur un logiciel dont la durée de vie ciblée est de plusieurs années.

Les stratégies 1 et 2 sont moins coûteuses que la 3, mais la qualité est partiellement sacrifiée et le niveau de finition également en faveur d’un temps de développement réduit (à court terme)

Réduction de temps de développement sans perte de qualité

Je vais vous présenter ici les techniques que nous mettons en œuvre pour réduire les coûts de développement sans pour autant réduire la qualité (voire le contraire).

Quel intérêt ?

Réduire les coûts sans sacrifier la qualité est évidemment intéressant pour l’entreprise ou le client car :

soit vous avez la même chose pour un coût inférieur ;
soit vous avez un périmètre fonctionnel plus étendu pour le même prix.

Du côté des développeurs, en revanche, on a parfois l’impression qu’on essaie de brader les compétences.

En réalité, il ne s’agit pas de brader des compétences mais :

d’industrialiser ce qui peut l’être sans surcoût ;
d’optimiser l’exploitation des compétences de chacun, des développeurs, certes, mais aussi des autres intervenants et en particulier des clients.

Quelques techniques

Les différentes techniques présentées ci‐dessous ne sont pas exhaustives et ne demandent qu’à être complétées via vos commentaires. Elles ne sont pas non plus systématiques car chacune s’appliquera plus ou moins bien selon le projet, l’état d’avancement, les interlocuteurs — client interne, externe, client compétent techniquement, béotien, etc.

Technique n^o 1 — ne pas prendre de décision à la place du client

Objectif : éviter à tout prix de redévelopper une fonctionnalité non conforme aux attentes

Quand on développe un logiciel, on le fait toujours pour un client. Ce client peut être externe — c’est le cas classique d’un prestataire de service, interne — on développe un logiciel à partir des demandes du marketing ou du responsable produit —, ou encore « perso » (on développe un outil dont on a soi‐même besoin).

Les cahiers des charges et spécifications ne sont jamais complets. Il y a alors systématiquement des sujets à trancher.

Les développeurs ont besoin de réponses pour avancer, mais ils n’ont pas la connaissance pour décider. Je parle bien de connaissance, pas de compétence : seul le client sait ce qu’il veut. Et si le développeur sait ce dont le client a réellement besoin (cas typique : un client qui ne connaît rien au métier du logiciel), il n’est toutefois pas en mesure de trancher seul.

Pourquoi ? Parce que la solution « idéale » qu’il aura implémentée ne sera pas celle que le client veut, donc le client ne sera probablement pas satisfait (ce qui n’est pas bon), ou alors, dans le pire des cas, il va vouloir que le boulot soit refait, ce qui implique « redéveloppement » et, dans tous les cas, négociations qui peuvent être coûteuses en temps (donc couteuses tout court et pas la partie la plus agréable).

Par exemple, un cahier des charges qui indiquerait « l’utilisateur doit pouvoir être notifié » :

est‐ce qu’on veut des notifications par courriel ? Des notifications sur sa application Web ? Par SMS ? Toutes ?
est‐ce que l’utilisateur choisi lui‐même quand et comment il est notifié ?

Pour caricaturer, dans ce cas de figure, un développeur va avoir 2 réflexes :

soit il va aller droit au but — avec un système de notifications tel qu’il l’imagine, lui ;
soit il va concevoir et implémenter un système complètement flexible.

Dans le premier cas, la solution ne sera pas évolutive et, s’il est parti sur de mauvaises bases, c’est potentiellement tout son travail qui sera à refaire, sans compter la frustration d’avoir « travaillé pour rien » ou « de ne pas être écouté ».

Dans le second cas, on aura une solution « over‐engineered » — de la surqualité, qui a un coût.

La solution : au moindre choix, il faut demander au client. Et, idéalement, au client final. On a vite fait de « savoir » lorsqu’on est chef de projet ou responsable produit, mais la réalité est la même : c’est le client qui sait.

Technique n^o 2 — se limiter strictement au cahier des charges

Objectif : développer uniquement ce qui est commandé.

Lorsque le client a rédigé son cahier des charges, il a pris le temps de réfléchir à ce dont il avait besoin. Idéalement, il fournira en plus du cahier des charges, un cahier des charges prévisionnel pour les versions suivantes, ou une stratégie d’évolution envisagée. Cette stratégie va permettre d’opérer des choix techniques et architecturaux mais ne doit en aucun cas générer de coûts de développement supplémentaires.

Parfois, en tant que développeur, on se dit « ah, mais si je fais ça de telle manière, ça prend juste quelques jours de plus et ça permet d’avoir un système plus évolutif ». Et en général plus complexe, donc plus fragile :

d’une part, si cette flexibilité n’est exprimée nulle part il ne faut pas la prendre en compte — il sera temps de l’implémenter le jour où elle sera vraiment demandée (si ce jour arrive) ;
d’autre part, en règle général, plus un système est flexible, plus il est complexe, plus il est fragile. Donc, plus il nécessite de tests pour être certifié « conforme ».

Si une certaine flexibilité est obtenue avec quelques jours de plus, il sera probablement préférable soit de ne rien faire, soit de prendre ces quelques jours pour blinder la couverture de tests automatiques. Ainsi, le code reste simple et robuste, et la future évolution sera plus facile à implémenter car toute régression sera décelée via les tests automatiques.

Technique n^o 3 — réduire le périmètre fonctionnel

Objectif : développer uniquement ce qui est nécessaire.

Lorsqu’un client écrit un cahier des charges, il ne prend pas toujours le temps de prendre le recul nécessaire pour évaluer la pertinence de ses attentes.
Concrètement, il va indiquer dans son cahier des charges l’ensemble des fonctionnalités qu’il attend, mais lorsqu’on présente un chiffrage mettant en relief le temps de développement associé à chaque fonctionnalité, il n’est pas rare que l’urgence de certains points devienne toute relative.

Technique n^o 4 — faire du « test‐driven » sur les interfaces

Objectif : (dé)terminer les spécifications de manière exhaustive.

Nous développons des applications Web et des applications distribuées. Cela signifie en particulier la définition d’API (REST pour la majorité, mais pas nécessairement).

Note : API signifie Application Programming Interface, il s’agit des interfaces qui vont permettre de piloter votre logiciel.

Ces interfaces sont potentiellement très différentes du code qui est dessous, mais une chose est sûre : lorsqu’on entame le développement, on ne sait pas exactement ce qu’on doit faire.

Dans le meilleur des cas, une partie du travail consiste à « finir les spécifications »
(par exemple, la gestion des cas d’erreur), dans le pire des cas, la tâche de développement consiste aussi à écrire les spécifications.

La meilleure manière de faire ce travail de spécification — en tout cas de le terminer —, est d’écrire les cas de test. Cela permet de se concentrer sur l’utilisation (donc le besoin) et non sur l’implémentation (la manière de faire les choses).

Concrètement l’idée est d’écrire tous les cas de test puis de les exécuter à chaque nouvelle itération du développement. D’un taux initial de 100 % d’erreur, on va finir par arriver à 100 % OK une fois que le développement est terminé.

Ça n’aura pas coûté plus cher et le gain sera double :

une conception adaptée au besoin ;
un refactoring simplifié car spécification complète (via les cas de test) et 100 % testée.

Dans l’hypothèse où l’on aurait commencé par le développement, puis écrit les tests, outre le fait qu’on prend le taureau par les cornes (on écrit la solution avant d’avoir écrit les spécifications), le risque est d’avoir conçu une solution qui ne va pas répondre à 100 % des besoins, ce qui veut dire qu’on doit faire du refactoring ou qu’on accepte une couverture partielle des besoins.

Faire du « test driven » sur les interfaces est une bonne chose, mais sur le reste ? Pas forcément.

Les meilleures spécifications qu’on pourra obtenir/définir seront toujours sur les interfaces. Dans ce contexte écrire les tests revient simplement à transcrire les spécifications en code.

Lorsqu’on travaille sur le développement (et la conception) interne(s), on a rarement des spécifications, on va plus avancer à tâtons, ce qui correspond à la technique suivante.

Technique n^o 5 — Faire de la conception progressive sur les composants internes

Objectif : avoir quelque chose de fonctionnel le plus rapidement possible.

Lorsqu’on conçoit un nouveau module logiciel, on sait rarement à l’avance exactement comment il doit être conçu et comment il va se comporter.

En général, on découvre la réelle complexité progressivement parce qu’on pense au fur et à mesure à l’ensemble des cas de figure. Ce qui semblait initialement simple devient (très) compliqué ; du coup la question de « refactoriser » le code devient récurrente, etc, etc.

L’idée ici est donc d’avoir au plus vite quelque chose qui fonctionne, et seulement ensuite de se poser la question de comment concevoir le module pour découper la complexité.

On assimile le métier via une première version « brouillon » puis on modélise ce métier proprement.

Cela signifie en gros :

développer le composant fonctionnant dans le cas nominal en mode « proto » ;
au cours du 1. on identifie naturellement les cas d’erreur possibles / à traiter (et on les documente d’une manière ou d’une autre dans le code) ;
on a un code fonctionnel, il est alors temps :
1. de rationaliser la conception,
2. de gérer/traiter les cas d’erreur,
3. d’écrire les tests unitaires une fois les composants clairement découpés.

On sépare les tâches d’assimilation métier et de modélisation logicielle.

Et pour la modélisation logicielle, rien de tel que la technique suivante.

Technique n^o 6 — Diviser pour mieux régner

Objectif : simplifier la maintenance et l’évolutivité du code.

Les développeurs n’aiment que rarement faire de la maintenance sur du code. Personnellement, je trouve que c’est la partie la plus passionnante du travail, car les contraintes sont fortes.

Bien souvent les jeunes diplômés (en particulier) ne veulent pas faire de maintenance mais veulent concevoir un logiciel entier. Et, lorsqu’il s’agit de reprendre du code, plutôt que le faire évoluer, ils préfèrent souvent tout refaire de zéro.

Pourtant, le code a une intelligence propre : il répond à des besoins métier qui ont été accumulés en son sein et, lorsqu’on réécrit un logiciel complètement, c’est une grande partie de cette connaissance que l’on perd.

La raison pour laquelle la maintenance n’est pas sexy est que très souvent le code est un véritable nœud de fonctionnalités et responsabilités et, lorsqu’on aperçoit un bout et que l’on essaie de tirer sur la ficelle, c’est toute la pelote qui vient. Et plus on tire, plus les nœuds se resserrent. ;)

Or, réécrire un code complet est très coûteux et carrément exorbitant si l’on considère qu’on veut réécrire à périmètre fonctionnel constant. (attention : toutes les réécritures n’ont pas pour objectif d’être iso‐fonctionnelles)

La bonne solution pour faciliter la maintenance est de découper le code pour qu’il soit plus facile de le faire évoluer.

Le principe est simple : « un module = une responsabilité ». Et inversement.

Prenons un exemple concret : je veux faire un logiciel de gestion de tâches (todo). J’identifie spontanément trois responsabilités :

le stockage des informations ;
l’intelligence du logiciel — le noyau ;
l’interface « utilisateur » (ça peut être une API REST).

Du MVC ? Si l’on veut, mais c’est le niveau 1 du découpage.

Imaginons, qu’on ait développé le dit logiciel en trois modules : une interface utilisateur en Qt, un module noyau qui implémente l’intelligence et un module « base de données » qui stocke dans une base SQLite.

Un jour, mon client me demande s’il est possible de faire une interface Web et qu’il aimerait pouvoir stocker dans une base de données MySQL, voire MongoDB.

Il y a du travail, mais on va pouvoir découper ça relativement facilement. Par rapport au cas précédent, les trois modules se décomposent désormais sept modules (7 responsabilités) :

l’instanciation du « pilote de données » (une fabrique) ;
le pilote SQLite (qui va reprendre grosso modo le code de l’ancien composant « stockage des informations ») ;
le pilote MongoDB (qui va implémenter une interface compatible avec l’ancien composant « stockage des informations ») ;
le noyau du logiciel (qui va désormais manipuler des objets génériques) ;
l’interface utilisateur Qt ;
Un composant « Web » qui implémente une API REST/JSON ;
Un composant « Web » frontal qui se connecte sur l’API.

Les composants 1, 2 et 3 de l’ancien logiciel sont quasiment naturellement les 2, 4 et 5 du nouveau.

Dans cette décomposition, chaque composant a une unique responsabilité. Et chaque responsabilité est gérée par un composant unique.

Note : les parties en gras qui signifient « et inversement » mettent en relief qu’une responsabilité qui serait découpée entre plusieurs composants rend la maintenance et l’évolutivité aussi difficile que des composants aux responsabilités multiples.

L’illustration caricaturale dans mon domaine est Django, qui n’incite en aucun cas à faire ce type de découpage :

les vues Django implémentent de l’intelligence « métier » (et donc, si on veut ré‐implémenter les même fonctionnalités via une autre interface, c’est un gros travail de refactoring) ;
la validation des données va être implémentée dans des formulaires ou dans les modèles eux‐mêmes voire dans des « ModelView » ;
lorsque l’on travaille avec Django Rest Framework (la seule vraie raison d’utiliser Django en 2017), les sérialiseurs risquent d’implémenter toute la logique — et de fait devenir le noyau partiel d’une application.

Bien entendu, on peut exploiter Django différemment, mais la pratique que l’on constate est celle‐ci.

Technique n^o 7 — Écrire du code simple

Objectif : simplifier la maintenance et l’évolutivité du code.

« Ce qui se conçoit bien s’énonce clairement » — Nicolas Boileay‐Despréaux.

Souvent les développeurs veulent faire des choses compliquées et exploiter les fonctionnalités d’un langage au maximum. Mais la réalité c’est qu’un logiciel qui est écrit simplement fonctionne aussi bien qu’un logiciel exploitant toutes les particularités d’un langage.

Il fonctionne aussi bien et ça ne coûte pas plus cher à écrire. Et il coûte beaucoup moins cher à lire, donc à comprendre, donc à maintenir et faire évoluer.

Parfois les arguments sont d’écrire du code concis ou du code « esthétique », mais la concision trop extrême devient inaccessible.

Analogie : prenons un four qui propose deux boutons rotatifs — un pour régler la position et un pour régler la température. Ce four est beaucoup plus simple à appréhender qu’un four avec un unique bouton rotatif sur lequel on peut « cliquer » pour entrer dans des menus. Esthétiquement, certains diront que c’est plus joli — c’est subjectif. En revanche, ce qui n’est pas subjectif, c’est que c’est moins naturel à utiliser et moins ergonomique. Pour le confirmer, il suffit de regarder ce qui se fait dans les cuisines des restaurants : on industrialise la cuisine, et les choix qui sont opérés sont représentatifs : du gaz, des boutons ronds, un bouton par fonctionnalité.

Quand vous codez, imaginez que vous êtes un chef étoilé. :)

Technique n^o 8 — Écrire un script d’installation d’un environnement fonctionnel

Objectif : monter un environnement de test en une minute

Dans l’esprit du Joel Test, il est de bon ton d’écrire un script d’installation qui permet d’obtenir un environnement fonctionnel en une commande voire deux. Cela permet de très rapidement intégrer un nouveau développeur (ou un nouveau poste de développement), cela permet aussi très rapidement de mettre au point un nouvel environnement de test, totalement vierge.

Cela réduit le frein au test et augmente donc le nombre de tests, et donc le nombre de bogues détectés (et probablement aussi le nombre de bogues résolus).

Plus on peut tester, plus on trouve de bogues, moins la qualité diminue. Écrire un tel script prendra probablement quelques heures en début de projet, mais ces heures « perdues » seront largement compensées par les heures perdues à mettre en place des environnements, à tester ou ne pas tester, car la configuration est trop pénible.

Inutile d’en dire plus.

Conclusion

Selon les cas et les projets, nous n’appliquons pas nécessairement toutes ces techniques.

Un point à prendre également en compte et qui n’apparaît pas ici : derrière l’idée de réduire les temps de développement se cachent différents aspects. On y trouvera naturellement des notions de coûts — moins de jours de développement coûtent moins cher (c’est le cas initial à l’origine de ce journal), mais on y trouve aussi des notions de time‐to‐market. Moins de temps de développement, c’est une arrivée sur le marché plus rapide. Ce qui génère potentiellement des gains différents.

Le time‐to‐market… c’est notamment la raison pour laquelle pas mal de start‐ups fabriquent une première version en mode « mvp » voire carrément en mode « proto » : cela permet de prendre les parts de marché initiales, quitte à complètement redévelopper le produit par la suite — une fois que le marché a été pris, la concurrence devient difficile, la start‐up est devenue rentable et les dépenses de R & D nécessaires à la construction d’un système propre et robuste deviennent envisageables.

# Pas évident

Posté par devnewton 🍺 (site web personnel) le 21 février 2017 à 16:26. Évalué à 5.

Les stratégies 1 et 2 sont moins couteuses que la 3

Je ne trouve pas du tout évident que la méthode 3 soit la plus coûteuse ou la plus lente. Partir sur un projet sans architecture et sans conception (en supposant que le projet soit assez simple pour le permettre) maximise les coûts très rapidement à cause du nombre de choses à faire et refaire, du nombre de bugs ou des mauvaises performances.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
- [^] # Re: Pas évident
  
  Posté par LeBouquetin (site web personnel, Mastodon) le 21 février 2017 à 21:25. Évalué à 8.
  Je ne trouve pas du tout évident que la méthode 3 soit la plus coûteuse ou la plus lente. Partir sur un projet sans architecture et sans conception (en supposant que le projet soit assez simple pour le permettre) maximise les coûts très rapidement à cause du nombre de choses à faire et refaire, du nombre de bugs ou des mauvaises performances.
  
  Si tu considères uniquement le temps de travail technique (développement, tests, conception, etc), la technique 3 est la plus économique. Mais cela part du principe qu'on sait exactement ce qu'il faut faire dès le début et qu'on a le temps pour le faire (si techniquement ce n'est pas un problème, c'est souvent un problème en terme de parts de marché)
  
  Les techniques 1 et 2 sont les plus rapides pour arriver à un périmètre fonctionnel donné, ce qui permet rapidement :
  - de valider ou d'invalider des hypothèses,
  - dans le cas où on commercialise, de rentrer de l'argent et prendre des parts de marché.
  Le time-to-market est un élément très important à prendre en compte, et dans ce contexte, plus tôt tu as un produit commercialisable (même si limite techniquement), plus tôt tu acquiers des clients, des parts de marché, donc également de la légitimité. Il faut bien voir l'économie comme une compétition et en particulier le monde des startups est féroce.
  
  Pour ceux qui connaisent des jeux tels que starcraft, il y a une stratégie quand tu as les Zergs qui est d'aller tuer dans l'oeuf tes ennemis car en début de partie les Zergs ont un moment où ils sont en supériorité pour une durée donnée. C'est exactement la même chose avec les startups : faire un produit qui est sur le marché le plus vite possible va largement compliquer la vie des concurrents et donc conforter la place de leader du premier arrivé - et donc paradoxalement faire un produit un peu pourri techniquement pour arriver le premier est le meilleur gage de pérennité.
  
  Cette explication est assez simpliste, mais c'est la réalité (alors bien sûr l'enjeu est aussi en général de lever des fonds mais à fonds levés égaux, celui qui prendra le premier la place sur un marché sera souvent celui qui survit. Je t'invite à lire l'article suivant : http://www.newyorker.com/tech/elements/in-silicon-valley-now-its-almost-always-winner-takes-all
  
  #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
  - [^] # Re: Pas évident
    
    Posté par groumly le 22 février 2017 à 09:47. Évalué à 4.
    
    Un point central dans cette stratégie est aussi que, aussi doué soient les product managers, ou utile soient les session d'user testing, absolument rien ne remplace le feed-back de vrais utilisateurs qui utilisent vraiment le produit pour de vrai.
    Plutôt que de tergiverser pendant des heures pour savoir si #feature doit marcher comme ci ou comme ca, tu fait un proto rapide qui te donne une réponse (ou un bout), et tu corriges le tir.
    Tout l'art tient dans la créativité de faire des protos qui tiennent la route (faut pas prendre les gens que pour des cons), et pour les ingénieurs de branler le tout pour que ca soit maintenable et évolutif (parce que, ouais, lean ne veut pas forcément dire travail de gougnafier).
    L'elevator pitch ressemble en général à:
    - la pire chose que tu puisses faire, c'est construire le mauvais produit
    - le meilleur moyen de construire qq chose vite, c'est de trouver rapidement ce qu'il ne faut pas construire
    - on pas la moindre foutue idée d'où on va ni comment on y va, alors on improvise et on se demerde (celle la, elle est de moi. Elle vend pas des masses, mais elle fait marrer les gens du milieu).
    
    C'est une philosophie foutrement utile quand t'as une grosse part d'incertitude/exploration/créativité sur le produit, que t'as pas mal d'utilisateurs et que tu peux te permettre des écarts de conduite pour une portion d'entre eux.
    D'où le fait que toute startup ayant du succès est rompue à ces techniques, vu qu'une startup à vachement tendance à tester de nouvelles idées de produit.
    il se trouve que dans le logiciel, en général, ya vachement d'incertitude, mais pas forcément. Si ton boulot, c'est les logiciels de gestion de feuilles de payes, ya vachement moins d'incertitude quand même (ca veut pas dire que tu gagneras pas à ce genre de technique, mais c'est vachement plus risqué, et t'as beaucoup moins du retour sur investissement).
    
    Linuxfr, le portail francais du logiciel libre et du neo nazisme.
  - [^] # Re: Pas évident
    
    Posté par devnewton 🍺 (site web personnel) le 22 février 2017 à 13:05. Évalué à 3.
    cela part du principe qu'on sait exactement ce qu'il faut faire dès le début et qu'on a le temps pour le faire
    
    Pas du tout: c'est justement quand on ne sait pas exactement ce qu'il faut faire qu'il faut réfléchir.
    
    De plus si tu ne sais pas ce qu'il faut faire, comment tu sais que tu as le temps?
    
    J'ai l'impression que ce qui est proposé est la bonne vieille technique de pas management:
    1. on fixe la date de mise en prod avant d'avoir le début d'une expression de besoin.
    2. on laisse les devs se démerder pour pondre un truc.
    3. on se plaint que ça n'est pas ce qu'on voulait dans 76,42% des cas (estimation du Dave Newton Institute Of Pifology)
    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
    - [^] # Re: Pas évident
      
      Posté par LeBouquetin (site web personnel, Mastodon) le 22 février 2017 à 13:29. Évalué à 2.
      
      cela part du principe qu'on sait exactement ce qu'il faut faire dès le début et qu'on a le temps pour le faire
      Pas du tout: c'est justement quand on ne sait pas exactement ce qu'il faut faire qu'il faut réfléchir.
      
      On sait ce qu'on veut à court terme, mais on est en général incapable de savoir ce qu'il faudra avoir dans 1 an ou dans 2 ans. Et dans ces conditions on n'anticipe pas sur la flexibilité à implémenter pour d'hypothétiques fonctionnalités qui pourraient arrivent dans quelques années.
      
      Plus tu réfléchis en début de projet à toutes les problématiques, plus tu retardes la sortie et en particulier la sortie de la v1. Donc plutôt que retarder ta v1 pour "mieux prévoir ta v2, v3 et autre", tu sorts ta v1 au plus vite, et tu capitalise sur l'expérience de ta v1 pour définir ta v2. Et tu vas de proche en proche.
      
      #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
      - [^] # Re: Pas évident
        
        Posté par Nicolas Boulay (site web personnel) le 22 février 2017 à 13:46. Évalué à 4.
        
        C'est le principe de l'Agile, non ?
        
        "La première sécurité est la liberté"
        
        [^] # Re: Pas évident
        
        Posté par devnewton 🍺 (site web personnel) le 22 février 2017 à 15:12. Évalué à 2.
        
        Sauf que même en développement Agile, on fait de la conception.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
    - [^] # Re: Pas évident
      
      Posté par groumly le 22 février 2017 à 18:59. Évalué à 7.
      
      Comment tu fais pour réfléchir quand t'as pas de données, que tu connais pas le marche et que le produit que tu crees n'existe pas (et donc tu ne sais pas comment il va être reçu, ni s'il répond correctement au probleme, quand tu ne sais meme pas précisément quel problem tu essayes de résoudre)?
      L'experience et la connaissance du milieu, ca donne un bon point de depart, mais au final, ca reste surtout une opinion.
      
      L'idee, c'est que quand tu connais mal ton marche, plutôt que de faire un pari a s'engager dans des designs couteux (produit et ingénierie) sur plusieurs années, autant tater le terrain avec un proto rapide qui coute peu et t'apprends beaucoup. Et tu revisite constamment la direction de ton produit.
      
      Encore fois, ca s'inscrit dans un process exploratoire. C'est utile quand t'as une forte incertitude sur la direction précise du produit. Et quand ton marche est tout nouveau et est mal connu. Une enorme partie de l'informatique/services en ligne grand public tombe dans cette catégorie, vu que cette industrie est tres jeune et évolue a la vitesse de l'eclair au galop.
      
      De plus si tu ne sais pas ce qu'il faut faire, comment tu sais que tu as le temps?
      
      Justement. La philosophie est que quand tu ne sais pas grand chose de ton produit, ni de ton marche, un des trucs les plus urgents et importants a faire est de comprendre ton produit et ton marche. C'est urgent – il faut le faire la main'nant toussuite, et c'est tres important – la survie de ton produit en depend fortement.
      
      Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Pleins de remarques

Posté par barmic le 21 février 2017 à 18:35. Évalué à 6.

Technique n°2 & 3

Tu commence par snober la notion de MVP puis 2 de tes 3 première techniques (la 2 et la 3) en reprennent en bonne partie les principes. Il va falloir un peu plus m'expliquer :)

Technique n°4 — faire du « test-driven » sur les interfaces

[…]

Dans l'hypothèse où l'on aurait commencé par le développement, puis écrit les tests, outre le fait qu'on prend le taureau par les cornes (on écrit la solution avant d'avoir écrit les spécifications), le risque est d'avoir conçu une solution qui ne va pas répondre à 100% des besoins, ce qui veut dire qu'on doit faire du refactoring ou qu'on accepte une couverture partielle des besoins.

Pour moi tu passe à coté. Ce n'est pas le fait de commencer par l'un ou par l'autre qui va changer quoi que ce soit. C'est le fait ta façon de communiquer avec l'utilisateur/le product owner/le client (appel le comme tu veux) qui va changer cela. Et le TDD n'aide pas vraiment à faire ça. C'est plus le BDD car il va permettre de faire valider les tests par le client (l'objectif théorique étant que ce soit le client qui écrive les tests).

Ce dont tu parle c'est d'avoir des tests d’acceptante, pourquoi pas mais tu peux faire du TDD hors de ça et inversement ;)

Dans l'idée de l'agilité les patterns d'itérations et des démo aident beaucoup là dessus.

le principe est simple : "un module = une responsabilité". Et inversement.

Si le concept est simple son application ne l'est pas vraiment. C'est quoi une responsabilité ? C'est quoi un module ? Une classe ? Une fonction ? Quelle est la granularité de tes responsabilités ? Je pense savoir faire un découpage correct et appliquer des pattern qui vont me permettre de définir les abstractions correctes entre les responsabilités, mais de là à affirmer que je produit quelque chose de bon, je ne m'avancerais pas.

Technique n°8 — Écrire un script de setup d'un environnement fonctionnel

Je le mettrais bien plus tôt dans l'ordre. Parce qu'il apporte beaucoup plus de choses que ce que tu décris. Monter en environnement en 18µs, ça peut être utile, mais bof. Avoir la maîtrise de l'environnement technique sur le quel on travail permet d'avoir des boucles de feedback qui sont rapides (et ça c'est très important pour être efficace). Ça permet de produire un environnement de test customisé. Ça donne aussi une vision (pas complète, mais ça peut montrer des signes) de la complexité architecturale de ce que t'es entrain de produire.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Pleins de remarques
  
  Posté par barmic le 21 février 2017 à 18:43. Évalué à 10.
  
  De manière plus générale, tu essaie de vendre l'idée que la qualité c'est simple, que ça ne prend pas de temps, etc et je ne te rejoins pas du tout là dessus. Faire de la qualité c'est compliqué, sinon tout le monde le ferais. Non seulement c'est compliqué, mais en plus c'est long à mettre en place. C'est un mensonge de commercial d'affirmer qu'on peut faire de la qualité en un minimum de temps à coût 0. Ceux qui prennent de haut ceux qui font des erreurs en se croyant garant d'une quelconque qualité, c'est probablement qu'ils n'ont jamais fait quelque chose de suffisamment important ou pendant suffisamment longtemps pour se rendre compte qu'il pêchaient à différents endroits.
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Pleins de remarques
    
    Posté par LeBouquetin (site web personnel, Mastodon) le 21 février 2017 à 21:32. Évalué à 6.
    
    De manière plus générale, tu essaie de vendre l'idée que la qualité c'est simple, que ça ne prend pas de temps, etc et je ne te rejoins pas du tout là dessus.
    
    Ce n'est pas du tout ce que je dis. Ce que je dis, c'est que pour un développement donné, tu peux souvent gagner en temps de travail sans réduire la qualité en mettant en oeuvre une certaine méthodologie
    
    Je me cite : "Les stratégies 1 et 2 sont moins couteuses que la 3, mais la qualité est partiellement sacrifiée et le niveau de finition également en faveur d'un temps de développement réduit (à court terme)"
    
    Faire de la qualité c'est compliqué, sinon tout le monde le ferais. Non seulement c'est compliqué, mais en plus c'est long à mettre en place.
    
    On est d'accord :)
    
    C'est un mensonge de commercial d'affirmer qu'on peut faire de la qualité en un minimum de temps à coût 0.
    
    Personne ici n'a dit ça. Le seul truc que j'ai dit c'est que tu peux réduire ton temps de développement sans forcément perdre en qualité, je n'ai à aucun moment dit "tu peux faire du haut-de-gamme au prix du low-cost".
    
    #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
- [^] # Re: Pleins de remarques
  
  Posté par LeBouquetin (site web personnel, Mastodon) le 21 février 2017 à 22:42. Évalué à 2.
  
  Dans l'hypothèse où l'on aurait commencé par le développement, puis écrit les tests, outre le fait qu'on prend le taureau par les cornes (on écrit la solution avant d'avoir écrit les spécifications), le risque est d'avoir conçu une solution qui ne va pas répondre à 100% des besoins, ce qui veut dire qu'on doit faire du refactoring ou qu'on accepte une couverture partielle des besoins.
  
  Pour moi tu passe à coté. Ce n'est pas le fait de commencer par l'un ou par l'autre qui va changer quoi que ce soit. C'est le fait ta façon de communiquer avec l'utilisateur/le product owner/le client (appel le comme tu veux) qui va changer cela. Et le TDD n'aide pas vraiment à faire ça. C'est plus le BDD car il va permettre de faire valider les tests par le client (l'objectif théorique étant que ce soit le client qui écrive les tests).
  
  Bah le TDD permet d'écrire la spec (en termes de dév, certes, mais au moins ça définit le fonctionnement). Le BDD est une extension de ça et va plus loin.
  
  Mais globalement ce que j'essaie d'exprimer c'est ce que tu dis (avec probablement un vocabulaire plus modeste sur le sujet;)
  
  le principe est simple : "un module = une responsabilité". Et inversement.
  Si le concept est simple son application ne l'est pas vraiment. C'est quoi une responsabilité ? C'est quoi un module ? Une classe ? Une fonction ? Quelle est la granularité de tes responsabilités ? Je pense savoir faire un découpage correct et appliquer des pattern qui vont me permettre de définir les abstractions correctes entre les responsabilités, mais de là à affirmer que je produit quelque chose de bon, je ne m'avancerais pas.
  
  Il n'y a pas de règle pour dire "granularité trop faible" ou "granularité trop importante". Ce qui compte, c'est déjà de se poser la question, et souvent naturellement on va se rendre compte que des composants sont à responsabilité multiple ou responsabilité éclatée.
  
  Et on travaille rarement seul, donc si tu discute sur un module donné, tu vas probablement arriver à un consensus.
  
  Enfin qu'est-ce qu'un module, bah tout dépend du niveau de vision que tu as. Ca peut être une classe, une fonction, un ensemble de classes… tout dépend des technos que tu utilises, mais globalement "plus tes composants peuvent être considérés comme des boîtes noires, mieux c'est".
  
  #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
  - [^] # Re: Pleins de remarques
    
    Posté par barmic le 22 février 2017 à 14:44. Évalué à 3.
    
    Mais globalement ce que j'essaie d'exprimer c'est ce que tu dis (avec probablement un vocabulaire plus modeste sur le sujet;)
    
    Je n'ai pas compris la remarque sur la modestie.
    
    Par contre le pas entre le TDD et le BDD est important. Dans le premier c'est le programmeur qui fait la spec et ça entre en collision avec un autre de tes points qui dis que ce n'est pas à toi de faire des choix.
    
    Il n'y a pas de règle pour dire "granularité trop faible" ou "granularité trop importante". Ce qui compte, c'est déjà de se poser la question, et souvent naturellement on va se rendre compte que des composants sont à responsabilité multiple ou responsabilité éclatée.
    
    Bien sûr c'est « naturel », une archi, un découpage c'est tout à fait inné… ou pas. L’expérience va beaucoup t'aider, la compréhension du domaine aussi. Mais non les découpage « naturels » c'est souvent des découpages techniques et ça pousse à reproduire toujours les même motifs type n-tière (ce qui n'est pas toujours bon).
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Pleins de remarques
  
  Posté par Albert_ le 22 février 2017 à 10:06. Évalué à 3.
  
  l'objectif théorique étant que ce soit le client qui écrive les tests
  
  Heureusement que tu as mis theorique car si le client etait capable de faire cela, il y a de grande chance qu'il soit capable de faire le logiciel. Heureusement, pour les boites tel que decrit ici, l'enorme majorite des clients ne pipe rien au coding.
  
  Pas vraiment dans le meme domaine que decrit ici, mais mon experience m'a montre que faire faire des tests meme d'interface utilisateur a un client et bien c'est la croix et la baniere et que mis a part a la fin du projet il ne le fera pas correctement. Enfin je n'ai peut etre pas eu de chance et que ailleurs cela n'est pas le cas.
  - [^] # Re: Pleins de remarques
    
    Posté par barmic le 22 février 2017 à 14:39. Évalué à 3.
    
    Heureusement que tu as mis theorique car si le client etait capable de faire cela, il y a de grande chance qu'il soit capable de faire le logiciel.
    
    Je suis d'accord, mais je pense que les principes de DDD (le Domain Driven Design) et rendre les tests d'acceptance compréhensible par le client ça a du sens. Quand tu utilise un outil de BDD normalement quelqu'un de purement fonctionnel peut le lire et te dire que c'est faux ou pas. Ça aide dans les discussions.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# script de setup d'un environnement fonctionnel

Posté par CrEv (site web personnel) le 21 février 2017 à 19:06. Évalué à 3.

Technique n°8 — Écrire un script de setup d'un environnement fonctionnel

Inutile d'en dire plus.

Ha ben si sinon c'est pas drôle :-)

Il ne faut surtout pas écrire de script de setup. A moins de vraiment savoir ce qu'il faut faire (et encore) c'est probablement pas quelques heures et probablement un script sur lequel il faudra revenir.
Maintenant sur le besoin je suis parfaitement d'accord. Mais il ne faut surtout pas réinventer la roue. Utiliser ansible, chef, puppet ou, celui que je préfère, terraform. Du Terraform, une ou plusieurs machines sous CoreOS, des containers et ça en devient juste super agréable tout ça pour un coût limité, une très bonne répétabilité et un démarrage rapide.
Si certains veulent essayer voici un exemple qui montre par exemple comment faire tourner facilement un ElasticSearch en container sur un CoreOS via Terraform. C'est un exemple comme un autre mais je trouve qu'il montre plutôt bien l'intérêt de ces solutions.
- [^] # Re: script de setup d'un environnement fonctionnel
  
  Posté par flan (site web personnel) le 21 février 2017 à 21:06. Évalué à 2.
  
  Personnellement, je ne comprends pas trop l'intérêt du 8.
  Enfin, si, mais je trouve qu'il revient à dire qu'il faut utiliser les bons outils (et savoir les utiliser ! ).
  Je trouve de la même façon que pour faire un projet web, utiliser un framework est au moins aussi important que savoir déployer son application, en test ou pas, qu'avoir documenté les différentes procédures critiques (au moins dès que c'est autre chose qu'un POC), de toujours partir du principe que la machine sera perdue demain, etc.
  - [^] # Re: script de setup d'un environnement fonctionnel
    
    Posté par LeBouquetin (site web personnel, Mastodon) le 21 février 2017 à 22:46. Évalué à 10.
    
    Le point 8 signifie : plus ton code est utilisable/testable par quelqu'un qui ne connait rien à rien de ta pile technologique, mieux c'est.
    
    Si tu fais une appli web avec mongodb, redis, nginx, etc, si tu es capable de donner un outil qui "en un clic ou en une ligne de commande" fait tout le setup et permet à n'importe qui de le tester, c'est du temps gagné car des personnes non compétentes pourront te remonter des bugs (donc tu pourras arriver à un niveau de qualité équivalent en passant toi-même moins de temps à tester)
    
    #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
- [^] # Re: script de setup d'un environnement fonctionnel
  
  Posté par LeBouquetin (site web personnel, Mastodon) le 21 février 2017 à 21:44. Évalué à 4.
  
  Il ne faut surtout pas écrire de script de setup. A moins de vraiment savoir ce qu'il faut faire (et encore) c'est probablement pas quelques heures et probablement un script sur lequel il faudra revenir.
  Maintenant sur le besoin je suis parfaitement d'accord. Mais il ne faut surtout pas réinventer la roue. Utiliser ansible, chef, puppet ou, celui que je préfère, terraform. Du Terraform, une ou plusieurs machines sous CoreOS, des containers et ça en devient juste super agréable tout ça pour un coût limité, une très bonne répétabilité et un démarrage rapide.
  Si certains veulent essayer voici un exemple qui montre par exemple comment faire tourner facilement un ElasticSearch en container sur un CoreOS via Terraform. C'est un exemple comme un autre mais je trouve qu'il montre plutôt bien l'intérêt de ces solutions.
  
  Mettre au point un déploiement ansible/chef/puppet juste pour permettre à quelqu'un de faire un test, c'est clairement pas un gain de temps court-terme.
  
  Un "script" tu mets ce que tu veux dedans - l'idée c'est que tu as en quelques heures un outil qui permet à n'importe qui de setup son environnement sans rien connaitre. Si tu veux mettre un docker derrière, CoreOS via terraform ou n'importe quoi, peu importe : ça dépend des compétences que tu as et des outils que tu connais.
  
  Mais ce qui compte c'est que tu sois capable de fournir à un testeur, à un chef de projet, à un admin sys ou à n'importe qui une solution du type "tu lances cette commande et tu as l'appli dispo à telle adresse et configurée avec les données de base".
  
  #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Hypothèse fondamentale discutable

Posté par Michaël (site web personnel) le 21 février 2017 à 21:11. Évalué à 5.

Réduire les coûts sans sacrifier la qualité est évidemment intéressant pour l'entreprise ou le client car :
- soit vous avez la même chose pour un coût inférieur,
- soit vous avez un périmètre fonctionnel plus étendu pour le même prix.

Ce n'est pas totalement vrai. Les plus gros défauts des analyses de coûts que je peux lire sont systématiquement 1. qu'elles font l'hypothèse que l'univers peut être modélisé avec des additions et dans quelques cas extrêmes des multiplications, et 2. qu'elles ne décrivent pas assez soigneusement le système qu'elles étudient. Ici c'est le 2, car lorsque tu as livré ton produit, ton entreprise n'est plus la même! Tu as des développeurs qui ont acquis des connaissances, soit purement techniques, soit plus conceptuelles (techniques de programmation, techniques de génie logiciel, gestion de projet par exemple), par exemple.

Ainsi donc, si on fait l'hypothèse que “le temps de travail utile” contribue soit directement à l'élaboration du produit final, soit à apprendre des choses on conclut qu'on peut réduire les coûts sans sacrifier la qualité sans pour autant arriver à une situation plus enviable pour l'entreprise: c'est le cas où on a rogné sur l'apprentissage.

Ceci dit, je peux passer l'âme tranquille à la suite de mes remarques, encore moins intéressantes que la première:

Technique n°2 — se limiter strictement au cahier des charges

Parfois, en tant que développeur, on se dit "ah mais si je fais ça de telle manière, ça prend juste quelques jours de plus et ça permet d'avoir un système plus évolutif". Et en général plus complexe, donc plus fragile.

Oui et non, vu que très certainement il va falloir faire la maintenance du logiciel, cela peut être une bonne chose de s'y préparer – avec discernement, mais c'est justement ce discernement que peut apporter l'expérience au travers d'une palette de techniques éprouvées et validées qui résolvent justement ce problème.

Disons que si on se limite strictement au cahier des charges de façon la plus littérale qui soit, on peut dans certains cas torcher un programme tout mal fichu “qui fait le job” mais dont les évolutions sont impossibles à partir de 4-5 itérations, et là on se retrouve dans la pire situation, avec un bug en prod et un logiciel tellement mal conçu que réécrire tout ou partie est un a priori nécessaire à la réparation! (Vécu.)

Technique n°4 — faire du « test-driven » sur les interfaces

J'ai l'impression que tu cantonnes le “test-driven” aux test unitaires automatiques. C'est un exemple important, mais je trouve l'approche “test-driven” particulièrement utile pour la conception du logiciel, et même dans le cas où on n'automatise pas les tests. Privilégier les tests oblige à concevoir des modules qui ne font pas référence au contexte global de l'application, ils sont donc plus facilement réutilisables. Je trouve aussi particulièrement utile de déléguer tous les accès au système à des classes spécialisées: le reste du code est alors essentiellement pur et peut-être testé avec des classes simulant les appels système (mockup). Cette technique réduit la complexité de mise en œuvre du test et accélère la boucle de développement.

Technique n°6 — Diviser pour mieux régner

Bien souvent les jeunes diplômés (en particulier) ne veulent pas faire de maintenance mais veulent concevoir un logiciel entier. Et lorsqu'il s'agit de reprendre du code, plutôt que le faire évoluer ils préfèrent souvent tout refaire de zéro.

Ils ont bien tort, faire de la maintenance est une des meilleures écoles pour apprendre à programmer simplement et efficacement! (Si on se donne la peine de tirer les leçons de chaque opération de maintenance.)

Technique n°7 — Écrire du code simple

« Ce qui se conçoit bien s'énonce clairement » — Nicolas Boileay-Despréaux.

… et les mots pour le dire viennent aisément!

Souvent les développeurs veulent faire des choses compliquées, et exploiter les fonctionnalités d'un langage au maximum. Mais la réalité c'est qu'un logiciel qui est écrit simplement fonctionne aussi bien qu'un logiciel exploitant toutes les particularités d'un langage.

C'est exact, mais cela néglige complètement l'aspect maintenance (et aussi l'aspect apprentissage). Si une version, en plus d'être plus courte, est plus facile à maintenir, il n'y a aucune raison de ne pas la retenir!
- [^] # Re: Hypothèse fondamentale discutable
  
  Posté par LeBouquetin (site web personnel, Mastodon) le 21 février 2017 à 21:55. Évalué à 1.
  
  Merci pour tes retours, qui m'invitent à leur tour à des remarques
  
  Réduire les coûts sans sacrifier la qualité est évidemment intéressant pour l'entreprise ou le client car :
  - soit vous avez la même chose pour un coût inférieur,
  - soit vous avez un périmètre fonctionnel plus étendu pour le même prix.
  
  Ce n'est pas totalement vrai. Les plus gros défauts des analyses de coûts que je peux lire sont systématiquement 1. qu'elles font l'hypothèse que l'univers peut être modélisé avec des additions et dans quelques cas extrêmes des multiplications, et 2. qu'elles ne décrivent pas assez soigneusement le système qu'elles étudient. Ici c'est le 2, car lorsque tu as livré ton produit, ton entreprise n'est plus la même! Tu as des développeurs qui ont acquis des connaissances, soit purement techniques, soit plus conceptuelles (techniques de programmation, techniques de génie logiciel, gestion de projet par exemple), par exemple.
  
  Il n'empêche que c'est intéressant pour l'entreprise de pouvoir réduire les coûts pour une qualité équivalente. Ça n'est pas forcément LA solution à retenir (et en tout cas surtout pas la solution à retenir systématiquement). Après il faut savoir faire la distinction entre les cas où c'est à mettre en oeuvre et les cas où c'est à proscrire.
  
  Et je te rejoins sur le fait que certains projets peuvent ne pas être concernés par "une rentabilité optimale en terme de temps de dév". Mais sur certains projets (au hasard, des dév sur des technos vieillissantes et des produits qui sont condamnés), on peut réduire les temps de dév sans "bacler le travail", ce qui permet de consacrer plus de temps à d'autres projets.
  
  #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
  - [^] # Re: Hypothèse fondamentale discutable
    
    Posté par Alex G. le 26 février 2017 à 15:36. Évalué à 2.
    
    En fait mon expérience perso est que ce qui bouffe pas mal du temps dans la conception d'un projet c'est que le développeur n'est pas seulement un codeur (un traducteur en code machine) mais extrêmement souvent le gardien de la logique et de la cohérence de l'application. Il doit perdre du temps à expliquer au client pourquoi telle ou telle chose n'est pas souhaitable, lui montrer les incohérence qu'elle produit etc. (et c'est long et difficile, ce qui explique que parfois il n'a plus trop envie de communiquer avec le client et cherche à répondre lui même au questions comme noté dans la technique n°1). Perso je pense que le plus gros gain de temps (et de confort) c'est quand on a un client qui a un esprit logique et ne rebute pas à affronter les problèmes. (On pourrait imaginer un test de logique fait au client avant de lui fournir un devis :-P), et en tout cas un dialogue fluide (réactivité aux questions / réponses, points régulier) est plus qu'indispensable.
    
    Ceci dit la technique n°3 (commencer/prototyper les interfaces) est sûrement intéressante (mais peut conduire à des promesses ensuite difficile à tenir, quand on a occulté une difficulté technique).
    - [^] # Re: Hypothèse fondamentale discutable
      
      Posté par Michaël (site web personnel) le 27 février 2017 à 23:26. Évalué à 5.
      
      Il doit perdre du temps à expliquer au client pourquoi telle ou telle chose n'est pas souhaitable, lui montrer les incohérence qu'elle produit etc.
      
      “Consacrer” me semble plus judicieux que “perdre”, notamment pour la raison que rendre compte de ses choix techniques devant son client est une manière comme une autre de les mettre à l'épreuve, ce qui créé de la confiance.
      - [^] # Re: Hypothèse fondamentale discutable
        
        Posté par Alex G. le 28 février 2017 à 10:23. Évalué à 2.
        
        Tu as raison. Ceci dit suivant la capacité / rapidité de compréhension du client, tu as parfois l'impression de "perdre" (surtout dans les cas ou tu es au forfait en fait…)
        
        Mais ceci dit j'aime aussi la discussion avec les gens qui ont une "autre logique", ça amène aussi à se reposer parfois des questions plus fondamentales, alors qu'on était prisonnier d'un détail logique. Ça amène aussi des découvertes par sérendipité (une réponse illogique qui amène à se rendre compte que le besoin est un autre).
- [^] # Re: Hypothèse fondamentale discutable
  
  Posté par LeBouquetin (site web personnel, Mastodon) le 21 février 2017 à 22:06. Évalué à 3.
  
  Technique n°2 — se limiter strictement au cahier des charges
  
  Parfois, en tant que développeur, on se dit "ah mais si je fais ça de telle manière, ça prend juste quelques jours de plus et ça permet d'avoir un système plus évolutif". Et en général plus complexe, donc plus fragile.
  
  Oui et non, vu que très certainement il va falloir faire la maintenance du logiciel, cela peut être une bonne chose de s'y préparer – avec discernement, mais c'est justement ce discernement que peut apporter l'expérience au travers d'une palette de techniques éprouvées et validées qui résolvent justement ce problème.
  
  D'une manière générale (et je m'inclus dans le lot), la tendance est de sur-anticiper les attentes des futurs développements. Si tu as une bonne couverture de test, tu peux faire du refactoring conséquent en limitant les risques.
  
  Je te rejoins sur le fait que c'est avec l'expérience qu'on est capable de mieux en mieux de déceler ce qu'il serait bon d'anticiper et ce qui ne l'est probablement pas. Sans jamais en être certain.
  
  Disons que si on se limite strictement au cahier des charges de façon la plus littérale qui soit, on peut dans certains cas torcher un programme tout mal fichu “qui fait le job” mais dont les évolutions sont impossibles à partir de 4-5 itérations, et là on se retrouve dans la pire situation, avec un bug en prod et un logiciel tellement mal conçu que réécrire tout ou partie est un a priori nécessaire à la réparation! (Vécu.)
  
  Dans ce contexte, je parles d'un cahier des charges qui vient aussi avec des perspectives d'évolution.
  
  Dans le contexte dans lequel je suis, je prends en compte non seulement les possibilités d'évolution, mais aussi les coûts associés. Et ça, peu de développeur le perçoivent. L'anticipation d'une feature qui viendra peut-être et qui fragilise le code au point que tu passes des plombes à stabiliser c'est un paquet d'argent perdu (ou investi) d'une manière ou d'une autre (et dans le cas où on considère que c'est investi, c'est un investissement avec quel chance d'être rentable ?)
  
  Si tu sens qu'il y a une limitation dans le cahier des charges et que tu penses qu'il faut vraiment anticiper tel ou tel aspect, je te renvoie au point n°1 : en discuter avec le client. Ca ne t'apportera peut-être pas de réponse, mais ce qui est certain c'est que si tu n'en parles pas c'est un pari que tu fais.
  
  #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
- [^] # Re: Hypothèse fondamentale discutable
  
  Posté par LeBouquetin (site web personnel, Mastodon) le 21 février 2017 à 22:15. Évalué à 3.
  
  Souvent les développeurs veulent faire des choses compliquées, et exploiter les fonctionnalités d'un langage au maximum. Mais la réalité c'est qu'un logiciel qui est écrit simplement fonctionne aussi bien qu'un logiciel exploitant toutes les particularités d'un langage.
  C'est exact, mais cela néglige complètement l'aspect maintenance (et aussi l'aspect apprentissage). Si une version, en plus d'être plus courte, est plus facile à maintenir, il n'y a aucune raison de ne pas la retenir!
  
  Non justement, l'aspect maintenance est au coeur de cette remarque. Tu ne peux pas présumer du niveau d'expertise du développeur qui fera la maintenance de ton code. Pour caricaturer, si ton code est maintenable par un développeur qui ne connait pas ta techno, c'est une bonne chose.
  
  En python (la techno sur laquelle je travaille beaucoup), il y a des moyens de rendre le code tellement concis que tu es obligé de le lire à voix haute, voire de le réécrire en structure classique pour être sûr de ce qu'il fait (et encore). C'est 3 lignes de code économisées pour un niveau de crainte complètement disproportionné quand tu cherches à comprendre/faire évoluer le code.
  
  Exemple de code trop concis :
  
  msg = "Hi " + ("there" if not name else ("Neo" if name == "Anderson" else name))
  
  (ne ris pas, ça existe ce genre de code;)
  (et encore, là c'est pas imbriqué dans des boucles et des set de listes de générateurs;)
  
  #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
  - [^] # Re: Hypothèse fondamentale discutable
    
    Posté par xcomcmdr le 21 février 2017 à 22:36. Évalué à 3.
    
    (et encore, là c'est pas imbriqué dans des boucles et des set de listes de générateurs;)
    
    Le code trop imbriqué par le développeur ça existe quel que soit le langage, hélas.
    
    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
  - [^] # Re: Hypothèse fondamentale discutable
    
    Posté par Michaël (site web personnel) le 22 février 2017 à 10:42. Évalué à 5.
    Exemple de code trop concis :
    msg = "Hi " + ("there" if not name else ("Neo" if name == "Anderson" else name))
    
    Le problème n'est pas la concision, c'est l'imbitabilité. Il y a aussi des formes longues qui sont imbitables, c'est complètement indépendant de la concision.
    
    Un bon exemple de bavardages inutiles est l'utilisation de curseurs pour explorer les structures de données, qui dans de nombreux cas peuvent avantageusement être remplacés par des fonctions d'ordre supérieur. (Dans certains cas, les curseurs sont indispensables, par exemple si l'exploration doit être contrôlée finement, avec des pauses, des reprises, des bifurcations par exemple.) Qu'on juge:
```
/* Itérateurs à la C++ de la vieille école */
for(x = set.begin(); x != set.end(); ++x){
   cout << x;
}
```
    contre
```
(* Fonctions d'ordre supérieur, à la OCaml *) 
StringSet.iter set print_endline
```
    La second version est plus claire, car l'intention est directement mise en évidence, alors que dans la première il faut d'abord réduire la boucle for pour comprendre ce qu'elle fait, ce qui est rendu complexe par une variable supplémentaire, le x, qui a disparu dans la seconde version.
    
    Un autre exemple très frappant est l'utilisation du pattern matching, ici pour définir l'évaluation d'expressions booléennes:
```
type expr =
| Atom of string
| Not of expr
| And of expr * expr
| Or of expr * expr

let rec eval truthtable = function
| Atom(a) -> truthtable a
| Not(a) -> not(eval truhtable a)
| And(a,b) ->  (eval truhtable a) && (eval truhtable b)
| Or(a,b) ->  (eval truhtable a) || (eval truhtable b)
```
    C'est un code très concis, surtout en comparaison de l'équivalent C++ qui demande d'implémenter un visitor pattern sur 2-3 pages pour faire la même chose, et de faire de chaque cas du type une classe à part, ce qui ajouteau bavardage. Sur cet exemple, le code plus court gagne sur toute la ligne: plus facile à écrire, et surtout à lire: l'intention est claire, la vérification est immédiate et la maintenance aisée.
    
    Bien-sûr, on peut aussi utiliser les possibilités d'un langage pour écrire des choses absconses et difficiles à maintenir, mais existe-t-il un seul langage où cela n'est pas possible? Même des langages relativement pauvres en termes d'expressivité, comme le C ou Java par rapport à OCaml, Python ou Javascript, offrent tout ce qu'il faut à un programmeur pour écrire n'importe comment. Roedy Green et ses coauteurs ont d'ailleurs abondamment documenté ces techniques!
# Pas mal

Posté par Philippe F (site web personnel) le 21 février 2017 à 22:01. Évalué à 7.

Je suis plutôt d'accord avec l'ensemble des techniques proposées. A noter que les techniques 1, 2, 3, 5 et 6 font partie de la méthodologie SCRUM ou plus généralement de la philosophie agile.

Je note la préoccupation de passer du temps avec les développeurs pour les dissuader de ne pas en faire trop: ne pas utiliser le dernier framework à la mode, ne pas expérimenter de nouvelles techniques, ne pas faire d'interface générique quand il n'y a qu'un seul cas particulier identifié à présent, etc. C'est à mon sens une part importante de la réduction des coûts de dev et j'ai souvent embêté mes développeurs là-dessus:

Exemple

[le développeur naïf]: on nous a demandé un outil au plus vite pour gérer YYY, j'ai commencé à coder qqch en Qt
[le cost killer]: outil, ce n'est pas un outil graphique. Vu l'urgence du besoin, tu fais de la ligne de commande et on verra si on on réclame vraiment un GUI.

Dans le monde unix, la ligne de commande est bien connue et valorisée, mais pour des gens qui viennent du monde Windows, il est difficile de concevoir un outil sans interface graphique.

Autre exemple:

[le développeur naïf]: j'ai besoin de gérer la notion de configuration, j'ai vu une lib en python qui gère très bien les .ini , on part sur ça ?
[le cost killer]: la syntaxe python fait un très bon fichier de config, tu fais juste un safe_eval() et c'est parti, tu as gagné en flexibilité, familiarité et maintenance (les .ini, c'est chiant à faire évoluer).

Ce serait intéressant de partager d'autres exemples comme ça tirée de votre vie réelle.

Je note en tout cas que c'est vraiment un état d'esprit de faire court et simple (KISS comme on dit de l'autre côté de l'Atlantique), et qu'il est pas si répandu que ça. Le but du projet n'est pas de faire plaisir au développeur mais au client.

L'approche agile par itération pour ce point est vraiment un must!
- [^] # Re: Pas mal
  
  Posté par wilk le 22 février 2017 à 11:15. Évalué à 5.
  
  Le but du projet n'est pas de faire plaisir au développeur mais au client.
  
  Ha non alors !
  Il ne faut pas sous estimer l'avantage de se faire plaisir sous peine de risquer de bacler le projet et de le payer par la suite.
  
  Au contraire, se faire plaisir c'est un investissement largement rentabilisé à long terme.
# Pas compris

Posté par Graveen le 21 février 2017 à 22:36. Évalué à 5.

J'ai lu ta prose, elle est confuse, et … on ne sait pas trop à quoi ca sert ni ce que tu veux vraiment dire.

Il n'y a pas de recette pour avoir quelque chose de mieux ou égal, pour moins cher. Si c'est le cas, c'est que ton devis n'est pas juste; chiffrer du proto pour du logiciel de prod est une erreur.

Du coup je prends ton journal comme un aide mémoire de conception avant-vente, ou un aide-mémoire des bonnes pratiques de définition et gestion d'un projet. Mais pas beaucoup plus. Une grande partie de ce que tu cites (les TDDs, les architectures…) sont soit des actions de bon sens, soit une vulgarisation qui n'est pas systématiquement applicable ou pertinente.
# Ergonomie !!

Posté par philm (site web personnel) le 22 février 2017 à 01:25. Évalué à 9.

En tant qu'utilisateur final & non informaticien je me mets très bien à la place du client.
En général ce que propose les prestataires fait le boulôt. Ou alors c'est grave. Ce n'est pas ce qui va faire râler le client. Mais vingt-trois clic pour arriver à générer un rapport, ce qu'on va faire toute la journée, ça, ça fait râler.
Petit exemple : je doit écrire des compte-rendus de plusieurs pages dans un carré de 10*10 cm sur mon superbe écran de 20'. Avec un nombre de colonnes & de lignes digne d'un Minitel première génération. La machinerie derrière marche très bien mais je m'en fiche ! Pouvoir afficher à l'écran les informations dont j'ai besoin pour ce compte-rendu ça serait bien. Mais non je doit tout fermer pour le rouvrir après. C'est ce genre de "détails" qui fait passer le fournisseur pour un gros nul.
Et je ne parle pas d'un logiciel précis, je travaille sur plusieurs sites avec des produits différents, tous sont très mal conçus pour le clampin de base qui va l'avoir sous les yeux toute la journée.
Et ne pas oublier que tout le monde n'est pas informaticien. Faites valider vos interfaces utilisateurs par des non-informaticiens. Sur un logiciel métier que j'utilise, pour créer une ligne dans un tableau il faut créer un objet qui a des propriétés & des méthodes !
L'ergonomie c'est un métier.
# Pas pour moi

Posté par Pierre-Marie D le 22 février 2017 à 10:32. Évalué à 0. Dernière modification le 22 février 2017 à 10:34.

Régulièrement les prospects et clients trouvent que les coûts sont élevés et cherchent à les réduire. C'est naturel.

J'hésite à m'arrêter à cette phrase.
Réduire les coûts sans se soucier des impacts ou seulement de la qualité, je ne trouve pas que ça soit "naturel".
Mais c'est avis tout personnel…
- [^] # Re: Pas pour moi
  
  Posté par LeBouquetin (site web personnel, Mastodon) le 22 février 2017 à 13:35. Évalué à 3.
  
  Réduire les coûts sans se soucier des impacts ou seulement de la qualité, je ne trouve pas que ça soit "naturel".
  
  Personne n'a dit que c'était sans se soucier des impacts. Réduire les coûts c'est naturel, et toute personne qui met en concurrence 2 offres le fait. Qu'il s'agisse de professionnels et de particuliers.
  
  Ca ne veut pas dire ne pas se soucier des impacts ni de la qualité, ça veut juste dire : "si tu peux payer moins cher pour le même produit/service, tu le fais". En tout cas, quand tu achètes, ça entre en ligne de compte.
  
  La question "est-ce que c'est le même service" est une autre question et c'est de la responsabilité des personnes concernées d'expliquer que non ça n'est probablement pas le même service.
  
  #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
  - [^] # Re: Pas pour moi
    
    Posté par Pierre-Marie D le 22 février 2017 à 13:55. Évalué à 2. Dernière modification le 22 février 2017 à 13:55.
    
    Sans doute que mon sous-entendu ne devait pas être clair.
    J'évoque l'impact humain (souvent appelé social) qui n'est que rarement pris en compte et quasi exclusivement négatif dès qu'on fait du downsize.
# Les gens.

Posté par Guillaume Smet (site web personnel) le 22 février 2017 à 11:06. Évalué à 6.
Le meilleur moyen de gagner du temps est d'avoir des "développeurs" qui sont capables de s'imprégner du métier des utilisateurs. Perso, je trouve le terme "développeur" un peu réducteur car le boulot ne se limite justement pas à développer.

Comprendre leurs enjeux, le pourquoi des tâches, ça change complètement la donne. Et ça évite énormément d'échanges et d'itérations inutiles.

Quelqu'un parlait d'ergonomie mais je pense que ça va même un peu plus loin que ça. Comprendre le métier de l'utilisateur, ça permet également de prendre du recul par rapport à ses souhaits pour lui proposer une meilleure solution qu'il n'avait pas imaginée. Ou alors, quelque chose d'assez classique, qu'il n'avait pas osé proposer car il pensait que ça prendrait trop de temps.

Si je devais résumer ce qui nous permettait d'aller vite et d'avoir des clients contents dans mon job précédent :
- un socle technique réutilisé sur tous les projets
- n'intégrer des nouvelles technos que si elles ont un apport manifeste
- la capacité à générer le template du projet en une commande
- une archi standard enrichie d'éléments spécifiques si nécessaire
- des technos qui vont plutôt à l'opposé de la mode actuelle : plus c'est compilé, mieux c'est (tout en évitant la lourdeur)
- des bonnes discussions avec le client pour comprendre le métier, les enjeux, le pourquoi du comment… Comme introduction, assez souvent, définir les grandes lignes du modèle de données avec eux aide bien à déblayer le terrain et à lever des loups, c'est un bon outil de discussion. Et creuser, toujours creuser pour mieux appréhender.
- une équipe de gens intelligents qui prennent en compte ces enjeux, prennent du recul par rapport à ce qu'ils font et savent se placer dans la peau d'un utilisateur
- une équipe qui bosse pour rendre les clients contents et pas que pour se faire plaisir techniquement
Et si on n'a pas les gens qui vont bien, on peut mettre en place toutes les méthodes qu'on veut, le résultat ne sera jamais terrible et ça prendra toujours plus longtemps que nécessaire. La clé, c'est de recruter les bonnes personnes pour construire une équipe efficace et qui se complète bien. Le reste, ça va plutôt tout seul.

Personnellement, un des trucs qui m'a toujours le plus plu dans ce métier (note : on bossait sur des applications métier, pas des sites web), c'est la capacité à découvrir des métiers totalement différents et de s'en imprégner, c'est vraiment super enrichissant et motivant. Et je pense qu'on devrait mettre cela plus en avant.
- [^] # Re: Les gens.
  
  Posté par wilk le 22 février 2017 à 11:43. Évalué à 2.
  
  …ne pas intégrer de nouvelles technos…
  une équipe qui bosse pour rendre les clients contents et pas que pour se faire plaisir techniquement
  
  Je considère au contraire que les deux sont indissociables. Il n'y a pas meilleur moteur que d'être motivé par ce que l'on fait, le résultat s'en ressent et le client en bénéficie aussi. Inversement il n'y a pas pire que de travailler frustré (on ne serait d'ailleurs pas ici pour en parler !).
  
  Aussi, pour cette même raison, je te rejoint sur le fait qu'il est bénéfique d'avoir une bonne compréhension du métier de l'utilisateur. Ca ne parait pas forcément indispensable au départ mais ça paye. Pour mon premier client à l'époque je n'avais pas hésité à manier le marteau-piqueur sur leurs chantiers, du coup j'ai gardé ce client plus de 20 ans et aujourd'hui je peux expliquer aux utilisateurs de mon programme comment fonctionne leur entreprise et pourquoi il est inutile d'espérer que mr X remplisse lui-même le formulaire avec son smartphone !
  - [^] # Re: Les gens.
    
    Posté par Guillaume Smet (site web personnel) le 22 février 2017 à 13:05. Évalué à 1. Dernière modification le 22 février 2017 à 13:07.
    
    Le truc, c'est que tu te fais plaisir différemment. Par ailleurs, tu as un peu tronqué ce que je disais : il faut intégrer des nouvelles technos mais pas juste parce que c'est le dernier truc à la mode mais parce qu'elles apportent fondamentalement quelque chose - notamment se simplifier la vie et ne pas réinventer la roue.
    
    Le fait de ne pas démarrer sans arrêt sur une nouvelle techno, c'est aussi ne pas refaire sans arrêt les mêmes choses : tu capitalises de projet en projet et du coup, tu fais des choses nouvelles et pas la même chose dans un nième langage différent parce qu'il est plus kikoo lol à l'instant t (et deviendra gavant à l'instant t+1).
    
    Tu intègres des nouvelles technos quand elles ont un intérêt, pas juste pour dire de tester une nouvelle techno. C'est frustrant pour une catégorie de gens mais pas pour tous - comprendre pas pour ceux que j'embauchais :). Il y a des gens qui prennent plaisir à construire de belles choses sur des fondations solides. A optimiser les choses pour que le démarrage du prochain projet soit encore plus rapide, le projet encore plus efficace et moins répétitif. Evidemment, il faut que les fondations solides soient chouettes pour que ce soit plaisant. Sinon, ça ne marche pas bien.
    
    Le fait d'avoir un socle préexistant, ça réduit le risque global, ça permet aussi de prendre plus de risques contrôlés sur des nouveaux enjeux. Du coup, on peut aussi tenter plus de choses.
    
    Et tu trouves aussi ton plaisir sur les nouveaux défis qui sont amenés par les nouveaux projets (bien les choisir est important). Qu'il soit plus gros, plus technique, dans un domaine complètement différent, ça apporte de toute manière plein de choses.
    
    Finalement, je pense que toute l'astuce est de faire en sorte que les gens trouvent un sens à ce qu'ils font. Ca marche en général bien mieux comme ça.
    
    Ah et j'oubliais un point important également lié aux gens : la réussite d'un projet, ça dépend aussi en grande partie du client. Tu peux mettre une équipe de rêve qui donne tout pour que ce soit une réussite, avec le mauvais client, ça donnera un mauvais projet. L'envie de faire des belles choses et la confiance doivent être partagées, ça permet aussi de gagner un temps fou.
- [^] # Re: Les gens.
  
  Posté par LeBouquetin (site web personnel, Mastodon) le 22 février 2017 à 13:56. Évalué à 3.
  Et si on n'a pas les gens qui vont bien, on peut mettre en place toutes les méthodes qu'on veut, le résultat ne sera jamais terrible et ça prendra toujours plus longtemps que nécessaire. La clé, c'est de recruter les bonnes personnes pour construire une équipe efficace et qui se complète bien. Le reste, ça va plutôt tout seul.
  
  Entre deux équipes qui sont bien constituées, celle qui met en place (en plus) des méthodes de travail sera probablement meilleure.
  
  Personnellement, un des trucs qui m'a toujours le plus plu dans ce métier (note : on bossait sur des applications métier, pas des sites web),
  
  Je ne sais pas ce que tu entends par "faire des sites web" ; on ne fait pas de sites web, on fait des applications web. On ne peut pas comparer "développer une application métier" et "développer une application web" car il s'agit d'aspects orthogonaux : une appli web, ça parle des technologies, une appli métier de la finalité.
  
  c'est la capacité à découvrir des métiers totalement différents et de s'en imprégner, c'est vraiment super enrichissant et motivant. Et je pense qu'on devrait mettre cela plus en avant.
  
  Je te rejoints totalement, et c'est bien pour ça qu'on développe des applications web et non des sites web.
  
  Notre métier n'est pas de faire du graphisme mais de comprendre les besoins des utilisateurs (professionnels ou pas) et de leur proposer des outils qui résolvent un certain nombre de leurs problèmes.
  
  Deux exemples sur des projets qu'on a fait l'an dernier :
  - une plateforme de mise en relation entre éditeurs de logiciels et acheteurs. C'est pas notre métier, nous on est réalisateurs. Mais notre client c'est son métier de faire ça, et ce qu'on développe c'est un outil qui répond à ses besoins (il faut donc comprendre son métier)
  - une plateforme de multidiffusion d'annonces immobilières. C'est pas notre métier de faire de l'immobilier, mais une fois que tu comprends le quotidien des agents immobiliers ciblés, tu comprends rapidement quelle valeur ajoutée tu peux/dois leur proposer.
  C'est sûr on fait aussi du graphisme, on construit des écrans "responsive", mais notre différenciateur, ça n'est pas de faire un site beau et qui s'adapte à l'écran de l'utilisateur - ça tu prends n'importe quelle agence web et si tu paies correctement tu es sûr d'avoir un bon résultat ; notre différenciateur c'est d'être capable de comprendre les besoins exprimés et non exprimés et de conseiller et accompagner le client.
  
  Bref, tout ça pour dire qu'on fait bien des applications métier et qu'on est très content de le faire - pour les même raisons que toi :)
  
  #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
  - [^] # Re: Les gens.
    
    Posté par Guillaume Smet (site web personnel) le 22 février 2017 à 15:08. Évalué à 2.
    
    Entre deux équipes qui sont bien constituées, celle qui met en place (en plus) des méthodes de travail sera probablement meilleure.
    
    Sans doute. Encore que. Je pense que les méthodes qui marchent vont dépendre de ton équipe. Et du client.
    
    Le coeur du truc, ce sont les gens et on l'oublie trop souvent. Il y a eu une époque où les clients choisissaient forcément la société qui disait le plus qu'elle appliquait la méthode agile. Résultat, un paquet de projets sont allés dans le mur. Et les clients en sont revenus. Sur la fin, on avait même des clients qui vérifiaient bien qu'on ne faisait pas de l'agile.
    
    On avait notre méthode à nous qui correspondait à l'équipe, à comment on voulait faire nos projets et aux clients qu'on essayait d'avoir. Elle n'avait pas de nom mais elle nous correspondait. Et on l'adaptait aussi en fonction du client.
    
    Globalement, ça me gêne qu'on théorise trop parce que ça généralise quelque chose qui ne l'est pas vraiment car avant tout bâti sur l'humain.
    
    Je ne sais pas ce que tu entends par "faire des sites web"
    
    Je voulais juste différencier application métier vs pur site de présentation mais tu as compris donc c'était assez clair comme ça ;).
    
    Bref, tout ça pour dire qu'on fait bien des applications métier et qu'on est très content de le faire - pour les même raisons que toi :)
    
    Ouais, ça peut vraiment être très intéressant, contrairement à ce que beaucoup de gens pensent. Mais j'ai changé de vie maintenant.
    
    Bonne continuation en tout cas.
# Malheuresement...

Posté par dyno partouzeur du centre le 22 février 2017 à 12:39. Évalué à 7.

Technique n°1 — ne pas prendre de décision à la place du client
Réalité: le client sait rarement exactement ce qu'il veut, a du mal à l'exprimer et celui qui réalise a du mal à le comprendre.

Technique n°2 — se limiter strictement au cahier des charges
Réalité: voir ci-dessus. Un cahier des charges n'est jamais exhaustif et les besoins évoluent dans le temps. De plus le client se focalise sir les livrables et ne perçoit pas certains aspects annexes mais nécessaires) à la réalisation.

Technique n°3 — réduire le périmètre fonctionnel
Merci Monsieur de la Palisse. Moins on en fait moins ça prend de temps.

Technique n°4 — faire du « test-driven » sur les interfaces
Réalité: les interfaces sont rarement définies a priori, elles emergent d'elles même lors de l'écriture du code et évoluent encore ensuite. Il est donc impossible d'écrire des tests avant.

Technique n°5 — Faire de la conception progressive sur les composants internes
Bon là j'avoue j'ai pas lu, "conception progressive" a déclenché une alert buzzwords et j'ai juste pensé FOUTAISES!

Technique n°6 — Diviser pour mieux régner
Réalité: Tout ensemble logiciel est amené à devenir bordélique. Voir https://en.wikipedia.org/wiki/Software_rot
Le projet est en retard? Pas de problème on va embaucher des stagiares qui n'ont jamais codé ou sous-traiter à des indiens achetés au kilo. Evidemment
Besoin d'un hot-fix pour un problème de prod? Hop un gros "if" qui gère le cas particulier à l'endroit le plus facile ou là où on rique le moins de régressions, et tant pis pour la belle architecture.
On se rend compte que l'archi nous limite dans l'implémentation d'une fonctionnalité? Pas de chance, c'est une feature mineure et on ne va pas pouvoir justifier le coût d'un refactoring pour si peu alors on va faire un gros hack qui contourne la séparation en modules. Je vous jure c'est "temporaire".

Technique n°7 — Écrire du code simple
Si le code est trop simple, c'est sans oute qu'il n'apporte pas grand chose. Voir également ci-dessus: tout code simple se transformera à terme en un plat de spaghettis indigestes

Technique n°8 — Écrire un script de setup d'un environnement fonctionnel
Réalité: Personne parmi les dévelopeurs en place ne maintient le script. Le jour où on a besoin d'un nouvel environnement, ça chouine un peu, et on fait marcher à l'arrache le truc à moitié construit par le script d'il y a 6 mois qui est maintenant obsolète.

Moralité: la seule méthode qui marche c'est http://www.la-rache.com/
- [^] # Re: Malheuresement...
  
  Posté par Nicolas Boulay (site web personnel) le 22 février 2017 à 13:52. Évalué à 5.
  
  Réalité: le client sait rarement exactement ce qu'il veut, a du mal à l'exprimer et celui qui réalise a du mal à le comprendre.
  
  Oui, donc, il faut des réponses précises à des questions précises, c'est un peu ce qui est dit dans le journal.
  
  Réalité: voir ci-dessus. Un cahier des charges n'est jamais exhaustif et les besoins évoluent dans le temps. De plus le client se focalise sir les livrables et ne perçoit pas certains aspects annexes mais nécessaires) à la réalisation.
  
  Donc, tu livres le plus souvent possible, pour avoir un retour le plus souvent possible, ce qui pousse aux prototypages.
  
  Merci Monsieur de la Palisse. Moins on en fait moins ça prend de temps.
  
  Le client veut toujours papa/maman. Sauf quand il s'agit de payer. Classer les fonctionnalités permets de choisir l'ordre de priorité.
  
  Réalité: les interfaces sont rarement définies a priori, elles emergent d'elles même lors de l'écriture du code et évoluent encore ensuite. Il est donc impossible d'écrire des tests avant.
  
  C'est dangereux ça. Cela veut dire que tu n'as pas de stabilité. Ce qui implique beaucoup de code spaghetti et des grosses dépendances que tu veux justement cassées.
  
  "La première sécurité est la liberté"
- [^] # Re: Malheuresement...
  
  Posté par floriang le 22 février 2017 à 16:28. Évalué à 2.
  
  Technique n°8 — Écrire un script de setup d'un environnement fonctionnel
  […]
  Moralité: la seule méthode qui marche c'est http://www.la-rache.com/
  
  Ou alors, c'est que l'environnement fonctionnel est trop compliqué… 😜
# On oublie le MOP et la generation de code à partir des prédicats de haut niveau

Posté par jepostesurlatribune le 22 février 2017 à 17:54. Évalué à 1. Dernière modification le 22 février 2017 à 17:55.

autre méthode,

Il y a le MOP de Pieter Hintjens associé à de la génération de code.

build early, build often, but build functionality.

ou l'on traite les concepts et on génère le code et les tests à partir des classes de représentation du pb.

dit comme ça c'est abscon, mais en fait c'est très logique. C'est juste un grand saut avec des outils de dev dont on a pas l'habitude.

Il en a fait son business.
- [^] # Re: On oublie le MOP et la generation de code à partir des prédicats de haut niveau
  
  Posté par Nicolas Boulay (site web personnel) le 23 février 2017 à 09:43. Évalué à 3.
  
  Cela s'appelle ingénierie des modèles (j'inclue les DSL dedans).
  
  Je ne connais pas, par contre, d'outils qui permet de tout faire autour de ses concepts. Je bosse dans une équipe qui en fait un. C'est SCADE Architect. C'est sur une techno Eclipse EMF et SySML, on peut faire un diagramme de classe d'un problème, ensuite, on peut éditer un modèle (instance) graphique. Pour faire de la transformation de modèle (format standard, pour générer du code, …), il faut par contre écrire du code spécifique.
  
  "La première sécurité est la liberté"
# "Génie" logiciel

Posté par harlock974 le 23 février 2017 à 06:05. Évalué à 3.

Il y a aussi ceux qui utilisent des environnements de développement super graphiques permettant de programmer super rapidement sans presque coder.
Un fournisseur avait réussi à nous refiler un logiciel réalisé comme ça grâce à un AGL appelé WinDev (de PC SOFT).
Résultat, au bout de 6 mois, poubelle : trop lourd, trop lent, trop instable…
- [^] # Re: "Génie" logiciel
  
  Posté par lasher le 24 février 2017 à 00:38. Évalué à 3.
  
  Il existe des environnements pour faire du développement orienté modèles, etc. qui marchent, mais ils ont tendance à se spécialiser sur des domaines précis.
  
  Après, le problème du génie logiciel, c'est que certains veulent faire croire que c'est une science, alors que ça commence tout juste à enfin trouver ses marques et effectivement proposer un certain formalisme. Les gens oublient juste qu'il a fallu ~200-300 ans pour formaliser les méthodes du génie mécanique une fois qu'on avait enfin des outils mathématiques efficaces pour aider à la conception de systèmes mécaniques (merci Newton, merci Leibnitz).
- [^] # Re: "Génie" logiciel
  
  Posté par Philippe GRAILLE le 24 février 2017 à 14:18. Évalué à 5.
  
  C'est ça le génie logiciel ? ;)
  
  Est ce l'outil qui en est la cause ?
  Souvent c'est sa mauvaise utilisation, surtout quand il est facile d'accès il est utilisée par des bricoleurs qui se croient des génies …
  
  Windev pour l'avoir utilisé et connaitre certains produits fait avec, est capable de jolie choses mais cela demande les même types de compétences que du C# ou Java.
  Pas de miracle !
# Découpages, responsabilités et API

Posté par Alex G. le 26 février 2017 à 16:03. Évalué à 1.

Tout d'abord merci pour ce journal, je trouve vraiment intéressant de prendre du recul comme ça. De plus le développement de projet au forfait n'est vraiment pas un métier facile.

Les API bien faite c'est vraiment le Graal, ce qui rende le produit évolutif et perso je pense qu'il faut au contraire pouvoir les casser pour arriver petit à petit à la bonne convergence. Seule règle que je trouve intéressante : les API de haut niveau devrait parler en langage métier (utiliser les mots / les concepts) c'est ce qui bougera le moins. Bien sur on a souvent besoin d'aller dans plus de détails technique (par exemple on a pas seulement des utilisateurs mais on doit se connecter à une BDD ou un LDAP…) doivent la encore refléter le mots de cet univers technique et si possible être dé-corrélées.

Concernant les tests, j'ai déjà essayé de faire des tests qui produisaient en sorti un scénario : je suis tel utilisateur, je fais ça puis ça, il se passe ça, etc… j'ai vu que malheureusement, comme j'ai dit dans un commentaire précédent, les clients n'ont souvent pas la volonté de vérifier tout ça ou pas la compétence d'en vérifier la cohérence. Le dialogue de personne à personne, l'écoute et l'intuition du besoin et du métier, la capacité de raisonnement et de créativité restent souvent les meilleurs facteurs de succès.

Le découpage en responsabilité et composants est également important et là encore très difficile à juger du premier coup. Par exemple je pourrais souvent, au début, mettre utilisateurs, groupes et permissions ensemble, mais si ça se complexifié ça devient un poids. De plus il faut éviter les dépendances croisées (A dépend de B qui dépend de A) qui sont une plaie pour les évolutions (il faut un A' qui dépend de A et B et éventuellement un B' qui dépend aussi de A et B) mais c'est très difficile de prendre la décision de refactorer au bon moment. Car sinon on va être dans l'over-engineering. Mais en pratique on se rend souvent compte trop tard, qu'à force d'entorses, on aurait dû séparer en plusieurs responsabilités. C'est de la dette technique et peu de client acceptent de payer pour ça (ou il faut vraiment une relation de confiance).

Tout cela sans compter que dans mon expérience sur une équipe de dév il y aura souvent 60% des gens qui n'auront pas une grande attention à ces discours, les trouverons obscurs ou superflus, ou simplement auront une petit flemme de bien faire et ne suivront donc que partiellement ces consignes…

Bref, je ne pense pas qu'il y ai de silver bullet. Par contre effectivement avoir une personne qui, dans l'équipe, tient l'œil sur ces points, mener des réflexions ensemble là dessus, est toujours intéressant et peut porter à un mieux.
- [^] # Re: Découpages, responsabilités et API
  
  Posté par Alex G. le 26 février 2017 à 16:18. Évalué à 1.
  
  Ah oui j'oubliais de dire que tout cela est aussi inhérent à ce que je nomme "métier de la connaissance" (voir Knowledg worker. On n'appréhende qu'un système ou un concept qu'avec le temps, qu'avec sa manipulation. Parfois ceci change complètement notre vision par rapport à la vision initiale. C'est la même chose pour l'API et le découpage du code, c'est souvent à la fin de projet qu'on a une idée plus claire de comment il aurait fallu faire…
  Et c'est bien le problème que tente d'adresser les méthodes agiles.