Points clés
1. Les histoires d'utilisateur sont de courtes descriptions simples des fonctionnalités du point de vue de l'utilisateur
Les histoires sont compréhensibles à la fois par les clients et les développeurs.
Concises et claires. Les histoires d'utilisateur suivent généralement un format simple : "En tant que [rôle de l'utilisateur], je veux [objectif] afin que [bénéfice]." Cette structure garantit que l'histoire se concentre sur la valeur pour l'utilisateur plutôt que sur la mise en œuvre technique. Les histoires sont souvent écrites sur des cartes index ou des notes autocollantes, soulignant leur nature temporaire en tant que déclencheurs de conversation plutôt que spécifications complètes.
Encourager la collaboration. La brièveté des histoires d'utilisateur favorise les discussions entre développeurs et clients, cultivant une compréhension partagée des exigences. Cette approche collaborative aide à révéler des hypothèses cachées et réduit le risque de mauvaise interprétation qui affecte souvent les spécifications écrites détaillées.
Flexibles et adaptables. Les histoires d'utilisateur permettent une réévaluation et une modification faciles à mesure que les besoins du projet évoluent. Leur simplicité facilite l'estimation des efforts et la planification des itérations, soutenant ainsi les pratiques de développement agile.
2. Les rôles d'utilisateur et les personas aident à identifier les besoins divers des utilisateurs et à guider la création d'histoires
Modélisation des rôles d'utilisateur : comprendre ce que les utilisateurs ont en commun et où ils diffèrent.
Identifier les types d'utilisateur. Les rôles d'utilisateur représentent différentes catégories d'utilisateurs qui interagiront avec le système, telles que "utilisateur novice", "administrateur" ou "utilisateur avancé". Les personas sont des personnages fictifs qui incarnent les caractéristiques clés de ces rôles, les rendant plus relatables et concrets.
Guider la création d'histoires. En tenant compte des rôles d'utilisateur et des personas divers, les équipes peuvent s'assurer qu'elles répondent aux besoins de tous les utilisateurs potentiels. Cette approche aide à éviter de négliger des fonctionnalités importantes ou des considérations d'utilisabilité pour des groupes d'utilisateurs spécifiques.
Prioriser les fonctionnalités. Comprendre l'importance relative des différents rôles d'utilisateur aide à prioriser les fonctionnalités et à faire des compromis durant le développement. Par exemple, une fonctionnalité cruciale pour les utilisateurs avancés pourrait être moins importante pour les utilisateurs novices.
3. Les techniques efficaces de collecte d'histoires incluent des interviews, des ateliers et l'observation
La meilleure façon de construire un logiciel qui répond aux besoins des utilisateurs est de commencer par des "histoires d'utilisateur" : des descriptions simples, claires et brèves de fonctionnalités qui seront précieuses pour de vrais utilisateurs.
Interviews d'utilisateur. Réalisez des interviews individuelles avec des utilisateurs potentiels pour comprendre leurs objectifs, leurs points de douleur et leurs flux de travail. Utilisez des questions ouvertes pour encourager des réponses détaillées et découvrir des insights inattendus.
Ateliers d'écriture d'histoires. Rassemblez développeurs, clients et utilisateurs pour générer et affiner collaborativement des histoires d'utilisateur. Cette technique favorise une compréhension partagée et aide à identifier les lacunes dans les exigences.
Observation. Observez les utilisateurs interagir avec des systèmes existants ou effectuer leurs tâches dans leur environnement naturel. Cela peut révéler des besoins et des opportunités que les utilisateurs eux-mêmes pourraient ne pas articuler lors d'interviews ou d'ateliers.
4. Estimer les histoires en points permet une planification et une priorisation flexibles
Les points d'histoire ne sont pas équivalents aux points d'histoire de mon équipe. Une histoire que votre équipe estime valoir trois points d'histoire peut en valoir cinq pour mon équipe.
Dimensionnement relatif. Les points d'histoire représentent l'effort ou la complexité relative de la mise en œuvre d'une histoire, plutôt que des estimations de temps absolues. Cette approche permet aux équipes d'estimer plus rapidement et plus précisément en comparant les histoires entre elles.
Échelle spécifique à l'équipe. Chaque équipe définit sa propre échelle pour les points d'histoire, qui peut être basée sur la complexité, l'effort ou le risque. Cela permet aux équipes d'estimer d'une manière qui a du sens pour leur contexte et leur expertise spécifiques.
Suivi de la vélocité. En mesurant combien de points d'histoire une équipe complète à chaque itération, les équipes peuvent prédire leur capacité future plus précisément. Cette métrique de "vélocité" aide à planifier les versions et à gérer les attentes des parties prenantes.
5. La planification des versions et des itérations équilibre les priorités des clients avec la capacité de l'équipe
Vélocité planifiée et réelle après les trois premières itérations.
Planification des versions. Les clients priorisent les histoires pour les prochaines versions, tandis que l'équipe de développement fournit des estimations. Cette collaboration garantit que les fonctionnalités les plus précieuses sont livrées en premier, dans les limites de la capacité de l'équipe.
Planification des itérations. Au début de chaque itération (généralement de 1 à 4 semaines), l'équipe sélectionne les histoires sur lesquelles travailler en fonction de leur priorité et de leur vélocité estimée. Cela permet un ajustement et une re-priorisation réguliers à mesure que de nouvelles informations émergent.
Adaptation continue. En comparant la vélocité planifiée et réelle, les équipes peuvent affiner leurs estimations et ajuster leurs plans en conséquence. Cela favorise la transparence et aide à gérer les attentes tout au long du projet.
6. Les tests d'acceptation définissent l'achèvement des histoires et favorisent une communication claire
Les tests d'acceptation valident qu'une histoire a été développée avec la fonctionnalité que l'équipe cliente avait en tête lorsqu'elle a écrit l'histoire.
Clarifier les attentes. Les tests d'acceptation spécifient les conditions sous lesquelles une histoire est considérée comme complète. Cela aide à prévenir les malentendus entre clients et développeurs sur ce que signifie "terminé" pour chaque fonctionnalité.
Guider le développement. Rédiger des tests d'acceptation avant la mise en œuvre aide les développeurs à comprendre le comportement souhaité et peut éclairer leurs décisions de conception technique.
Automatiser la vérification. Dans la mesure du possible, l'automatisation des tests d'acceptation permet un retour rapide sur la question de savoir si de nouveaux changements ont rompu la fonctionnalité existante. Cela soutient les pratiques d'intégration et de livraison continues.
7. Les histoires d'utilisateur encouragent la collaboration, l'adaptabilité et un développement centré sur le client
Les histoires ne sont pas des obligations contractuelles. Comme nous le verrons, les accords sont documentés par des tests qui démontrent qu'une histoire a été développée correctement.
Promouvoir la conversation. Les histoires d'utilisateur servent de rappels pour avoir des conversations sur les exigences, plutôt que d'essayer de documenter chaque détail à l'avance. Ce dialogue continu aide à découvrir et à aborder les complexités au fur et à mesure qu'elles se présentent.
Accepter le changement. La nature légère des histoires d'utilisateur facilite l'adaptation aux exigences ou priorités changeantes. Contrairement aux spécifications détaillées, les histoires peuvent être facilement modifiées, ajoutées ou supprimées à mesure que le projet évolue.
Se concentrer sur la valeur. En reliant continuellement le travail de développement aux besoins des utilisateurs et à la valeur commerciale, les histoires d'utilisateur aident les équipes à éviter de construire des fonctionnalités inutiles ou de sur-ingénier des solutions. Cela garantit que l'effort est consacré à ce qui compte le plus pour les clients et les utilisateurs.
Dernière mise à jour:
FAQ
What's User Stories Applied about?
- Focus on User Stories: User Stories Applied by Mike Cohn emphasizes the role of user stories in agile software development, providing a framework for writing effective stories that capture user needs.
- Requirements Process: The book outlines a process that saves time and reduces rework, teaching how to gather, prioritize, and utilize user stories throughout the development lifecycle.
- Practical Guidance: It offers practical advice on writing, organizing, and using user stories for planning, management, and testing, making it a comprehensive guide for agile methodologies.
Why should I read User Stories Applied?
- Enhance Agile Practices: The book enhances understanding of agile practices, particularly in writing and utilizing user stories effectively, making it valuable for developers, testers, analysts, and managers.
- Improve Communication: It helps improve communication between technical teams and stakeholders, leading to software that better meets user needs.
- Practical Tools and Techniques: Cohn provides tools and techniques that can be immediately applied to projects, useful for both beginners and experienced practitioners in agile development.
What are the key takeaways of User Stories Applied?
- User-Centric Development: Emphasizes writing user stories from the user's perspective to ensure software meets actual user needs.
- INVEST Criteria: Introduces the INVEST criteria for good user stories: Independent, Negotiable, Valuable, Estimatable, Small, and Testable.
- Continuous Collaboration: Highlights the importance of ongoing collaboration between developers and users to refine requirements and adapt to changing needs.
What is a user story according to User Stories Applied?
- Definition: A user story is a simple, clear, and brief description of functionality valuable to real users, capturing what the user wants to achieve.
- Three Aspects: Consists of a written description, conversations to flesh out details, and tests to confirm completion, ensuring clarity and accountability.
- Example: An example might be, "As a job seeker, I want to search for jobs by location so that I can find opportunities near me."
How do I write effective user stories as per User Stories Applied?
- Follow the INVEST Criteria: Ensure stories are Independent, Negotiable, Valuable, Estimatable, Small, and Testable for manageability and user value focus.
- Use User Roles: Include specific user roles to clarify who the story is for, enhancing effectiveness.
- Keep It Simple: Avoid unnecessary details or technical jargon, focusing on user needs for further discussion and refinement.
What techniques does User Stories Applied suggest for gathering user stories?
- User Interviews: Conduct interviews to gather insights about user needs and expectations, uncovering valuable information.
- Story-Writing Workshops: Organize workshops for stakeholders to collaboratively write user stories, encouraging participation and idea generation.
- Observation: Observe users interacting with existing systems to identify pain points and areas for improvement, providing real-world context.
What is the role of acceptance testing in User Stories Applied?
- Validation of User Stories: Used to validate that software meets requirements outlined in user stories, ensuring alignment with user expectations.
- Customer Involvement: Customers specify acceptance tests, clarifying user story details and ensuring development team understanding.
- Part of the Development Process: Integrated into the development process, catching issues early and ensuring software alignment with user needs.
How does User Stories Applied define the concept of velocity?
- Definition of Velocity: Velocity is the amount of work (measured in story points) a team can complete in a single iteration, serving as a key planning metric.
- Importance for Planning: Helps teams estimate completion time for remaining work and plan future iterations effectively.
- Adjusting Expectations: Velocity can change over time; regular measurement allows teams to adjust plans and expectations based on performance.
What are the best practices for planning a release according to User Stories Applied?
- Prioritize Stories: Collaboratively prioritize user stories based on organizational value and user needs, using techniques like the MoSCoW method.
- Estimate Workload: Estimate total story points for the release and use team velocity to predict needed iterations, setting realistic timelines.
- Flexibility in Planning: Be prepared to adjust the release plan as new information emerges or priorities change, maintaining flexibility for success.
What are "story smells" in User Stories Applied?
- Indicators of Problems: Story smells are signs of issues with user stories, such as being too small or too large.
- Guidance for Improvement: Provides a catalog of common story smells and suggests ways to address them, refining user story practices.
- Promotes Better Practices: Recognizing and addressing story smells leads to more effective user stories, improving the development process.
How does User Stories Applied integrate with Scrum?
- User Stories in Scrum: Explains how user stories can be used within Scrum, particularly in managing the product backlog.
- Sprint Planning: Discusses how user stories help prioritize work during sprint planning, ensuring valuable features are developed first.
- Daily Scrums: Provides context for daily scrum meetings, helping teams stay focused on delivering user value throughout the sprint.
What are some common pitfalls to avoid when using user stories according to User Stories Applied?
- Avoid Over-Detailing: Writing too many details can lead to confusion and detract from facilitating conversation.
- Don't Ignore User Input: Failing to involve users in the story-writing process can result in stories that don't reflect user needs.
- Neglecting to Prioritize: Not prioritizing user stories can lead to wasted effort on non-valuable features, impacting project success.
Avis
User Stories Applied reçoit des avis partagés, avec une note moyenne de 3,89/5 étoiles. Les lecteurs apprécient son introduction claire aux user stories dans le développement agile, louant les exemples pratiques et l'étude de cas. Beaucoup le trouvent bien écrit et facile à suivre. Cependant, certains critiquent son contenu daté (publié en 2004) et le manque de profondeur sur certains sujets. Ce livre est recommandé pour ceux qui découvrent les méthodologies agiles, mais pourrait être moins précieux pour les praticiens expérimentés. Certains lecteurs soulignent son ampleur excessive et son prix élevé comme des inconvénients.
Similar Books
