InfOsaurus - Commentaires

Tintin, course de haies et TDD - Guillaume

Guillaume — Sun, 18 Dec 2011 17:35:54 +0100

Merci pour ton retour. J'ai mis de la musique pour dynamiser le tout. Sans ça, je trouvais qu'on s'endormait un peu pendant les moments creux, déjà que je trouve ma voix pas terrible ^^

Je vais essayer de m'améliorer pour la prochaine ;)

Tintin, course de haies et TDD - Yotsumi

Yotsumi — Sun, 18 Dec 2011 15:40:52 +0100

Excellente idée cette vidéo.

Une petite remarque toutefois, la musique en arrière-plan... à éviter la prochaine fois ^^ C'est gênant pour la compréhension de tes explications.

J'avais fait le Kata Harry Potter 1 ou 2x ces derniers mois, je vais voir ta manière de faire plus en détail.

Tintin, course de haies et TDD - Guillaume

Guillaume — Thu, 01 Dec 2011 23:24:52 +0100

Dans ma version de Resharper, je n'ai le choix que de l'initialiser dans Current Member, Field initializer ou Constructor :(

Tintin, course de haies et TDD - Jean-Baptiste

Jean-Baptiste — Thu, 01 Dec 2011 07:14:26 +0100

Je confonds souvent les possibilités d'Idea et R#, mais dans Idea au moment du introduce field, comme endroit d'initialisation on peu choisir setup method.

Tintin, course de haies et TDD - Guillaume

Guillaume — Wed, 30 Nov 2011 19:57:33 +0100

Merci ;)

Tu as raison, pour le champ en fait j'avais essayé un Introduce Field mais sans succès. Au final j'ai trouvé, il faut juste mettre le curseur sur la variable pour que ça marche mais sans la sélectionner (bizarre).
Par contre pour l'apparition du SetUp j'ai pas trouvé, à moins de créer un snippet...

Tintin, course de haies et TDD - Jean-Baptiste

Jean-Baptiste — Wed, 30 Nov 2011 07:57:30 +0100

Bonne initiative parfaitement exécutée :)

Ma seule remarque serait qu'il me sembe que certaines de tes étapes de refactoring que tu fais à la main pourraient être faites par R# automatiquement . Par exemple la convertion en champs dans le test du panier et l'apparition du setup, ou l'introduction du paramètre dans la méthode calculMontantAvecReduction

L'auto-organisation : analyse d'un concept subversif - Guillaume

Guillaume — Sun, 19 Jun 2011 20:31:13 +0200

@goupils : Beaucoup de choses à dire sur ton commentaire, qui me semble plein de mauvaises interprétations et malheureusement révélateur de la perte de sens de ce qui faisait l'esprit des méthodes agiles, aujourd'hui noyé sous des tonnes de hype et de "marketing" agile...

Sur les contrats et la relation avec le client tout d'abord. Je suis d'accord que le cadre juridique des contrats client prestataire n'est pas du tout adapté à une démarche agile en France, en particulier celui du forfait. En revanche on dirait que tu blâmes la méthode alors que ce genre de problème est plutôt dû à des particularités budgétaro-financières rigides et abhérrentes ou à un client de mauvaise foi... On peut toujours dire que c'est comme ça, que les mentalités n'évolueront jamais, mais à ce compte là, ça ne vaut même pas la peine d'essayer de nouvelles méthodes pour rétablir la confiance entre client et prestataire puisque toute amélioration est impossible...

