Reprise du message précédent :
Tu peux expliquer comment t'as réduit la taille du code à ce point ? J'imagine que ça s'est pas fait au détriment des fonctionnalités ? Utilisation de lib ? factorisation ? Ou alors t'as carrément repensé la logique du produit ?

tout  
mais on a viré des "fonctionnalités" aussi.
 
Le projet souffrait de Featuritis aussi.
 
et comme je suis dans l'équipe qui définit le produit d'avril à septembre, je contient aussi de ce côté là

Ok, par "fonctionnalités" tu veux dire des options inutiles genre changer la couleur de la toolbar ? (me semble que t'avait parlé de ca)
 
et une dernière question: cette "refonte" s'est faite en parallèle d'une release, a partir d'une initiative personnelle avec nuit blanches à la clé ou bien y'avait un projet de refonte bien défini avec un cout chiffré et l'implication de toute l'équipe ?

Chez nous, on supprime du code qui ne sert plus, on factorise, on simplifie le code. C'est tout con, mais c'est efficace.
 

Les Related quotes

Ils ont quand même réussi à placer une quote de Bruce Lee, faut le faire

non, on écrit un générateur de tests, donc les fonctionnalités pour aider le générateur à bosser, les fonctionnalités pour choisir l'algo de génération, le timeout etc. On les a virées. D'autre part on a changé la techno interne, donc on a rien releasé pendant 4 mois.
 
Mais c'est surtout les pratiques de dev qui ont changé : régulièrement un dev en a plein le cul de voir un bout de code crade, et il prend le temps de lui peter la rondelle. Ou avant de faire une modif, y'a souvent un temps pour préparer le terrain.

tu peux raconter brièvement ?
edit> car au bureau on a du pilotage classique de projet et je serais curieux de voir ce que ça pourrait nous apporter car visiblement on a la même "architecture" de code/produits que vous aviez...

ouaou, ça va être long.
 
première chose : propriété collective du code, tout le monde commite dans toute l'appli. Pour l'administration système, elle est répartie sur 4 personnes (les autres, dont moi, ont pas envie d'en faire).
 
ensuite : tous les jours à midi, on réuni toute l'équipe debout 10 min c'est le scrumm meeting. on fait passer un objet de main en main, celui qui a le truc parle, il dit ce qu'il a fait hier aprèm' et ce qu'il compte faire cet aprèm'. Une fois le tour fini on fait passer les annonces et les discussions (une série de points qu'on marque au tableau au cours de la journée pour ça justement). Par exemple ce midi je vais dire que hier et ce matin j'ai modifié la vue des instances et cet aprèm' je vais faire une release. Comme point, on va parler d'avancer le meeting de 15min, qu'on va faire une nouvelle release, les Délégué du personnel vont debriefer la réunion avec le PDG, etc.
 
 
suite bientôt ....

j'ose même pas imaginer ça ici    
mais ça pourrait être pas mal cela dit...

attends, je fais caca, je fais ma release et je te donne les *vrais gros* changements qu'on a fait ...

 
en même temps ils attribuent à St Ex une phrase de De Vinci...mais bon
 

ah ouhais c'est marrant ça...j'aime bien entendre parler de ces mise en oeuvre de technique de gestion d'équipe un peu différente...lors d'une prez de notre équipe méthode, ils ont parlé d'une technique d'animation de meeting avec des cartes...quand ca discute planification des taches, on évoque les taches, et chacun a des cartes allant de 1 à 10-15, et vote pour estimer le nombre de jours qu'il pense pour la tache...tlm vote, pour tt les taches...ce qui permet une approche par consencus rapide...ca a pas l'air mal ton truc, je m'en souviendrais si j'ai à animer des réunions pour savoir l'avancement de taches
 

fais gaffe nraynaud, tu vas finir par te rendre indispensable dans ta boite

Donc, tout notre processus est fondé sur des fiches cartonnées.
Les fiches blanche c'est les tâches d'amélioration de l'application (le dev quoi)
Les roses c'est les bugs
Les vertes les tâches techniques n'ayant pas de valeur directe pour le client (ex: gros refactorings, changement de version d'une lib, évaluation de Teamcity)
 
On a un grand tableau autocollant (j'avais jamais vu ça avant, mais c'est génial) avec 4 zones : "todo", "en cours", "à valider", et "fini". Rien de révolutionnaire (mais on a quand même réussi à optimiser ce tableau ).  
 
On a un système d'itération de 15 jours, qui fini un vendredi.
On a un mec dans la boîte qui a un rôle spécial (en ce moment c'est moi mais ça tourne régulièrement) on l'appelle le client XP. Si c'était une boîte de service, ça serait un employé du client ou un mec de l'AMOA, comme on est un éditeur et qu'on vend (enfin on tente, vu qu'on a que des grands comptes) sur étagère, on fait notre marketting nous-même.  
 
En fin d'itération, le lundi matin (pas trop tôt) on fait une rétrospective d'itération : on discute de ce qui vient de se finir. Le client XP fait une démo des nouveaux trucs, on réuni et on classe les faits marquants, on discute de ce qu'on voudrait améliorer, on regarde l'évolution de quelques stats: la vélocité (j'y reviendrai), la couverture des tests automatiques, et l'évolution du nombre de ligne de code. Ensuite les développeurs décident de la vélocité qu'ils s'engagent à atteindre lors de l'itération suivante (en fonction des congés, de ce qui vient de ce produire etc.).  
Ensuite le client XP, en début d'itération, il prépare la suivante : il choisi les fiches blanches qui devront être développées au coup suivant en mettant autant de point sur .
 
De temps en temps, il faut créer des nouvelles fiches blanches, ça c'est facile, on écrit une ou 2 phrases dessus, mais après, il faut faire ce qu'on appelle une cotation. Le client XP réuni les développeurs (et tout le monde ensemble, c'est un critère pour avoir un truc un peu reproductible) et négocie avec eux fiche par fiche un nombre de points par fiche. Les points, au début on met des hommes-jours (idéaux : sans les réunions et l'overhead) et quand le processus mûri, on met de la complexité relative de fiches (telle fiche semble 2 fois plus complexe que telle autre donc elle vaudra le double). Au cours de la discution, le client XP défini ce qu'il entend par la phrase qu'il a mis sur la fiche, donne l'esprit dans lequel il voit le truc (un peu de vision bordel), le contexte (un peu d'histoire), répond aux questions précises des développeurs sur le périmètre et discute en général avec les devs de la fonctionnalité. Au cours de la discussion, on peut décider de regrouper ou découper les fiches (en fonction de la quantité de boulot à faire). A l'issue de la discussion, les développeurs décident du nombre de points de la fiche (par concensus) et le client n'a pas le droit d'intervenir pour influencer le truc (même s'il en a envie ). Et ainsi de suite.
Donc la vélocité, c'est la somme des points qui sont sur les fiches dans la case "fini" en fin d'itération.
Les fiches vertes et roses ne rapportent pas de point.
 
Je mets toujours les fiches roses (les bugs donc) en premier, donc les développeurs prennent les bugs d'abord.
 
Le développeurs se mettent en binômes et prennent la première fiche sur le tableau. Ils développent la fiche, viennent voir le client XP régulièrement s'ils ont des questions, des pétouilles, des choix qui impactent le produit à faire. Le client XP est dans la salle des développeur et est interrompu en gros tous les quart d'heure (sauf quand les devs sont en réunion comme maintenant). Le client XP garde son autre boulot (donc je reste dev), mais il n'est tenu à aucun résultat concernant son ancien boulot. Il doit traiter immédiatement toutes les questions qu'on lui pose, bouger son cul pour aller voir l'écran du binôme qui l'appelle. Et je téléphone à nos consultants expatriés au moins 2 fois par semaine.
 
Ok, ça c'est le processus à court terme, la suite (que j'utilise pas vraiment) sur la plannif à long terme plus tard ....

