اونچه اسکرام پیش از آغاز فاز تحلیل و پیاده سازی توصیه میکنه؟؟؟

[ali valizadeh]

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

[Yahya Mohajer]

سلام

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

پس این شناخت و جلو رفتن قدم به فدم با حضور مشتری برداشته مبشه
البته این برنامه ریزی و مرتب کردن و داکیومنت کردن و مشخص کردن اولویت
ها نیاز مند روش های متفاوتی هست که در روش های چابک دیده شده

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

شاید یکی از مهمترین چیز ها قبل از پروژه نحوه ی قرارداد و ارتباط شروعی
با مشتری باشه که بتونید این روش رو به درستی براش شرح بدید و مزایا و
نحوه ی عملکرد رو بهش منتقل کنید

[Ali H. Moghadam]

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

2011/5/27 Yahya Mohajer <ya.mo...@gmail.com>

[Yahya Mohajer]

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

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

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

ولی یه صورت فاز خیر چیزی نداریم

Yahya

On May 28, 10:00 am, "Ali H. Moghadam" <ali.mogha...@gmail.com> wrote:
> سلام
> البته اسکرام نمیگه نباید قبل از شروع تولید راجب محصول فکر کرد. اتفاقا به نظر
> من خیلی هم خوب و لازمه که صاحب محصول قبل از اینکه دنبال پیاده سازی باشه و
> بیاد سراغ تیم توسعه, مدتی رو به تعمق و تفکر بگذرونه و خوب به اینکه محصول به
> چه دردیش قراره بخوره فکر کنه و اگه لازمه با سایر شرکا هم مذاکره کنه و تا حدی
> هم که میتونه راجب نیازها پیش بینی بکنه و حتی یه مستند اولیه و یه سری دیاگرام
> هم تولید کنه (حالا با هر فرمتی, مثلا شاید سند چشم انداز تجاری, ولی خب البته
> نباید محدود بشه به قالب های آماده) و میشه اسم این مرحله را تحلیل هم گذاشت.
> ولی نکته در اینه که اولا این سند نقطه شروع خواهد بود نه حرف آخر و در ضمن
> پروسه توسعه ممکنه همه چیز این سند تغییر کنه و ثانیا فاز جداگانه ای به نام
> طراحی وجود نداره
> علی
>

> 2011/5/27 Yahya Mohajer <ya.moha...@gmail.com>

[Ashkan Roshanayi]

ما برای اینکه یه شناخت اولیه نسبتا خوب از پروژه پیدا کنیم یه کم اسکرام رو تغییر دادیم (پیشنهاد میکنم شما هم به اسکرام به دید یه چارچوب حداقلی نگاه کنین همیشه انیجوری خیلی مسایل حل میشه!) به این ترتیب که یه اسپرینت 0 اضافه کردیم که بهش 

tracer bullet

میگیم (البته این مفهوم رو از یه فرآیند دیگه گرفتیم) و این اسپرینت معمولا 1 ماه است  در حالی که اسپرینت های عادی و بعدی 2 هفته ای هستن. در طی اسپرینت 0 ما و صاحب محصول به همراه هم سعی میکنیم حوزه مساله رو بهتر بشناسیم و 

Product backlog

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

  ورژن اولیه از پروداکت بکلاگ ناظر به هسته اصلی مساله * 

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

 خاصی CASE tool  بدون استفاده از ERD مدل سازی دامنه بصورت شی گرا یا *

معماری قابل اجرای واقعی با پیاده سازی 1 یا 2 مورد از نیازمندیهای ملموس برای صاحب محصول* 

این اسپرینت باعث میشه که ما در اسپرینت های بعدی خیلی چابک تر حرکت کنیم و تقریبا دید نسبتا مشترکی با صاحب محصول داشته باشیم.

درباره گسترش اسکرام و مواردی نظیر اسپرینت 0 و جایگاه معماری در اسکرام (و اساسا فرآیندهای چابک) به زودی یه رشته پست http://www.rubako.ir/blog هایی رو در وبلاگمون خواهیم داشت.

----
Ashkan

2011/5/28 Yahya Mohajer <ya.mo...@gmail.com>

[Yahya Mohajer]