Sur la structure des organisations, effectivement une hiérarchie est nécessaire entre développeurs débutants, les confirmés, les experts... La présence d'un Scrum Master ne change rien à cela. Là où nos avis divergent, c'est sur la responsabilité individuelle. Sur le papier, c'est bien beau d'invoquer la notion de "chef responsable" pour justifier une structure fortement pyramidale, mais je n'ai jamais vu un membre du middle management, chef de projet, tech lead... et encore moins au-dessus, assumer la responsabilité de l'échec d'un projet ou d'une partie d'un projet. Jamais. En général on se contente de trouver un "coupable" parmi l'équipe de développement (et c'est ce dernier qui a des ennuis), de blâmer le client, la techno...
A cela, l'auto-organisation oppose le principe de responsabilité collective, c'est à dire de réussite collective ou d'échec collectif, qui est à mon avis bien plus pertinent et proche de la réalité. Cela sert non pas à se dédouaner des erreurs commises, mais au contraire à réfléchir tous ensemble à ce qui n'a pas marché et essayer de l'améliorer.

Sur les builds intermédiaires, je rappelle que Scrum, XP... nécessitent la présence d'un représentant du client dans l'équipe, donc le le dialogue avec les développeurs est quotidien et le feedback immédiat, ce qui évite à l'équipe d'"avancer dans la mauvaise direction". Visiblement, ce n'était pas le cas dans le projet auquel tu fais allusion.

Sur la documentation, préjugé encore une fois : le manifeste agile ne bannit pas toute documentation mais recommande de donner la priorité à un code qui fonctionne par rapport à une documentation pléthorique. Cela ne *veut pas* dire qu'aucune doc n'est nécessaire. En l'occurrence, rien n'empêche de faire un court compte rendu écrit du stand-up meeting (chose que je fais actuellement dans mon contexte professionnel), et bien entendu rien n'empêche non plus de noter noir sur blanc les décisions prises lors des workshops métier. En fait, tout détail considéré comme utile devrait être noté dans le backlog, dans les tests d'acceptance des user stories, ou ailleurs.

En conclusion, nous sommes d'accord sur un point : non, Scrum n'est pas la panacée universelle immédiate que certains veulent nous vendre, surtout si aucun effort de transformation et de lâcher prise vis-à-vis des vieux réflexes n'est fait.
Une des choses dont les projets informatiques souffrent le plus, et les projets agiles n'y échappent pas, c'est cette défiance entre les différence acteurs, cette guéguerre client/prestataire, manager/développeur... que tu as bien décrite et qui empêche tout le monde d'aller dans le même sens.

Ce que l'agilité propose face à cela, et que certains ont visiblement oublié en tapant un peu vite sur la méthode, c'est un cadre qui permet 1/ d'identifier et de mettre le doigt sur ce type de problèmes très tôt dans le cycle de développement et 2/ de pouvoir s'améliorer rapidement et redresser la barre facilement *si la volonté est là*.

L'auto-organisation : analyse d'un concept subversif - goupils

goupils — Thu, 26 May 2011 19:05:48 +0200

Bonjour,

Je viens de découvrir ce blog à l'instant et je voulais juste profiter de ce billet pour faire part de mon expérience personnelle. Je travaille sur des projets multimédia assez volumineux et comme beaucoup nous avons succombé à la méthodologie SCRUMM / AGILE. Et je dis: Attention car un effet de mode s'est emparé de notre industrie en vendant les bienfaits d'une méthodologie dont le nom semblait séduisant mais le retour d'expérience a été un peu cuisant pour plusieurs prestataires

- Dans le cadre d'un projet au forfait avec des paiements liés aux livrables mensuels, continuer d'imposer une phase de spécification du projet (80%) pour garantir vos rentrées d'argent.
En vendant le principe que client peut redéfinir ses besoins et les affiner à chaque itération, il trouve cela très plaisant et c'est très constructif pour l'équipe, mais il ne le fait pas pour les paiements en se défaussant sur le service juridique et comptable qui vous annonce que le paiement du mois ne peut pas être fait car le contrat n'est pas respecté à la lettre.
Le Product Owner (client) que vous impliquez dans votre méthodologie n'est pas nécessairement le décisionnaire et cette méthodologie peut rapidement vous étouffer financièrement

- Conservez la notion de Chef de Projet au SCRUM MASTER pour gérer les conflits humains, éviter que chacun partent dans des délires techno et confondent décision de R&D et développement. Dans les grosse équipes comme nous (60 personnes) il faut conserver une structure de lead technique, lead artiste, lead ergonome ... avec des strates (de senior à junior).
Un jour la problématique des responsabilités individuelles viendra sur la table et la notion d'équipe unifiée explose à ce moment. Le lead technique prend des choit techniques pour les juniors et est en responsable. Cette pyramide permet également de conserver un système d'évaluation des individus sur le long terme. Ce n'est pas le chef de projet, mais bien les leads qui vont évaluer les juniors ( en cas de primes ou de promotion)

- ne communiquer pas les builds intermédiaires au client mais uniquement les livrables qui sont liés à un paiement car le client va créer un décalage entre le temps pour lui de faire une évaluation (1 semaine pour les grosse applications comme les notre, de formaliser un feedback et nous le communiquer)
Entre temps l'équipe à avancer dans la mauvaise direction et c'est du temps perdue. Imposer un délai contractuelles (15 jours max) pour le client formalise son feedback et toujours le faire faire par écrit

- Ne négliger pas la documentation, les réunions stand-up meeting ont la fâcheuse tendance de ne laisser aucunes traces. Réduisez les à l'essentielle et laisser les leads organiser des réunions métier avec un COMPTE RENDU à la clef ... ce qui permet aux gens de s'y référer si un problème resurgit et une décision déjà prise

Persistez votre domaine avec Raven DB - Guillaume

Guillaume — Fri, 04 Jun 2010 16:18:20 +0200

Merci, effectivement je viens de voir que ton article sur AppEngine soulevait les mêmes loups :)

