Story point?

[Sahar Safavi]

مجموع کل ساعتهایی که برای
task
مشخص میشه باید با میزان نیرو روزی که برای
story point
های یک داستان در نظر گرفتیم یکی باشه؟(در صورتی که
story point
بر حسب نیرو روز باشه)

مثلا یک داستانی که یک نیرو روز هست در شرکتی که 6 ساعت در روز کار می
کنه مجموع ساعتهایی که در وظایفش مشخص میشه باید به 6 ساعت برسه؟

[Sadeq Naqashzadeh]

ضریب توجه هم یک عامل است.
مثلا با ضریب توجه ۵۰٪ باید دوروز کار برای استوری‌پوینت معادل یک روز
کار در نظر گرفت

2011/6/28 Sahar Safavi <serena...@yahoo.com>:

[Hamid Saberi]

سلام
ما هم درباره تخمین تسک ها و نسبت اون با تخمین داستان خیلی درگیر بودیم
و هستیم
چند نکته به ذهنم میرسه که عرض می کنم
اول اینکه خود گردانی ِ تیم نکته بسیار مهمیه که یکی از مواردی که تاثیر
زیادی روی اون داره تخمین و زمانبندی کارهاست
وقتی کارها با معیارهای زمانی مثل نیرو روز یا نیرو ساعت تخمین زده
میشند، هرچند خود ِ تیم این تخمین ها رو زده باشه این احساس وجود داره که
باید اون کار در اون زمان انجام بشه و در بسیاری موارد تغییرات یا
مشکلاتی در مسیر انجام کار بوجود میاد که کار رو طولانی تر میکنه

اما بطور مشخص درباره سوال شما به نظر من مجموع تخمینی که برای تسکهای یک
داستان زده میشه باید در حدود تخمین داستان باشه. میشه بازه ی مختصری
برای کمتر یا بیشتر بودن در نظر گرفت، اما حتما اگر داستانی رو یک یک
نیرو روز تخمین زدید، و وقتی تسکهای اونو تخمین میزنید مثلاً 9 ساعت یا
بیشتر مجموع تخمین تسکها شد، به این نتیجه میشه رسید که تخمینی که برای
داستان زده بودید درست نبوده.
به نظر من هرگز خودتونو ملزم نکنید که باید مجموع تخمین تسکها به اندازه
تخمین داستان باشه. بلکه درصورتی که مجموع تخمین تسکها تا حد زیادی بیشتر
یا کمتر از تخمین داستان مربوط به تسکها بود، این تخمین داستان ِ که باید
درست بشه، نه تخمین تسکها.
یک دلیل برای این حرف اینه که تسک ها کوچکتر هستند و تخمین کارهای کوچک،
دقیق و صحیح تره (این نکته رو بارها ما با مقایسه درستی تخمین کارها در
بازبینی اسپیرینت در کارمون دیدیم) بنا بر این مجموع تخمین تسکهای یک
داستان، تخمین دقیقتری برای اون داستان ِ، تا یک تخمین کلی که برای
داستان زده شده
تاکید و یاداوری میکنم که تخمینها فقط تخمین هستند و نباید حساسیت زیاد
روی دقیق و محکم بودن اونها داشت. مثلاً اگر مجموع تسکهای کار ِ 1 نفر
روزه 6.5 یا 7 ساعت شد، زیاد مته به خشخاش نگذارید!
نکته دیگه اینکه این بازه ی قابل قبول از اختلافِ این دو مقدار (تخمین ِ
داستان و مجموع تخمین تسکها) باید نسبت به اندازه تسک متفاوت باشه. مثلاً
شاید برای داستان با تخمین یک نیرو روز اختلاف قابل قبول یکی دو ساعت، و
برای یک داستان با تخمین 15 نیرو روز یکی دو روز باشه.

[Hamid Saberi]

جناب نقاش زاده عزیر
برداشت من از ضریب توجه متفاوته.
من اینطور متوجه شدم که اینطور نیست که اگر ضریب توجه مثلاً 50% باشه،
کار ِ یک روزه رو 2 روز تخمین بزنیم
بلکه در برنامه ریزی اسپیرینت اگر کلاً برای مثال 100 نفر روز نیرو
داریم، و ضریب توجه 50% بوده، به اندازه 50 نفر روز برای اسپیرینت کار
تعهد میکنیم.
(هرچند با حالتی که شما فرمودید یعتی دو برابر تخمین زدن کارها هم همین
نتجیه حاصل میشه، اما به نظرم اون حالت کمی مبهم به نظر میرسه و مهمتر
اینکه تخمین ِ زده شده برای کارها رو غیر واقعی میکنه. مثلاً ممکنه کار ِ
یک روزه رو تیمی با ضریب توجه 50% در یک روز انجام بده، و اونچه باعث
هدر رفتن زمان میشه مسائل دیگه در بین انجام کارها باشه)ء

[Ashkan Roshanayi]

چند تا نکته راجع به تخمین وجود داره که بد نیست یه بار مرور کنیم:

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

دوما تخمین زمان انجام کار بسته به پارامترهای خیلی زیادیه و وقتی مهندسین با متغیرهای به شدت وابسته به تعداد زیادی پارامتر مواجه میشن چیکار میکنن؟ بله سعی میکنن انتزاعی تر و ساده تر ببینن مساله رو تا قابل حل بشه!‌ این تکنیک اگرچه برای برنامه نویسی و طراحی عالیه ولی برای تخمین زمان کارها افتضاح به بار میاره!

سوما و مشخصا درباره استوری پوینتهای اسکرام: اینه که اساسا هیچ ارتباط مستقیمی و معناداری با مواردی مثل نفر-ساعت، نفر-روز، نفر-ساعت-تیمی و ... نداره و به تجربه من هر موقع سعی کردم به زور همچین ارتباطی رو قبل از اجرای ۳ یا ۴ اسپرینت واقعی برقرار کنم نتیجه ای به بار نیومده. استوری پوینت ها برای قیاس بین پیچیدگی دو استوری هستند و نه چیز بیشتر.

 (همه اینها رو گفتم که به این نکته برسم که با فرض ثبات افراد تیم و با لحاظ کردن روزهای تعطیلی در جلسه برنامه ریزی اسپرینت (که در مملکت ما کم هم نیستن

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

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

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

-------

اشکان روشنایی

www.rubako.ir/blog

2011/6/28 Hamid Saberi <hamid....@gmail.com>

[sahar]

سلام

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

در واقع موضوع پرژه پایانیم هستش.راجع به اسپرینت و

استوری پوینت مشکل دلرم.منابعی هم که دوستان اینجا گذاشتن مثل کتاب اسکرام و اکس پی ساده شده رو خوندم

اما الان نمیدونم آیه بر اساس در خواست مالک محصول الویت بندی میکنیم داستانها رو؟ پس تکنیک پوکر پلنینگ برا چیه؟

[سـ ـهیل‎]

با سلام

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

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

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

[mohsen momeni]

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

 مالک محصول ارزش هر یک از داستان‌های کاربر را مشخص می‌کند. 

توسعه‌دهندگان سایز هر یک از کارهای لازم برای توسعه‌ی داستان‌ها را (از نظر فعالیتی که برای توسعه‌ی آن‌ها لازم است (معمولن با استفاده از تکنیک پوکرپلنینگ)) انجام می‌دهند.

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