چگونه داستان‌های کاربری و کارها (تسک) مدیریت کنیم؟

[Milad Khajavi]

سلام

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

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

[سـ ـهیل‎]

جناب خواجوی،
به منظور یافتن پاسخ بخشی از سوالاتتون، لطفا به جستجوی کلیدواژه اسپایک بپردازید. مثلا پیشنهاد میکنم این ترکیب رو گوگل کنید spikes in scrum
نتایج خوبی در انتظارتون خواهد بود.

در خصوص بخش دیگر پرسشتون که عدم شناخت فریم ورک و استوری پوینت بود باید عرض کنم که اغلب هیچ تیم اسکرامی در اسپرینت اول نمیدونه چند پوینت رو در آخر اسپرینت تکمیل میکنه. سرعت مفید بعد از سه یا چهار اسپرینت بدست میاد.

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

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

ممنون
سهیل صمدزاده

--

--- You received this message because you are subscribed to the Google Groups "Iran Agile Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iran-agile-community+unsub...@googlegroups.com.
To post to this group, send email to iran-agile-community@googlegroups.com.
Visit this group at http://groups.google.com/group/iran-agile-community.
For more options, visit https://groups.google.com/d/optout.

[Ansar Rezaei]

آقای صمد زاده مرسی بابت مطرح کردن spike
منم نیاز داشتم

[Milad]

سلام،

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

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

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

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

آیا چنین دیدی درست به نظر می‌رسه؟

To unsubscribe from this group and stop receiving emails from it, send an email to iran-agile-commu...@googlegroups.com.
To post to this group, send email to iran-agile...@googlegroups.com.

[سـ ـهیل‎]

دوستان عزیز، آقای خواجوی و رضایی خوشحالم که مشکل تون حل شد.

در مورد فریم ورک و داستان‌های کاربر سعی می‌کنم بیشتر توضیح بدم:
به‌صورت کلی اگر دانش فنی گروه توسعه (اعم از فنّاوری، دامنه محصول، سواد برنامه‌نویسی، سواد مهندسی یا غیره) کم هست، این کاستی‌ها به‌صورت فصل مشترک تمام نیازمندی‌های کارکردی یا غیر کارکردی خودش رو در برآوردها نشون میده.

فرض کنید قصد دارید یک app موبایل برای اندروید تولید کنید که پس از شناسایی کاربر (login)، کانتکت های تکراری در گوشی فرد رو شناسایی و مرتب کنه!

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

1-      لاگین کاربر توسط سرویس google

2-      امکان اسکن کردن contact list کاربر (دکمه مربوط به اسکن دستی)

3-      امکان پیکربندی در خصوص زمانبندی اسکن خودکار

4-      نمایش لیست تداخل‌ها و مغایرت‌ها

5-      امکان پالایش لیست و اعمال تغییرات بر روی contact  کاربر

6-      سینک کانتکت ها با مخاطبان گوگل کاربر

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

خب، توجه کنید که این عدم دانش بر روی کل اقلام بک لاگ سایه انداخته، یعنی اگر پیچیدگی هر قلم بک لاگ رو مستقلا 100 بگیرید، مثلا 30 قسمت از اون مربوط به دانشی هست که ندارید. این 30 درصد در کل داستان های کاربر یکسان هست. در اینجا به اولویت نگاه نکنید، چون ممکن هست اولویت ها توسط مالک محصولتون تغییر بکنه. یعنی اینجور تصور نکنید که خب، وقتی من به قلم سوم برسم، قطعا دانش نداشته ام رو کسب کردم! 

البته اگر بک لاگ و اقلام اون رو درست استخراج بکنید تصمیم گیری براتون راحت تر خواهد شد ولی همیشه کارها به این سادگی نیستند. مخصوصا در بک لاگ های بزرگ!

پس وزن دهی رو بر اساس دانش نداشته تون انجام می دید و بخش از برآورد هر قلم ناخودآگاه شامل نقاط تاریک خواهد بود.

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

در انتها چند نکته رو مدنظر داشته باشید:

1-      در خصوص اسپایک ها: اسپایک ها ابزارهای فرعی و بشدت موقت هستند. در استفاده از اونها زیاده روی نکنید. دیده شده که فرآیند تولید نرم افزار گاها تبدیل به یک پروژه تحقیقاتی شده بجای پروژه عملیاتی و اجرایی.

2-      اگر دانش کافی در زمینه ای ندارید، قبل از شروع فرآیند بخشی از اون رو کسب کنید یا فردی رو در تیم توسعه موظف به کسب اون بکنید تا با ایجاد یک shared collaboration در طول فرآیند، دانش به کل تیم منتقل بشه.

3-      از اسکرام مستر و مالک محصول استفاده کنید. این نقش ها حذف شدنی نیستند و مهم تر از اون نقش های گروهی نیستند.

4-      از فن آوری استفاده کنید که بلدید. پروژه های نرم افزاری جایی برای ماجراجویی نیستند. مالک محصول رو قانع کنید که استفاده از فن آوری که پیشنهاد می کنید، حتی اگر قدیمی هست ولی در نهایت بدلیل کاهش سربار آموزش، ارزش آفرین خواهد بود.

 

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

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

از برآوردها و نیازمندی های بزرگ پرهیز کنید. (به Invest - Guide to Agile Practices رجوع کنید). یعنی مثلا وقتی تصمیم می گیرید که این نیازمندی 2 هفته طول میکشه!، ریسک بالایی رو می پذیرید. اصولا هیچوقت متوجه نشدم که از کجا پی میبریم که این نیازمندی 2 هفته طول میکشه وچرا ده روز طول نمیکشه یا مثل سه هفته؟ در دنیای چابک وقتی یک قلم بک لاگ قراره دو هفته طول بکشه (با توجه به اسپرینت های عموما 3 یا 4 هفته ای)، یعنی باید شکسته بشه یا بهش بیشتر فکر بشه و غیره.

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

توصیه هایی که در بالا گفتم تجربیات و نقطه نظرات شخصی خودم هستند و قطعا روش ها و نظرات دیگری هم وجود داره که میتونه مفید باشه.

از طولانی شدن پاسخ عذرخواهی می کنم.

موفق و چابک باشید
سهیل صمدزاده