Concernant le champ couvert par les bases NoSQL, j'ai du mal à les voir décoller dans un contexte d'entreprise si ça reste du one-shot sans intégration avec les outils et autres sources de données de l'organisation. D'après ce que j'ai compris, une des cibles désignées des bases NoSQL est le business web à forte croissance qui a besoin de scalabilité, en général ce type d'activité nécessite aussi des outils d'administration / sauvegarde / reporting / analyse de données assez poussés.

Pour l'instant ces outils existent peu et si on ne les voit pas arriver, je doute que des bases comme Raven dépassent le niveau anecdotique.

Persistez votre domaine avec Raven DB - Jean-Baptiste

Jean-Baptiste — Fri, 04 Jun 2010 08:24:04 +0200

Chouette article, c'est vrai que j'en causais aussi dans mon billet sur AppEngine du rapprochement DDD/NoSQL. D'ailleurs Big Table et ses drivers java souffrent des mêmes soucis que tu décris.

Ceci dit, je ne suis pas sûr d'être d'accord avec ta conclusion : je ne sais pas si on attend des bases NoSQL de faire tout ce que savent faire les SGBDR. Elles tentent de couvrir une nouvelle plage de besoins j'ai l'impression, que les SGBD n'abordaient pas, ou difficilement.Elles essayent aussi je pense d'enlever le côté "silver bullet" des bases de données classiques, nous donnant el choix dans la manière de persister nos données, mais les deux approchent ont leurs mérites, et l'une n'excluse pas l'autre.

Règlement de comptes à Données Corral - Guillaume

Guillaume — Fri, 21 May 2010 10:59:08 +0200

Oui, les bases NoSQL sont de leur propre aveu limitées à certains usages dont beaucoup tournent autour du Web (cf présentation de RavenDB : http://ravendb.net/documentation/do...).

De l'objet ou du relationnel, qui fait régresser la situation ? Je pense que c'est un débat sans réponse ;-)

Règlement de comptes à Données Corral - Arialia

Arialia — Wed, 19 May 2010 16:03:16 +0200

Je pense franchement que les deux types de bases de données n'ont pas les mêmes usages.

La base de données relationnelle permet de gérer les données et de pouvoir les extraire même sans programme, elles ont été conçues pour pouvoir fournir des réponses à des questions non prévues (pour peu que les données soient présentes )

