آیا داشتن دانش فنی برای اسکرام مسترها ضروری است؟

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

به تازگی در گروه تلگرامی Iran Agile چالشی مطرح شد و آقای «اسد صفری» سوالی مطرح کرد و پاسخهای دوستان حاوی نکات تامل بر انگیزی بود که البته می‌توانید در گروه به آنها دسترسی داشته باشید.

اما سوال این بود:

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

هومن کشاورز:

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

مهیار:

• به نظرم اسکرام مستر باید از پرکتیس های تولید تجربه عملی داشته باشه و به قول شما فنی باشه که واسه حرفش تره خرد کنن. وگرنه اگه یک آدم بی تجربه بخواد حرف از TDDو Refactor و از این دست بزنه بعیده که اثری روی تیم بذاره

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

یوسف بزرکار:

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

محمد حسین احمدی:

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

دلپاک:

من نظرم اینه که اسکرام مستر بهتره در مسایل فنی (حتی اگر مهارت داشته باشه) بی طرف باشه و تصمیمات رو به تیم واگذار کنه. اسکرام مستر عضو تیم توسعه نیست و قرار نیست Best Practice های کدینگ و دیزاین رو به اعضای تیم آموزش بده. اسکرام مستر به سه حوزه از مسایل باید توجه کنه:

• Adaption
• Transparency
• Inspection

اینها عمده مسوولیت اسکرام مستر هستند.

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

از همه اینها گذشته اسکرام مستر بهتره که Soft Skill‌ داشته باشه تا Hard Skill. شما یه ادم خیلی فنی هم به عنوان اسکرام مستر داشته باشید ولی آدم اشتباهی باشه، یعنی Soft Skill نداشته باشه فرایند با مشکل مواجه میشه. برعکسش خیر.

نقشهای اسکرام به وضوح تفکیک شده اند.

• Product Owner
• Scrum Master
• Development Team

در مورد اینکه سوال فرمودید که چرا اسکرام مستر عضو تیم نیست، خب به دلیل همون تفکیک نقشها و به طبع اون تفکیک اختیارات و مسولیتها هستش.
آیا در جلسات برنامه ریزی اسپرینت، دیدید که روی ظرفیت اسکرام مستر، پلن بشه؟
اسکرام مستر یه تسهیل گر و ناظره که سعی میکنه تیم یا سازمان به سطح بالغ تری از چابکی برسه. این حوزه عمل اسکرام مستر به کلی با حوزه عمل تیم توسعه متفاوته و کمترین وجه مشترکی ندارند.
من در پاسخ بعضی از دوستان دیدم که اشاره کردند که مثلا اسکرام مستر اگه TDD‌بلد نباشه، تیم ازش حرف شنوی نداره. به نظرم این کاملا اشتباهه. اسکرام مستر به تیم چابک گوشزد میکنه که به موضوع Technical Excelence توجه جدی داشته باشن. این به عهده ی خود تیمه که اساسا از پرکتیسی مثل TDD‌ یا سایر پرکتیسهای طراحی و تست و حتی ALM استفاده کنه یا خیر.
احساس نیاز به اینها باید از درون تیم بجوشه و نه اینکه توسط اسکرام مستر تزریق بشه.
خلاصه اینکه در مورد اسکرام مستر و تعاملش با اعضای تیم، نظرم اینه که اساسا بحث فنی مشترکی ندارند و به همین حرف شنوی یا پیروی و ... اصلا نباید محل مناقشه باشه. اگر تیمی دچار این وضعیت شده،‌احتمالا با یک اسکرام مستر مداخله گر که به توان خودسازماندهی تیم تردید داره، مواجه هستیم.

سهیل:

حالا سوال اینه که آیا همچین اسکرام مستری که دقیقا همینجوری کار بکنه و همینقدر ازش انتظار باشه -دست کم توی ایران، داریم؟
اون سازمانی که آگهی استخدام اسکرام مستر درج و منتشر میکند، دقیقا چه چیزی در سر می پروراند؟

