آموزش اسکرام

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

برای اینکه درک درستی از زیربنای اسکرام داشته باشیم باید مقایسه بین روش های سنتی مدیریت پروژه بین اسکرام انجام دهیم. باید بدانیم چرا از اسکرام استفاده میکنیم و کجا اسکرام به عنوان یک متد برای ما مناسب است.

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

تغییر پذیری و عدم قطعیت را از چهار منظر بررسی می کنیم. پذیرش تغییرپذیری سودمند، توسعه تدریجی و تکراری، تطبیق و شفافیت در تغییر پذیری و کاهش عدم قطعیت. چه تفاوتی بین توسعه تدریجی و تکراری وجود دارد و چرا دارای اهمیت است؟

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

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

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

section 26

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

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

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

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

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

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