پاتون جف داستان های کاربر هنر توسعه نرم افزار چابک

حاشیه نویسی

این کتاب یک الگوریتم روایت‌شده برای انجام فرآیند توسعه از ایده تا اجرا با استفاده از تکنیک‌های چابک است. فرآیند به صورت مرحله ای تنظیم شده است و در هر مرحله روش های مرحله فرآیند نشان داده شده است. نویسنده به این نکته اشاره می کند که اکثر روش ها بدون ادعای اصالت، اصیل نیستند. اما سبک نگارش خوب و تا حدی یکپارچگی فرآیند کتاب را بسیار مفید کرده است.

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

در عین حال، فرآیند را می توان به روش های مختلف توصیف کرد. می‌توانید در حین دستیابی به یک ارزش کلیدی مراحلی را بسازید، یا می‌توانید به سادگی روز کاری کاربران را در حین استفاده از سیستم تصور کنید. نویسنده بر این واقعیت تمرکز می‌کند که فرآیندها باید ترسیم شوند، به شکل یک داستان کاربر روی نقشه فرآیند بیان شوند، این همان چیزی است که نام نقشه داستان کاربر را به ما داد.

چه کسی به آن احتیاج دارد

برای تحلیلگران فناوری اطلاعات و مدیران پروژه. حتما بخوانید. خواندن این کتاب آسان و لذت بخش است، حجم کتاب متوسط ​​است.

فایل را نقد کنید

در ساده ترین شکل آن، این روش کار می کند.

یک بازدیدکننده به یک کافه می آید، غذاها را انتخاب می کند، سفارش می دهد، غذا می گیرد، غذا می خورد و پول می پردازد.

ما می توانیم برای آنچه از سیستم می خواهیم در هر مرحله الزامات بنویسیم.

سیستم باید لیستی از ظروف را نشان دهد، هر ظرف دارای ترکیب، وزن و قیمت است و بتواند به سبد خرید اضافه شود. چرا ما به این الزامات اطمینان داریم؟ این در توصیف "استاندارد" الزامات توضیح داده نشده است و این باعث ایجاد خطر می شود.

مجریانی که نمی دانند چرا این کار ضروری است، معمولاً کار اشتباهی انجام می دهند. مجریانی که در فرآیند خلق ایده دخالتی ندارند در نتیجه دخیل نیستند. Agile می گوید، بیایید در درجه اول روی سیستم تمرکز نکنیم، بلکه بر روی افراد، مصرف کنندگان، وظایف و اهداف آنها تمرکز کنیم.

ما پرسونا می‌سازیم، جزئیاتی را برای همدلی به آنها می‌دهیم، و شروع به گفتن داستان‌ها از سمت شخص می‌کنیم.

کارمند دفتر زاخار به ناهار رفت و می خواهد یک میان وعده سریع بخورد. او به چه چیزی نیاز دارد؟ ایده این است که او احتمالاً یک ناهار کاری می خواهد. ایده دیگر این است که او می خواهد سیستم ترجیحات او را به خاطر بسپارد، زیرا او رژیم دارد. یک ایده دیگر. او می خواهد فوراً برایش قهوه بیاورند زیرا عادت دارد قبل از ناهار قهوه بنوشد.

و همچنین یک تجارت وجود دارد (شخصیت سازمانی شخصیتی است که منافع یک سازمان را نمایندگی می کند). کسب و کارها می خواهند میانگین چک را افزایش دهند، دفعات خرید را افزایش دهند و سود را افزایش دهند. ایده این است - بیایید غذاهای غیرمعمول از برخی از غذاها را ارائه دهیم. ایده دیگر - بیایید صبحانه را معرفی کنیم.

ایده‌ها می‌توانند و باید در قالب یک داستان کاربری مشخص، تبدیل و ارائه شوند. به عنوان یک کارمند مرکز تجاری زاخار، می‌خواهم سیستم مرا بشناسد تا بتوانم منویی را بر اساس ترجیحاتم دریافت کنم. من به عنوان پیشخدمت از سیستم می خواهم زمان نزدیک شدن به میز را به من اطلاع دهد تا مشتری از خدمات سریع راضی باشد. و غیره.

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

مسیر نویسنده: ما نه عملکرد، بلکه نتیجه = آنچه کاربر در پایان به دست می آورد را در اولویت قرار می دهیم.

یک نکته واضح و آشکار: جلسه اولویت‌بندی توسط کل تیم انجام نمی‌شود، زیرا بی‌اثر است، بلکه توسط سه نفر انجام می‌شود. اولی مسئولیت کسب و کار، دومی برای تجربه کاربر و سومی برای پیاده سازی است.

اجازه دهید حداقل را برای حل یک مشکل کاربر (حداقل راه حل قابل اجرا) انتخاب کنیم.

