Continuous Delivery VS Scrum : est-ce compatible ?

[@ScrumLife]

Maîtrise pleinement le Definition of Done : kzbin.info/www/bejne/jHmlZ52LZqiMn80

[@BlocheValentin]

Trop bien la réponse en vidéo, merci les gars 😇 Vos contenus sont toujours aussi instructifs et énergiques à suivre 💪🏻

[@ScrumLife]

Merci à toi pour ta question sur le forum Valentin ! Et du coup quels sont les prochains sujets que tu aimerais que nous traitions ? Robin

[@BlocheValentin]

@@ScrumLife Deux me viennent à l'esprit : - un premier relatif aux IA : comment peuvent elles épauler l'équipe Scrum dans son quotidien ? Comme Jeff Shuterland l'a évoqué dans sa récente intervention à l'occasion du 30ème anniversaire de Scrum, tirer le meilleur des deux mondes en intégrant l'IA dans l'équipe Scrum en permettant aux humains de se concentrer sur ce sur quoi ils sont les plus pertinents kzbin.info/www/bejne/mXOkZmponN-Cpsk - un deuxième sur la hate de Scrum d'une partie de la communauté dév : comment débunker ce ras-le-bol "Trop de réunions", "Ca sert juste à nous mettre la pression", et j'en passe. Je présume que vous connaissez le sujet 😉 Voilà 😁

[@ScrumLife]

Ah ! les IA, c'est la mode en plus :p Il faudra en parler c'est sûr, typiquement mon idée pour l'instant, est que l'IA serve en effet à se concentrer sur la valeur, automatiser ce qui peut l'être. Et d'ailleurs pourquoi pas en lien avec le sujet de la semaine ! La doc ! Est-ce qu'une IA pourrait déjà formuler une doc utilisateur ou un chatbot pertinent en "lisant" le backlog et le code comme "entrée d'apprentissage" ?? -- Constantin

[@NiokSam]

Allez, c'est parti : J'ai l'impression (mais je suis sûr que ce n'est qu'une impression) qu'il y a une confusion entre intégration continue et déploiement continu. Faire payer aux utilisateurs du code inactif dans le bundle front d'une application, c'est pas très écologique :p (entre autres). De plus, il faut aussi faire attention avec le déploiement continu: Selon la façon dont l'application/le serveur va gérer les updates, on peut se trouver dans des cas extrêmement irritants. Par exemple, devoir attendre une update majeur d'un outil pour pouvoir l'utiliser alors qu'on est dans une situation non propice (rush, stress...), c'est clairement pas cool. Et si ça se répète fréquemment, ça devient carrément un repoussoir. Concernant la solution de l'ergonomie, comme vous le dites, c'est contextuel. Maintenant, le sujet est bien plus complexe que simplement "si c'est du grand public, allez vers l'ergo". D'abord, qu'est que ça veux dire grand public ? Si Photoshop est "grand public", on a clairement un exemple (parmi beaucoup d'autres) ou ergo et grand public sont incompatibles. Sur des domaines complexes, le but est d'avoir des interfaces simples (contraire de compliqué), pas simplexes (contraire de complexe). Plus loin que ça, et toujours sur le sujet du grand public, plus on adresse de population, plus ce qu'on pense être ergonomique ne l'est pas : De manière générale, on voit bien que les populations les plus âgés ont du mal avec des interfaces même considérées comme ergonomiques. Mais plus loin que ça, toutes les personnes avec des handicaps sont aussi à prendre en compte dès lors qu'on augmente la densité de la population des utilisateurs. Et du coup, des compromis sont à trouver. Pas de "silver-bullet"... Pour ce qui est de la doc, j'ai le sentiment qu'on a un peu survolé le sujet, notamment sur les canaux de communications: quid des newsletters, des vidéos tutos, des patch-notes etc...?

[@ScrumLife]

Hâte d'être au Live hebdo pour en échanger avec toi ! 😊 -- JP

[@ScrumLife]

La question du handicap est essentiel et devrait d'ailleurs être traité à la source. Tout comme on se tourne vers du "security by design", le "inclusion by design" (ça doit avoir un autre nom) est indispensable. Ca ouvre plein d'idées d'ailleurs, comme la selection des key users. On en parle au live j'espère ! -- Constantin