محمد حسین احمدی: [In reply to . Delpak]
فکر کنم یه چیزی که باعث ابهام میشه، بحث اتوریته داشتن اسکرام مستر روی فرایند هست. اگه اسکرام مستر روی فرایند اتوریته داشته باشه، پس آیا معنیش اینه که می تونه از تیم بخواد مثلا کدشون رو با TDD بزنن؟ که در این صورت باید تیم ازش حرف شنوی داشته باشه و بنابراین اسکرام مستر باید فنی باشه.
اگر اسکرام مستر همچین اختیاری نداشته باشه، اون وقت باید با روشهایی شبیه اون مثالی که بالا زدم تیم رو ترغیب بکنه به بهبود فرایندش، که در این صورت میشه همون Adoption Agent که آقای صمدزاده بالاتر گفتند و می تونه فنی نباشه، هرچند فنی بودن در این شرایط هم بهش کمک می کنه تا سریعتر بتونه تیم رو در مسیر بهبود سوق بده.
کدومش درست تره؟ می تونیم بگیم دومی بهتره ولی توی شرایط غیر ایده آل (مثلا توی سازمان های ایرانی) اولی هم رویکرد قابل قبولیه؟

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

"... although the ScrumMaster has no authority over Scrum team members, the ScrumMaster does have authority over the process. Although a ScrumMaster may not be able to say, “You’re fired,” a ScrumMaster can say, “I’ve decided we’re going to try two-week sprints for the next month.”

" They have authority, but that authority is granted to them by the team."

" A ScrumMaster can say to a team, “Look, we’re supposed to deliver potentially shippable software at the end of each sprint. We didn’t do that this time. What can we do to make sure we do better the next sprint?” This is the ScrumMaster exerting authority over the process; something has gone wrong with the process if the team has failed to deliver something potentially shippable."

" But because the ScrumMaster’s authority does not extend beyond the process, the same ScrumMaster should not say, “Because we failed to deliver something potentially shippable the last sprint, I want Tod to review all code before it gets checked in.” Having Tod review the code might be a good idea, but the decision is not the ScrumMaster’s to make. Doing so goes beyond authority over the process and enters into how the team works."

" Project managers often have the fallback position of “do it because I say so.” The times when a ScrumMaster can say that are limited and restricted to ensuring that Scrum is being followed."
https://www.mountaingoatsoftware.com/agile/scrum/scrummaster

دلپاک: [In reply to Mohammad Hossein Ahmadi]
اتوریته روی فرایند نه تنها مجوزی برای دخالت در تصمیمات فنی تیم تولید نمیده و بلکه با مبانی چابکی متضاده.
تاکید میکنم که اسکرام مستر حتی اگر با دانش و تجربه فنی باشه،‌ نباید پرکتیسی رو به تیم تحمیل یا تزریق کنه. من می پسندم تیمم چند اسپرینت شکست بخوره و به هدف اسپرینت نرسه اما خودش به این نتیجه برسه که مشکل از کجاست و خوش راه حل بده. این موید دو ارزش از ارزشهای XP هم هست:

Respect
Courage

دلپاک: [In reply to سهیل صمدزاده]
خب اسکرام قرار نیست کل مشکلات بشریت رو با هم حل کنه.
اما اینکه سازمان با چه نیتی آگهی استخدام اسکرام مستر زده، یعنی اینکه فکر میکنی اسکرام مستری میخواد که به الگوهای معماری، Clean Code , تست و ریفکتور و غیر و ذالک آشنا باشه؟‌
من اگه توی همچین مصاحبه ای شرکت کنم به مصاحبه کننده میگم «مردی و کاری» روشنش میکنم. همین.

محمد حسین احمدی: [In reply to . Delpak]
👍👍
موافقم، ولی این مثال مایک کان من رو گیج کرده:

... a ScrumMaster can say, “I’ve decided we’re going to try two-week sprints for the next month.”

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