La base Nosql pour ce qu'en j'en ai vu est dépendante du programme de création/extraction.

Si une nouvelle question surgit il faudra impérativement faire un programme d'extraction ( là où au pire en cas de question difficile on fera appel à l'expert SQL ).

Pour des applications telles twitter c'est très bien mais pour la gestion du personnel ou des aéronefs j'ai un doute.

Par contre j'ai un sérieux doute sur les bases de données conçues ces dernières années sur le modèle objet avec persistence de données dans des SGBD relationnels : facile à remplir , c'est une horreur à interroger ... conséquence des programmes tournent la nuit pour extraire les données de ces bases et les rendre interrogeables par les traditionnels requêteurs/infocentre (Bi-query par exemple) .

Sous prétexte de vouloir faire de l'objet j'ai l'impression que l'on régresse ...

Règlement de comptes à Données Corral - Guillaume

Guillaume — Wed, 10 Mar 2010 23:28:34 +0100

Je suis d'accord avec toi, les deux approches n'ont rien d'inconciliable.
Cette guerre se situe avant tout dans les échanges d'amabilités et réactions violentes de quelques experts. Après, personne n'a dit qu'une guerre se terminait forcément par l'anéantissement d'un des deux camps ;)

Règlement de comptes à Données Corral - Antoine

Antoine — Wed, 10 Mar 2010 12:05:14 +0100

Guerre oui et non. NOSQL permet une nouvelle façon de structurer le stockage de données et il est généralement bon de voir les possibilités techniques s'élargir. Il y a des métiers ou des architectures qui tirent et tireront encore le plein intérêt d'un modèle relationnel, alors que pour d'autres ce type de modèle représente plutôt un handicap. C'est le contexte particulier à chaque application qui déterminera l'adoption d'une approche plutôt que de l'autre.
On est encore dans une zone de turbulences alimentée par des prises de position assez extrèmes, mais aucun modèle de stockage n'est la silver bullet et je ne vois pas pourquoi une solution supplanterait totalement l'autre.

En 2010, sachons lâcher du lest ! - Antoine

Antoine — Tue, 05 Jan 2010 10:26:34 +0100

So say we all.

DDD Vite Fait, notions avancées - mije

mije — Wed, 09 Dec 2009 10:09:43 +0100

C'est fort bien écrit, ce qui n'est pas souvent le cas dans le monde de la traduction informatique. Bravo donc.

DDD Vite Fait, notions avancées - Guillaume

Guillaume — Tue, 08 Dec 2009 13:56:18 +0100

Benoît - le deuxième ;) ,

J'avoue que j'ai tergiversé longtemps pour le titre :

DDD Vite Fait
DDD Rapide
DDD En Vitesse
DDD Accéléré
...

Le problème c'est que le terme Quickly correspond à tout sauf un bouquin de plus de 80 pages. D'où l'idée de le séparer en deux, et pour le coup j'ai trouvé que Vite Fait décrivait bien la lecture de la première partie.

C'est vrai que Vite Fait peut avoir une connotation de "mal fait" mais je n'ai pas trouvé de terme qui sonne aussi bien et qui soit aussi fidèle au mot anglais...

DDD Vite Fait, notions avancées - Benoit Guérout

Benoit Guérout — Tue, 08 Dec 2009 10:48:23 +0100

Bravo!

Par contre je trouve que la traduction du titre : "DDD Quickly" --> "DDD Vite fait" donne un coté péjoratif.

DDD Vite Fait, notions avancées - Benoît

Benoît — Mon, 07 Dec 2009 13:49:09 +0100

Merci !

Muramasa, the Demon Blade - Guillaume

Guillaume — Mon, 23 Nov 2009 19:38:50 +0100

Effectivement Mad World avait attiré mon attention aussi mais c'était déjà il y a assez longtemps... A tester donc quand j'aurai fini Muramasa ;)