Reprise du message précédent :
ben le premier projet de Ken Beck était énorme autant que je sache, mais c'est difficile de faire du changement sur une grosse équipe à moins d'avoir un charisme de dingue.

Certes, mais ISO, ça rime avec pipo. Quand tu dois te plier aux normes CE ou FCC ou pire, si ton produit est soumis aux exigences de certaines administrations américaines (FDA, veteran hospitals ou autres), là, tu le sens vraiment passer. Les mecs viennent auditer chez toi et si tu n'es pas compliant, adieu le marché américain jusqu'à ce que tu satisfasses à leurs exigences. Exemple pour la doc: toute la documentation du produit doit satisfaire à un cycle de relecture/corrections par plusieurs relecteurs dont au moins un en dehors de l'équipe de concepteurs. Ce cycle est lui-même documenté et paraphé, chaque remarque devant être corrigée par l'auteur et acceptée par les relecteurs. T'imagines la lourdeur du processus... Les tests sont tous précisément décrits ainsi et les différences avec les résultats attendus justifiées. Les problèmes remontés par les clients ne doivent pas être plus vieux que 6 mois, et on n'a pas le droit de fermer un cas sans l'accord du client qui l'a fait ouvrir, etc. Et tout ça est précisément examiné par les auditeurs. Bref, ça ne s'improvise pas. Et j'imagine que c'est aussi comme ça chez Airbus et partout où les vies humaines sont en jeu. Mais là je dévie un peu du sujet initial, qui concernait le développemnt logiciel en particulier.

http://bossavit.com/files/XpGame.pdf

 
Oui, c'est en partie vrai.
Il y a quand même des souplesses, par exemples sur les cycles de développement, sur lesquels on est consultés (nous, développeurs) par avant. Il "suffira" de suivre ces cycles pour être conformes. Ce qui est plutôt bien vu donc, puisqu'on est pas cantoné au cycle en V par exemple. Pour la doc, tout ça, c'est vrai que c'est lourdingue. Pour les bugs, les tests, etc, on a des clients type Thalès où là c'est comme pour Airbus, on a pas le droit à l'erreur. Et là, la lourdeur prends tout son sens.
 
Je rajoute que je suis assez d'accord sur l'aspect pipo de la chose, maisnos chers décideurs y sont sensibles. Si ça apporte une certaine formalisation, c'est déjà un pas en avant.
 
Je suppose que l'idéal doit être de pouvoir définir des règles de développement en fonction d'un projet.

Une review d'un bouquin sur les méthodos :
http://www.maxwideman.com/papers/p [...] logies.pdf

hop 3c dans le nourrain : organisation
 
 

les fiches (pas les CRC, mais les fiches de boulot)
 
en rose, les bugs
 
photo prise aujourd'hui, l'itération se fini vendredi.
 
à gauche, ce qui est planifié pendant l'itération  
sur la fiche jaune, il y a la vélocité qu'on s'est engagé à faire.
Il reste une fiche blanche parce que le client a tenté de nous gratter des points en planifiant plus que ce qu'on s'était engagé à faire.
 
en bas à gauche, c'est le bonus, ce qu'on fait si on a plus de temps que prévu, c'est en général une partie de ce que planifiera le client à l'itération suivante.
 
en haut au mileu, ce qui est en cours.
en dessous, ce qui est développé, mais non validé
 
à droite ce qui est validé, c'est là qu'on compte les points en fin d'itération.
 
la feuille excel, c'est les congés de l'équipe de dev /o\

Ah oui, ça me rappelle une équipe au forfait qui utilisait ça, avec des ficelles en plus.
On s'amusait le soir à modifier un peu le tableau.
Comme ça le matin, le premier truc qu'ils faisaient c'était de tout remettre en ordre et de bien relire ce qu'ils avaient marqué.

ça c'est du vécu.    
Sinon, vous êtes combien dans votre équipe ?
Chaque itération, c'est combien grosso-modo de j.h ?
 
Pour l'instant je dois avancer avec une stagiaire limite compétente, et un contrat de qualif un peu chien fou.
Donc, je pense pas pouvoir arriver à ton niveau d'organisation avec les moyens à ma dispo...
Mais quand dans ma boite on arrivera à recruter une personne confirmée, j'espère pouvoir mettre en place une mini-team de dev de ce style... qui sait...

verdoux > c'est super intelligent, je suis fier de toi.
 
Remarque, on attend encore ta première contribution positive.

on est 9 en dev, 2 en validation, mais en ce moment c'est les vacances.
 
une itération c'est 2 semaines (comme on est au début on fait des itérations courtes pour mieux suivre le bousin).
 
C'est pas moi qui ai mis ça en place, on a recruté un mec qui connait XP pour ça.

Carrément, vous avez recruté un XP-Man exprès...
Vous faites du dév from scratch ou c'est de l'évolution applicative existante ?

