 Your new post is loading...
Your new post is loading...
Scoop.it!
Avec le Domain-Driven Design ou DDD, communiquez une architecture technique. Utilisez la méthode UML, les diagrammes de cas d’utilisation et de classe. 
No comment yet.
Sign up to comment
Scoop.it!
The smartest approach to collaborate beyond silo boundaries.
Mickael Ruau's insight:
EventStorming is a flexible workshop format for collaborative exploration of complex business domains. It comes in different flavours, that can be used in different scenarios:
The adaptive nature of EventStorming allows sophisticated cross-discipline conversation between stakeholders with different backgrounds, delivering a new type of collaboration beyond silo and specialisation boundaries. StylesWhat will you use EventStorming for? Pick the most suitable style for your own purposeImproveyour organizationDig into the business flow of an entire line of business Uncover inconsistencies between different perspectives and competing goals Highlight key impediments to meaningful value delivery Gather collective understanding and consensus around the next actions Envisionyour startup ecosystemExplore the landscape of an entire new business ecosystem Enforce consistent storytelling between stakeholders and partners Highlight architectural boundaries to allow robust and flexible evolution Explorenew services' dynamicsDesign services collaboratively, involving key stakeholders Support cross-discipline conversations between business, service designers and IT representatives Manage multiple perspectives on the same model, from value delivery to emotions and risks. Designcritical softwareDesign key software behaviour for your most critical processes Unfold the needs of multiple stakeholders on a sophisticated event-driven model Be ready to embrace the full power of Microservices and Domain-Driven Design
Scoop.it!
L’event Storming est un atelier très simple. Quelques règles suffisent. Il est aussi très efficace et souvent utile.
Mickael Ruau's insight:
L’idée de l’event storming est de rendre visible ce processus. Pour cela, comme le rappelle son créateur, Alberto, il faut de l’espace et de tonnes de stickers. Sur cet espace une ligne de temps est représentée par du papier craft sur quelques mètres. On y collera des des stickers dont les codes couleur seront bien respectés, et sur lesquels on aura pris soin de bien écrire en majuscules. Puis l’objectif sera de rendre palpable le processus, ce qui se déroule dans la vraie vie, sur cette ligne de temps. L’intérêt étant d’en percevoir véritablement les circonvolutions, les creux, les surcharges, tous les signaux que nous ne voyons pas autrement, et surtout les voir tous ensemble, avec tous les acteurs. Principes de base
Scoop.it!
Mesurer la prédictibilité avec le cycle time permet d'avoir une vision future de l'atterrissage de notre backlog en Kanban.
Scoop.it!
Je me questionne beaucoup sur la valeur de la prédictibilité. L’article de Dave Rooney “Is Predictability Really What We Want ?” m’a donné un certain éclairage que je vais essayer de traduire ici.
Scoop.it!
À la page 14 du guide Kanban condensé, les auteurs mentionnent qu’il existe deux façons de prévoir la date de livraison : l’estimation ou la prévision probabilistique. Selon mon expérience, l’estimation, par la technique du poker planning, est fortement employée dans des projets Scrum. Il existe même la pratique de la session murale pour estimer rapidement et au complet un carnet de produit dès le départ. Grâce à ces outils, il est possible de donner des dates de livraison, dates qui étaient constamment révisées après chaque itération.
http://blog.scrum.org/wall-session-practice/
Scoop.it!
Quelques signes de faux-agile et comment s'en prémunir
Les 3 Ps - Les 3 principaux manquements des équipes agiles
Mickael Ruau's insight:
Les 7 Fs du plan de vol de l’équipe agileThe 7th Fs of (the Agile Inside Out) Flight Plan:
Limiter la quantité de choses en cours (le multitâche) et la taille des éléments ou lots de travaux (batch size) permet d’accélérer le flux, de diminuer le temps de parcours moyen de l’ensemble des éléments. Instaurer des limites fortes peut paraître contreintuitif au début. Pour autant, c’est par la contrainte que l’on s’aperçoit des problèmes de fond et que l’on arrive à améliorer l’ensemble du système de proche en proche.
Il s’agit de vérifier fréquemment et régulièrement les paramètres et indicateurs de vol. Cela se traduit par des rétrospectives préparées par un Scrum Master pour collecter les indicateurs et données utiles à l’introspection de l’équipe sur ses pratiques, afin de dégager les ajustements ou éventuels changements plus importants pour assurer la suite du voyage.
Scoop.it!
La transformation des équipes ou organisation vers les méthodes agiles et particulièrement Kanban ou ScrumBan prend de plus en plus d’ampleur dans l’écosystème des organisations. Cette adhésion, ou la volonté d’expérimentation, des organisations aux méthodes Kanban est portée par la capacité d’un système Kanban à produire des métriques permettant une visibilité forte sur la capacité…
Mickael Ruau's insight:
La mesure de la prédictibilité par le débit nous offre également une indication assez fiable de la date prévisionnelle d’atterrissage de notre Release. Le calcul de base est simple et tient compte des éléments suivants : La formule appliquée est la suivante : Nous divisons simplement le nombre de Stories restant à réaliser, ainsi que le nombre d’anomalies à corriger, avec une estimation du nombre d’anomalies prévisionnelles que nous serions amenés à avoir et tenant compte du ratio d’anomalies/story terminée. Le débit est calculé sur une semaine (5 jours ouvrés) et nous fournit donc le nombre de semaines nécessaires afin de réaliser l’ensemble de notre Backlog de Produit. Jusque là rien de compliqué, sauf que le débit est mesuré sur la capacité d’une équipe sur une période. Qu’en est-il de la fiabilité du débit lorsque cette capacité vient à baisser ou augmenter ? Afin de pallier ce risque, la charge de l’équipe ayant permis de mesurer le débit, ainsi que la charge de l’équipe sur laquelle doit se baser la prédictibilité doit être prise en compte, ce qui nous donne la formule suivante : Ou :
Scoop.it!
In 2003, Mary and Tom Poppendieck's Lean Software Development introduced development techniques that adapt the principles of Lean manufacturing and logistics (like the Toyota Production system, which revolutionized the automobile industry) for use in software development. Now their second book, Implementing Lean Software Development: From Concept to Cash, offers a companion guide: a blend of history, theory, and practice which shows exactly how to implement Lean software development, hands-on.
Scoop.it!
« C’est bien votre Kanban, mais comment je fais pour planifier mon projet ? ». Cette phrase revient souvent dans la bouche des Managers, sur les projets que j’accompagne vers une transformation Agile en Kanban. Les DSI, après avoir rêvées devant les bénéfices de l’Agilité, ont maintenant besoins de résultats tangibles et pérennes auxquels les…
Scoop.it!
Learn how to use the Kanban method with data tools like Nave in order to visually track progress and efficiency from your Trello workflows.
Scoop.it!
This is a case study that describes how Kanban and lean development techniques were used to rescue a distressed project.
Mickael Ruau's insight:
Eliminate Waste and Control the Flow of Work with ConstraintsAs mentioned, the development team started off working in a waterfall approach. However, things ended up breaking down into an ad-hoc approach once development began and the big-up-front-requirements document became invalidated by uncontrolled change. From there, it didn't take long for the line from the code back to the requirements to become blurred and then eventually erased. The profile of the work assignment was a classic push system with a very large batch size. The development team was pushed a large requirements artifact from the analysis team. The test team was pushed a large code base by the development team plus the very large requirements artifact from the analysis team. During testing, when defects were uncovered, they were pushed to specific developers by a manager. When the fixes were made, a manager pushed them to specific testers for verification. This approach resulted in a lot of waste. In the analysis phase, a vast amount of unimplemented requirements accumulated. In the development phase, a vast amount of untested code was developed. In the test phase, a vast amount of unimplemented and improperly implemented requirements were identified.
Scoop.it!
|
Scoop.it!
L’Event Storming est un moyen d’harmoniser les modèles mentaux de différents acteurs en modélisant un métier, un processus, un existant. On veut cartographier de la connaissance. On veut mettre en lumière des zones d’ombre, des points de douleurs, des problèmes. Et on veut le faire tous ensemble pour s’aligner. On va créer des discussions et confronter des visions avec toutes les personnes impliquées.
Mickael Ruau's insight:
On pourrait modéliser le fonctionnement d’une équipe de RHs tout comme le parcours d’achat d’une application. Les événements forment la colonne vertébrale de L’Event Storming. On parle de ce qu’il se passe dans le processus, dans le système, sur une ligne de temps. On peut le raconter, c’est une histoire. Le storytelling est un aspect très puissant de cet atelier. C’est en plus modulable : on peut ajouter différentes étapes qui feront naître de nouvelles conversations selon le besoin. On pourrait par exemple introduire les acteurs qui agissent sur le système ou les dépendances externes. On peut s’adapter en fonction du niveau d’abstraction que l’on souhaite avoir, d’une vision très macro à une vision très micro sur un bout de logiciel. Pour autant, l’Event Storming reste simple, ce qui le rend d’autant plus efficace - on va en retirer quelque chose à la fin. Le cadre est léger. C’est très libre, voire parfois chaotique. Et c’est très bien. Ça donne de l’espace aux participants pour faire émerger une compréhension commune.
Scoop.it!
Julien vous présente une méthode agile : l'Event Storming.Elle vous permet de modéliser votre domaine métier en mettant en relation des profils technique
Scoop.it!
Après avoir vu les 3 principes fondamentaux, analysons les 7 concepts qui réfèrent aux 7 méthodes Kaizen qui transforment la philosophie Kaizen en une méth
Scoop.it!
Retour d'expérience sur la mise en place des multiples Kanban pour gérer des projets auprès de grandes entreprises françaises dans l'objectif d'obtenir des indicateurs de prédictibilité en temps réel des projets. Les indicateurs nous permettront de mener des rétrospectives pour améliorer le processus de développement à partir d'éléments factuels et pragmatiques.
Scoop.it!
TL-DR Kanban et Scrum sont deux outils qui se complètent très bien. L’un apporte des informations pour analyser la performance du flux de création de valeur, l’autre apporte des artéfacts et des boucles de rétroaction pour rendre transparent la performance de vos processus.
Scoop.it!
La focalisation dans Scrum consiste à concentrer l’effort de l’équipe pour chaque sprint, à livrer ce qui a potentiellement le plus de valeur métier. Reste à définir des hypothèses de valeur métier des éléments auprès du sponsor, des clients et utilisateurs potentiels, afin de les confirmer au plus tôt, en itérant rapidement. La focalisation est aussi le premier des 4 paliers du modèle Agile Fluency. C’est le signe de la primauté de la question de la valeur (pourquoi), au sein de l’équipe sur les autres dimensions de technicité (comment), et de l’optimisation (plus vite, plus efficient).
Mickael Ruau's insight:
Le rôle de l’équipeLe rôle et mission de l’équipe Scrum est de réaliser et livrer les éléments à plus forte valeur ajoutée pour ses clients, utilisateurs et sponsors. Pour accomplir cette mission, certains coéquipiers ont besoin d’être plus focalisés sur certaines choses. Tous les coéquipiers qui réalisent à proprement parler le produit ou service, ont besoin d’être concentrés pour mettre en oeuvre leurs compétences respectives au service de l’objectif de l’équipe. Selon le contexte et l’objectif, cette activité peut être plus ou moins coopérative, avec plus ou moins d’interactions entre coéquipiers. Le rôle du PO dans la focalisationLe PO donne à l’équipe Pourquoi et Sur Quoi porter son effort pour le prochain sprint. Lors du démarrage du sprint le PO informe l’équipe de ce qui est le plus important et urgent à faire pour les parties prenantes extérieures. L’équipe partage et définit ensemble ce qu’elle peut faire de mieux commme résultat, en tenant compte des contraintes de réalisation. Le PO s’améliore individuellement dans la focalisation en limitant la taille du backlog de produit à une cinquantaine d’items. Le PO est focalisé sur la définition et priorisation d’éléments à plus forte valeur ajoutée pour les parties prenantes, et à réaliser par l’équipe. Le rôle du SM dans la focalisationLe SM protège l’équipe des perturbations qui pourraient l’écarter de son objectif. Le SM anticipe les obstacles, les risques et prépare les actions pour les limiter. Le SM est focalisé sur la performance de l’équipe globale en soutien au PO et aux développeurs. Cette focalisation lui impose d’être à l’écoute de cet écosystème complexe. Quelques méthodes / référencesPour votre équipe, où la coopération et la focalisation sur un objectif collectif est importante, je n’ai pas mieux que Scrum. Pour gérer un flux de demandes où la répartition et le séquencement des tâches de réalisation importent plus qu’un objectif commun à 2 ou 3 semaines, une approche Kanban peut être mieux adaptée. Avec un peu d’expérience, tirer le meilleur des deux permet de se focaliser sur les bonnes choses au bon moment et de la bonne manière…
Scoop.it!
La méthode Kanban est formidable car elle est simple à comprendre et à mettre en place. Elle s’adapte à votre contexte.
Scoop.it!
La transformation des équipes ou organisation vers les méthodes agiles et particulièrement Kanban ou ScrumBan prend de plus en plus d’ampleur dans l’écosystème des organisations. Cette adhésion, ou la volonté d’expérimentation, des organisations aux méthodes Kanban est portée par la capacité d’un système kanban à produire des métriques permettant une visibilité forte sur la capacité…
Mickael Ruau's insight:
La force d’un Management Visuel et d’un processus Kanban est de permettre une mesure de la prédictibilité d’une équipe, au travers des éléments suivants : 3 niveaux de Prédictibilité sont mesurables dans un projet IT :
Ces 3 niveaux sont représentés par les formules suivantes : Ces 3 niveaux sont associés afin de permettre la mesure de la prédictibilité d’un projet IT, au travers de la formule suivante : A partir de cette formule, nous pouvons définir le nombre de mois nécessaires à la réalisation des Cartes restantes, Stories et Anomalies, avec une estimation du nombre de nouvelles anomalies pouvant potentiellement apparaitre et basé sur le Ratio. De là, à partir de la date de mesure de la prédictibilité, de la date de fin de Release fixée (TTM : Time To Market), nous obtenons la date d’atterrissage estimée et ainsi le nombre de jours d’écart qui sera positif si la date d’atterrissage est inférieure au TTM et négatif dans le cas contraire.
Scoop.it!
Adapter les limites basses/hautes avec la loi de Little
Scoop.it!
Last year I saw the term ‘Kanban roadmap’ emerge subtly in some product circles. At first I thought it was a bit of a faux pas, perhaps something that would die off naturally as some things do.
Scoop.it!
Scoop.it!
Scrum vs XP Both are very similar that are aligned with each other and complement each other. If you walked to a team then it very is very hard to recognize which practice team is using if they are using one of the above practices. XP is Scrum with technical practices. It’s mindset/behavior and a more prescriptive approach with a strong feedback loop. Scrum XP The iteration is between 2 to 4 weeks. The iterations are 1-2 weeks or less. For very aggressive teams, it can go up to a day. In Scrum product owner prioritizes the product backlog but the Scrum team has a privilege to chose a lower priority item in a sprint to work on before the high priority XP teams must always work in priority order as features to be developed are prioritized by the customer. Changes in the sprint are not allowed XP Teams are much more amenable to change within their iterations, but change can only be made if the team hasn’t started working on a feature and at the same time the change is of the equivalent of the swapped item. The validation of the software is completed almost at the end of each sprint, (i.e. Sprint Review) The software needs to be validated at all times, to the extent that the tests are written prior to the actual software. Scrum doesn’t prescribe any engineering practices The XP does. The Scrum Master is responsible for what is done in the Sprint, including the code that is written A developer can modify or refactor the parts of the code as and when the need arises.
|
L'event storming est un atelier qui réunit les différentes parties prenantes impliquées dans la construction du produit, notamment les développeurs. Il permet d'esquisser ce que devra être l'application. Vous allez pouvoir déterminer ses objectifs, mais également les événements connexes qui entraînent l'atteinte de l'objectif.
Bien sûr, vous pouvez utiliser toutes les informations récoltées en session d'event storming pour peaufiner votre modèle de domaine.