سلام. خسته نباشید، ممنون از توضیحاتتون.
در فضای واقعی، آیا این موضوع پیش میاد که در مواقعی از پیشبرد پروژه از موقعیت پیچیده به موقعیت آشوب بریم؟
یا اینجور بپرسم، آیا ممکنه یه پروژه یا مسئله دو بخشی بشه و در بخشی نیاز به تثبیت و در بخشی از اسکرام استفاده بشه؟
سپاس
بله، یعنی در واقع اجزای پروژه خودشان میتوانند به تنهایی رفتار مختلفی داشته باشند. با اینکه شاید یک پروژه نرم افزاری در رده پروژه های پیچیده دسته بندی بشود، اما تمام اجزای آن لزوما می توانند پیچیده نباشند. این تعریف صرفا برای این هست که اکثریت موارد پیچیده هستند.
سلام مجدد
در پروژهها، مرسوم هست که کارفرماها فازی به اسم فاز شناخت دارند. (که اصولا از نبود این فاز کوتاه نمیان و مشاور موظف هست طبق RFP یک سری جلسات برگذار کنه بابت پروژه، به نظرم بخشی از جواب What و How در این فاز مشخص میشه)
با توجه به مقاله ایی که از شما اخیرا تو سایت خوندم با عنوان “اسکرام چیست؟”، برام سوال پیش اومد و برگشتم به این تکه از آموزشتون. به نظر میرسه و اگر اشتباه نکنم در اسکرام، این فاز شناخت در هر اسپرینت تکرار میشه و آپدیت میشه و به عنوان یک فاز جدا محسوب نمیشه.
سوال من اینجاست، که آیا میشه با توجه به اصول برخی از کارفرمایان (محیط واقعی پروژه) که در بالا ذکر کردم، این دو روش اسکرام و بخش ابتدایی روش آبشاری رو کمی با هم ترکیب کرد؟ اگر اینطور بشه
سلام
همانطورکه فرمودین، ما در اسکرام چنین چیزی رو نداریم، و شناخت در طول اسپرینت های مختلف اتفاق میفته.
اما
چند پرکتس وجود دارد، مثلا بعضی تیم چیزی به اسم اسپرینت صفر دارن که در اون یک بخشی از شناخت و توافقات حقوقی و طرح ریزی کلی رو انجام میدن.
این مقاله که قبلا نوشته بودم، یک تجربه واقعی در مورد مسئله شما است:
سلام
جالب بود دسته بندی و تعریفتون وقتی داشتم میدیدم این بخش رو به صورت ناخوداگاه تلاش میکردم رو مساله های شرکت مپ کنم این مطالب رو و حس گیجی کمتری بهم دست میداد نسبت به چالش های محصولی که داریم
دم شما گرم
سوالم به طور کلی تر این هست که در اسکرام، شرایط آشوب رو چطوری حل میکنیم؟
درسته که کارها به ۳ دسته واضح، پیچیده، و آشوب تقسیم میشن. و دو دسته اول رو میشه تو اسکرام راحت آورد، اما برای شرایط آشوب چه میکنیم؟
مثلا یک باگ داریم، که تخمین میزنیم ۴ روز شناساییش طول بکشه، چون باید سیستم رو دقیق تست کنیم، سراغ دیتای زیاد و چندین sp بریم تا تازه بفهمیم گره کار کجاست. بعدش هم باید این باگ حل بشه. ولی از ابتدا نمیتونیم بگیم ۴ روز شناسایی، ۱ روز رفع باگ. ممکنه طی ۴ روز هم شناسایی نشه، ممکنه شناسایی بشه ولی رفع کردنش خودش ۴ نفر-روز کار نیاز داشته باشه.
این صورت مسئله که گفتید، جزئی از یک مسئله بزرگتر هست، یعنی در یک مسئله پیچیده، یک مسئله آشوب داریم. من پیشنهادم به شما اینکه این دوره رو مشاهده کنید، چون این دوره اختصاصا به این تیپ مسائلی که شما اشاره کردید، فقط پرداخته است.
به این جور مسئله ها معمولا میگن
complicated
در اینجا هم میشه دوباره از اسکرام استفاده کرد، ولی چون میدونیم چی میخواهیم، حداقل امکان برنامه ریزی بهتری خواهیم داشت. ولی تجربه من این بوده، معمولا وقتی “نحوه” معلوم نیستف و بعدا “آشکار” میشه، روی خود “چی” هم تاثیر داره، مثلا تیم سه تا روش برای انجام کار کشف میکنند، اما در دو مورد میگن نیازمندی رو اگر اینگونه تغییر بدیم، این کار راحتتر انجام میشه و اینطوری وری “چی” هم تاثیر میگذارند
سلام ممنون از آموزش خوبتون. میخواستم بدونم راهی هست که تو حالت توهم دانستن نیستیم؟ مطمئن باشیم اطلاعاتی که داریم و میخوایم براساس برنامه ریزی کنیم درست هستند.
سلام
دو حالت ممکن وجود “میدونیم که نمیدونیم” و “نمیدونیم که نمیدونیم”. در وضعیت اول، چون میدونیم که نمیدونیم یا احتمالش زیاد هست که چیزی رو ندونیم، با انجام آزمایش و تحلیل میشه سعی کرد قطعیت بیشتری بدست آورد. اما در وضعیت دوم، “نمیدونیم که نمیدونیم”، در طی گذشت زمان و البته لا انجام و گرفتن بازخورد میشه متوجه شد. برای همین روش اسکرام، با شکستن کار به بخش های کوچکتر و انجام اونها در بازه های زمانی کوتاه، سعی میکنه چرخه بازخورد کوتاه مدت برای ما ایجاد کنه که سریعتر متوجه بشویم که چیزهایی بود که نمیدانستیم.
Comments
کیفی کردن نمودار خیلی ایده خوبی بود برای کمک به درک مطلب ما.
خیلی ممنون از بازخورد، سعی میکنیم در بخش ها مشابه هم از نمودار و کمی کردن بیشتر استفاده کنیم
سلام. خسته نباشید، ممنون از توضیحاتتون.
در فضای واقعی، آیا این موضوع پیش میاد که در مواقعی از پیشبرد پروژه از موقعیت پیچیده به موقعیت آشوب بریم؟
یا اینجور بپرسم، آیا ممکنه یه پروژه یا مسئله دو بخشی بشه و در بخشی نیاز به تثبیت و در بخشی از اسکرام استفاده بشه؟
سپاس
بله، یعنی در واقع اجزای پروژه خودشان میتوانند به تنهایی رفتار مختلفی داشته باشند. با اینکه شاید یک پروژه نرم افزاری در رده پروژه های پیچیده دسته بندی بشود، اما تمام اجزای آن لزوما می توانند پیچیده نباشند. این تعریف صرفا برای این هست که اکثریت موارد پیچیده هستند.
سلام مجدد
در پروژهها، مرسوم هست که کارفرماها فازی به اسم فاز شناخت دارند. (که اصولا از نبود این فاز کوتاه نمیان و مشاور موظف هست طبق RFP یک سری جلسات برگذار کنه بابت پروژه، به نظرم بخشی از جواب What و How در این فاز مشخص میشه)
با توجه به مقاله ایی که از شما اخیرا تو سایت خوندم با عنوان “اسکرام چیست؟”، برام سوال پیش اومد و برگشتم به این تکه از آموزشتون. به نظر میرسه و اگر اشتباه نکنم در اسکرام، این فاز شناخت در هر اسپرینت تکرار میشه و آپدیت میشه و به عنوان یک فاز جدا محسوب نمیشه.
سوال من اینجاست، که آیا میشه با توجه به اصول برخی از کارفرمایان (محیط واقعی پروژه) که در بالا ذکر کردم، این دو روش اسکرام و بخش ابتدایی روش آبشاری رو کمی با هم ترکیب کرد؟ اگر اینطور بشه
سلام
همانطورکه فرمودین، ما در اسکرام چنین چیزی رو نداریم، و شناخت در طول اسپرینت های مختلف اتفاق میفته.
اما
چند پرکتس وجود دارد، مثلا بعضی تیم چیزی به اسم اسپرینت صفر دارن که در اون یک بخشی از شناخت و توافقات حقوقی و طرح ریزی کلی رو انجام میدن.
این مقاله که قبلا نوشته بودم، یک تجربه واقعی در مورد مسئله شما است:
https://blog.scrum.ir/2016/07/agile-project-kickoff
در مورد اینکه پروژه های چابک رو چطوری میشه استارت زد
سلام
جالب بود دسته بندی و تعریفتون وقتی داشتم میدیدم این بخش رو به صورت ناخوداگاه تلاش میکردم رو مساله های شرکت مپ کنم این مطالب رو و حس گیجی کمتری بهم دست میداد نسبت به چالش های محصولی که داریم
دم شما گرم
سلام
سپاس از به اشتراک گزاری نظرتون خوشحالیم ازینکه این دوره به کار شما آمده .
سلام.
اگر دقیقا بدونیم چی میخوایم، ولی ندونیم چطوری انجامش بدیم، باید چه کار کنیم؟
یعنی What شفاف، و How ناشفاف و غیرقابل پیش بینی هست.
سوالم به طور کلی تر این هست که در اسکرام، شرایط آشوب رو چطوری حل میکنیم؟
درسته که کارها به ۳ دسته واضح، پیچیده، و آشوب تقسیم میشن. و دو دسته اول رو میشه تو اسکرام راحت آورد، اما برای شرایط آشوب چه میکنیم؟
مثلا یک باگ داریم، که تخمین میزنیم ۴ روز شناساییش طول بکشه، چون باید سیستم رو دقیق تست کنیم، سراغ دیتای زیاد و چندین sp بریم تا تازه بفهمیم گره کار کجاست. بعدش هم باید این باگ حل بشه. ولی از ابتدا نمیتونیم بگیم ۴ روز شناسایی، ۱ روز رفع باگ. ممکنه طی ۴ روز هم شناسایی نشه، ممکنه شناسایی بشه ولی رفع کردنش خودش ۴ نفر-روز کار نیاز داشته باشه.
این صورت مسئله که گفتید، جزئی از یک مسئله بزرگتر هست، یعنی در یک مسئله پیچیده، یک مسئله آشوب داریم. من پیشنهادم به شما اینکه این دوره رو مشاهده کنید، چون این دوره اختصاصا به این تیپ مسائلی که شما اشاره کردید، فقط پرداخته است.
سلام با تشکر از شما بابت محتوای دوره. این لینک دوره ای که معرفی کردید انگار حذف شده. برای مشکل اصلی مطرح شده چه راه حلی میشه پیدا کرد؟
سلام و خیلی ممنون
لینک اصلاح شد
دوره آموزشی برنامه ریزی و تخمین چابک
به این جور مسئله ها معمولا میگن
complicated
در اینجا هم میشه دوباره از اسکرام استفاده کرد، ولی چون میدونیم چی میخواهیم، حداقل امکان برنامه ریزی بهتری خواهیم داشت. ولی تجربه من این بوده، معمولا وقتی “نحوه” معلوم نیستف و بعدا “آشکار” میشه، روی خود “چی” هم تاثیر داره، مثلا تیم سه تا روش برای انجام کار کشف میکنند، اما در دو مورد میگن نیازمندی رو اگر اینگونه تغییر بدیم، این کار راحتتر انجام میشه و اینطوری وری “چی” هم تاثیر میگذارند
سلام این تعریف و فلسفه پیچیدگی باعث یه نگاه عمیق تر به اسکرام پیدا کنم و متوجه بشم اسکرام واقعا چیه
خیلی ممنون بابت بازخورد
سلام ممنون از آموزش خوبتون. میخواستم بدونم راهی هست که تو حالت توهم دانستن نیستیم؟ مطمئن باشیم اطلاعاتی که داریم و میخوایم براساس برنامه ریزی کنیم درست هستند.
سلام
دو حالت ممکن وجود “میدونیم که نمیدونیم” و “نمیدونیم که نمیدونیم”. در وضعیت اول، چون میدونیم که نمیدونیم یا احتمالش زیاد هست که چیزی رو ندونیم، با انجام آزمایش و تحلیل میشه سعی کرد قطعیت بیشتری بدست آورد. اما در وضعیت دوم، “نمیدونیم که نمیدونیم”، در طی گذشت زمان و البته لا انجام و گرفتن بازخورد میشه متوجه شد. برای همین روش اسکرام، با شکستن کار به بخش های کوچکتر و انجام اونها در بازه های زمانی کوتاه، سعی میکنه چرخه بازخورد کوتاه مدت برای ما ایجاد کنه که سریعتر متوجه بشویم که چیزهایی بود که نمیدانستیم.