c'est carré

ouais on a testé plein de trucs pendant les cotations (y compris ça), en ce moment on utilise une échelle bloquée (2, 4, 6, 10 points) et on discute autour.

t'inquiètes pas que c'est pas moi qui ait mis tout ça en place, c'est surtout le boss de l'équipe de dev.

non, par exemple pour les petites tâches je fous un post-it à un développeur il faut savoir downscaler les procédures.
 
En fait on donne une impression de bordel permanent, y'a jamais personne sur sa propre machine, ça bouge, ça discute (pas fort, c'est étonnant car on est 15 dans la salle), ça va au tableau etc.

visiblement vu les résultats ca a l'air efficace...
 
ceci dit pour l'avoir vu en live sur un plateau de 60 personnes, la discussion c la vie...tu vas voir un gars, un autre, à 3 dont 2 accroupis à coté du 3ème on discute vite, en 5 min le pb est expliqué, compris et des propals de solutions sont faites...
 
c très efficace, et c'est carrément un des points noirs de l'offshore pour moi : mixer tous les gens ensemble ca crée une dynamique : tu iras tjs plus facilement poser une question à un gars à 2m de toi qu'à un gars à 10.000 km

Tu vois nraynaud, c'est ce genre de trucs vraiment intéressants que tu pourrais blogger (au lieu de laisser ton blog mourir) où dont tu pourrais faire des articles (pas nécessairement de gros trucs, et pas nécessairement du point de vue d'un gars qui a poussé dans cette direction, juste du point de vue d'un dev qui a vu/suivi le déroulement du truc)