دلپاک: [In reply to Mohammad Hossein Ahmadi]
تفاوت اینه که TDD‌موضوعی مربوط به نحوه ی کد نویسیه، اما طول اسپرینت مربوط به فرآینده. تنظیم طول اسپرینت چیزیه که اختیارش با اسکرام مستره که البته این هم معمولا به صورت توافقی با تیم تعریف میشه.
در مورد تیمهایی که گفتید که نظر اسکرام مستر رو نمیپذیرند و میخوان اسپرینت یک ماهه داشته باشند، این به نظرم نوعی مداخله ی تیم در کار اسکرام مستره که این هم باید توسط آموزش و مذاکره و گفتگو اصلاح بشه و تیم درک کنه که همانطور که اسکرام مستر در جزییات کدینگ دخالت نمیکنه اونها هم نباید در مسله ای مانند طول اسپرینت دخالت کنند.
مثال مایک دقیقا همینه که اسکرام مستر کجاها اختیار عمل داره و کجاها نداره.
به همین منوال تیم هم اختیار عمل محدودی داره و مجاز نیست که بازی اسکرام رو به هم بزنه.

بهروز بختیاری: [In reply to . Delpak]
دقیقن موضوع همین است چون مباحثی مانند TDD، معماری و ... اصلن در اسکرام مورد بحث نیستند و اسکرام مستر هم نباید خودش را درگیر این مسائل بکند حتی اگر در این حوزه ها هم تخصص داشته باشد

دلپاک:

آنکل باب توی کتاباش دو اصطلاح Code Smell‌ و Design Smell‌ رو مطرح میکنه و همه شما با این مفاهیم اشنایید. من مایلم از Process Smell‌ صحبت کنم. نمیدونم قبلا این اصطلاح جایی بیان شده یا خیر. اما منظورم از این اصطلاح اینه که وقتهایی فرایند بو دار میشه و نشون از شروع خرابی و فاسد شدن فرایند هستش.
از این Process Smell ها میشه به همین تمایل اسکرام مستر برای فورس کردن تیم به استفاده از پرکتیسهای کد و طراحی استفاده کرد.
اسکرام مستر نباید همچین اشتباهی کنه و تیم هم نباید همچین اجازه ای بده.

مجتبی ایزدی:

اگر فرهنگ تیمی خوبی حاکم باشه و نقش‌ها کاملاً مشخص باشند، آیا مطرح کردن یه مسأله‌ی فنی توسط اسکرام‌مستر، به صورت مشاوره یا پیشنهاد، خوب نیست؟

دلپاک: [In reply to MJ Izadi]
اگه اون موقع کلاه اسکرام مستر سرش نگذاشته باشه خیلی هم مفیده.

محمد حسین احمدی: [In reply to سهیل صمدزاده]
باز هم این سؤال هست که مگه پرکتیس های فنی برای potentially shippable بودن محصول در پایان هر اسپرینت و در نتیجه برای اجرای صحیح اسکرام حیاتی نیستند؟ پس بالاخره اسکرام مستر - به عنوان اسکرام مستر - باید به تیم پیشنهاد این پرکتیسها رو بده یا نه؟
توی راهنمای اسکرام هم یکی از وظایف اسکرام مستر اینه: آموزش و رهبری تیم برای ایجاد محصولات با ارزش بالا. آیا این شامل پرکتیس های فنی نمی شه؟

مهیار: [In reply to Behrouz Bakhtiari]
درسته که توی راهنمای اسکرام اسمی از TDD برده نشده اما TDD اصلا یک پرکتیس چابکه و حتی خودش مستقلا بعنوان یک متدولوژی مطرح میشه.
در راهنمای اسکرام یکی از سرویسهایی که اسکرام مستر به تیم میده این ذکر شده

Helping the Development Team to create high-value products;

به نظرم راهنمایی تیم توی حوزه هایی مثل TDD شامل این بند میشن

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

همه میدانیم که اسکرام مستر servant leader است... همه چیزهایی که میگم‌از leaderبودنش‌ناشی‌میشه... میدانیم که فرق مدیر و رهبر اینه که مدیر دستور میده اما رهبر نشون میده... اسکرام مستر هم باید بتونه روش صحیح انجام یک پرکتیس را به تیم نشون بده. وگرنه از لیدر تبدیل‌ میشه به مدیر یا مشاور

سهیل: [In reply to Mohammad Hossein Ahmadi]
نه حیاتی نیست. اگر حیاتی به معنی عدم  توانایی زندگی (توسعه) بدون اون عنصر باشه.
برای پروژه/تیم من ممکنه حیاتی باشه و برای پروژه/تیم شما خیر
آب حیاتی ه ولی آب پرتقال حیاتی نیست ، گرچه ممکنه خیلی مفید باشه ؛)

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

