نوشته های آرش قنبری

آشنایی با روشها و نکات مهم نوشتن یوزر استوری

آرش قنبری — Sun, 11 Jul 2021 01:38:54 +0430

بطور کلی نوع نوشتن یوزر استوری مناسب می تواند در مسیر چابک شدن تیم اسکرام تاثیر زیادی بگذارد. زیرا در ادامه راه بعنوان یک مبنا برای سنجش میزان کارها (از طریق استوری پوینت) قرار گرفته می شود و همچنین می تواند در جلوگیری از پیچیدگی های بی مورد و زمان گیر جلوگیری کند. به عبارتی شما با انجام این کار از هدر رفت زمان در آینده ای نزدیک جلوگیری می کنید.روشهای مورد نیاز:دو روش موفقی که بسیار مورد استفاده قرار می گیرند روش توسعه رفتار محور و روش توسعه فرضیه محور می باشند. مواقعی وجود دارد که شما از یکی یا از هر دو استفاده می کنید و زمانهایی نیز بسته به شرایط شما از روشی متفاوت. فراموش نکنید که نوشتن یوزر استوری از زمان برنامه نویس مفرط یا همان ایکس پی تا به امروز بنا بر نیازهای متفاوت شرکتها گستردگی زیادی را شاهد بوده است.روشBehavior Driven Development (BDD)از آنجایی که این امر از یک نیاز آماری و محاسباتی ناشی می شود، منطقی است که داستان های کاربر خود را شخصی سازی کنیم. یکی از راه های خوب این شخصی سازی، ادغام آن با روش توسعه رفتار محور می باشد و اطلاعات بیشتری در مورد آنچه مورد نیاز است، چرا مورد نیاز است و زمینه های اضافی را در یوزر استوری وارد کنید.مثال:به عنوان [نقش] من [ویژگی] را می خواهم بنابراین [سود]ملاک پذیرشبا توجه به [متن]وقتی [رویداد]سپس [نتیجه]همانطور که مشاهده می کنید چرایی و چیستی در این روش به راحتی به یک شخص فنی و حتی غیر فنی به راحتی انتقال داده می شود. همچنین، مقدار در جمله اول انتقال داده شده و معیارهای پذیرش به راحتی قابل آزمایش است.روشHypothesis Driven Development (HDD)روش توسعه فرضیه محور یک گام به عقب تر رفته و از انتقال خروجی های تجاری باز می گردد و می پرسد: چگونه بفهمیم که خواسته مد نظر برای کاربر نهایی ارزشمند است یا خیر؟مثال:ما معتقدیم که <این قابلیت>منجر به <این نتیجه> خواهد شدوقتی <سیگنالی قابل اندازه گیری می بینیم> می فهمیم که موفق شده ایمآنچه مدیران عالی محصول روی میز می آورند ، نه تنها مجموعه ای از ایده های عالی از طرف خود ، طراحان ، مهندسان ، سهامداران و کاربران است ، بلکه توانایی آزمایش این ایده ها ، تفسیر نتایج و تصمیم گیری آگاهانه تر است.توسعه فرضیه محور شما را در راه ایجاد یک فرضیه قوی کمک می کند و تعیین می کند که چگونه موفقیت ، ایمنی و رفتار را از ابتدا اندازه گیری کنید. این روش از زمان صرف شده و دلسردی تیم از آزمایشاتی که پس از انجام یک یوزر استوری میتواند گرفتار آن شود، جلوگیری می کند.سفارشی سازیمواقعی وجود دارد که شما نیاز دارید یوزر استوری را برای یک پروژه سفارشی کنید. البته که در همه موارد این سفارشی سازی به معنی بهتر کردن داستان شما نیست و باید آن را بر اساس نیاز خاص به محصول اضافه کرد و نه ترجیح. وقتی که مشتری برای یک محصول افزودن معیاری را برای تست یکی از ویژگی های نرم افزار خود تقاضا می کند جزو این نیازهای خاص است.قالب:از بین همه افرادی که <اقدام> می کنند (جمعیت)چند (عدد)در <مشاهده> (مخرج)از آنجایی که این امر از یک نیاز آماری و محاسباتی ناشی می شود، منطقی است که داستان های کاربر خود را شخصی سازی کنیم. یکی از راه های خوب این شخصی سازی، ادغام آن با روش توسعه رفتار محور می باشد و اطلاعات بیشتری در مورد آنچه مورد نیاز است، چرا مورد نیاز است و زمینه های اضافی را در یوزر لستوری وارد کنید.مثال:به عنوان [کاربر] [متریک] را می خواهم تا [بتوانم ویژگی جدید را آزمایش کنم]ملاک پذیرش:با توجه به وجود داده هاوقتی از معیار بازدید برای خرید در صفحه اصلی استفاده می کنمسپس نتیجه ای را مشاهده خواهم کرد:از بین همه افرادی که از صفحه اصلی بازدید کرده اند (جمعیت)چه تعداد روی دکمه "خرید" کلیک کردند (عدد)برای بازدید از صفحه اصلی (مخرج)اما جدای از اینکه چارچوب نوشتن یوزر استوری شما کدامیک است، رعایت نکاتی در همه این روشها بسیار ضروری است و باید به آنها توجه کرد. نکاتی که باید رعایت شوند عبارتند از:1. بدون ابهام بودنصفات یکی از مهمترین منابع ایجاد ابهام در یوزر استوری هستند. صفاتی مانند خوب، عالی، بهتر، کامل، عادی و... را در نظر بگیرید. بدلیل انتزاعی بودن این صفات معنا و شکل استفاده آنها برای افراد مختلف، متفاوت می باشد و این موضوع می تواند باعث ایجاد سوءتعبیراتی از یوزر استوری شود. بعنوان مثال بجای «کاربر می تواند با کلیکهای خیلی کم به کارایی الف برسد» میتوانید بگویید:«کاربر می تواند با 3 کلیک به کارایی الف برسد».منبع ابهام دیگری که باید به آن دقت کرد فعلها هستند. فعلها مخصوصا با گرایش به گذشته می توانند دردسرهایی را برای تبیین درست یوزر استوری ها ایجاد کنند. افعالی مانند: انجام خواهد شد، تعریف می شود، در دسترس بوده است و استعلام شده بود جزو این گروه هستند که به روان و ساده بودن یوزر استوری لطمه می زنند. در کل استفاده از استفاده از جملات کوتاه و ساده بهترین راهکار برای یک یوزر استوری خوب و مناسب است و باعث می شود که از تعبیرات دوگانه دوری شود.2. کامل بودنبرای اینکه تیم بتواند بیشترین درک را از بک لاگ محصول داشته باشد، یوزر استوری باید تمام اطلاعات مورد نظر را داشته باشد. نباید فراموش کنیم که اگر هنگام نوشتن یوزر استوری در دادن اطلاعات تکمیل کننده و جامع خساست به خرج دهیم در طول جلسات اسپرینت باید زمان اضافه ای را برای تکیل آن صرف کنیم.3. با ثبات بودنثبات و تقارن خواسته های ما یکی از اصلی ترین ویژگی های مورد نیاز در اسکرام هستند. فراموش نکنید که هدف ما در پروژه حل کردن یکه مساله پیچیده می باشد و نباید خودمان با تغییر در نوع ارایه خواسته هایمان از تیم باعث پیچیدگی و سردرگمی آنها شویم. ثبات در نیازها حتی در مابقی متد های مدیریت پروژه هم از اهمیت بالایی برخوردار است. اگر پرهیز از دوباره کاری ها در تیم خود هستید حتما به این نکته توجه ویژه کنید.4. امتیاز بندی شده بر اساس اهمیتعنوان بهتر برای این ویژگی نوشتن یوزر استوری با این پیش فرض که قرار است بر اساس اهمیت کار امتیاز دهی و درجه بندی شوند، است. در توسعه یک محصول چابک باید به این نکته توجه شود که چیزی که از همان ابتدا برای تیم مهم است امتیاز بندی بک لاگ مخصول می باشد و این صرفا یک ارزش گذاری تجاری نیست و کارهای مورد نیاز برای رسیدن به آن ویژگی هم شدیدا مد نظر تیم است.حتی همه فعالیتهای تیم در طول اسپرینتهای پیش رو و نسخه های اولیه نرم افزار تحت تاثیر همین موضوع هستند.5. مستقل بودنیوزر استوری ها باید مستقل باشند. اهمیت این نکته هم در زمان امتیاز بندی بک لاگ محصول و هم در جلسه برنامه ریزی اسپرینتها گریبانگیر ما خواهد شد. البته در رعایت این نکته باید حواسمان به این موضوع هم باشد که نباید بین مستقل بودن یوزر استوری و کامل بودن آن یکی را فدای دیگری کنیم.6. قابل تست بودنقابل تست بودن به این معنی است که هر کسی می تواند وارد آن شود و بررسی کند که آیا داستانهای کاربر کار می کنند یا نه. در اینجا هم باز باید از استفاده از صفات دوری کرد. از عباراتی مانند کاربر پسند و به خوبی کار کند استفاده نکنید.7. نحوه اجرا و پیاده سازی الزامات یوزر استوری را مشخص نمی کندالبته پیشنهاد دادن به تیم ممنوع نیست و همانطور که تیم توسعه می تواند ویژگی های کاربردی را پیشنهاد دهند، صاحب محصول می تواند پیشنهادات فنی ارائه دهد. اما نیازی به وسواس در این کار نیست و باید توجه داشت که نحوه اجرای کار در نهایت توسط تیم مشخص می شود.8.توافقی بودنچیزی که نباید هیچوقت از یادتان برود هدف نوشتن یوزر استوری است. شما قرار است نیازهای مشتری را در قالبی مشخص به تیم منتقل کنید. پس نباید از چیزی که مد نظر مشتری است فاصله بگیرید و در نظر داشته باشید که بهترین محصولی که از یوزر استوری شما حاصل می گردد وقتی است که توافق شکل گرفته با مشتری در آن به طور واضح بیان شده باشد.9.قابل مذاکره بودناولین کسانی که بعد از نوشتن یوزر استوری نظرات خود را حول آن وارد می کنند، اعضای تیم می باشند. اما آنها تنها کسانی نیستند که با آنها سر و کار دارید. مشتری و مدیران بالا دستی را هم باید وارد لیست کنید تا متوجه شوید قابل مذاکره بودن چیزی که می نویسید چقدر مهم است. در یک داستان کاربر باید به وضوح مشخص شود که خواسته ها و چراها به گونه ای قابل آزمایش است که هم توسط مهندسی و هم از نظر تجاری قابل درک باشد.نتیجه گیری نهاییاکنون ما آشنایی خوبی با روشهای نوشتن یوزر استوری و همچنین نکات مهمی که باید رعایت کنیم، داریم. اما این پایان راه نیست و نوشتن یوزر استوری خوب نیاز به کسب تجربه در یک محیط تجاری جدی هم دارد. فاکتورهای زیادی وجود دارد که باید در هنگام قضاوت در مورد اینکه آیا یک داستان به نتیجه دلخواه خود می رسد در نظر گرفته شود ، از جمله اینکه آیا یک ساختار ، اندازه داستان ، برش های عمودی در مقابل برش های افقی و موارد دیگر دارد. یک روش آسان برای قضاوت این است که از روش INVEST بیل ویک استفاده شود.در پایان باید به این نکته هم اشاره کنم که یوزر استوری بعنوان یک ابزار مدیریت پروژه در نظر گرفته می شود که به دستیابی نتیجه محصول کمک می کند. پس از وسواس بیش از حد در انتخاب روشها بپرهیزید و سعی کنید به هدف اصلی این ابزار وفادار بمانید.