این هم یک راه بسیار خوبیه
مخصوصا که از قبل ابزار هاتون آمادس و تجربه ی خوبی هم باهاشون دارید
در این اسپرینت میشه نرم اقزار های دیگه مثل سی آی و ورژن کنترل و جیرا
و بفیه ابزار ها رو برای پروژه جدید آماده کنید

http://blogs.collab.net/agile/2007/05/19/sprint-zero/?q=blog/dan_rawsthorne/sprint_zero

که در اکس پی هست دیدش و ریسک پروژه رو پایین آورد spike در بعضی از
پروژه ها هم می شه به دید

که این به تیم و پروژه و تجربه های قبلی بر می گرده

Yahya

On May 28, 12:11 pm, Ashkan Roshanayi <ashkan.roshan...@gmail.com>
wrote:

> ما برای اینکه یه شناخت اولیه نسبتا خوب از پروژه پیدا کنیم یه کم اسکرام رو
> تغییر دادیم (پیشنهاد میکنم شما هم به اسکرام به دید یه چارچوب حداقلی نگاه
> کنین همیشه انیجوری خیلی مسایل حل میشه!) به این ترتیب که یه اسپرینت 0 اضافه
> کردیم که بهش
> tracer bullet
> میگیم (البته این مفهوم رو از یه فرآیند دیگه گرفتیم) و این اسپرینت معمولا 1
> ماه است  در حالی که اسپرینت های عادی و بعدی 2 هفته ای هستن. در طی اسپرینت 0
> ما و صاحب محصول به همراه هم سعی میکنیم حوزه مساله رو بهتر بشناسیم و
> Product backlog
> متشکل از صرفا نیازمندیهای خیلی اساسی که بدون اونها محصول بی معنی میشه یا

> ماهیتا غیر-کارکردی که ریسک محسوب میشن رو در بیاریم. * خروجی های اصلی این
> اسپرینت* اینها هستن:

>   ورژن اولیه از پروداکت بکلاگ ناظر به هسته اصلی مساله *
> مجموعه ای استوری کارت ها که یادداشت های ما از آیتم های پروداکت بکلاگ هستن و
> باید مجتمع و وارد جیرا بشن *
>  خاصی CASE tool  بدون استفاده از ERD مدل سازی دامنه بصورت شی گرا یا *
> معماری قابل اجرای واقعی با پیاده سازی 1 یا 2 مورد از نیازمندیهای ملموس برای
> صاحب محصول*
>
> این اسپرینت باعث میشه که ما در اسپرینت های بعدی خیلی چابک تر حرکت کنیم و
> تقریبا دید نسبتا مشترکی با صاحب محصول داشته باشیم.
>
> درباره گسترش اسکرام و مواردی نظیر اسپرینت 0 و جایگاه معماری در اسکرام (و

> اساسا فرآیندهای چابک) به زودی یه رشته پستhttp://www.rubako.ir/blogهایی رو

> در وبلاگمون خواهیم داشت.
>
> ----
> Ashkan
>

> 2011/5/28 Yahya Mohajer <ya.moha...@gmail.com>

[Hamidreza Motaghian]

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

2011/5/28 Ashkan Roshanayi <ashkan.r...@gmail.com>

--
Regards,
H.R.Motaghian

[sina ostadhashem]

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

[Ashkan Roshanayi]

حمیدرضا: آره مخصوصا زمانی که پروژه بزرگه و بحث معماری و شناخت اولیه اش در عرض یکماه کار سختی میشه. تکرار اسپرینت 0 ولی راه حل کار نیست و علیرغم اینکه خیلی وسوسه خواهید شد که اینکارو بکنین اکیدا توصیه میکنم سراغش نرین! چون همیشه جای کار هست و شما هیچوقت به شناخت کامل و معماری ایده آل نخواهید رسید و این کار صرفا شما رو میبره سمت فرآیندهای آبشاری و مشکلات خاص خودش.

در این حد که شما بتونین ریسک های پروژه (نیازمندیهای غیرکارکردی) رو دیده باشین و یه معماری 

