|
Scooped by
Mickael Ruau
onto Devops for Growth December 5, 2021 5:30 AM
|
Scoop.it!
“The Pragmatic Programmer” est une bible pour les développeurs. Il est l’œuvre d’Andrew Hunt et Dave Thomas d’après leurs expériences en tant que développeurs. Leur objectif est simple, faire du lecteur un Pragmatic Programmer, un développeur fier de son travail et qui utilise les meilleures techniques à sa disposition pour faire un travail de qualité.
 Your new post is loading...
Your new post is loading...
Scoop.it!
Alors que les systèmes d’intelligence artificielle (SIA) se déploient dans tous les secteurs, leur intégration dans les organisations pose des questions...
Scoop.it!
Retards, dépassements de budget, équipes en perte de repères…
Scoop.it!
Le moins bon Les travaux de Troy Magennis à ce sujet indiquent qu’on devrait favoriser 5 à 9 personnes seulement si les performances de l’équipe sont plus importantes que sa prévisibilité et que l’équipe est plus importante que le système. On devrait augmenter à 15 si on peut couper une dépendance et si on veut un système plus stable et prévisible. Il faut faire attention à l’optimisation locale (l’équipe), qui cause presque toujours une sous-optimisation globale (l’écosystème de projet);
Les travaux de Dave Snowden au niveau du Cynefin framework ont permis de mieux définir la complexité. Peut-être qu’en 1996 développer du logiciel était complexe, mais vingt ans plus tard, on voit plutôt des systèmes de livraison compliqués et simples. L’écosystème de la forêt amazonienne est complexe;
Nous sommes loin de la valeur Agile « People over Process » si le soucis premier du Scrum Master est le processus Scrum. Le paragraphe qui suit est parfait et le guide gagnerait à retirer cette phrase sans rien perdre de son essence;
Un excellent article récent de John Cutler résume bien les avantages et inconvénients de cette mécanique. Je sens encore beaucoup l’influence de la charge de projet traditionnelle avec des échéances et des évaluations, juste en plus petit.
Scoop.it!
Cet accompagnement reprend les learning path officiels de Scrum.org et les enrichit avec des ressources de référence en français pour faciliter l'assimilation des concepts clés (articles, vidéos, ebooks...).
Scoop.it!
There are 2 recognised Scrum training organisations: Scrum.org & Scrum Alliance. Scrum Alliance is a little bigger, Scrum.org is a lot better. I am of course biased being a Professional Scrum Trainer with Scrum.org. Scrum.org is run by Ken Schwaber who co-created the Scrum framework in the 1990’s. The big
Mickael Ruau's insight:
Scrum.org Scrum Alliance Mission “Improving the profession of software delivery.” “Transforming the world of work.” Leadership Founded and led by Ken Schwaber, co creator of Scrum. Governed by a board of directors. Scrum Master Certification Professional Scrum Master I (PSM I) Professional Scrum Master II Professional Scrum Master III Certified ScrumMaster (CSM) Training 2 day PSM Course 2 day CSM Course Courseware Collaboratively maintained courseware from all Trainers, ensuring a consistent high quality learning experience, globally. Overseen by Ken Schwaber Created by individual trainers, so content, quality and learning experience varies per trainer. Certification Must pass a rigorous assessment associated with the course content. No requirement to attend a course. Must attend 2 days of training. Assessment is almost impossible to fail Cost Assessment cost included in the training. $150 without training. No renewal fee. First two years of certification included in training, then $100 every 2 years. Other Training Professional Scrum Foundations Professional Scrum Product Owner Professional Scrum Developer Scaled Professional Scrum Certified Scrum Product Owner Certified Scrum Developer Other Certifications Professional Scrum Product Owner I Professional Scrum Product Owner II Professional Scrum Developer Scaled Professional Scrum Certified Scrum Professional Certified Scrum Product Owner Certified Scrum Developer More Information www.scrum.org www.scrumalliance.org
Scoop.it!
From
ckti
Etes-vous prêt(e)s à chasser ensemble les fausses croyances (les farfadets) et à favoriser l'esprit critique dans les professions d'accompagnement ? Cet article est pour vous…
Scoop.it!
From
aqoba
Les Liberating Structures ou "Structures Libérantes" en français, sont un ensemble de méthodes et d'outils qui ont été développés pour aider les groupes de toutes tailles à travailler plus efficacement et de manière plus collaborative. Créées par Keith McCandless et Henri Lipmanowicz en 2014, les Liberating Structures ont été conçues pour donner une voix à chacun et encourager la participation active de tous les membres d'un groupe. Elles sont sous licence Creative Commons
Scoop.it!
Bien au-delà d’un simple exercice de surveillance et de conservation, il s’agit assurément de mettre à jour nos compétences, notre savoir et nos relations aux autres. A vous maintenant de découvrir le large éventail de méthodes et d’approches présentées par Constantin Guay pour faire sa veille, et les nombreux avantages que vous pourrez en tirer.
Scoop.it!
Ici, vous trouverez quelques outils qui peuvent vous aider pour votre management au quotidien ! Manager n'est jamais facile, et un type de management ne conviendra pas à tout le monde. Toutefois, certains outils vous faciliteront votre vie de manager, c'est pourquoi, je vous en propose quelques-uns. Ce que je dois savoir quand je travaille…
Scoop.it!
![[Kit] Démarrage d'accompagnement Agile V1, Visual Workspace for Innovation | Devops for Growth | Scoop.it](https://img.scoop.it/X_mhX1Ub3Rmx-DIA0D4EnTl72eJkfbmt4t8yenImKBVvK0kTmF0xjctABnaLJIm9)
Découvre ce Kit de démarrage d'accompagnement Agile clé en main ! Mon approche au démarrage d'un accompagnement Agile consiste dans un 1er temps à OBSERVER & à CREER DU LIEN afin de bien prendre en main le contexte & faciliter les changements à venir. Je te partage 3 outils incontournables.
Scoop.it!
Turn the ship around is the book from captain David Market who implemented radical delegation when he took charge of the submarine Santa Fe. The summary of this approach called the Leader-Leader model aims at giving the control to the staff by building mastery, aka competence, and providing clarity, in other words purpose.
Scoop.it!
Dans l’entreprise A, des cadres expérimentés se réunissent plusieurs fois et dessinent un plan très précis de leur projet. Ils en parlent ensuite aux personnes de l’atelier dans des réunions d’une vingtaine de personne. Le Directeur de Production montre le nouveau plan aux employés et leur demandent ce qu’ils en pensent. Il y a peu de réponses, les gens disent que ça a l’air bien. L’implantation est réalisée pendant la fermeture de l’usine.
|
Scoop.it!
Inspirées des Liberating Structures, les Liberating Structures basées sur les Forces sont une adaptation positive et intentionnelle de ces processus d'interaction. Elles représentent une magnifique collection de pratiques qui nous invitent à révéler le potentiel et à célébrer la contribution de chaque personne dans un groupe en se concentrant explicitement sur ce qui fonctionne déjà.Cette structure a été créée par Henri Lipmanowicz et Keith McCandless et adaptée avec l'Appreciative Inquiry par L
Scoop.it!
Retours utilisateurs ignorés, besoins flous, solutions mal alignées…
Scoop.it!
Maîtrisez l’art du questionnement avec des techniques qui améliorent la clarté et l’engagement. Améliorez considérablement vos compétences en communication.
Scoop.it!
Prépare les certifications Scrum.org cet été : c'est gratuit !
Ce parcours reprendre les learning path Scrum.org pour aider à réussir en autodidacte les certifications de Scrum Master (PSM1) et Product Owner (PSPO1).
Mickael Ruau's insight:
Expresso Agile en partenariat avec Scrumline , DEVWAY et Flowr (le logiciel édité par Odeven ) te proposent un accompagnement communautaire en ligne gratuit sous forme de MOOC, pour t'accompagner dans la préparation des certifications #PSM1 et #PSMO1 . Au programme : des contenus à retrouver chaque semaine dans cette newsletter, des lives et leur replay chaque semaine du 24 juin au 16 septembre sur la page Linkedin Expresso Agile .
Scoop.it!
A la découverte des Liberating Structures - Téléchargez le document au format PDF ou consultez-le gratuitement en ligne
Scoop.it!
ScrumAlliance vs Scrum.org - Pourquoi avoir choisi le cursus ScrumAlliance.org ?
Scoop.it!
De nombreuses équipes changent souvent le format et la conception des phases de leur rétrospective afin d'assurer la diversité et de stimuler la créativité des participants.
Mickael Ruau's insight:
Conseils pour ta prochaine rétrospective
Voilà pour la théorie. Qu'est-ce que tu peux en tirer pour la pratique ? Voici mes conseils pour utiliser le modèle "Double Diamond" dans les différentes phases de ta prochaine rétrospective :
1. pas de mesures dans la première moitié
Pour certaines équipes, c'est devenu une habitude peu agréable de vouloir prendre des mesures directement dans la phase de "rassemblement des données", qui sont lancées dans l'espace.
Conséquence : la dynamique nécessaire à la pensée divergente est perturbée et il est plus difficile d'obtenir de nouvelles perspectives. Essaie plutôt de noter consciemment les idées d'action en tant qu'idée – pas en tant qu'action finale de la rétro.
2. percer plus profondément dans les problèmes (ouverture du premier diamant)
Les commentaires sur les post-it sont souvent courts et donc sujets à interprétation. Si les commentaires ne sont pas très clairs ou semblent inhabituels, pose activement des questions de compréhension – plutôt une question de trop qu'une question de moins. De temps en temps, tu remarqueras que ta compréhension initiale d'un feedback change.
Autre avantage : tes questions aideront probablement les autres membres de l'équipe à mieux comprendre.
3. décide de ce qui est vraiment important (fermeture du premier diamant)
Selon la taille de l'équipe, le nombre de feedbacks peut être écrasant. Avant de passer à l'action, il faut donc décider quels sont les sujets qui méritent une timebox spécifique pour l'action.
Ce n'est qu'une fois qu'il est clair quels sont les sujets qu'il est judicieux d'aborder avec l'ensemble de l'équipe que le deuxième diamant doit être ouvert.
4. explorer la salle des solutions (ouvrir le deuxième diamant)
Ne te laisse pas séduire par la première solution venue. Une règle d'or : pour chaque thème, prends au moins le temps d'envisager une ou deux solutions alternatives. Il n'est pas rare que l'une des solutions alternatives soit finalement préférée – alors n'hésite pas à penser à Echometer 🙂
5. seulement des mesures de grande importance
Il n'est pas difficile de prendre en compte 10 mesures dans une rétrospective. Ce qui est difficile, c'est de retenir 1 à 3 mesures correctes. Personne ne peut se souvenir de 10 mesures et personne n'a la motivation de suivre autant de mesures. Si tu déduis 10 mesures, 5 d'entre elles passeront probablement complètement inaperçues, 3 n'auront pas ou peu d'impact et seules 2 resteront en mémoire et feront avancer l'équipe.
Tout l'art consiste donc à se concentrer sur les choses qui ont vraiment un impact tangible pour autant de membres de l'équipe que possible.
Scoop.it!
La formation gratuite conçue par Scrum Life pour :
Scoop.it!
Mickael Ruau's insight:
Un site qui présente des outils pour faciliter des ateliers agiles à distance
Scoop.it!
It was one of the best Christmas gifts of my life. My girlfriend handed me a small package. It was certainly a book. I ripped open the paper and a note fell off the top of the book. The note said…
Mickael Ruau's insight:
4. Make the default answer useful. If a boss asks, “Do you get it?” the subordinate will want to immediately say, “Yes!” and appear competent. The problem is that this default answer is a hurdle when the answer is, “No.” An open-ended question, such as, “What am I missing?” creates space for clarification. For more from David Marquet, you can find our video interview by clicking here to go to my YouTube channel.
Scoop.it!
Les jeux de Thiagi dans ce chapitre : présentation des jeux de Thiagi la ludo-pédagogie : pourquoi utiliser les jeux ? les jeux-cadres et jeux à thèmes Thiagi ressources Mieux-Apprendre et le Thiagi Group Présentation des jeux de Thiagi La ludo-pédagogie : pourquoi utiliser les jeux ? L’expression « ludo-pédagogie » est devenue courante depuis quelques années, […]
Scoop.it!
Scoop.it!
La « stratégie créative Disney » est responsable en grande partie du succès de Walt Disney™. Je vous présente la méthode derrière cette stratégie créative efficace, de l'idéation à la réalisation concrète.
|
Pour le résumé de “The Pragmatic Programmer”, je vais reprendre les “tips” qui accompagne les 46 items.
Tips :
1. Care About Your Craft Pourquoi passer son temps à développer des logiciels si on ne prend pas le soin de le faire bien ?
2. Think! About Your Work Désactiver le pilote automatique et prenez le contôle. Ayez un sens critique et réévaluez constamment votre travail.
3. Provide Options, Don’t Make Lame Excuses Au lieu de fournir des excuses, proposez des solutions de contournement. Au lieu de dire que c’est impossible, expliquez ce qu’il est possible de faire à la place.
4. Don’t Live with Broken Windows Améliorer les mauvais choix de conception, les mauvaises décisions et le code “sale” quand vous tombez dessus.
5. Be a Catalyst for Change Vous ne pouvez pas imposer le changement aux personnes. Montrez leur plutôt comment pourrait être le futur et encouragez-les à participer à sa création.
6. Remember the Big Picture Ne restez pas le “nez dans le guidon” et levez la tête pour voir ce qui se passe autour de vous.
7. Make Quality a Requirements Issue Impliquez vos utilisateurs à définir le niveau réel de qualité du projet.
8. Invest Regularly in Your Knowledge Portfolio Apprendre doit devenir une habitude, un réflexe.
9. Critically Analyze What You Read and Hear Ne vous laisser pas influencer par les vendeurs, “buzzs” médiatiques, ou dogmes. Analyser les informations dans votre contexte et celui de votre projet.
10. It’s Both What You Say and the Way You Say It De bonnes idées ne sont rien sans une communication efficace.
11. DRY - Don’t Repeat Yourself Chassez la duplication. Chaque connaissance, au sens large, doit avoir une représentation unique, non ambigu et faisant référence pour tout le système.
12. Make It Easy to Reuse Si votre code est facilement réutilisable, il sera réutilisé. Créer un environnement qui encourage la réutilisabilité.
13. Eliminate Effects Between Unrelated Things Concevez des composants indépendants et qui ont un but unique et bien défini.
14. There Are No Final Decisions Aucune décision n’est gravé dans la pierre. Voyez-les plutôt comme inscrites dans du sable à la plage et préparez-vous aux changements.
15. Use Tracer Bullets to Find the Target L’utilisation de “balles traçantes” permet de raffiner vos idées en essayent des choses et en voyant comment elles se comportent en situation réelle.
16. Prototype to Learn Le prototypage est une expérience d’apprentissage. Sa valeur n’est pas dans le code que vous produisez mais dans les leçons que vous pouvez en tirer.
17. Program Close to the Problem Domain
Concevez et codez dans le langage de vos utilisateurs.
18. Estimate to Avoid Surprises
Estimer avant de commencer. Vous ferez remonter les problèmes potentiels à la surface
19. Iterate the Schedule with the Code
Utiliser l’expérience acquise au cours du projet pour affiner vos estimations.
20. Keep Knowledge in Plain Text
Contrairement à des formats fermés, le “plain text” ne peut devenir obsolète. De plus, il facilite le debuggage et les tests.
21. Use the Power of Command Shell
Ne sous-estimez pas la puissance des commandes Shell face aux interfaces graphiques.
22. Use a Single Editor Well
L’éditeur de texte devrait être une extension de vos mains. Assurez-vous que votre éditeur est configurable, extensible et programmable.
23. Always Use Source Code Control
Un gestionnaire de versions est une machine à voyager dans le temps pour votre travail : vous pouvez revenir dans le passé.
24. Fix the Problem, Not the Blame
Peu importe si un bug est votre faute ou celle d’un autre, ça reste toujours votre problème et il nécessite toujours d’être corrigé.
25. Don’t Panic When Debugging Prenez une grosse inspiration et réfléchissez sur la cause du bug.
26. “select” Isn’t Broken
Il est rare de trouver un bug dans le système d’exploitation ou dans le compilateur, ou même dans une bibliothèque tierce. Le problème est plus vraisemblablement dans l’application.
27. Don’t Assume It, Prove It
Prouver vos intuitions dans l’environnement du projet avec les données réelles et les conditions limites.
28. Learn a Text Manipulation Language
Vous passez la majeure partie de votre journée à travailler avec du texte. Pourquoi ne pas laisser l’ordinateur en faire un peu à votre place ?
29. Write Code That Writes Code
Les générateurs de code augmente votre productivité et évite la duplication d’information.
30. You Can’t Write Perfect SoftwareIl n’y a pas de logiciel parfait. Protéger votre code et les utilisateurs des inévitables erreurs.
31. Design with Contracts
Utiliser la notion de contrat comment documentation et pour vous assurer que votre code ne fasse ni plus ni moins que ce qu’il prétend.
32. Crash Early
Un programme mort fait normalement moins de dégât qu’un programme estropié.
33. Use Assertions to Prevent the Impossible
Une assertion valide vos hypothèses. Utilisez-les pour protéger votre code d’un monde incertain.
34. Use Exceptions for Exceptional ProblemsRéservez les exceptions aux choses exceptionnelles.
35. Finish What You Start
Quand c’est possible, une routine ou un objet qui alloue une ressource devrait aussi être responsable de sa désallocation.
36. Minimize Coupling Between Modules
Évitez le couplage en écrivant du code “timide” et en appliquant la Loi de Déméter.
37. Configure, Don’t IntegrateImplémentez les choix de technologies pour une application avec des options de configuration plutôt que par de l’intégration.
38. Put Abstractions in Code, Details in Metadata
Programmez pour le cas général et placer les spécificités en dehors du code compilé.
39. Analyze Workflow to Improve Concurrency
Utiliser la concurrence pour améliorer les flux de votre application.
40. Design Using Services
Concevez en termes de services : des objets indépendants, concurrents derrière des interfaces bien définies et cohérentes.
41. Always Design for ConcurrencyAutorisez l’accès concurrent et vous concevrez des interfaces plus propres avec moins d’hypothèses.
42. Separate Views from Models
Gagnez en flexibilité facilement en concevant vos applications en termes de modèles et de vues.
43. Use Blackboards to Coordinate Workflow
Utiliser des “tableaux noirs” permet de coordonner des faits et des agents très différents tout en maintenant l’indépendance et l’isolation des différents participants.
44. Don’t Program by Coincidence
Ne compter que sur des choses fiables. Méfiez-vous des complexités accidentelles et ne confondez pas une heureuse coïncidence avec un plan bien déterminé.
45. Estimate the Order of Your Algorithms
Ayez une idée de combien de temps vont prendre vos routines avant de les écrire.
46. Test Your Estimates
L’analyse mathématique de vos algorithmes ne vous dit pas tout. Essayez de mesurer votre code dans l’environnement cible.
47. Refactor Early, Refactor Often
Tout comme réarranger un jardin et enlever la mauvaise herbe, réécrivez, retravailler et revoyez l’architecture de votre code quand c’est nécessaire. Attaquez-vous à la racine du problème.
48. Design to Test
Commencer à réfléchir aux tests avant d’écrire la moindre ligne de code.
49. Test Your Software, or Your Users Will
Tester impitoyablement. Ne laissez pas les utilisateurs trouver les bugs pour vous.
50. Don’t Use Wizard Code You Don’t Understand
Les assistants peuvent générer des portions de code. Soyez sûr de les comprendre dans leur globalité avant de les intégrer dans votre projet.
51. Don’t Gather Requirements, Dig for Them
Les besoins émergent rarement tous seuls. Ils sont souvent enfouis sous des couches d’hypothèses, de méconnaissance et de politique.
52. Work with a User to Think Like a User
C’est la meilleure façon de voir comment un système est utilisé dans des conditions réelles.
53. Abstractions Live Longer than Details
Investissez dans l’abstraction, pas dans l’implémentation. Les abstractions peuvent survivre aux changements d’implémentations et de technologies.
54. Use a Project Glossary
Créez et maintenez une source unique de tous les termes et vocabulaire spécifiques au projet.
55. Don’t Think Outside the Box, Find the Box
Devant un problème impossible, identifiez les contraintes réelles. Demandez-vous : “Est-ce que ce doit être traité de cette façon ? Est-ce que ça doit être fait tout court ?”
56. Start When You’re Ready
Vous augmentez votre expérience toute votre vie. Ne sous-estimez pas vos doutes et votre petite voix intérieure.
57. Some Things Are Better Done than Described
Ne tombez pas dans la spirale de spécifications, à un moment il faut commencer à coder.
58. Don’t Be a Slave to Formal Methods
N’adoptez pas les yeux fermés n’importe quelle technique sans la confronter avec le contexte des pratiques et capacités de développement de votre projet.
59. Costly Tools Don’t Produce Better Designs
Méfiez-vous des super vendeurs, des dogmes de l’industrie et de l’aura des prix. Jugez les outils sur leurs mérites.
60. Organize Teams Around Functionality
Ne séparez pas les concepteurs des codeurs et des testeurs. Construisez vos équipes comme vous construisez votre code.
61. Don’t Use Manual Procedures
Un script exécutera les mêmes instructions dans le même ordre, jour après jour.
62. Test Early, Test Often, Test Automatically
Des tests joués à chaque “build” sont beaucoup plus efficaces que des plans de tests qui dorment sur une étagère.
63. Coding Ain’t Done Until All the Tests RunTout est dit !
64. Use Saboteurs to Test Your Testing
Placer des bugs volontairement dans une copie du code source pour vérifier que vous tests les capturent.
65. Test State Coverage, Not Code Coverage
Identifier et tester les états significatifs de votre programme. Tester seulement les lignes de code n’est pas suffisant.
66. Find Bugs Once
Une fois qu’un testeur humain trouve un bug, ça devrait la dernière fois qu’un humain trouve ce bug.
67. English is Just a Programming LanguageÉcrivez vos documents comme vous écrivez votre code : respectez le principe “DRY“, utilisez les metadata, MVC, génération automatique, etc
68. Build Documentation In, Don’t Bolt It On
La documentation écrite en dehors du code a peu de chance d’être correcte et à jour.
69. Gently Exceed Your Users’ Expectations
Commencez par comprendre les attentes de vos utilisateurs, et ensuite délivrez-leur à peine plus.
70. Sign Your Work
De tout temps, les artisans sont fiers de ce qu’ils produisent. Vous devriez l’être aussi.