5 موضوع بحث برانگیز که از اسکرام حذف شدند

آرش قنبری — Tue, 29 Jun 2021 16:09:38 +0430

گر بیشتر از 5 سال باشد که با اسکرام آشنا باشید، منبع متفاوتی برای درک اسکرام داشته اید که امروز وجود ندارد. موارد زیادی وجود دارد که زمانی به عنوان بخشی از اسکرام تعریف می شدند ، حتی در راهنمای اسکرام ذکر شده اند ، اما در برخی موارد حذف شدند. برخی از موارد به طور کلی خارج شدند و موارد دیگر با چیز دیگری جایگزین شد. منطقی است که بسیاری هنوز این موضوعات را به اسکرام پیوند می دهند ، اما اسکرام تکامل یافته است و در نتیجه انجام این کار دیگر منطقی نیست.در اینجا 5 مورد بحث برانگیز آورده شده است که یا حذف شده یا جایگزین شده اند. اگر این موارد شما را به تأخیر انداخته است ، ممکن است بخواهید در مورد مفید بودن اسکرام تجدید نظر کنید.1. مرغ و خوکراهنمای اسکرام داستان زیر را داشت:روزی یک مرغ و یک خوک با هم بودند. مرغ به خوک گفت: بیا یک رستوران بزنیم.خوک به فکر فرو میرود و سپس میگوید: اسم این رستوران را چه میگذاریم؟ مرغ می گوید: ژامبون و تخم مرغ!خوک می گوید: نه ممنون، شما فقط درگیر این موضوع خواهید شد در حالیکه برای من یک تعهد واقعی اشت!تیم اسکرام خوک و بقیه مرغ هستند. یک مرغ نمی تواند به خوکها بگوید که چگونه کار خود را انجام دهند.این داستان همیشه تاثیر مطلوبی نداشته باعث ایجاد اختلاف بین تیم اسکرام و عوامل بیرون از تیم مانند مشتری یا مدیران شده. این داستان از نسخه 2011 به بعد خارج شده است.2. تعهد به کار برنامه ریزی شده در اسپرینتاز سال 2011 ، تیم توسعه دیگر متعهد به کار برنامه ریزی شده در اسپرینت نیست و در عوض پیشبینی می کند.این یک تغییر اساسی بود. تعهد باعث این میشد که هیچ بینش جدیدی در طول اسپرینت در تیم بوجود نیاید. این بینش و پیشبینی بر اساس اصول تجربه گرایی در نظر گرفته میشوند: شفافیت، بازرسی، سازگاری.3.آراستگیراهنمای اسکرام نسخه 2012 آراستگی بک لاگ محصولات را تنها بعنوان نکته در نظر گرفته شده بود وسپس در نسخه جولای 2011 به راهنمای اسکرام اضافه شد. نسخه ژوِییه 2013 آراستگی را با پالایش جایگزین کرده است. زیرا کلمه آراستگی بار منفی دارد.4.سه سوال در طول اسکرام روزانهراهنمای اسکرام به اعضای تیم اجبار می کند که سه سوال زیر را همواره در جلسات اسکرام روزانه پاسخ دهند:1.چه کاری را از آخرین جلسه به بعد تکمیل کرده؟2.چه کاری را قبل از جلسه بعدی انجام می دهد؟3.چه موانعی بر سر راه او وجود دارند؟در نتیجه جلسات اسکرام روزانه اغلب چیزی بیش از یک رویداد وضعیتی نبودند و در نتیجه تیم غالبا هدف اسپرینت و چگونگی اوضاع را در نظر نمی گرفت. به طبع آن تیم اسکرام روزانه موثری نداشت و این موضوع دید بدی به آن می داد. به همین دلیل در سال 2013 این سه سوال تغییر یافتند:1.دیروز چه کاری انجام دادم که به تیم توسعه کمک کرده هدف اسپرینت را برآورده کند؟2.امروز برای کمک به تیم توسعه در رسیدن به هدف اسپرینت چه کاری انجام خواهم داد؟3.آیا مانعی می بینم که از دستیابی من یا تیم توسعه به هدف اسپرینت جلوگیری کند؟این یک قدم بزرگ رو به جلو می باشد. با این حال وقتی تیمی خود سازمان دهی می کند، می تواند به این نتیجه برسد که راه دیگری برای دستیابی به بهترین کارایی در اسکرام روزانه دارد. به همین دلیل در سال 2017 سه سوال را بعنوان آپشنی در اسکرام روزانه معرفی می کند و تصریح می کند که تا زمانیکه تمرکز روی هدف اسپرینت باشد میتوان از رزشهای مختلف استفاده کرد.5.استاد اسکرام جلسات اسکرام روزانه را رهبری می کنداین همان چیزی است که کتاب "توسعه نرم افزار چابک با اسکرام" می گوید: استاد اسکرام مسئول انجام موفقیت آمیز اسکرام روزانه است. این کتاب همچنین در مورد چگونگی راه اندازی جلسات اسکرام روزانه توضیحاتی می دهد. راهنمای اسکرام 2010 این مورد را تغییر داد: استاد اسکرام از برگزار شدن جلسه توسط تیم اطمینان حاصل می کند. این تیم مسئولیت اجرای برنامه اسکرام روزانه را بر عهده دارد.از زمان ارایه نسخه 2010 راهنمای اسکرام این وضعیت همچنان باقی مانده است. تیم توسعه مسئولیت اسکرام روزانه را بر عهده دارد. زیرا آنها یک تیم خود سازمان دهنده هستند که پیشروی به سمت هدف اسپرینت را ارزیابی می کنند. در واقع استاد اسکرام تیم را بری جلسات 15 دقیقه ای روزانه مربیگری می کند و همچنین مواردی را که مورد نظر تیم توسعه در این جلسات است را سازماندهی می کند. با این تفاسیر لازم نیست حتما در جلسات شرکت کند.