دلپاک: [In reply to Mahyar]
من فکر میکنم که high value بودن ارتباطی با استفاده از پرکتیسهایی کد تمیز و ریفکتور و طراحی نداره. بلکه ناظر به ایجاد بالاترین ارزش برای ذینفعانه. اسکرام مستر این اطمینان رو برای ذینفعان فراهم میکنه که در هر itrate چیزی ارزشمند تولید شده. از طرف دیگه به تیم گوشزد میکنه که هر زمان اماده باشه که به استقبال تغییرات بره. اینجاست که تیم باید مکانیسمی برای افزایش توان پذیرش تغییرات داشته باشه. فکر میکنم هر تیم چابکی در اینجا ارزش ازمونهای مختلف و پرکتیسهای کد تمیز و اصولی مانند SOLID رو درک میکنه.

من مخالف هر گونه بحث و گفتگو و توصیه  فنی بین اسکرام مستر و تیم توسعه هستم. شاید رادیکال به نظر بیاد. باز هم میگم که "مردی و کاری".
اصل Single Responsibilty رو هم اینجا بیاریم بد نیست 😉

مهیار:

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

علی دیشیدی: [In reply to . Delpak]
ممنون بابت جواب. من اینجوری به قضیه نگاه نمیکنم. به نظرم برای فضای کاری ما در ایران، که توش تجربه دارم، کاربردی نیست. یعنی در تئوری حرفتون قابل درک هست ولی در عمل فکر نمیکنم بشه اجراش کرد. فکر میکنم اجرای هر متدی در این فضای غیرحرفه‌ای که ما داریم احتیاج به آدم های چند بعدی و مربی طور داره. نمیتونیم خطی بکشیم و کلا هر رل رو منحصر به کار خودش بکنیم.

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

دلپاک: [In reply to Ali Deishidi]
اتفاقی که در ایران افتاده اینه که تقریبا همه ی اسکرام مسترها افرادی هستند که قبلا در نقشهایی مانند «سرپرست تیم»، «برنامه نویس ارشد» یا «مدیر واحد تولید» و ... فعالیت کردند. این افراد (از جمله خودم) وقتی که میخوان نقش اسکرام مستری ایفا کنند، نمیتونند از نقش قبلی خودشون فاصله بگیرن. این مشکل وجود داره. تا چند وقت پیش توصیه های فنی این اشخاص لازم الاجرا بوده ولی الان در فریم ورک اسکرام مجالی به ایشون داده نمیشه.
اما راه حل به نظرم اینه که اسکرام مستر ها بتونند به موقع کلاه با رنگ مناسب سرشون کنند. ضمنا پرکتیسهای ترویج و اشتراک دانش و برنامه های آموزشی و ... میتونه به تیم ها کمک کنه که تجربیات فنی محدود به افراد خاصی نمونه.

علی دیشیدی: [In reply to . Delpak]
با این کاملا موافقم. از اون طرف هم ولی اسکرام مستری که میگید وجود نداره. کارشناسان صنایعی هستند در نقش اسکرام مستر که به "گان چارت"  و "نیرو" علاقه دارن و یا مدیرانی که قبلا طرف حسابشون مدیر فنی بود و الان طاقت ندارن بشنون مدیر فنی سابق فلان چیز رو میدونسته ولی تیم رو "مجبور" نکرده به انجامش. برای عبور از این فضا قوانین سفت و سخت کار رو نشد میکنند.

دلپاک: [In reply to Ali Deishidi]
میشه یه نمونه از «فلان چیز رو میدونسته» بفرمایید که منم ذهنم به شما نزدیکتر بشه؟

علی دیشیدی: [In reply to . Delpak]

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

دلپاک: [In reply to Ali Deishidi]

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

سهیل: [In reply to Ali Deishidi]
البت اسکرام مستر خوب اونه که دیگه اسپرینت دوم، دیگه خیلی دیر، اسپرینت سوم موضوع رو برای تیم عینی کرده باشه ؛)
اینم بگم. گاهی اسکرام مسترها و چابکسرها (یه وقتی خودم هم به اشتباه اینجور بودم) میگن، به من چه، به درک (پوزش 🙊🙈) ، بذار fail بشن. وظیفه ی من نیست که، چه و چه و چه...
ولی بعدها فهمیدم که استراتژی مناسبتری هم میشه پیش گرفت و اون چیزی شبیه Training from the Back of the Room هست.

