Version imprimable
On ne passe pas à Agile pour rien, on passe à Agile car notre entreprise est Agile. Après, est-ce que c'est un pur argument commercial, ou bien est-ce que des gens qui ont une vision plus globale de l'entreprise et des différents produits pensent que c'est réellement une bonne chose, et qu'après avoir mis en balance les points positifs et négatifs, ils ont trouvé des arguments en ce sens, je ne sais pas.Citation:
Envoyé par Saverok
Dans mon ancien boulot, je bossais sur une appli qui avait déjà près de 20 ans, et qui avait été porté du C au C++ 5 ans auparavant. Autant dire que c'était bien moche.Citation:
Envoyé par gangsoleil
Appli vendu, avec machines qui l'embarquaient, à travers le monde.
On était plusieurs centaines à bosser dessus bien sûr, dans plusieurs pays, et on travaillait avec SCRUM.
Oui une équipe SCRUM se limitera à moins d'une dizaine de personnes. Heureusement ça scale, c'est pas juste une méthodologie gadget pour projet étudiant. :weird:
Si t'es plus nombreux, on fait ce qu'on appelle des "SCRUM de SCRUM".
Chaque équipe a sa portée, ses spécialités, des équipes encadrent, etc etc... Un système "pyramidal", sauf que les fondations ne sont pas simples exécutants écervelés juste bon à abattre une tâche souvent mal définie.
Quand un développement impactait notre rayon d'action, on était mis au courant. On participait au plus grand nombre de phases du process d'élaborration du cahier des charges etc...Citation:
Envoyé par gangsoleil
Ne serait-ce que pour éviter que les catastrophes déjà en place ne se reproduisent, parce que quand un bug, ou un truc foireux sort, l'argument du "c'est ce qui est écrit sur le CDC", bizarrement le client il l'accepte moyen..
Faire participer l'équipe de dév, c'est tout bénéf amha
- ça les implique, ça les motive, ça donne moins l'impression d'une hiérarchie prédominante qui ne s'intéresse pas au "bas peuple"
- avec la motivation, le travail est mieux fait
- quoi qu'on en dise, ils sont les mieux placés pour se rendre compte que si tu mets tel bouton là, tu vas avoir tel cas dans tel cas où tel action empêche que le bouton apparaisse, ou qu'il apparaitra sous un autre, ou ...
- avec une vision plus globale il sera mieux armé pour les évolutions à venir, encore une fois il est en première ligne
Au final, le product owner avait une vision globale oui, mais chaque équipe avait sa vision sur son périmètre et était concertée quand ça l'impactait. Et je trouvais ça très performant et efficace.
Donc faire de l'agile oui, mais le faire bien, et savoir le faire. Et ça, j'ai l'impression que la plupart des entreprises qui se targuent "d'être agile" n'en ont que le titre, et éventuellement du papier qui le certifie.:aie:
Je suis globalement d'accord avec Gangsoleil et Boursk et je vais essayer de synthétiser mon point de vue : j'ai l'impression que l'introduction d'Agile dans les entreprises se fait par effet de mode et parce que ça fait bien, un peu comme les boîtes qui ont dépensé je sais pas combien et foutu le bordel dans leurs équipes pour avoir la biblique certification ISO 9000 et consorts valable 3 ans et après on retourne dans les façons de faire d'avant.
J'ai peur qu'Agile soit dans la majorité des cas mis en place pour justifier des développements à la Monsieur Cadbury en se retranchant derrière l'effet de mode "C'est Agile, le truc super" !
Certes les méthodes que je qualifie de "traditionnelles" n'empêchent pas le travail de porc, mais à mon avis Agile va amplifier ça !
Quant à dire que les devs se sentent plus impliqués si ils font autre chose que du dev, à mon avis c'est une foutaise : une personne se sent impliquée dans son travail dès qu'on la félicite si elle le fait bien. La société est une gigantesque pyramide, il en a été ainsi de tous temps et dans tous les lieux : des grands chefs, des moyens chefs, des petits chefs des sous chefs et en bas quoi qu'on puisse en dire, des gens qui exécutent.
Vouloir que tout le monde ait son BAC et aille en fac c'est de la connerie, parce qu'on n'a pas besoin d'un plombier avec un DEUG.
Ben on n'a pas besoin non plus d'un DEV sur diplômé, on a juste besoin d'un mec qui sache faire son boulot correctement, sans trop de bugs (je rappelle qu'un bug c'est une erreur de codage, ça n'a rien à voir avec une spec erronnée !).
Et si une autre solution existait ? Et si ce système pyramidal où chacun se dédouane sur le niveau d'au dessus et en cachant la moitié des conneries et en s'attribuant le mérite des gens d'en dessous était suranné ?Citation:
Envoyé par arkhamon
C'est une vision partielle du développeur, qui ne colle plus depuis longtemps à la réalité. Il fut un temps où les chefaillons faisaient les specs, et même le prototype des méthodes, et le développeur implémentait l'algorithme qu'on lui avait donné dans la méthode sus-nommée.Citation:
Vouloir que tout le monde ait son BAC et aille en fac c'est de la connerie, parce qu'on n'a pas besoin d'un plombier avec un DEUG.
Ben on n'a pas besoin non plus d'un DEV sur diplômé, on a juste besoin d'un mec qui sache faire son boulot correctement, sans trop de bugs (je rappelle qu'un bug c'est une erreur de codage, ça n'a rien à voir avec une spec erronnée !).
Maintenant, il y a aussi des sociétés dans lesquelles le dev est une personne qui est reconnue pour avoir de bonnes connaissances sur le logiciel, et c'est pour ça qu'il participe aux (réunions de) conception et de spécification, et qui après écrit le code en fonction de ce qui a été décidé.
Et personnellement, la société dont tu parles dans laquelle le dev s'épanouit parce qu'on le félicite, à mon avis c'est tout aussi faux : moi je m'épanouis beaucoup plus parce que je fais quelque chose d'intéressant que parce que mon travail est reconnu par ma hiérarchie. Si je voulais être reconnu, ça fait longtemps que je serai passé chef, et que je lècherai le cul de mes supérieurs pour qu'ils me félicitent encore plus (et vu les chefs que j'ai eu, je pense que je pourrai être pas mauvais à ce jeu en appliquant ce qu'ils faisaient).
Pour avoir eu l'occasion de le tester avec pas mal de développeurs différents, j'ai pu constater une nette différence dans le comportement entre la simple exécution et la prise en charge de l'ensemble de la fonctionnalité.Citation:
Envoyé par arkhamon
Et même au delà du comportement, le travail est mieux réalisé dans le sens mieux documenté.
La gestion des connaissances au sein de l'équipe est mieux distribuée et cela améliore la communication.
Cela permet aussi aux développeurs de se projeter dans le temps au niveau de leur gestion de carrières pro. Tous les développeurs n'aspirent pas forcément à le rester et toucher partiellement aux métiers de la MOA, dialoguer avec les autres équipes (SEO, graphistes, web analystes, etc.) permet de leur ouvrir de nouvelles perspectives.
Personnellement, je n'y vois que des avantages.
Je suis totalement en phase avec le commentaire de gangsoleil sur cette remarque.Citation:
Envoyé par arkhamon
Une autre façon de faire est possible (et personnellement, je dirai même qu'elle est souhaitable).
Avec la complexité des SI, et des applications qui le composent, on ne parle plus de développeur mais d'analyste développeurCitation:
Envoyé par arkhamon
Ce n'est pas juste un terme bateau, cela a une vraie signification.
On ne peut plus se permettre "juste de développer", il faut effectuer une véritable analyse à 360° de son développement pour en mesurer tous les impacts, avoir un sens critique aiguisé et constant.
Ce n'est plus un boulot de "technicien" mais d'ingénieur
Je ne vais polémiquer sur les niveau d'étude car je ne pense pas que le diplôme fasse tout (surtout que j'ai eu l'occasion de travailler avec des BA+2 bien plus compétents que des BAC+5)
Une erreur de codage peut être induite pas de mauvaises specCitation:
Envoyé par arkhamon
Et puis, au sens client, la définition d'un bug est très large
Le client se moque de savoir si c'est une erreur technique du framework ou du dev ou de besoin métier mal défini ou de cas non prévus dans la spec
Encore une fois, c'est ce qu'en fait l'homme qui rend la pyramide inadaptée. Dans un système pyramidal, chacun est responsable devant celui d'au dessus de ce qui se passe en dessous, en "échange" de quoi il a le droit de donner des ordres à ceux d'en dessous. Ca a fait ses preuves et ça continue à le faire partout où chacun a le courage de prendre ses responsabilités. LE problème, c'est ceux qui se battent comme des chiens pour devenir petit chef à plumes, et qui après n'assument pas leurs responsabilités !Citation:
Envoyé par gangsoleil
C'est dommage et je suis le premier à le reconnaître, que tout le monde ne soit pas super intelligent et super fort et super beau. Mais c'est la réalité biologique et naturelle : l'intelligence de la population se répartit selon une distribution de Gauss. Donc comme tout le monde ne peut pas être à droite, il faut bien trouver du boulot pour ceux de gauche. D'où une segmentation du travail. Y a des CDP, des ingénieurs, des analystes, des programmeurs et des codeurs. Ça existait au début de l'informatique, comme dans tous les autres métiers. Mais d'une façon incompréhensible, ce n'est qu'en informatique qu'on considère que tout le monde doit pouvoir tout faire.
Regardez un peu comment ça fonctionne dans le bâtiment, dans les hôpitaux, dans l'armée...
JE crois que la difficulté est induite par le terme "développeur" qui regroupe tout et rien. Comme "soignant" qui regroupe des professeurs en chirurgie, des chirurgiens des médecins spécialistes, mais aussi les infirmières et les aides soignants. On fait un amalgame entre 10 professions qui sont totalement différentes !Citation:
Envoyé par gangsoleil
Encore une fois, un travail "de base" peut être intéressant. Il est totalement chimérique de croire que tout le monde peut être en haut de l'échelle en étant compétent !Citation:
Envoyé par gangsoleil
Aïe ça c'est mal !Citation:
Envoyé par gangsoleil
Ce que je préconise n'est en rien un frein à la progression. Ca permet même à chacun de comprendre à quel moment il a découvert sont point de compétence maximal.Citation:
Envoyé par Saverok
A mon époque on parlait d'analyste programmeur. Et c'était déjà trop flou.Citation:
Envoyé par Saverok
PAs d'accord. Si tout le monde se mèle de tout ça devient le bazar !Citation:
Envoyé par Saverok
Non pour moi un bug c'est ça :Citation:
Envoyé par Saverok
Voila ça c'est un bug car si la fonction est appelée avec b=0 ca plante.Code:
2
3
Sinon on parle d'erreur de specs ou d’erreur de conception.
la définition d'un bug, c'est le fonctionnement "apparemment" erratique ou "aléatoire" d'une application, dans la mesure où le programme s'arrête ou fournit un résultat faux de façon non systématique !
N'oublions pas que ce mot a une signification historique et technique : c'est au début des ordis dans les années 40 quand les fils mal isolés ou bouffés par les cafards ("bug") faisaient faux contact !
On ne demande pas à un développeur de savoir tout faireCitation:
Envoyé par arkhamon
L'idée est de mettre le développeur au centre de la conception de la fonctionnalité et supprimer tous les intermédiaires dispensables
Le CP ne sert à rien en tant que simple "passe plat".
Pour en revenir au développement Agile, il est souvent rappelé que cela s'adresse à des développeurs expérimentés
On ne demande pas au débutant de savoir gérer une fonctionnalité complexe dans son ensemble
Par contre, quelqu'un d'expérimenté peut apporter bien plus que de la simple technique.
Cela est particulièrement vrai dans le cas du web car c'est un domaine assez spécifique.
Par exemple, un client est spécialisé dans la vente et la fabrication de meuble et souhaite ouvrir ou développer son activité sur le web.
Un développeur expérimenté va pouvoir l'aider et le conseiller pour aborder ce canal spécifique. Il n'est pas question de le conseiller sur comment faire ou vendre un meuble.
De même, dans le cas de la mobilité, ce n'est pas parce qu'un client est présent depuis longtemps sur la toile qu'il maîtrise les codes liés à la mobilité ainsi que toutes les nouvelles fonctionnalités et contraintes de ce canal.
etc etc
etc
Pour finir, même les débutants ont leurs apports
Dans le cas du web par exemple, j'adore avoir un "jeune" dans mon équipe qui baigne dans les réseaux sociaux car personnellement, je n'y connais pas grand chose
Il m'est déjà arrivé de me faire accompagner par un stagiaire à une réunion sur l’implémentation de fonctionnalités de social-commerce...
Tout ça pour dire que ce n'est pas parce qu'un développeur fait un job technique que ses seules compétences sont de l'ordre de la techniques
Un développeur qui bosse depuis 10 ans dans un domaine métier et qui a eu l'occasion d'implémenter des centaines de fonctionnalités sur des dizaines de projets a un retour d'expérience sans égal
Limiter quelqu'un comme ça à une stricte tâche de développement, personnellement, je trouve que c'est du gâchi
Bah oui, mais moi je bosse avec des humains... Et le système pyramidal, j'en ai bien bien vu les limites :Citation:
Envoyé par arkhamon
- Mon chef, manager de 12 personnes, unanimement reconnu comme extrèmement compétent (aussi bien par les dev que par la hiérarchie), n'a jamais été plus haut, car il disait ce qu'il pensait -- et il a onc dit un jour qu'une décision n'était pas la bonne, avec arguments. Soucis : le type qui a pris la décision était un bon ami des hauts placés.
- Mes N+2 : j'en ai vu 3 ou 4 en 5 ans dans une seule entreprise, je ne sais même plus. Entre celui qui ne disait pas bonjour aux grouillots (sur 14 dans l'open space, il disait bonjour aux 2 chefs), celui qui faisait des choix techniques aberrants (mais qui lui permettaient de "jouer" avec le matériel), etc... Et absolument aucun ne défendait ses sous-fifres.
- Dans un grand groupe, les chefs, même au plus bas niveau, sont plus difficiles à joindre que l'administration française, car ils sont réellement tout le temps en réunion.
- Et je ne pense pas que la segmentation du travail soit une bonne chose : dans une entreprise, il y avait un service documentation qui rédigeait les docs utilisateur. Et ce rédacteur technique avait parfois des questions sur les logiciels, donc il venait voir les devs, ce qui nous prenait environ 5 minutes de temps en temps, et en plus il était sympa, donc tout allait bien. Et puis un jour, le chef des dev n'a pas supporté que le rédacteur vienne poser une question - la question de trop visiblement, et donc il a demandé à ce que la voie pyraidale soit respectée : lorsque el rédatcer a une question, il la pose à son chef, qui transmet au chef des développeur, qui choisit à quel développeur il transmet la question. Celui-ci doit alors répondre par mail à ce même chef, qui transfert au chef du rédacteur, qui transfert au rédacteur.
Résultat : une doc pourrie car plus d'interaction, une ambiance pourrie, et bien sur le rédacteur qui est allé voir ailleurs, donc en fait plus de doc.
- etc etc etc
Donc oui, je pense que si tout le monde était beau, gentil, compétent à la place qu'il occupe, et s'occupait de son poste, alors le système pyramidal serait peut-être quelque chose de bien. Mais là, non, c'est vraiment pas le pied, donc oui, je trouve que tout système qui a tendance à applatir cette pyramide pour que les gens puissent s'exprimer, c'est une bonne chose.
Mais pourquoi je suis toujours d'accord avec toi. Pourquoiiiiiiiiiiiiiiii?????Citation:
Envoyé par gangsoleil
Le truc le plus important, je crois, c'est la qualité de la communication. Avant même la compétence des gens, leur motivation, ou leur capacité de remise en cause(qui sont pourtant des facteurs essentiels). On est pas à l'armée ou les informations à passer sont simples(3 hostiles au deuxième étage - demande appui!) et ou le respect de la chaine hiérarchique complète est essentiel. La communication, dans nos domaines, ne peut pas se permettre la moindre approximation. Or, à chaque intermédiaire, à chaque passe-plat, on introduit des risques d'approximation ou d'oubli.
Le genre de communication qu'on a, c'est du genre "il faut dispatcher les paiements entre TIP, virement, et chèque. LE TIP est prioritaire, sauf si montant supérieur à 1 million". Sauf que généralement sont oubliés plein de détails, comme "1 million inclus, ou exclus?" "Quelle priorité entre virement et chèque? Si on ne vient pas d'un TIP au montant trop élevé? Et si on en vient?". Et caetera. Sur un bête aiguillage tout con, on se retrouve déjà avec plein de subtilités.
Si on passe par la chaine hiérarchique complète, ce genre de subtilités passe complètement à l'as. Le grand chef a autre chose à foutre que de gérer ce genre de détails(et c'est parfaitement légitime, ce n'est pas son rôle). C'est la première raison pour laquelle il faut communiquer directement entre sachants, sans se farcir 7 étapes intermédiaires.
La deuxième raison, c'est qu'en plus, ça permet de comprendre pourquoi. Quand un programmeur sait pourquoi il doit faire une chose, il anticipera facilement plein de détails. Par exemple, la limite du TIP à 1 million, j'ai fini par l'apprendre, était due à la taille du pré-imprimé : 6 caractères avant la virgule. Donc ça n'était pas du tout un caprice, et ça répondait aussi mécaniquement à la question de savoir si la limite était inclusive ou exclusive(et à 2 ou trois autres, parce-qu'en fait le cas était beaucoup plus compliqué).
La segmentation du travail est une catastrophe dans notre domaine parce-que justement elle éparpille la connaissance, et la maitrise qui va avec. A mon sens, il ne doit jamais y avoir plus de trois intervenants sur le chemin d'un élément(correction, évolution, morceau de projet) : Métier, Réalisation, Tests. Quitte à découper dans l'autre sens, et avoir plein de gens différents sur plein de sujets différents. A l'extrême rigueur, le métier peut être représenté par une MOA, mais les réalisateurs et les testeurs doivent quand même avoir accès au vrai métier.
Sinon? Sinon, ben personne ne comprend rien, et des gens très compétents se plantent, parce qu'ils n'ont pas saisi toutes les subtilités du projet.