c'est de la tentative de repsise oui
 
 
200 000 lignes de code de merde

May God bless you  
 
Sinon, ton cas m'intéresse bcp... Disons je (disons ma boite) me situe de l'autre côté.
On a un ERP maison qui est actuellement maintenu par un petit éditeur de logiciel (qui n'a d'ailleurs que nous comme client)
Le problème, c'est que pour l'instant, niveau organisation, c'est un peu free-style...
Ton histoire, ça m'inspire...
Comment vous faites pour gérer les modifs souhaitées en cours de route par le client ?

ben les fiches bleues, c'est ce qui a été ajouté après la planification initale du milestone.
 
y'a un très bon calcul à faire : calculer le nombre de points de vélocité ajoutés par itération, si c'est plus que ce que l'équipe c'est engagée à faire dans l'itération, ça veut dire que le projet ne se fini jamais.
Très pratique d'expliquer ça au client

Il y a surtout un apport marketing à mon avis. Le client y est sensible.

 
C'est ce que je sous entendais

je relance d'un banane :
http://www.agile2005.org/XR4.pdf#s [...] %20mind%22

http://www.zutubi.com/products/pul [...] ghtenment/

c'est moi, ou ils ne font que lister l'évidence ?

ouais, en fait je viens de capter qu'en fait c'est un vendeur de machin d'intégration continue, désolé /o\
 
mais je dois dire qu'ici on est pas encore au bout.
 
dans mon boulot précédent, y'avait rien de tout ça.

ah mais moi non plus, on est a peine en train de faire quelques tests U, mais je connais quand même l'objectif suivant, même si faudra bien deux ans pour que ca soit a peu pres répendu ici.
 
par contre on a déjà l'étape 6 (release automatisée)

on a même pas le prerequis

ah ouais, quand même

 
On a la gestion d'accès concurent et on versionne les fichiers produits, mais disons que le format de travail utilisable directement n'est pas versionné.

je bosse chez des pinpins

en fait, ce qu'il nous manque (en dehors que les tests c'est pas encore la fête à la maison, on couvre à 30%, ce qui sur un bloat pareil est pas mal je trouve), c'est :  
- la release automatisée dans le système de build et des tests automatiques sur cette release. mais c'est assez compliqué d'installer automatiquement une appli avec notre système d'installeur, on devrait passer au MSI, et nettoyer notre bloat dans les scripts ant
- le déploiement de la plateforme de dev complète rapidement.

De notre coté c'est plus simple : maven fait le war et execute les tests-u, et on a des scripts maison pour la diffusion sur serveurs d'intégration, puis de prod. Donc on peut cocher la case, mais ca a pas demandé d'effort particulier (et surtout, ca empeche pas que de la merde soit diffusée, même si y'en a moins que y'a deux ans)
 
Et y'a une sacrée motivation derriere, parce que si ca se vautre a la diffusion, je dois me lever plus tôt

motif de démisison
 
 
c'est vrai que de ce côté le web ça a des avantages.

bof, s'ils me foutent une crasse dans une jsp, j'ai aucun moyen de m'en rendre compte pour l'instant.
 
d'ailleurs, quelqu'un connait "selenium" ? http://www.openqa.org/selenium-core/

Moi ch'uis tout seul à développer, alors je tombe facile dans le cowboy-style... Un peu à l'arrache, je vais des trucs suivant ma motivation.
 
Bon là j'me suis quand-même mis aux tests unitaires, ce qui permet tout de suite de voir les problèmes d'implémentation, du coup mon appli ressemble un peu à quelque chose.
 
Mais c'est un peu dur quand y'a personne pour relire le code et dire si y'a pas des énormités...

Ouep
Ca marche plutôt *bien*
Je n'ai fais que des tests "basique" pour l'instant (en fait, je ne sais pas ecrire de test pertinant   )
 

  Pas besoin de courir dans toute la boite pour gueuler sur le con qui a fait du code de merde, tu sais qui sais directement, gain de temps, gain d'argent  
 
 
Pour un projet étudiant, on a utilisé SubVersion avec Trac : dès qu'il y a(vait) un commit je recevais un mail avec en liens la page Trac du commit. Je lis donc juste la partie du code qui a changé (en considérant que ce qui était avant était bon) donc je fais une petite relecture rapidos du code des autres et donc je les conseilles de changer si la qualité n'est pas bonne (exemple : code qui fait quelque chose qu'une fonction fait déjà, ou autre facteur completement subjectif...).
 
 
Sinon, C'est quoi la méthode pour écrire des tests significatifs ?  
Car mes tests ne volent pas haut et ne vérifie pas grand chose pour l'instant.
(a part vérifier que un egal fait bien un egal, ça ne fait rien d'autre...)
 
Vous auriez des lectures, autre ?

pragmatic unit testing ?