نکات کلیدی
۱. داستانهای کاربری توصیفهای کوتاه و سادهای از ویژگیها از دیدگاه کاربر هستند
داستانها برای هر دو گروه مشتریان و توسعهدهندگان قابل درک هستند.
مختصر و واضح. داستانهای کاربری معمولاً از یک فرمت ساده پیروی میکنند: "به عنوان یک [نقش کاربر]، میخواهم [هدف] تا [مزیت]." این ساختار اطمینان میدهد که داستان بر ارزش کاربر تمرکز دارد نه بر پیادهسازی فنی. داستانها معمولاً بر روی کارتهای یادداشت یا برچسبهای چسبان نوشته میشوند که بر جنبه موقتی آنها به عنوان شروعکنندههای گفتگو تأکید میکند و نه به عنوان مشخصات جامع.
تشویق به همکاری. کوتاهی داستانهای کاربری بحثها را بین توسعهدهندگان و مشتریان ترویج میکند و درک مشترکی از نیازها ایجاد میکند. این رویکرد همکاری به کشف فرضیات پنهان کمک کرده و خطر سوءتفاهمی که معمولاً مشخصات مکتوب دقیق را تحت تأثیر قرار میدهد، کاهش میدهد.
انعطافپذیر و قابل تطبیق. داستانهای کاربری اجازه میدهند تا به راحتی اولویتها تغییر کند و اصلاحات انجام شود، زیرا نیازهای پروژه تکامل مییابند. سادگی آنها برآورد تلاش و برنامهریزی تکرارها را آسانتر میکند و از شیوههای توسعه چابک پشتیبانی میکند.
۲. نقشهای کاربری و پرسونای کاربر به شناسایی نیازهای متنوع کاربران و هدایت ایجاد داستان کمک میکند
مدلسازی نقش کاربر: درک آنچه کاربران در آن مشترک هستند و جایی که تفاوت دارند.
شناسایی انواع کاربران. نقشهای کاربری نمایانگر دستههای مختلفی از کاربران هستند که با سیستم تعامل خواهند داشت، مانند "کاربر مبتدی"، "مدیر" یا "کاربر حرفهای." پرسونای کاربر شخصیتهای خیالی هستند که ویژگیهای کلیدی این نقشها را تجسم میکنند و آنها را قابل ارتباط و ملموستر میسازند.
هدایت ایجاد داستان. با در نظر گرفتن نقشها و پرسونای متنوع کاربران، تیمها میتوانند اطمینان حاصل کنند که به نیازهای تمام کاربران بالقوه پاسخ میدهند. این رویکرد به جلوگیری از نادیده گرفتن عملکرد یا ملاحظات کاربری مهم برای گروههای خاص کاربران کمک میکند.
اولویتبندی ویژگیها. درک اهمیت نسبی نقشهای مختلف کاربران به اولویتبندی ویژگیها و انجام تعادل در طول توسعه کمک میکند. به عنوان مثال، یک ویژگی که برای کاربران حرفهای حیاتی است ممکن است برای کاربران مبتدی کمتر اهمیت داشته باشد.
۳. تکنیکهای مؤثر جمعآوری داستان شامل مصاحبهها، کارگاهها و مشاهده است
بهترین راه برای ساخت نرمافزاری که نیازهای کاربران را برآورده کند، شروع با "داستانهای کاربری" است: توصیفهای ساده، واضح و مختصر از عملکردی که برای کاربران واقعی ارزشمند خواهد بود.
مصاحبههای کاربری. مصاحبههای یک به یک با کاربران بالقوه انجام دهید تا اهداف، نقاط درد و جریانهای کاری آنها را درک کنید. از سوالات باز استفاده کنید تا پاسخهای دقیقتری دریافت کرده و بینشهای غیرمنتظرهای را کشف کنید.
کارگاههای نوشتن داستان. توسعهدهندگان، مشتریان و کاربران را گرد هم آورید تا به طور مشترک داستانهای کاربری را تولید و اصلاح کنند. این تکنیک درک مشترک را ترویج میکند و به شناسایی شکافها در نیازها کمک میکند.
مشاهده. کاربران را در حین تعامل با سیستمهای موجود یا انجام وظایف خود در محیط طبیعیشان مشاهده کنید. این میتواند نیازها و فرصتهایی را که خود کاربران ممکن است در مصاحبهها یا کارگاهها بیان نکنند، فاش کند.
۴. برآورد داستانها به نقاط اجازه میدهد تا برنامهریزی و اولویتبندی انعطافپذیری داشته باشد
نقاط داستان معادل نقاط داستان تیم من نیستند. داستانی که تیم شما آن را سه نقطه ارزشگذاری میکند ممکن است برای تیم من پنج نقطه ارزش داشته باشد.
اندازهگیری نسبی. نقاط داستان نمایانگر تلاش یا پیچیدگی نسبی پیادهسازی یک داستان هستند، نه برآوردهای زمانی مطلق. این رویکرد به تیمها اجازه میدهد تا سریعتر و دقیقتر برآورد کنند و داستانها را با یکدیگر مقایسه کنند.
مقیاس خاص تیم. هر تیم مقیاس خاص خود را برای نقاط داستان تعریف میکند که ممکن است بر اساس پیچیدگی، تلاش یا ریسک باشد. این به تیمها اجازه میدهد تا به روشی که برای زمینه و تخصص خاص آنها منطقی است، برآورد کنند.
پیگیری سرعت. با اندازهگیری تعداد نقاط داستانی که یک تیم در هر تکرار کامل میکند، تیمها میتوانند ظرفیت آینده خود را دقیقتر پیشبینی کنند. این معیار "سرعت" در برنامهریزی انتشارها و مدیریت انتظارات ذینفعان کمک میکند.
۵. برنامهریزی انتشار و تکرار تعادل بین اولویتهای مشتری و ظرفیت تیم را برقرار میکند
سرعت برنامهریزی شده و واقعی پس از سه تکرار اول.
برنامهریزی انتشار. مشتریان داستانها را برای انتشارهای آینده اولویتبندی میکنند، در حالی که تیم توسعه برآوردهایی ارائه میدهد. این همکاری اطمینان میدهد که ارزشمندترین ویژگیها ابتدا ارائه میشوند، در چارچوب ظرفیت تیم.
برنامهریزی تکرار. در آغاز هر تکرار (معمولاً ۱-۴ هفته)، تیم داستانهایی را برای کار انتخاب میکند که بر اساس اولویت و سرعت برآورد شده آنها باشد. این امکان تنظیم و اولویتبندی منظم را به محض ظهور اطلاعات جدید فراهم میکند.
تطبیق مداوم. با مقایسه سرعت برنامهریزی شده و واقعی، تیمها میتوانند برآوردهای خود را اصلاح کرده و برنامهها را بهطور متناسب تنظیم کنند. این شفافیت را ترویج میکند و به مدیریت انتظارات در طول پروژه کمک میکند.
۶. تستهای پذیرش تعریفکننده تکمیل داستان و ترویج ارتباط واضح هستند
تستهای پذیرش تأیید میکنند که یک داستان با عملکردی که تیم مشتری در زمان نوشتن داستان در نظر داشته، توسعه یافته است.
وضوح انتظارات. تستهای پذیرش شرایطی را مشخص میکنند که تحت آن یک داستان کامل در نظر گرفته میشود. این به جلوگیری از سوءتفاهمها بین مشتریان و توسعهدهندگان درباره اینکه "تمام شده" به چه معناست برای هر ویژگی کمک میکند.
هدایت توسعه. نوشتن تستهای پذیرش قبل از پیادهسازی به توسعهدهندگان کمک میکند تا رفتار مورد نظر را درک کنند و میتواند تصمیمات طراحی فنی آنها را تحت تأثیر قرار دهد.
خودکارسازی تأیید. در صورت امکان، خودکارسازی تستهای پذیرش اجازه میدهد تا بازخورد سریعی درباره اینکه آیا تغییرات جدید عملکردهای موجود را شکستهاند یا خیر، دریافت شود. این از شیوههای ادغام و تحویل مداوم پشتیبانی میکند.
۷. داستانهای کاربری همکاری، انطباقپذیری و توسعه متمرکز بر مشتری را تشویق میکنند
داستانها تعهدات قراردادی نیستند. همانطور که خواهیم دید، توافقات با تستهایی مستند میشوند که نشان میدهند یک داستان به درستی توسعه یافته است.
ترویج گفتگو. داستانهای کاربری به عنوان یادآورهایی برای گفتگو درباره نیازها عمل میکنند، به جای اینکه سعی کنند هر جزئیات را از قبل مستند کنند. این گفتگوی مداوم به کشف و رسیدگی به پیچیدگیها در حین پیشرفت کمک میکند.
پذیرش تغییر. ماهیت سبک داستانهای کاربری انطباق با نیازها یا اولویتهای در حال تغییر را آسانتر میکند. بر خلاف مشخصات دقیق، داستانها میتوانند به راحتی اصلاح، اضافه یا حذف شوند زیرا پروژه تکامل مییابد.
تمرکز بر ارزش. با پیوند مداوم کار توسعه به نیازهای کاربر و ارزش تجاری، داستانهای کاربری به تیمها کمک میکنند تا از ساخت ویژگیهای غیرضروری یا مهندسی بیش از حد راهحلها جلوگیری کنند. این اطمینان میدهد که تلاش بر روی آنچه برای مشتریان و کاربران مهمتر است، صرف میشود.
آخرین بهروزرسانی::
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.
نقد و بررسی
کتاب داستانهای کاربر در عمل با نظرات متنوعی مواجه شده و میانگین امتیاز ۳.۸۹ از ۵ ستاره را کسب کرده است. خوانندگان از معرفی واضح این کتاب به داستانهای کاربر در توسعه چابک قدردانی کرده و به مثالهای عملی و مطالعه موردی آن اشاره میکنند. بسیاری آن را بهخوبی نوشته شده و آسان برای پیگیری میدانند. با این حال، برخی به محتوای قدیمی آن (منتشر شده در سال ۲۰۰۴) و کمبود عمق در برخی موضوعات انتقاد کردهاند. این کتاب برای کسانی که تازه با متدولوژیهای چابک آشنا میشوند، توصیه میشود، اما ممکن است برای حرفهایهای با تجربه کمتر ارزشمند باشد. برخی خوانندگان به وسعت بیش از حد و قیمت بالای آن بهعنوان نقاط ضعف اشاره کردهاند.
Similar Books







