257 private links
Waterfall, agile, AI in comparison to build a product.
Imagine you worked like this:
- At the start of the week: Get together with the team to decide what to ship—bring live—at the end of the week. Ideally, everyone contributes, but this is intentionally not a requirement.
- At the end of the week: Get together and look at what was shipped. Everyone high-fives or, together, lands on one lesson to learn.
At the end it's about time.
Ce qui a surtout déclenché cet article est une poignée de billets sur LinkedIn publiée par Marie Glandus, une conceptrice UX. Elle a témoigné d’un point de bascule dans sa carrière où elle a arrêté de vendre sa méthode et a commencé à vendre des améliorations mesurables. « [O]n ne te paie pas pour suivre un process. On te paie pour faire bouger des chiffres », dit-elle. Elle a remarqué que le même changement devait s’opérer dans l’agilité.
L'auteur décrit 3 limites de l'agilité
- l'agilité est en fin de vie: l’agilité est arrivée à la dernière phase : le marché est mature, les acteurs se consolident, les marges sont réduites, les pratiques sont homogènes, c’est un standard qui est attendu et les derniers retardataires s’y mettent.
- elle comporte des incohérences; les auteurs le rappellent "Nous sommes en train de découvrir comment mieux développer des logiciels[…]"
- elles est incomplète
Quelques pistes pour améliorer l'agilité:
- revenir aux sources: des fondamentaux ont été oubliés
- Éviter le terme agilité
- Respecter le choix des gens et nous devons d’abord chercher à résoudre leurs problèmes. Si une méthode agile est adaptée, tant mieux. Si ça ne l’est pas, on s’en fout.
- Produire des chiffres irréfutables
- S’aligner avec les commanditaires sur des objectifs SMART.
- Piloter par le ROI: gérer 4 risques en même temps : la valeur, la viabilité (dans laquelle on retrouve la rentabilité), la faisabilité et l’utilisabilité.
- mettre de et comprendre l'humain
Créer des affordances plutôt que convaincre
Tester les hypothèses avec une démarche scientifique: formuler des hypothèses, expérimenter, les invalider ou les valider, produire de la connaissance.
En complexité, on peut piloter l’exploration par les pertes acceptables et la diversification de son portfolio.
A minimal and easy to maintain Kanban board.
En 50 pages, ce qui est plus succinct que les longs livres.
Au format PDF sur 4 pages: https://pablopernot.fr/pdf/tres-petit-guide-agile-sans-jargon-agile-1-0.pdf
On retrouve la Matrice de Priorité selon l'importance et l'urgence, ainsi que la méthode MoSCoW (Must Have, Should Have, Could Have, Won't Have).
Le planning poker, le jeu: Buy a feature et le story mapping.
There are multiple definition of done (DoD).
Ne plus mesurer l'item d'un backlog avec son ROI, mais aussi avec l'impact environmental et l'impact social.
Quelles sont les sensations d'un environnement agile? On se sent
- conscient, en maîtrise
- franc et transparent, les journées sont remplies de choses qui font sens, sont utiles et nécéssaires
- utiles et directs, essentiels, léger
- capable de fabriquer quelque chose et le voir se bâtir
- concentré
- valeur et impact, le reste devient secondaire
- capable de saisir ses sujets
Cela implique de fabriquer de façon itérative, incrémentale. C'est inachevé, mais nous bâtissons sans connaître la forme finale. C’est une ignorance consciente, assumée, qu’il est inutile de trop en savoir, tout en sachant ce que l'on fait.
DORA and SPACE give some pointers, and we offer two more:
- Producing at least one customer-facing thing per team, per week.
- Delivering business impact committed to by the team.
The first reference about agility since 2001
This role requires you to have a good sense of the overall architecture of your systems and a solid understanding of how to design complex software. It probably also requires you to be able to understand business requirements and translate them into software. »
Un facteur souvent oublié est le prise en compte des besoins de l*entreprise.
Les facteurs sens commercial, stratégie de développement, partenariat, vélocité, coûts représentent des finalités par rapport au simple outils que sont la dette technique ou nos qualités techniques.
Le senior s’arrêtera à « il faut faire comme ça » alors que j’attends des rôles de lead et de staff la reflexion de « oui mais ce dont nous avons besoin aujourd’hui c’est … ».
Comme enseigné et illustré en cours d'agilité:
Communiquer au plus tôt de la façon la plus transparente possible. Non seulement ça permettra de répondre au problème plus tôt, mais ça diminuera le stress de tout le monde.
La règle : On ne blâmera jamais quelqu’un pour lever de façon constructive une alerte, y compris très tôt. On pourra par contre reprocher de ne pas l’avoir fait.
La question de l'agilité, c'est d'abord un choix de méthode. Il n'est pas guidé par la tendance du moment, mais par la nature des projets.
Comme le disait mon professeur, il s'agit avant tout d'un état d'esprit.
La démarche agile sert avancer sur des projets :
- dont on ne connaît pas le produit fini
- à condition d'avoir bien identifié la boucle de rétroaction.
Une méthode agile, ça n'est pas forcément le bon choix pour un projet. Parce qu'elle impose d'échouer souvent, de faire pleins d'erreurs que l'on va chercher à corriger petit à petit pour obtenir le design définitif.
Ces gestes sont bien pratiques, et finalement plus claire dans une réunion que chacun qui s'exprime dès le départ oralement.
À voir comment ils pourraient être adopté.
Acceptance Criteria define how a particular feature could be used from an end user’s perspective.
- Each Product Item Backlog must hast at least 1 acceptance criteria
- Acceptance Criteria are written before implementation
- Each acceptance criterion is independently testable
- Acceptance criteria must have a clear Pass / Fail result.
- It focuses on the end result.
- Include functional as well as non-functional criteria - when relevant.
- Team members write acceptance criteria and the Product Owner verifies it. It confirms the PO and the team have a shared understanding of the user story.