Et après ça permettrait aux gens à côté d'avoir des arguments pour essayer de mettre en place ce genre de trucs

Il a qu'a se faire interviewer par infoQ, on mettra ca dans les succes stories

 
+1000  

Pour ceux que ça interesse, il y a aussi les présentations des XP Days France 2007 ici
Il y en a 2/3 qui sont pas mal.

qq'un va à Javapolis cette année ?

Pour les curieux, voici notre bordel :

Les couleurs dont j'ai pas parlé sont le jaune, heu c'est des fiches à la con, c'est pas des tâches, c'est des reminders ; et le bleu qui sont des tâche d'admin.

les fiches en bas sur le truc blanc sont le stock
le bout de panneau à droite c'est de l'administration système, aucune idée de ce qu'il y a dessus.

on a un système d'intégration continue assez chevelu (et qui nous fait parfois perdre des cheveux AHAHHA) avec un panneau visible par tout le monde :

(la valid est en vrac, on sait, merci)

mais ou sont les stress tests

ben comme tout le monde, tu stress test en prod pardi

dans la valid
 
(y'a des modèles de fou là-dedans, genre des modèles qui ont 1000 if/else imbriqués et tout)

avec un collègue on a fait un peu de coding en binôme, c'est vraiment impressionnant la vitesse à laquelle on avance et surtout la propreté du bazar... le premier code et l'autre le soutient (corrige ça, est qu'il ne faudrait pas..., ouais t'as raison ce sera mieux comme ça, ...)
 
au bout du compte, on a fait en 3 jours ce qui était planifié pour une semaine et quand les fonctionnels ont testé le bazar ce fût vite torché.
 
faudra que je lise un peu sur le sujet tiens... ça à l'air pas mal comme méthode générale.

en ce moment on fait une expérimentation sur les binômes : on casse le binôme toute les demi-journées. donc chaque personne reste une journée sur une tâche.
 
L'expérimentation est en cours donc pas de résultats pour l'instant, mais on a trouvé ça dans un papier : http://www.excastle.com/blog/archi [...] /5721.aspx

Chuis déçu, il est pas funky du tout votre panal de tests

A qui le dis-tu...
 
Chez nous, c'est très exac tement tout le contraire: lourd, inefficace, pénible et inutile.

c'est un barbu linuxien pythonneux qui l'a fait

je dirais rien sur l'off shore, mes insultes reveilleraient le rambolitain

J'ai pas de barbe et j'aime pas pinux, ça doit être pour ça que je comprend pas pourquoi faire un panal aussi moche

 
quoi : l'offshore ou l'orga par plateau ?
 

 
l'offshore c'est comme la brandade de morue : bien fait ça peut être très bon...
 
plus sérieusement dans ma boite ce sont des malades de l'offshore, on a des objectifs de jours à offshoriser, aucun projet n'y échape meme pas les plus stratégiques...ca fait 3-4 ans que ca dure, il commence à y avoir des bons retours d'XP sur le sujet...et en gros les projets réussissent qd tu les mêles dès le départ au projet, qu'ils participent aux specs (ED + CTD), et qu'ils ont une bonne couche de fonctionnel...
le hic c'est que pour arriver à ça faut limite les faire venir 1-2 mois en début de projet, et là tu ruines un peu le business case à mon humble avis
 
on a de l'offshore en Inde (Mindtree, Geometrics) et du nearshore en Pologne (une division de ma boite)...le gros pb de l'inde, et de la pologne dans une moindre mesure, c'est le turnover...si on prend le temps de former des gars fonctionnelement, dans un an ils sont partis faut recommencer, on capitalise jamais rien...mais bon, dans ma boite y'a une raison de le faire : pas d'offshore = pas de marché indien = on refourgue pas nos camions, et vu la taille dudit marché on peut pas se permettre
 
sinon ces 2 dernières pages ont été fort instructives

+1

 

 
deja que j'aime pas les captcha, si c'est pour qu'il me sorte des mots pareils ..

tu veux le mien ? (il marche aussi en anglais)

Edit: ptain, suffit que je fasse un screenshot pour qu'une faute de frappe apparaisse dans la question... je corrige.

Le plus marrant, ça serait que ça passe pas parce que le serveur filtre les mots vilains

en même temps, "you must be at least 18 to"

c'est le captcha de fouettemoi.com de toutes façons ...