علی دیشیدی: [In reply to . Delpak]
دارم سعی میکنم تضاد فضای کاری ایران با اسکرام رو واضح کنم. تیم از شکست نمیترسه اتفاقا. برای مدیر هضم این سناریو که توضیح دادم سخته ولی. مدیر تیپیکال فرصت برای آزمون و خطا نمیبینه.

دلپاک: [In reply to سهیل صمدزاده]
آخه چرا اسکرام مسترها فکر می‌کنند «دانای کل» هستند؟
اسکرام مستر تا کجا میخواد Suggest , Advice بده؟ اختیارات فرایندی کافی نیست که میخواد پا تو کفش توسعه دهندگان کنه؟
تیم رو قوی کنید ماهی گیرشون کنید ماهی بهشون ندید.

سهیل:

من همچین رویکردی ندارم والا. برعکس ولی چون پروژه ها و محصول ها یه جور کارنامه ن برام، خوشم نمیاد زیاد fail بشن 😄
احتمالا چون زیاد fail کردم 😂

توی راهنمای اسکرام سه جا از coach برای اسکرام مستر استفاده شده. گمونم باید مجهز باشه به یه سری ترفند های آموزشی و پرورشی البته 😉 حالا چه فنی و چه غیرفنی

مسعود بهرامی:

‎نقش های اسکرام از مباحث اصلی و اساسی در اسکرام هستند و کمبود یا عدم ایفای مناسب هرکدام میتونه مشکلات اساسی آشکار و پنهانی داشته باشد.
از نظر بنده مجهورترین و در عین حال پر بحث ترین و چالش برانگیرترین مباحث در مورد همین رول #اسکرام_مستر مطرح هست.
که تمایل داشتم #چالش بعدی رو در این زمینه در مورد یک مسیله fundamental  ولی مهم مطرح کنم. که چون بحث امروز به درازا کشید باشد بوقتی دیگر.
اما در مورد بحث امروز توضیحات زیر در مورد sm رو بنده خدمت دوستان مطرح می کنم.
‎وظیفه اصلی اسکرام مستر ساری و جاری کردن مناسب فرآیند اسکرام در سازمان هست.  بله جاهای زیادی از کلمه Coach استفاده شده اما از این واژه تعبیر به غلط دستور و دخالت در تیم نشود. مدیریت تیم که تیم بتواند به بهترین نتیجه برسد که این جمله کلی خود جای بحث زیادی داره.
از بین بردن فشار بیرونی به تیم تشکیل منظم و درست میتینگ های اسکرام مانیتور کردن بگ لاگ آیتم ها که همیشه آیتم به اندازه کافی باشه و تعامل با po در این زمینه. جلوگیری از over-commit تیم اسکرام و ...  اینها بخشی از وظایف محوله اوست.
بله دقیقا اسکرام مستر اتوریتی داره اما این اتوریتی بخصوص در مباحث تکنیکال کاملا به تیم و اعضای تیم تفویض میشه و به هیچ وجه حتی گاها رابطه اسکرام مستر و تیم اوردری یا حتی افری(بقول آقای دلپاک با کلاه اسکرام مستری) نیست.
اصولا فرض کنید اسکرام مستر فنی باشه و نظر فنی هم بده و کمک کنه از اونجایی که ممکنه در بحثی فنی که تضارب آرا پیش بیاد و چون ممکنه در بعضی مباحث فنی تیم ممبری(هایی) باشن که از اسکرام مستر در بعد تکنیکال بهتر باشد این در ادامه میتونه نوعی تقابل بوجود بیاره که تبعات مشخص و هویداست
فصل الخطاب از آقای مایک کان عزیز

The ScrumMaster is there to help the team in its use of Scrum. Think of the help from a ScrumMaster as similar to a personal trainer who helps you stick with an exercise regimen and perform all exercises with the correct form. A good trainer will provide motivation while at the same time making sure you don’t cheat by skipping a hard exercise. The trainer’s authority, however, is limited.

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