ما ایده‌های اولویت اول را با استفاده از داستان‌های کاربر، طرح‌های طراحی، محدودیت‌ها و قوانین کسب‌وکار بر روی نقشه داستان کاربر با گفتن و بحث با تیم درباره آنچه مردم و سهامداران در هر مرحله از فرآیند نیاز دارند، به تفصیل شرح می‌دهیم. ما ایده های باقی مانده را در فرصت های عقب مانده بررسی نشده رها می کنیم.

این فرآیند از چپ به راست روی کارت‌ها نوشته می‌شود و ایده‌هایی روی کارت‌ها در زیر مراحل فرآیند وجود دارد. ضروری است که مسیر کل داستان با اعضای تیم مورد بحث قرار گیرد تا از درک متقابل اطمینان حاصل شود.

تفصیل به این روش باعث ایجاد یکپارچگی در انطباق با فرآیندها می شود.

ایده های دریافت شده نیاز به آزمایش دارند. یک عضو غیر تیمی کلاه فرد را بر سر می گذارد و روز آن فرد را در سر او زندگی می کند و مشکل او را حل می کند. این امکان وجود دارد که او تحولات را نبیند، دوباره کارت ایجاد کند و تیم جایگزین هایی برای خود کشف کند.

سپس جزئیات برای ارزیابی وجود دارد. سه نفر برای این کار کافی است. مسئول تجربه کاربر، توسعه دهنده، تستر با یک سوال مورد علاقه: "چه می شود اگر ...".

در هر مرحله، بحث از یک نقشه فرآیندی از تاریخچه کاربر پیروی می کند، که اجازه می دهد تا وظیفه کاربر را در ذهن نگه دارید تا یک درک منسجم ایجاد کنید.

آیا مستندات از نظر نویسنده ضروری است؟ بله، من به آن نیاز دارم. اما به عنوان یادداشت هایی که به شما امکان می دهد آنچه را که توافق کرده اید به خاطر بسپارید. درگیر کردن مجدد یک فرد خارجی مستلزم بحث است.

نویسنده با تمرکز بر لزوم بحث، به موضوع کفایت مستندات نمی پردازد. (بله، مستندات لازم است، مهم نیست که افرادی که درک عمیقی از چابک ندارند، چگونه ادعا می کنند). همچنین، توضیح تنها بخشی از قابلیت ها ممکن است منجر به نیاز به بازسازی کامل کل سیستم شود. نویسنده به خطر توضیح بیش از حد در مواردی که ایده اشتباه است اشاره می کند.

برای از بین بردن خطرات، دریافت سریع بازخورد در مورد محصول در حال ایجاد برای به حداقل رساندن آسیب ناشی از ایجاد محصول "اشتباه" ضروری است. ما طرحی از ایده ساختیم - آن را با کاربر تأیید کردیم، نمونه‌های اولیه رابط را ترسیم کردیم - آن را با کاربر تأیید کردیم و غیره. (به طور جداگانه، اطلاعات کمی در مورد چگونگی اعتبار سنجی نمونه های اولیه برنامه وجود دارد). اهداف ایجاد نرم افزار، به ویژه در مرحله اولیه، یادگیری از طریق دریافت بازخورد سریع است؛ بر این اساس، اولین محصول ایجاد شده، طرح هایی است که قادر به اثبات یا رد یک فرضیه هستند. (نویسنده بر کار اریک ریس "استارتاپ با استفاده از روش ناب" تکیه کرده است).

نقشه داستان زمانی که پیاده سازی در چندین تیم انجام می شود به بهبود ارتباطات کمک می کند. چه چیزی باید روی نقشه باشد؟ آنچه برای ادامه مکالمه نیاز دارید. نه فقط یک داستان کاربر (چه کسی، چه چیزی، چرا)، بلکه ایده ها، حقایق، طرح های رابط و غیره...

با تقسیم کارت های روی نقشه تاریخ به چندین خط افقی، می توانید کار را به نسخه ها تقسیم کنید - حداقل ها را برجسته کنید، لایه ای از قابلیت های فزاینده و کمان.

ما داستان هایی را در نقشه فرآیند تعریف می کنیم.

یک کارمند برای ناهار آمد.

او چه میخواهد؟ سرعت خدمات به طوری که ناهار او از قبل روی میز یا حداقل در سینی منتظر او باشد. اوه - یک مرحله از دست رفته: کارمند می خواست غذا بخورد. او وارد شد و گزینه ناهار کاری را انتخاب کرد. او محتوای کالری و محتوای غذایی را برای کمک به رژیم غذایی و عدم افزایش وزن دید. او عکس هایی از ظرف را دید تا تصمیم بگیرد که آیا در آن مکان غذا می خورد یا نه.

