توضیحات

اگر از یک روند توسعه چابک استفاده می‌کنید، به احتمال زیاد لیست کار‌های انجام نشده (backlogs) را با داستان‌های کاربری پر می‌کنید. از آنجایی که من تصور می‌کردم که داستان‌ها (stories) شیوه رایجی هستند، نوشتن درباره آنها در این کتاب باعث اتلاف وقت من می‌شود. اما من اشتباه می‌کردم. در یک دهه و نیم از زمانی که داستان‌ها توسط Kent Beck برای اولین بار توصیف شده اند، آنها بیشتر از هر زمان دیگری محبوب‌تر هستند و همچنین بیشتر بد فهمیده و بد استفاده شده اند. این مرا ناراحت می‌کند. علاوه بر این، همه مزایایی که ما از نگاشت داستان به دست می‌آوریم را از بین می‌برد. بنابراین، در این کتاب، من مایلم تا آنجا که می‌توانم تصورات غلط بزرگ در مورد داستان‌ها و نحوه استفاده از آنها در توسعه نرم افزار Agile و Lean را اصلاح کنم. به همین دلیل، به گفته Tom Waits، من این «ساندویچ را به یک ضیافت» تبدیل کرده ام. نگاشت داستان کاربری، ابزاری ارزشمند برای توسعه نرم افزار است؛ اما وقتی که دلیل و نحوه‌ی استفاده از آن را بفهمید. این کتاب آموزنده، بررسی می‌کند که چگونه این تکنیک اغلب بد فهمیده شده، می‌تواند به تیم شما کمک کند تا بر روی کاربران و نیاز هایشان بدون گم شدن در ویژگی‌های منحصر به فرد محصول، متمرکز باقی می‌بماند. نویسنده این کتاب، Jeff Patton به شما نشان می‌دهد که چگونه نگاشت‌های داستانی متغیر، تیم شما را قادر می‌سازد تا در طول مراحل توسعه گفتگوهای بهتری درباره پروژه انجام دهند. تیم شما یاد خواهد گرفت تا به درکی مشترک از آن چه که شما کوشش می‌کنید تا بسازید برسد.

نظر

نظر

• امتیاز : 08/10
• به دیگران توصیه می‌کنم : بله
• دوباره می‌خوانم : بله
• ایده برجسته : User Story Mapping به تیم‌ها کمک می‌کند تا دید بهتری نسبت به محصول و نیازهای کاربران داشته باشند و از گم شدن در جزئیات ویژگی‌ها جلوگیری کنند
• تاثیر در من : درک بهتر از اهمیت نگاشت داستانی در توسعه نرم‌افزار و بهبود همکاری تیمی
• نکات مثبت : کمک به تمرکز بر نیازهای کاربران، بهبود همکاری تیمی، تسهیل گفتگوهای پروژه
• نکات منفی : ممکن است برای تیم‌های تازه‌کار در Agile کمی پیچیده باشد

مشخصات

• نویسنده : Jeff Patton
• انتشارات : O’Reilly

بخش‌هایی از کتاب

بخش ۱: پیش‌گفتار مارتین فاولر (Foreword by Martin Fowler)

۱. ریشه اصلی User Story (داستان کاربر): فاولر توضیح می‌دهد که مفهوم User Story اولین بار توسط کنت بک (Kent Beck) در متدولوژی XP (Extreme Programming) معرفی شد. هدف اصلی کنت بک این بود که فرآیند «نیازمندی‌های نرم‌افزار» (Requirements) را تغییر دهد. در رویکردهای سنتی، نیازمندی‌ها به صورت اسناد سنگین و طولانی نوشته می‌شدند که اغلب درک درستی از آنها بین تیم فنی و بیزنس وجود نداشت.

۲. سوءتفاهم رایج در صنعت: نکته انتقادی فاولر این است:

“Many people have focused on the ‘User Story’ as a thing written on a card.” (بسیاری از افراد تمرکزشان را فقط روی این گذاشتند که User Story چیزی است که روی یک کارت نوشته می‌شود.)

بسیاری از تیم‌ها فکر می‌کنند اگر نیازمندی‌ها را روی کارت‌های کوچک بنویسند، در حال انجام Agile هستند. اما هدف اصلی کنت بک، نوشتن نبود؛ بلکه گفتگو (Conversation) بود. کارت‌ها فقط باید بهانه‌ای برای شروع گفتگو بین توسعه‌دهندگان و ذینفعان (Stakeholders) باشند، نه اینکه جایگزین مستندات قطور شوند و همان رفتار سنتی را داشته باشند.

