Les méthodes agiles, la communication, la documentation
Jonathan Lebrun
j'ai écrit un article dans lequel je me questionne sur certains points
concernant les méthodes agiles.
En voici le début :
Alors que je lisais cet article sur les methodes agiles, j'en viens à
me poser quelques questions sur 2 des termes généraux employés :
- Communication (les individus et leurs interactions)
- Des fonctionnalités opérationnelles (plutot que de la documentation
exhaustive)
Mes questions par rapport à ces affirmations :
- Qu'est-ce que la communication ?
- Qu'est-ce que de la documentation exhaustive ?
Dans ce que je comprends, communication veut dire communication
verbale exclusivement. Pourtant communiquer n'un acte de parole mais
aussi, et entre autres, d'écrit. Pour moi communiquer efficacement,
signifie faire passer un message compréhensible et s'assurer que le
message est compris pour tous les participants et surtout compris de
la même manière.
Le reste se trouve là :
http://jonathanlebrun.louerlinternet.com/technologie/les-methodes-agiles-la-communication-la-documentation
Pourriez-vous me donner vos avis sur ces sujets ?
Merci
Xavier NOPRE
Je viens de lire très vite ton article.
Avant d'y réagir, une petite question pour situer le contexte : quel est ton niveau de connaissance et surtout de pratique des méthodes agiles, et quelle(s) méthode(s) ?
Xavier NOPRE
ScrumMaster, Coach agile, Architecte
Emmanuel Lecharny
J'hésitais à lancer un Troll sur le sujet, je me disais que l'on
penserai que je suis un gros trolleur velu, mais, bon, si tu me prends
par les sentiments ;)
Je lirai ton post pendant le déjeuner, et je balancerai mes commentaires
sur le sujet, et quelques éructations additionelles dans l'après-midi
(sauf que je suis assez busy ces derniers temps, donc ça risque d'être
assez décousu).
Il ne faut pas réveiller le monstre qui somnole ;)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
yannick grenzinger
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Yannick Grenzinger
Emmanuel Lecharny
On 5/22/11 2:46 AM, Jonathan Lebrun wrote:
> Bonjour,
> j'ai écrit un article dans lequel je me questionne sur certains points
> concernant les méthodes agiles.
Concernant l'article que tu cites, quand il commence par :
“Une *méthode agile* est une approche itérative et incrémentale, qui est
menée dans un esprit collaboratif avec juste ce qu’il faut de
formalisme. Elle génère un produit de haute qualité tout en prenant en
compte l’évolution des besoins des clients”
je ne peux m'empêcher de penser que l'auteur est un enfonceur de portes
ouvertes, dans une maison sans murs. On se demande ce qui fait que le
produit est de haute qualité. En clair, du pipeau. Mais je pense qu'en
général, tout ce qui relève de "l'agile" est purement marketing.
Après tout, les personnes cités (Cokburn Fowler, Jeffries, etc) sont
peut-être des évangelistes hors pairs, mais ils ont codé quoi dans leur
vie ?
En ce qui concerne plus précisément L'agile manifesto, en quoi cela
est-il un gage de réussite d'un projet par rapport aux méthodes de base
(cycle en V, top-down, bottom-up, telles qu'on les pratiquaient dans les
années 1980/1990 ? Analysons :
1) Satisfaire le client est la priorité : ben oui, mon con. Mais c'est
juste une évidence.
2) Accueillir les demandes de changement « à bras ouverts » : va dire ça
au commercial, sur un projet au forfait...
3) Livrer le plus souvent possible des versions opérationnelles de
l’application : ouais, nous, à l'époque, on disait surtout : "celui qui
casse le build se fait fouetter la verge avec des orties trempées dans
du citron" (certes, c'est sexiste, mais il y avait peu de nana à
l'époque...). Ce qui revient au même, à condition de considérer le
niveau "d'operationalité" de l'appli. Faut pas rêver, sur un projet de 2
années/homme, livrer une version opérationnelle dans les 15 premiers
jours, c'est Cool & the Gang ("Just an illusion",
http://www.filestube.com/f4692e5edb204b4003e9/go.html)
4) Assurer une coopération permanente entre Client et Equipe projet :
c'est sûr, en 1988, quand j'ai commencé, le client vennait de Mars et
nous de Venus, donc chacun fermait sa gueule. Le client, de toute façon,
il raconte que des conneries, hein ? Pfff... Et c'est l'un des principes
essentiel ? mais c'est juste une évidence, non ?
5) *Construire des projets autour d’individus motivés *: ah, c'est donc
ça : on bossait qu'avec des connards patentés qui s'en branlaient à deux
mains, s'ils le voulaient bien, en 1990 ? Désolé, mais des individus
motivés, il y a 20 ans, c'étais la norme. Maintenenant, en SSII, c'est
un peu différent, et c'est sûr que si tu choisis des gars motivés,
intelligents, travailleurs, compétents, ne regardant pas sur les
horaires, maîtrisant leur planning, avec des ordinateurs puissants, sans
excès de bureaucratie, bien payés, avec un client intelligent qui sait
lire les diagrammes UML et te fait des retours en 24h chrono sur les
docs que tu lui remets, et que le commercial qui a vendu le projet a
fait son boulot correctement et que le client est prêt à payer le prix
demandé, alors, oui, ton projet sera un succès... Bref, Connerie...
6) Privilégier la conversation en face à face : ah, ben c'est drôle...
Nous on était plutôt à l'école de l'auberge du cul tourné, peut-être ?
7) Mesurer l’avancement du projet en termes de fonctionnalités de
l’application : pareil, on avait Malumba, grillot sénégalais, qui en
plus de mesurer l'avancement du projet, faisait revenir l'être aimer,
venir l'argens, soignait les blesures, redonnait la vigeur au mambre,
grand gourou afriquain, maléfice ppur chasser les daimons et
autres...Mais tu veux les mesurer avec quoi les progrès, si c'est pas en
termes de fonctionalités, sérieux ???
8) Faire avancer le projet à un rythme soutenable et constant : je sait
même pas ce que ça veut dire. J'ai jamais vu un projet se dérouler avec
des personnes bossant 7h par jour pendant toute la durée sans coup de
bourre.
9) Porter une attention continue à l’excellence technique et à la
conception : ah ah ah ! Mais bien sûr. D'habitude, on s'en tamponne.
D'ailleurs, c'est pas réellement un problème, ce qui compte, ce sont les
délais de toute façon. Va dire ça au commercial "oui, on est en retard,
mais on a pondu une tuerie de framework technique, même qu'on génère les
DAO à la volée, c'est juste bug free". je crois qu'il va sentir sa
cravatte le serrer...
10) Favoriser la simplicité : ça, si on peut, oui, c'est sûr que c'est
l'idéal. Malheureusement, on travaille avec des abrutis qui cherchent
toujours à faire des trucs super compliqués et vachement balaises. Mais
c'est normal, on respecte le principe (9). Pourquoi faire simple quand
on peut faire complexe, après tout ? Ah bon, c'est pas le cas dans vos
équipes ??? Feriez-vous de l'agile sans le savoir ?
11) Responsabiliser les équipes: les meilleures architectures,
spécifications et conceptions émergent d’équipes autoorganisées : Le
sommet ! D'habitude, on dit aux grouillots, que l'on traite d'ailleurs
de fonctionnaires, que c'est pas grave s'ils font de la merde. Ils
s'auto organisent aussi : à savoir qui part à 16h, qui arrive à 11h, et
qui apporte le pinard pour la dégust de mercredi midi. Et généralement,
les meilleurs émergent de là. Bon, sérieux, quand je staffe une équipe,
j'attend pas qu'elle s'auto-organise, je choisis les personnes
compétentes, je les place aux postes qui correspondent à leurs qualités,
je leur affecte des tâches dont la responsabilité leur est confiée, et
tout s'auto-organise de cette façon. Je connais pas d'autre système en
milieu contraint. (délais, coûts)
12) Ajuster, à intervalles réguliers, son comportement, ses processus
pour être plus efficace : oui, c'est sûr, nous on faisait le contraire,
à savoir trouver les moyens de faire plus lentement, de moindre qualité.
Bon, tu l'as compris, c'est juste un tissu de lieux communs. Appeler ça
"Agile", c'est juste prendre les gens pour des cons, et leurs vendre des
formations à 2500€ les 3 jours.
Ce qui est symptomatique, c'est que l'on a inventé une nouvelle
'profession' : le Coach Agile ! Visiblement, pour faire de l'agile
correctement, il faut des coachs. C'est nouveau. Ca doit être une sorte
de gourou auto-proclamé, pas assez compétent pour être ingénieur, pas
assez rigoureux pour être Ingénieur qualité. Remarque, ça laisse de la
place pour ceux qui savent parler dans l'oreille des bourrins (ou des
clients).
Bon, passons...
> En voici le début :
> Alors que je lisais cet article sur les methodes agiles, j'en viens à
> me poser quelques questions sur 2 des termes généraux employés :
>
> - Communication (les individus et leurs interactions)
> - Des fonctionnalités opérationnelles (plutot que de la documentation
> exhaustive)
>
> Mes questions par rapport à ces affirmations :
> - Qu'est-ce que la communication ?
> - Qu'est-ce que de la documentation exhaustive ?
>
> Dans ce que je comprends, communication veut dire communication
> verbale exclusivement. Pourtant communiquer n'un acte de parole mais
> aussi, et entre autres, d'écrit. Pour moi communiquer efficacement,
> signifie faire passer un message compréhensible et s'assurer que le
> message est compris pour tous les participants et surtout compris de
> la même manière.
Ta questions est extrèmement pertinente. Si on élimine le fatras
idéolo-pipeaunique Agile, le vrai problème est comment s'assurer que le
besoin client a été correctement compris, et comment s'assurer que les
équipes qui réalisent l'application sont capables de remonter les
questions au client de façon compréhensible par celui-ci.
Il n'y a pas qu'une communication verbale. En fait, c'est la plus
pauvre. L'écrit est plus formel, mais il se trouve que c'est le seul qui
soit contractuel, donc il ne doit pas être négligé. C'est aussi sous cet
aspect légal qu'il faut entendre l'exhaustivité : tout manque sera
considéré comme non contractuel. "Les paroles s'envolent, les écrits
restent..."
Mais il y a aussi d'autres modes de communication : la vue, par exemple.
On parlait à l'époque de méthode RAD, qui permettait de 'montrer' au
client le résutat final, une maquette. Cela n'est pas neuf, les
architectes font cela depuis des siècles. Le toucher aussi, mais pas
comme on l'entend. La maquette permet au client de 'tester' physiquement
le comportement de l'appli. Il saura dire tout de suite que la
navigation n'est pas confortable (les séquences de touches sont trop
complexes, etc).
Le plus important canal de communication, c'est quand même la confiance.
Pour qu'elle soit établie, il faut que chacun accepte que l'autre
comprend ce que l'on a en tête. C'est du non-dit, mais de l'évidence,
dont il s'agit. Evidence, que le fournisseur mettra les moyens
nécessaires pour aboutir. Non-dit, que le client trouve son intérêt à la
réussite du projet. Evidence que le contrat est un engagement. Non-dit
qu'une certaine latitude est laissé au fournisseur dans son costing,
evidence que le client sacrifiera les fonctionalités les moins
importantes, non-dit que cela ne se traduira pas par une négciation à la
baisse du prix pratiqué. Mais uniquement si une relation de confiance,
une communication de confiance, a été construite. C'est une
communication parce que cela se construit sur le long terme et sur la
crédibilité des actes du quotidien d'un projet. C'est aussi lié au fait
que notre engagement en tant que professionnels est basé sur "l'état de
l'art". C'est ce qu'on vend, en fait : nous mettons en oeuvre des
technos et des pratiques en respect de cet état de l'art. Les
professionnels du batiment ont formalisés cela sous le doux terme de DTU
: Document Technique Unifié, qui décrit les obligations implicite des
fournisseurs. En SSII, ce sera plutôt le dossier Qualité qui reprend ce
rôle.
En tout état de cause, devant un tribunal, c'est ce qui sera retenu : la
correspondance à l'état de l'art. Et quand on n'oublie pas cet aspect,
alors la communication verbale et écrite permettent de se concentrer sur
les aspects non triviaux.
Un petit interlude amusant : un ami m'a fait part d'un échange avec un
ingé en inde (outsourcing) qui lui avait rendu une merde fumante sans
tests ou presque. Au premier essai, il se tape un énorme
DivideByZeroException, parce que l'argument n'était pas checké et que la
première instruction de la méthode était une division par cet argument.
Bien sûr, pas de test unitaire. "Why didn't you check this condition ?"
"It was not in the specifications..."
Ca coupe juste court à toute discussion sur ce qu'est une spec
exhaustive. La spec exhaustive, c'est celle qui permet au développeur au
fait de l'état de l'art de coder la fonction sans avoir à s'inquiéter de
tels atrocités. Checker l'argument s'il peut générer un DBZE, c'est
juste une évidence, pas besoin de le spécifier.
Sur ton blog : j'adhère à 100% à ta conclusion, mais je vais plus loin.
Tu dis "Une méthode agile marchera sur des projets à courts termes", je
dis que non. Tu peux adopter n'importe quelle méthode sur un petit
projet, ça marchera aussi bien si tu as les personnes compétentes.
Pour moi, Agile, c'est juste un buzzword. De la prose, comme monsieur
Jourdain : on en fait *tous les putains de jours* de l'agile à ce titre.
Et j'ai pas besoin de me coller des postits au cul, ni de me mélanger
avec mes collègues dans une mélée furieuse (scrum), ou de programmer à
deux devant un écran (ah ah ah ! Le XPair programming, quelle vaste
plaisanterie...) pour pondre des applis qui marche correctement (plus ou
moins). Et vous non plus. be pragmatic, adapt.
I'm programming, Mother fucker !
Voilà, ça va nourrir la ML LCC sur les prochains jours, et je vais me
faire pourrir la gueule par les Coach Agile et autre, mais franchement,
je m'en cogne... D'un autre côté, une étiquette ne fait pas le pinard
non plus, et certans sont obligé par leur entreprise de faire figurer ce
titre sur leur CV...
Biz et love, les amis ! Je vous aime ! (c'est pour atténuer le caractère
trollesque du post :)
Emmanuel Lecharny
"Imagination", pas "Boules and the Glandes"
Nicolas Chambrier
Manu
Tout ton message peut se résumer en un seul fait, bien connu: l'Agile, ce n'est pas compatible avec le forfait.Du coup au final, c'est un peu toi qui enfonce des portes ouvertes, parce que justement tout le monde le sait que faire de l'agile au forfait, c'est illusoire ;)
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
To view this discussion on the web visit https://groups.google.com/d/msg/lescastcodeurs/-/bGlBaWdEOE1IS2dK.
Benoît Dissert
Tout ton message peut se résumer en un seul fait, bien connu: l'Agile, ce n'est pas compatible avec le forfait.Du coup au final, c'est un peu toi qui enfonce des portes ouvertes, parce que justement tout le monde le sait que faire de l'agile au forfait, c'est illusoire ;)
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Jean-Laurent de Morlhon
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Henri Gomez
> ayatollahs "agiles" et des troll-post de la LCC :
> On en a déjà parlé au snowcamp, vient bosser avec moi sur un projet où
> l'agilité est utilisé, tu pourras vraiment te faire ton opinion et de rendre
> compte de ce que c'est. En pratique en vrai, pas juste sur une ml.
Comme en toute chose la modération et la mesure sont obligatoires.
Il faut donc se méfier des ayatollahs pro ou contre agile mais piocher
dedans les bonnes idées, pratiques et méthodes applicables dans son
environnement de travail de tous les jours :)
Jeff MAURY
Il a même cité un exemple de projet au forfait lancé par BT sur Londres auquel Accenture a répondu et les conditions étaient les suivantes:
- Sprint d'une semaine avec delivery à la clé
- Si BT n'est pas satisfait, il peut interrompre le contrat.
A+
Jeff
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
"Legacy code" often differs from its suggested alternative by actually working and scaling.
- Bjarne Stroustrup
http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury
Etienne Charignon
D’habitude j'ai bien tes mails, mais la je trouve que là tu fait un
peu ta tête de con !
Si l'agilité était vraiment un lieu commun ça ne serrait pas si
difficile à mettre en place.
Je me souviens encore de la surprise d'une personne d'une grande SSII
française quand je lui ai dit que les développeurs parlaient
directement avec le client.
"Ah, mais on pourrait jamais faire ça chez nous !". Le gens qui
croient que les développeurs ont les lunettes trop sales ça cours les
rues.
Bref, en fait, le mouvement agile est plutôt sympathique. Les
développeurs que je croisent (et dont je fait partie) apprécient de
travailler comme ça et constatent une nette différence dans leur
travail au quotidien.
C'est dommage ta réaction... A moins que tu joue juste à faire le
troll mais dans ce cas, c'est un peu naz.
Etienne
Emmanuel Lecharny
> Emmanuel,
>
> Loin des conclusions fumeuses de ceux qui ne pratiquent pas, des
> ayatollahs "agiles" et des troll-post de la LCC :
> On en a déjà parlé au snowcamp, vient bosser avec moi sur un projet où
> l'agilité est utilisé, tu pourras vraiment te faire ton opinion et de rendre
> compte de ce que c'est. En pratique en vrai, pas juste sur une ml.
Je pense que je fais de l'agile tous les jours. Je pense qu'il n'y a pas
besoin de donner un nom à cette méthode de travail. Je pense que tout
ceux qui prétendent faire de l'agile ne font rien d'autre que de faire
ce que l'on faisait il y a vingt ans quand on appelait cela faire du
top-down.
C'est juste un problème de perception, en fait. Et de marketing. L'Homme
aime bien les étiquettes, ça le rassure.
Sinon, prend une équipe de branlos, avec des délais insuffisants, un
environnement inadapté, et bien, Agile ou pas, tu seras dans le mur.
Prend une équipe de cadors, des délais adaptés dans un cadre de
circonstance, Agile ou pas, tu réussiras.
Ce n'est pas la méthode qui fait l'Homme, c'est l'Homme qui fait la méthode.
Emmanuel Lecharny
> Déjà, il faudrait s'entendre sur ce qu'est la définition commune de
> l'agilité car j'ai assisté la semaine dernière à une formation ScrumMaster
> par J Sutherland et je lui ai posé la question du forfait mais il ne m'a pas
> semblé qu'il laissait entendre que Scrum et forfaits étaient incompatibles.
> Il a même cité un exemple de projet au forfait lancé par BT sur Londres
> auquel Accenture a répondu et les conditions étaient les suivantes:
>
> - Si BT n'est pas satisfait, il peut interrompre le contrat.
>
> Reste que visiblement, la gymnastique de la réponse ne semble pas simple: il
> préconise quelques sprints pour bien évaluer la date de fin et/ou un
> chiffrage mixte Agile/Waterfall.
Ca me semble gérable pour une boîte comme Accenture, qui surfacture ses
consultants.
Maintenant, on imagine une boîte de taille moyenne (style 500 salariés)
qui place 30 des siens sur un projet de ce type, bien sûr qu des bons
(c'est un des critères, non ?) et que le client décide brutalement à
l'issu d'un Sprint que le projet s'arrête...
La petite boîte se retrouve avec 6% de son staff en inter-contrat...
Comment elle s'en sort ???
Emmanuel Lecharny
> Salut Emmanuel,
>
> D’habitude j'ai bien tes mails, mais la je trouve que là tu fait un
> peu ta tête de con !
week-end..
> Si l'agilité était vraiment un lieu commun ça ne serrait pas si
> difficile à mettre en place.
> Je me souviens encore de la surprise d'une personne d'une grande SSII
> française quand je lui ai dit que les développeurs parlaient
> directement avec le client.
> "Ah, mais on pourrait jamais faire ça chez nous !". Le gens qui
> croient que les développeurs ont les lunettes trop sales ça cours les
> rues.
on parlait au client. C'est quoi la SSII qui interdit de parler au
client ? Ce ne serait pas plutôt la personne qui t'a remonté cette
anecdote qui a une vision étriquée du problème ?
> Bref, en fait, le mouvement agile est plutôt sympathique. Les
> développeurs que je croisent (et dont je fait partie) apprécient de
> travailler comme ça et constatent une nette différence dans leur
> travail au quotidien.
faudrait travailler, mais qu'on a sans doute perdu de vue ce mode de
fonctionnement suite à quelques années de crise (avant 2000, je te
promets que l'ambiance était radicalement différente).
Les contraintes économiques, la pression de l'offshore, et aussi la
transformation de la relation client-fournisseur a entraîné une
modification radicale de notre façon de travailler. On code moins, on se
cadre plus légalement parlant, les entreprises négocient comme des
truies sur les tarifs et les délais, il devient difficile de se faire
plaisir dans le cadre d'un projet puisque on est obliger de contrôler
tout ce que l'on dit au client (promettre ne serai-ce qu'un changement
de couleur fait l'objet d'avenants...)
Je caricature, bien sûr, mais mon propos est de dire que Agile ou pas,
ce n'est pas le problème. En soit, je n'ai rien contre l'Agile, Je
voulais juste mettre bien violemment les pieds deans le plats pour vous
faire réflechir. Etre Agile, c'est juste revenir aux base de notre
métier. On n'a pas besoin de coach ou de formations pour cela.
> C'est dommage ta réaction... A moins que tu joue juste à faire le
> troll mais dans ce cas, c'est un peu naz.
Un dernier truc : si tu bosses sur un projet OpenSource, et bien tu te
rends compte que tu pratiques *aussi* l'agile, toujours sans que cela se
dise. En fait, tu n'as qu'une contrainte en moins par rapport à un vrai
projet, le délai. Remarque que cela change tout.
Je récuse juste les faux prophètes qui ont eu la révélation en 2001,
avec le don sur le mont Sinaï des tables de la Loi (le Agile Manifesto),
et que d'un seul coup le monde Informatique a *enfin* découvert comment
il fallait travailler... Ca, c'est complètement naze...
Et n'oublie pas : tout ce qui est excessif est insignifiant :)
Trognon Patrice
+100
Tu as parfaitement résumé mon ressenti de l'agile :)
Pour brasser de l'air ça ne brasse
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Julien Vermillard
Je pense que tu a soulevé le merdier.. quand j’entends "ce n'est pas
évidant qu'un codeur parle au client.."
Quand le lit l'agile manifesto "value Working software over
comprehensive documentation" ont est pas loin de
programming motherfucker :)
La bonne chose de l'agile c'est qu'il met un nom et un peu de couleur
marketing sur une méthode ancestrale :
de bonnes équipes, de petite taille, qui codent en se parlant, qui
écoutent le client et qui se sortent les doigt du cul :D
Après s'il faut un guru payé très cher pour faire changer certain
excès de sur organisation, pourquoi pas.
Julien
Jonathan Lebrun
mais bof bof.
Par contre je vois autour de moi qui pense savoir ce que sont les
méthodes agiles mais en lisant à gauche et à droite, j'en suis de
moins en moins sûre (d'après les lectures et c'est parfois
inquiétant)
Par contre au delà de la méthode elle-même, c'est surtout la partie
communication entre équipe qui m'intéresse et comment la gérer. Dans
une même équipe de développement c'est ok mais comment gérer quand on
agit avec des équipes de tests, de déploiements, ... différentes et
qui travaillent sur plusieurs projets.
Jonathan
Jonathan Lebrun
fait d'accord avec les uses cases par exemple.
"L'agilité, c'est du jetable à court terme" : ça veut dire qu'on ne
fait que des projets à court termes? Ca ne marche pas avec des gros
projets?
On 1 juin, 11:49, yannick grenzinger <yannick.grenzin...@gmail.com>
wrote:
>
> En fait un des points intéressant de l'agilité par rapport à la
> documentation et la mémoire du projet c'est de rendre la doc obligatoire et
> directement associée au code.
>
> Comment ? bah simplement par les tests :)
> Tests unitaires, TDD pour forcer à faire les tests, BDD pour introduire une
> véritable notion fonctionnelle par les tests, etc
>
> L'agilité sans test c'est faire du jetable à court terme.
>
> Pour ton histoire du bleu roi vs bleu pastel, une spec n'aurait rien changé
> car la précision aurait tout autant été oublié.
> Par contre oui tu aurais pu te défendre devant l'échafaud de la performance
> que je vous assure monsieur le juge on ne me l'avait pas dis comme ça (ce
> qui est malheureusement trop souvent utile).
>
> Pour le texte est aussi utile qu'un schéma, je vais être un peu cash mais
> c'est faux : un schéma vaut toujours qu'un texte car plus rapide à
> comprendre et souvent moins sujet à interprétation.
>
> Après je pense que des bons schémas d'architecture et des explications des
> choix techniques ou fonctionnels permettent de faciliter un nouvel entrant.
>
> Yannick
>
> >> Pourriez-vous me donner vos avis sur ces sujets ?
>
> >> Merci
>
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> >www.iktek.com
>
> > --
> > Vous recevez ce message, car vous êtes abonné au groupe Google
> > Groupes lescastcodeurs.
> > Pour envoyer un message à ce groupe, adressez un e-mail à
> > lescast...@googlegroups.com.
> > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
> > lescastcodeur...@googlegroups.com.
> > Pour plus d'options, consultez la page de ce groupe :
> >http://groups.google.com/group/lescastcodeurs?hl=fr
>
> --
> Yannick Grenzinger
Arnaud Héritier
Jonathan Lebrun
En fait c'est ce que je ressent aussi mais pas ce que je sais.
Autre ressenti à propos de l'agile, c'est que ça se base sur les
développeurs. Je me pose alors la question suivante : un projet
informatique tourne-t-il uniquement autour des développeurs ?
Qu'en est-il du support des applications développées (des applications
avec un business assez lourd et qui ne tournent pas uniquement autour
des technologies employées et de l'architecture mais surtout de
l'emploi de l'application) ? Qu'en est-il des formateurs et des
personnes qui réalisent les manuels utilisateurs ? Ne font-elles pas
partie du projet informatique ?
Si on développe une application sensée tenir plusieurs années, comment
se passe la maintenance de l'application ? Comment fait-on pour le va
et vient des développeurs sur plusieurs années ?
Si Jean Devun a parlé avec le client en janvier 2010, que Jean s'en va
et est remplacé par Pierre Devdeu ? Que sait-il du projet ? Si Pierre
Devdeu modifie une implémentation discutée avec le client et le
documente par des tests et de la javadoc, comment Ed Supporter sait
que ces changements ont été faits ? Par la formation donnée par
Pierre ? Etc...
Je suis aussi d'accord avec le fait qu'il y des bonnes idées à piocher
dans Agile, mais ça veut dire que tout n'est pas bon et qu'il vaut
mieux créer sa propre méthodo avec les outils "offerts" à gauche et à
droite ?
Je sais, ces questions paraissent un peu bizarre mais j'ai du mal
d'avoir les idées claires là-dessus.
On 2 juin, 06:39, Trognon Patrice <ptrog...@gmail.com> wrote:
Thierry MERITAN
Equipe 5 à 7 personnes, entre 5 et 15 sprints : 5x20x5 minimum 500 jours donc.
Hélas beaucoup de client pense faire de l'agile alors qu'ils font du RAD (crade).
Thierry
Arnaud Héritier
Emmanuel Lecharny
> Hummm je pense qu'on va pouvoir faire rebondir notre ami Emmanuel sur un autre Buzz word actuel : devops
Ce que je sais, c'est qu'une équipe de développeurs ne comprenant pas ce
qu'est l'exploitation est juste bonne à coder de la merde. A tous le
moins, un des développeurs doit avoir en tête les contraintes
opérationnelles, et les faire prendre en compte par les développeurs.
Ca touche les logs, le failover, le crash disaster recovery,
l'exploitation applicative, l'infrastructure réseau, la scalabilité, la
gestion du pic de charge, la sécurité, la procédure d'installation, la
procédure de migration, la procédure d'exploitation. (j'en oublie
peut-être...)
Il faut avoir au moins un fois dans sa vie de développeur participé à
une mise en prod pour comprendre une partie de ces contraintes, et
j'avoue que c'est assez passionnant. Les exploitants (système et réseau)
ne sont pas des autistes ou des abrutis complets, au contraire. Ils sont
malheureusement en bout de chaîne, sans explication sur ce qu'ils
doivent installer ni administrer, et se faire respecter en tant que
développeur par un administrateur impose une relation autre que écrite.
Une bière de temps en temps peut aider...
Yannick Grenzinger
"L'agilité SANS LES TESTS c'est du jetable" :)
Yannick
Emmanuel Lecharny
> Je me permets de répondre.
>
> En fait un des points intéressant de l'agilité par rapport à la
> documentation et la mémoire du projet c'est de rendre la doc obligatoire et
> directement associée au code.
excuse, mais de quelle doc parles-tu ?
> Comment ? bah simplement par les tests :)
> Tests unitaires, TDD pour forcer à faire les tests, BDD pour introduire une
> véritable notion fonctionnelle par les tests, etc
BS. TDD, c'est comme Agile, c'est just un bizzword. Il y en a qui
aiment, mais ça fait pas avancer un projet.
C'est encore une vision par le petit bout de la lorgnette : "mes
développeurs ne testent pas, on va les forcer à écrire les tests
d'abord, comme ça, on aura des tests" (je schématise). C'est un peu
comme si on disait à un enfant : "tu ne mangeras pas tant que tu n'auras
pas prouvé que tu ne peux pas aller sur le pot faire ton caca tout seul".
Les tests font partie du métier. Pas besoin de TDD pour cela. Il y a 20
ans, on faisait déjà des tests (en boîte blanche et en boîte noire) et
je pense que c'était aussi le cas il y a 40 ans...
C'est quand même marrant cette tendance à renommer des pratiques
complètement évidentes, et que cela donne des érections à des petits
jeunes qui ont l'impression de découvir le nouveau monde ! Les gars,
l'amérique a été colonisée par l'ouest 15 000 ans avant les espagnols !
(je dit cela sans méchanceté, j'ai aussi été bercé par l'illusion que
mes illustres ancêtres qui faisaient du Cobol était juste des
dinosaures, et que moi, je faisait partie de la nouvelle vague. Jusqu'au
jour où j'ai compris que rien de neuf n'a été inventé en informatique
depuis Dijkstra - ou si peu... On est tous forcément un con à un moment
de sa vie. Parfois toute sa vie :)
Pierre-Yves Ricau
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Pierre-Yves Ricau
http://cv.piwai.info
ehsavoie
le but de TDD n'est pas de tester mais de faire émerger le design et de décrire les spécifications sous forme de tests.
J'ecris ce que je veux puis j'ecris ce qu'il faut de code pour l'obtenir : l'intérêt est dans la double approche du problème sa description et sa solution.
Parfois on est tellement dans le comment qu'on en oublie le problème que l'on résoud et le TDD permet d'avoir ce recul (là encore rien de neuf) et surtout une trace écrite
et exécutable. Le filet de tests de non régression n'est qu'un effet secondaire.
Le code produit dans un mode tests à posteriori est en moyenne (car hélas le monde n'est pas fait que de brutos) plus concis et plus simple donc ca fait avancer un projet ;o)
Après moi je dis I'm prograaming and unit-testing motherfucker et je pendrais bien ceux qui ont osé écrire le code que je refactore....
----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie
Jean-Laurent de Morlhon
Patrice Trognon
100% d'accord, ou mieux encore que l'équipe de dev bosse avec l'équipe d'exploitation afin que
leurs exigences (tout à fait justifiées) puissent être prise en compte dès le début.
De toute façon cette synergie est souhaitable une fois que le passage en prod est terminé
donc une fois que les vrais problèmes vont commencer à apparaitre.
bref, quand le dev a terminé son code en réalité il n'a fait que 25% de son taf :)
Pat
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Baptiste MATHUS
Juste pour éclaircir ce point :
le but de TDD n'est pas de tester mais de faire émerger le design et de décrire les spécifications sous forme de tests.
J'ecris ce que je veux puis j'ecris ce qu'il faut de code pour l'obtenir : l'intérêt est dans la double approche du problème sa description et sa solution.
Parfois on est tellement dans le comment qu'on en oublie le problème que l'on résoud et le TDD permet d'avoir ce recul (là encore rien de neuf) et surtout une trace écrite
et exécutable. Le filet de tests de non régression n'est qu'un effet secondaire.
Le code produit dans un mode tests à posteriori est en moyenne (car hélas le monde n'est pas fait que de brutos) plus concis et plus simple donc ca fait avancer un projet ;o)
Après moi je dis I'm prograaming and unit-testing motherfucker et je pendrais bien ceux qui ont osé écrire le code que je refactore....
A ce propos, j'aime beaucoup la phrase :
"Programme comme si celui qui allait reprendre ton code est un psychopathe qui sait où tu habites" :-).
--
Baptiste
ehsavoie
Emmanuel Lecharny
> Le 3 juin 2011 à 08:06, Emmanuel Lecharny a écrit :
>
>> Il faut avoir au moins un fois dans sa vie de développeur participé à une mise en prod pour comprendre une partie de ces contraintes, et j'avoue que c'est assez passionnant. Les exploitants (système et réseau) ne sont pas des autistes ou des abrutis complets, au contraire. Ils sont malheureusement en bout de chaîne, sans explication sur ce qu'ils doivent installer ni administrer, et se faire respecter en tant que développeur par un administrateur impose une relation autre que écrite. Une bière de temps en temps peut aider...
>>
>>
> 100% d'accord, ou mieux encore que l'équipe de dev bosse avec l'équipe d'exploitation afin que
> leurs exigences (tout à fait justifiées) puissent être prise en compte dès le début.
Chez France-Telecom, tout projet démarre par la rédaction d'un DAT
(Document d'architecture Technique), qui est bien plus vaste qu'une spec
technique. Il s'agit de couvrir tous les aspects applicatifs, et cela
intègre la gestion de flux réseaux prévisibles sur 3 ans, par exemple.
Je parle là d'une étude qui est menée *en amont*, avant que le projet
soit simplement démarré, et qu'un appel d'offre soit émis.
C'est de loin ce que j'ai trouvé de mieux dans ma carrière en terme
d'anticipation sur les problèmes posés. Bon, après, la qualité du DAT
est intrinsèquement lié à ceux qui le rédigent (ça ne se fait pas tout
seul...)
> De toute façon cette synergie est souhaitable une fois que le passage en prod est terminé
> donc une fois que les vrais problèmes vont commencer à apparaitre.
Toujours chez FT (Wanadoo en fait, mais c'est devenu pareil), on
surveillait les applis 15 jours après la mise en prod. Si ça tenait dans
ce délai, c'est clair que ça validait l'appli. Je précise que je parle
ici d'appli qui recevait un pic de charge assez important (plusieurs
centaines de requêtes par seconde, avec du traitement derrière).
Les exploitants comptaient sur nous pour les aider à déterminer d'où
venait les problèmes, et le transfert de compétence s'effectuait comme
cela. Franchement, chez FT, l'ambiance est peut-être mortel, mais
l'informatique, ils connaissent... (et un process qui boucle, chez eux,
c'est Kill -9 ;)
Emmanuel Lecharny
> Ainsi donc, il y a 20 ans, on écrivait déjà les tests *AVANT* d'écrire le
> code ?
Meuhhh non... Il y a vingt ans, on n'avait pas besoin de tests, on
codait sans bugs :)
En bien, au risque de te surprendre, oui, on écrivait des tests mais pas
forcément après ni avant. On procédait en fonction des besoins.
Par ailleurs, on n'avait pas JUnit ou autre...
Emmanuel Lecharny
> ... Mais alors certains sont partis à la conquête de l'espace, pendant que d'autre sont fiers de rester dans leur jardin en pensant que rien n'a été découvert depuis copernic... ;)
capable de savoir distinguer le buzz du réel...
Emmanuel Lecharny
Oui, c'est excellent !
Jeff MAURY
On 6/3/11 11:41 AM, Pierre-Yves Ricau wrote:Meuhhh non... Il y a vingt ans, on n'avait pas besoin de tests, on codait sans bugs :)
Ainsi donc, il y a 20 ans, on écrivait déjà les tests *AVANT* d'écrire le
code ?
En bien, au risque de te surprendre, oui, on écrivait des tests mais pas forcément après ni avant. On procédait en fonction des besoins.
Par ailleurs, on n'avait pas JUnit ou autre...
Ca me rappelle un discussion la semaine dernière avec un personne qui avait un certaine expérience et une autre qui en avait moins: la dernière pensait que le concept d'intégration continue avait été amené par la mouvance Java et la première de lui répondre: nous, en 1996, on codait en C/C++, et tous les soirs la batterie de tests étaient passés.
A+
Jeff
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
"Legacy code" often differs from its suggested alternative by actually working and scaling.
- Bjarne Stroustrup
http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury
Pierre-Yves Ricau
http://cv.piwai.info
Jonathan Lebrun
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Jonathan Lebrun
Jeff MAURY
Jeff
Pierre-Yves Ricau
Ça s'appelle intégration continue, pas intégration discrète ;-)
yannick grenzinger
Donc en gros l'ensemble des systèmes existants devrait être tous maintenable, compréhensible et performant ! (comme les systèmes en Cobol tiens qu'on garde dans nos SI parce qu'ils répondent exactement aux besoins et qu'ils sont simple à maintenir)
Bizarre je dois vraiment pas avoir de bol ou ne pas vivre dans le même monde :(
Yannick
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Yannick Grenzinger
Emmanuel Lecharny
> ça s'appelle plus ou moins une nightly build, et effectivement c'set un truc
> de papi ;-) Par contre, le build à chaque commit, ça doit être quand même un
> peu plus récent non ? (j'en sais strictement rien..)
Mais le principe restait le même : tu casses le build, tu corriges. Donc
on testait avant de committer.
Ce qui changeait, c'est qu'il était plus rare de disposer d'un réseau.
Le code était local, chacun se passait une copie des parties sur
lesquelles on bossait, et on se mettait d'accord sur les fichiers
communs (headers). Pas simple...
Et si on avait du réseau (Novell par exemple), et bien les fichiers
étaient partagés, donc c'était pareil qu'aujourd'hui.
Emmanuel Lecharny
> Bah déjà, on préfèrera se tourner vers du push que du polling (post commit
> hook), histoire de pas consommer des ressources pour rien. Evidemment,
> builder plus souvent = problèmes détectés au plus tôt (sauf quand Hudson est
> submergé..). Par ailleurs, le build à chaque commit permet d'identifier
> immédiatement le commit fautif. Avec une nightly build, ce commit sera perdu
> au milieu des commits de la journée.
pratique pas (ou plutôt si, mais on n'en tient pas compte) le build à
chaque commit.
C'est simplement inutile.
Poruquoi ? Cela déresponsabilise les committers, et pénalise ceux qui
restent tard et ceux qui arrivent tôt. Un exemple : j'ai des enfants à
chercher à la crêche, donc je doit m'arracher à 18H, je commit à
l'emporte-pièces un truc qui normalement ne devrait pas faire pêter le
build (faut pas déconner quand même, j'ai juste changé deux brcicoles).
Pas de cul, dans mon élan committatoire, j'ai intégré une petite modif
anodine mais qui a le mauvais goût de flinguer un test obscur. Bang !
Ceux qui font un svn up (ou pull une branche Git) vont avoir un code
qui marche plus, et vont être obligé de m'attendre (et comme je me suis
mis une mine la veille avec des amis, j'arrive à 10h30 a tête dans le
cul). Bref, j'ai fait perdre une heure à 3 personnes, qui vont
m'accueillir avec des fleurs (du mal...)
Donc, non, le build-on-commit, c'est pas forcément nécessaire. Perso, je
build localement avany de committer (20 minutes sur ma bécane, donc ça
coûte) par respect pour les autres.
Le nighty-build, c'est juste moins coûteux, et ça permet de catcher les
erreurs d'envirronement (style sur W$, comme je bosse sur Mac).
Après, je suis pas catégorique. Je dis juste que c'est pas forcément la
panacée...
Emmanuel Lecharny
> Ah donc depuis le début de l'informatique on fait de la documentation claire
> expliquant ce que fait et comment fonctionne un logiciel et en plus on fait
> des tests permettant d'assurer sa qualité ?
aussi il y a 20 ans, hein ? :)
> Donc en gros l'ensemble des systèmes existants devrait être tous
> maintenable, compréhensible et performant ! (comme les systèmes en Cobol
> tiens qu'on garde dans nos SI parce qu'ils répondent exactement aux besoins
> et qu'ils sont simple à maintenir)
>
> Bizarre je dois vraiment pas avoir de bol ou ne pas vivre dans le même monde
> :(
Non, on it bien dans le même monde. Il y a des gens qui bossent
correctement, comme il y avat des porcs il y a 20 ans.
Ce que j'assaye de dire c'est que ce qui a changé depuis 20 ans, c'est
l'outillage. Faire des tests il y a 20 ans, c'était juste plus pénible.
Mon premier projet (un compilateur) avait sa batterie de tests qu'on
tournait régulièrement, et il y avait aussi de la doc (y compris dans le
code). je dis pas que ça a été le cas de tous les projets sur lesquels
j'ai bossé par la suite ;)
Mais il aurait fallu...
yannick grenzinger
Quelques buzzwords et évangélistes pour remettre les bonnes pratiques au gout du jour voir peut être les améliorer.
Moi j'attends le jour où on redeviendra des ingénieurs au lieu de pisseur de code/fossoyeur ou au mieux artisan ;)
Yannick
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
Emmanuel Lecharny
> Moi j'attends le jour où on redeviendra des ingénieurs au lieu de pisseur de
> code/fossoyeur ou au mieux artisan ;)
Pour sortir du troll (qui n'a pour objet que de faire réagir, finalement).
Je me pose souvent cette question : sommes-nous des ingénieurs ou des
artisans ?
Les deux, je pense. Des ingénieurs, indéniablement, puisque nous
appliquons des algorithmes clairement définis. Un tri est un tri, mais
il y a plusieurs façon de procéder, en fonction du contexte. Le travail
de l'ingénieur est de sélectionner le bon moyen par rapport à trois
contraintes :
- le temps (ou le coût)
- la performance
- la maintenabilité
Mais nous sommes également des artisans, et c'est là où le Lean est une
escroquerie intellectuelle : on ne "construit" pas une application comme
une voiture, et l'assemblage (l'intégration) de composants restera
toujours une activité hautement artisanale. Mais une activité artisanale
où chaque personne doit interragir avec ses collègues pour que le
résultat final soit respectable. Cela implique un minimum
d'organisation, mais on reste là dans le bon sens. L'usine logicielle
que d'aucuns vantent n'est pas prête d'exister. On est plus proche de la
manufcture...
Mais l'artisanat n'impique pas l'amateurisme.
Et c'est heureux...
Pierre-Yves Ricau
Perdre 20 minutes avant que commit, c'est dommage... ça veut dire aussi que tu attends le dernier moment pour commiter, parce que ça prend du temps. Je préfère commiter le plus souvent possible (en local, avec git ou git svn), afin de pouvoir revenir en arrière / revenir en arrière sur mes retours arrières... quitte à réorganiser mes commits avant de pousser. Ensuite, pendant que mes changements sont buildés, libre à moi de faire autre chose...
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
Henri Gomez
Tu as très bien résumé un des enjeux du DevOps Emmanuel.
C'est réduire la fracture entre les mondes du développement et ceux de
l'exploitation.
C'est un clivage très fort qui conduit a une mauvaise perception du
travail des uns et des autres avec tous les dérapages imaginables.
Je dirais que le DevOps c'est donc avant tout de faire en sorte que le
processus de production logicielle, de l'analyse, au développement, le
passage aux tests et QA puis la mise en place se fasse dans un
processus qui soit le plus agile et le plus productif possible. Avec
des feed-backs dans les 2 sens, comme par exemple attente des équipes
de production dès les phases initiales de l'analyse et du
développement et d'un autre coté présentation des infrastructures mise
en place et envisagées par la prod aux équipes de dév.
Je vois souvent fait mention dans les articles DevOps du déploiement
continu, c'est un rien réducteur.
Au final le DevOps, c'est avant tout une reconciliation des
différentes équipes qui rentrent dans le cycle de vie d'une
application, la QA et la production en faisant tout autant partie que
les analystes et les dévs.
Emmanuel Lecharny
> Le problème du build cassé qui impacte les autres, tu le résous donc en ne
> buildant pas :-) ? Au dela des buzzwords, c'est là que le concept de build
> incassable devient intéressant : mes modifications ne sont pas mergées tant
> que le build ne passe pas => si ce que j'ai fait ne fonctionne pas, ça
> n'impacte et ne concerne que moi, pas les autres. Bon, c'est sûr, faut avoir
> une batterie de machines de build ;-) .
tu travailles en Java muti-version (combien de fois je me suis fait
gauler par du Java 6 qui compile pas en Java 5...) ou en multi-OS.
> Perdre 20 minutes avant que commit, c'est dommage...
doc, processer tes mails, prendre un café...
> ça veut dire aussi que
> tu attends le dernier moment pour commiter, parce que ça prend du temps.
je commit, c'est que j'ai terminé une un deux journées de travail sur un
morceau de code.
> Je
> préfère commiter le plus souvent possible (en local, avec git ou git svn),
C'est juste une facilité pour pouvoir reverter un patch.
Ca manque à Subversion, cela dit.
Après, si quelqu'un avec Git tire ta branche et que ça lui pête la
sienne, t'es dans la même situation.
Emmanuel Bernard
>
> Après, si quelqu'un avec Git tire ta branche et que ça lui pête la
> sienne, t'es dans la même situation.
>
sociopathes et ils connaissent ton adresse.
Nicolas Delsaux
>
> Pas exactement. Les gens qui utilisent Git sont des psychopathes/
> sociopathes et ils connaissent ton adresse.
>
<TROLL>
Ce qui ne les empêche d'ailleurs pas de fourguer des softs même pas compilés.
Ca me fait d'ailleurs enrager de voir à quel point GitHub encourage
les développeurs Open-source à ne même plus packager leur code.
Parfois, il faut soi-même compiler le code - en corrigeant au passage
les tests qui ne passent pas, alors qu'on est censé être sur du code
stable.
Un exemple ? http://gexf.net/gexf4j/
J'aurais jamais cru dire ça un jour, mais pitié, rendez-moi Sourceforge !
</TROLL>
--
Nicolas Delsaux
Emmanuel Lecharny
On en revient à ce que je disais il y a deux ans sur Git : ça a beau
être un DVCS, à un moment, il doit y avoir un "repo" central qui agrège
la 'bonne' version. SVN fonctionne comme cela, et travailler avec Git
impose qu'une des personne s'occupe de recréer ce repo central.
Question de discipline, pas d'outil.
Pierre-Yves Ricau
Les repos Git sur Github sont des repos centraux, au même titre qu'un svn. Ce dont se plaint Nicolas n'a en fait pas grand chose à voir avec Git ou Svn, mais est plus en rapport avec les forges (GitHub vs SourceForge). SF propose de très bons services d'upload / download de binaires, ce qui encourage les devs à packager et uploader leurs binaires. A ma connaissance, pas Github... faut dire, le download de binaires ça coute cher, c'est bien plus lourd que des sources. Pas folle la guèpe !
GitHub favorise la collaboration et la décentralisation... et a une UI bien mieux pensée que SF. Mais je pense qu'ils n'ont pas vocation a recréer toutes les features de SF, préférant se concentrer sur ce sur quoi ils peuvent apporter de la valeur.
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
Henri Gomez
> Ce qui ne les empêche d'ailleurs pas de fourguer des softs même pas compilés.
> Ca me fait d'ailleurs enrager de voir à quel point GitHub encourage
> les développeurs Open-source à ne même plus packager leur code.
> Parfois, il faut soi-même compiler le code - en corrigeant au passage
> les tests qui ne passent pas, alors qu'on est censé être sur du code
> stable.
> Un exemple ? http://gexf.net/gexf4j/
>
> J'aurais jamais cru dire ça un jour, mais pitié, rendez-moi Sourceforge !
> </TROLL>
Pour une librairie, le packaging est ad-minima un artifact Maven voir un jar.
Pour une application, ça me parait plus limite, sans aller jusqu'à un
package natif (DEB/RPM/DMG/MSI), il faut ad-minima un tarball/zip
utilisable
Emmanuel Lecharny
> y dit qui voit pas lrapport..
Je voulais juste dire que sans repo centralisé, c'est juste ingérable.
Le repo centralisé peut aussi être virtuel : c'est la branche gérée par
le release manager.
Pierre-Yves Ricau
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
Emmanuel Lecharny
> Un autre effet de bord de cette facilité à créer des projets / forker sur
> github, c'est probablement une explosion du nombre de projets. N'importe qui
> peut créer n'importe quoi... et dès lors, se pose la question de la
> sélection des projets "sérieux". Désormais, les devs peuvent partagr le
> moindre bout de code pourri avec le monde entier au lieu de le garder au
> chaud dans un coin.. A nous d'apprendre à faire le tri ;-) . GitHub, le
> Comment Ça Marche de l'open source ?
Ou alors, il y a des fondations qui hébergent des projets qui ont fait
leur preuves ... (Apache, par exemple ;)
Benoît Dissert
A ma connaissance, pas Github... faut dire, le download de binaires ça coute cher, c'est bien plus lourd que des sources. Pas folle la guèpe !
Patrice Trognon
Henri Gomez
> moi sur mon serveur
> que je backup, si je veux exposer la je pousse sur un google-code ou github,
> mais uniquement
> une fois que le code est stabilisé et propre.
> on va pas exposer n'importe quelle daube aussi !
Clap Clap !
Emmanuel Lecharny
Pierre-Yves Ricau
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
Thomas Queste
Mais j'imagine que ça doit être moins automatisés qu'un SourceForge.
Pour l'explosion de projet sur Github grâce (ou à cause) du fork facile, ça crée une sacré émulation.
Quand tu regardes les issues d'un projet, tu vois que pas mal de monde inclut un "pull request", c'est à dire les modifications de code qui vont bien (patch, ajout de features).
Depuis quelques temps, le mainteneur du projet n'a qu'un bouton à appuyer pour merger le code.
C'est vraiment efficace.
Pour les forks inutiles, ça reste des repos que personne n'utilisera. Ca ne se retrouve pas "devant" sur Google, çà n'est pas vraiment gênant.
Disons que les avantages des fork compensent largement les inconvénients.
Tom