بعد میره ناهار و شام بخوره؟ یا شاید ناهار به دفتر او تحویل داده شود؟ سپس مرحله فرآیند انتخاب مکانی برای غذا خوردن است. او می‌خواهد ببیند چه زمانی به او تحویل داده می‌شود و هزینه آن چقدر است، بنابراین می‌تواند انتخاب کند که زمان و انرژی خود را در کجا صرف کند - رفتن به طبقه پایین یا رفتن به محل کار. او می خواهد ببیند که کافه چقدر شلوغ است تا در صف ها به هم نخورد.

سپس کارمند به کافه آمد. او می خواهد سینی اش را ببیند تا بتواند آن را بردارد و مستقیماً به شام ​​برود. کافه می خواهد پول بپذیرد تا از سرویس پول دربیاورد. کارمند می خواهد حداقل زمان خود را در شهرک با کافه از دست بدهد تا زمان گرانبها را بیهوده هدر ندهد. چگونه انجامش بدهیم؟ پیش پرداخت یا بالعکس پس از سرویس از راه دور پرداخت کنید. یا در محل با استفاده از کیوسک پرداخت کنید. مهمترین چیز در این مورد چیست؟ چند نفر حاضرند هزینه ناهار را با کارت بانکی بپردازند؟ چند نفر به این غذاخوری برای ذخیره شماره کارت خود برای پرداخت های مکرر اعتماد می کنند؟ بدون تحقیق میدانی مشخص نیست، آزمایش لازم است.

در هر مرحله از فرآیند، شما باید به نحوی عملکرد را ارائه دهید؛ برای این کار باید فردی را به عنوان مبنا انتخاب کنید و آنچه برای او مهمتر است (همان سه انتخابگر) را انتخاب کنید. داستان را تا انتها دنبال کرد = یک راه حل قابل اجرا ساخت.

بعد جزئیات می آید. مشتری می خواهد ببیند که کافه چقدر شلوغ است، تا در صف ها تکان نخورد. او دقیقا چه می خواهد؟

پیش بینی تعداد افراد را در 15 دقیقه ببینید که او به آنجا می رسد

میانگین زمان سرویس دهی در کافه و پویایی آن را نیم ساعت قبل مشاهده کنید

وضعیت و دینامیک اشغال جدول را ببینید

اگر سیستم پیش بینی نتیجه نامشخصی بدهد یا کار را متوقف کند چه؟

از طریق ویدیو صف های موجود در کافه و همچنین اشغال میزها را تماشا کنید. هوم، چرا اول این کار را نکنی؟!

نویسنده به تمرین کوچکی برای تمرین اشاره می کند: سعی کنید تصور کنید صبح بعد از بیدار شدن چه می کنید. یک کارت = یک عمل. کارت ها را بزرگ کنید (به جای آسیاب کردن قهوه، نوشیدنی نشاط آور بنوشید) تا جزئیات فردی را حذف کنید، نه بر روش اجرا، بلکه روی هدف.

این کتاب برای چه کسانی است: تحلیلگران فناوری اطلاعات و مدیران پروژه. حتما بخوانید.

نرم افزار

بحث و تصمیم گیری در گروه های 3 تا 5 نفره موثر است.

روی کارت اول بنویسید که چه چیزی باید توسعه یابد، در کارت دوم - آنچه را که در اول انجام دادید تصحیح کنید، در کارت سوم - آنچه را که در اول و دوم انجام شد تصحیح کنید.

داستان هایی مانند کیک آماده کنید - نه با نوشتن یک دستور، بلکه با پیدا کردن اینکه کیک برای چه کسی، برای چه مناسبتی و برای چند نفر است. اگر فروش را تقسیم کنیم، آن وقت نه به تولید کیک، خامه و غیره، بلکه به تولید کیک های کوچک آماده می شود.

توسعه نرم افزار شبیه ساخت فیلم است، زمانی که باید قبل از شروع فیلمبرداری فیلمنامه را با دقت توسعه و صیقل دهید، صحنه، بازیگران و غیره را سازماندهی کنید.

همیشه کمبود منابع وجود خواهد داشت.

20 درصد تلاش ها نتایج ملموس می دهد، 60 درصد نتایج غیرقابل درک می دهد، 20 درصد تلاش ها مضر هستند - به همین دلیل مهم است که روی یادگیری تمرکز کنید و در صورت نتیجه منفی ناامید نشوید.

مستقیماً با کاربر ارتباط برقرار کنید، خود را در جای او احساس کنید. روی برخی مشکلات تمرکز کنید.

جزئیات و توسعه داستان برای ارزیابی ترسناک ترین بخش اسکرام است، بحث ها را در حالت آکواریوم ایستاده کنید (3-4 نفر در هیئت مدیره بحث می کنند، اگر کسی بخواهد شرکت کند، او جایگزین کسی می شود).

منبع: www.habr.com