۳. مشکل Backlogهای خطی (Flat Backlogs): فاولر اشاره می‌کند که تیم‌های Agile اغلب با یک لیست طولانی و خطی از داستان‌ها (Flat Backlog) مواجه می‌شوند. این لیست خطی باعث می‌شود تیم، «تصویر بزرگ» (The Big Picture) پروژه را گم کند. یعنی تیم‌ها روی فیچرهای کوچک تمرکز می‌کنند بدون اینکه بدانند این قطعات چطور در کنار هم یک تجربه کاربری منسجم را می‌سازند.

۴. راهکار جف پاتون: تکنیک User Story Mapping که در این کتاب معرفی می‌شود، دقیقاً برای حل همین مشکل است. این تکنیک به تیم کمک می‌کند تا از گم شدن در جزئیاتِ لیست‌های طولانی جلوگیری کند و ارتباط بین داستان‌ها و کل سیستم را ببیند.

فصل ۱: تصویر بزرگ

بخش ۱: کلمه “الف”

معنای عملی Agile: اگر از کتاب‌های دیگر شروع کنی، احتمالاً با «مانیفست Agile» (Manifesto for Agile Software Development) سرو کار خواهی داشت که در سال ۲۰۰۱ توسط ۱۷ نفر نوشته شد. اما پاتون (نویسنده) در اینجا از ذکر دوباره مانیفست صرف‌نظر می‌کند و بجای آن یک نکته حیاتی را مطرح می‌کند:

Agile فقط به معنای سرعت یا ساختار فنی نیست. بلکه این یک فلسفه است که تمرکز را از مستندات سنگین به سمت گفتگو و همفهمی مشترک منتقل می‌کند.

بازگشت به تاریخ: پاتون در سال ۲۰۰۰ در یک استارتاپ در سان‌فرانسیسکو کار می‌کرد، جایی که کنت بک (Kent Beck) به عنوان مشاور حضور داشت. کنت بک خالق Extreme Programming (XP) و معرف مفهوم User Story بود. مقدار کلیدی:

Stories نام خود را از نحوه استفاده آن‌ها می‌گیرند، نه از آنچه باید نوشته شود.

این تفاوت بنیادی است. بسیاری تیم‌ها فکر می‌کنند User Story یعنی کاغذ یا تیکتی در Jira، اما حقیقتاً منظور تعامل و گفتگو است.

مشکل دوران قدیم (Pre-Agile): روش سنتی مدیریت پروژه بر این اساس بود:

1. تحلیل‌گران نیازمندی‌ها را جمع‌آوری می‌کردند
2. آن‌ها را به صورت اسناد طولانی و تفصیلی می‌نوشتند
3. آن اسناد را به توسعه‌دهندگان می‌رساندند

مشکل اصلی: اسناد مکتوب تفسیرهای مختلفی را برای افراد مختلف ایجاد می‌کند. همین که صفحات و صفحات مستند بنویسی نمی‌توانی اطمینان داشته باشی که تمام افراد یک‌سان آن را درک کرده‌اند.

تجربه شخصی پاتون: اولین بار که پاتون در یک پروژه Agile کار کرد، تنگناهایی را احساس کرد:

• یک User Story می‌نوشت که به اعتقادش می‌توانست در یک iteration انجام شود
• اما وقتی با توسعه‌دهندگان صحبت کرد، فهمید داستان خیلی بزرگ است
• این باعث ناامیدی او شد چون تصویر بزرگ را از دست داد

این مشکل تا به امروز جریان دارد: تیم‌ها در جزئیات گم می‌شوند و نمی‌دانند چگونه قطعات کوچک در کنار هم یک تجربه کاربری منسجم را می‌سازند.

حل پاتون - Story Mapping: پاتون متوجه شد که ما نیاز داریم:

1. بر روی تصویر بزرغ تمرکز کنیم
2. سپس آن را به قطعات کوچک برای ساخت تقسیم کنیم

این دقیقاً آنچیزی است که User Story Mapping حل می‌کند.

نتیجه‌گیری برای این بخش: سه نکته کلیدی:

1. Agile به معنای سرعت در نوشتن نیست؛ بلکه به معنای گفتگویی است که درک مشترک ایجاد می‌کند
2. User Story ابزار برای گفتگو است، نه برای جابه‌جایی تیکت‌ها
3. مشکل پروژه‌های Agile امروزی این است که تیم‌ها در فهرست‌های خطی و بدون معنی گم می‌شوند