اولیه ساده که بشه در اسپرینت های بعدی تکمیلش کرد رو تولید کنین (تقریبا معادل 

( توی آر.یو.پی executable architecture

برای بستن این اسپرینت 0 کفایت میکنه. البته باز هم تجربه شما از حوزه مساله خیلی موثره.

حالا اگه پروژه خیلی بزرگ بود و نشه این کارو 1 ماهه انجام داد چی؟ آیا اسپرینت 0 رو بکنیم 2 ماه؟

یا حتی بیشتر؟ به نظرم اینجاست که وقتشه بجای پیدا کردن جواب ایده آل، صورت مساله رو عوض کنین یعنی پروژه رو به چند تا پروژه کوچکتر بشکنین (با هدایت و راهنمایی صاحب محصول) که بشه اسپرینت 0 شونو توی حداکث 1 ماه جمع کرد. البته این نتیجه ایه که من بهش رسیدم و راه حل های دیگه ای هم برای مساله میتونه وجود داشته باشه.

----
Ashkan

2011/5/28 Hamidreza Motaghian <m.ham...@gmail.com>

[Yahya Mohajer]

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

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

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

On May 28, 12:39 pm, Hamidreza Motaghian <m.hamidr...@gmail.com>
wrote:

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

> 2011/5/28 Ashkan Roshanayi <ashkan.roshan...@gmail.com>

>
>
>
>
>
>
>
>
>
> > ما برای اینکه یه شناخت اولیه نسبتا خوب از پروژه پیدا کنیم یه کم اسکرام رو
> > تغییر دادیم (پیشنهاد میکنم شما هم به اسکرام به دید یه چارچوب حداقلی نگاه
> > کنین همیشه انیجوری خیلی مسایل حل میشه!) به این ترتیب که یه اسپرینت 0 اضافه
> > کردیم که بهش
> > tracer bullet
> > میگیم (البته این مفهوم رو از یه فرآیند دیگه گرفتیم) و این اسپرینت معمولا 1
> > ماه است  در حالی که اسپرینت های عادی و بعدی 2 هفته ای هستن. در طی اسپرینت 0
> > ما و صاحب محصول به همراه هم سعی میکنیم حوزه مساله رو بهتر بشناسیم و
> > Product backlog
> > متشکل از صرفا نیازمندیهای خیلی اساسی که بدون اونها محصول بی معنی میشه یا

> > ماهیتا غیر-کارکردی که ریسک محسوب میشن رو در بیاریم. * خروجی های اصلی این

> > اسپرینت* اینها هستن:

> >   ورژن اولیه از پروداکت بکلاگ ناظر به هسته اصلی مساله *
> > مجموعه ای استوری کارت ها که یادداشت های ما از آیتم های پروداکت بکلاگ هستن و
> > باید مجتمع و وارد جیرا بشن *
> >  خاصی CASE tool  بدون استفاده از ERD مدل سازی دامنه بصورت شی گرا یا *
> > معماری قابل اجرای واقعی با پیاده سازی 1 یا 2 مورد از نیازمندیهای ملموس برای
> > صاحب محصول*
>
> > این اسپرینت باعث میشه که ما در اسپرینت های بعدی خیلی چابک تر حرکت کنیم و
> > تقریبا دید نسبتا مشترکی با صاحب محصول داشته باشیم.
>
> > درباره گسترش اسکرام و مواردی نظیر اسپرینت 0 و جایگاه معماری در اسکرام (و
> > اساسا فرآیندهای چابک) به زودی یه رشته پستhttp://www.rubako.ir/blogهایی
> > رو در وبلاگمون خواهیم داشت.
>
> > ----
> > Ashkan
>

> > 2011/5/28 Yahya Mohajer <ya.moha...@gmail.com>

[Hamidreza Motaghian]

ممنون اشکان. خود شکوندن پروژه هم حرف کمی نیست! داستان زیاد داره یه دفعه یه جوری میشکنیم که پروژه ریز ریز میشه ;)
ات یحی: بحث رو به آر.یو.پی نمیخوام منحرف کنم . اساس ایتریتوبودن مستقل از اسکرام یا آر.یو.پی هست
موفق باشید

2011/5/28 Yahya Mohajer <ya.mo...@gmail.com>

--
Regards,
H.R.Motaghian

[ali valizadeh]

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