موسسه Scrum.org فهرستی از مهارت‌های حرفه‌ای اسکرام را به منظور کمک به هدایت رشد شخصی افراد در رابطه با اسکرام ایجاد کرده است. ایجاد مهارت مرتبط با اسکرام بر اساس اصول اولیه، درک و بکارگیری چارچوب اسکرام آغاز می‌شود و این پایه و اساسی برای رشد شخصی است. شایستگی‌ها و حوزه‌های تمرکز اصلی برای تیم اسکرام (Product Owner، Scrum Master و Developers) و سایر نقش‌ها در سازمان مانند Agile Leaders (رهبران اجایل) اعمال می‌شوند.

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

* با اجازه مخاطب عزیز و دوست داشتنی جملات داخل { … } توضیحات شخصی و خارج از ترجمه می باشند و سعی شده با زبان عامه همراه با شوخی و تمثیل بیان بشه که خوندن ش راحت تر و درک موثری تری داشته باشه. لابلای متن مواردی هست که تیم اسکرامی و محصول و هدفش به صورت گروهی تشبیه شدن که برای رسیدن به یه فانوس دریایی دارن پارو میزنن!

درک صلاحیت‌ها

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

درک و بکارگیری چارچوب اسکرام

• تجربه گرایی (Empiricism) 

{ بر طبق تعریف راهنمای اسکرام تجربه گرایی به معنای کار به شیوه ای “مبتنی بر واقعیت”، “مبتنی بر تجربه” و “مبتنی بر شواهد” است}

• ارزش های اسکرام (Scrum Values)

{ ارزش‌های اسکرام مجموعه‌ای از ارزش‌ها و کیفیت‌های اساسی هستند که در چارچوب اسکرام، تعهد-commitment، تمرکز-focus، صداقت و گشودگی-openness، احترام-respect و شجاعت-courage را شامل میشود.

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

• تیم اسکرام  (Scrum Team)

{ تیم اسکرام فقط و فقط شامل 3 نقش با عناوین Product Owner، Scrum Master و Developers می باشد و تقریبا سایر نقش های سازمانی با عناوین مدیریت و لیدری رو نمی توان در تیم های اسکرامی داشت. اگر میخواهید نقش های سازمانی خاص و مطبوع سازمان خودتون رو داشته باشید لطفا از اسکرام استفاده نکنید! یا ساختاری رو که کار میکنید با عنوان اسکرام خطاب نکنید! مرسی!}

• رویداد‌ها (Events)  

{چارچوب اسکرام دارای 5 رویداد یا جلسه است، شامل: یک تکرار در طول زمان پیشرفت پروژه یا محصول با عنوان Sprint، جلسات روزانه با عنوان Daily Scrum، جلسه برنامه ریزی کارهای هر تکرار با عنوان Sprint Planning،  جلسه بازبینی نتایج و کارهای انجام شده در طول یک تکرار با عنوان Sprint Review و جلسه بازنگری عملکرد و شرایط بهبود تیم برای آینده با عنوان ;Sprint Retrospective که در هر تکرار اجرا می شوند. لطفا و خواهشا خودتون رو گول نزنید! حذف و عدم اجرای صحیح و به موقع این جلسات نتیجه ای جز عدم شفافیت و عدم امکان بررسی و تطبیق پذیری مبتنی بر تجربه گرایی رو از شما خواهد گرفت و بدون آن ها صلاحیت(Competencies) لازم برای اسکرام رو نخواهید داشت، پس بی تعارف اگر نمی خواهید یا شرایط لازم رو ندارید یا علاقه ای به اجرای آن ها ندارید، اجباری نیست!! اسکرام نباشید }

• مصنوعات خروجی‌ها (Artifacts)

{به نظر شخصی خودم از وقتی که حرف از اجایل و اسکرام شروع شد اولین چیزی که زیر سوال رفت و کم کم توی حوزه نرم افزار به حاشیه کشیده شد بحث مهم مستندات بود! اما اسکرام مصنوعاتی دارد که هر کدام میتونن مهمترین مستندات پروژه باشند:  یه product backlog خوب که توش هدف کلی محصول (Product Goal) مشخص باشه و به عنوان هدف مثل یه فانوس دریایی برای تیم و سازمان عمل کنه تا همیشه بتونن علاوه بر تغییر مسیر در امواج و مشکلات پیش بینی نشده مسیر یه هدف بزرگتری برای تنظیم و تطبیق پذیری داشته باشند. یه sprint backlog که اول هر تکرار یا sprint میشینن دور هم و با یه Sprint Goal که در واقع هدف اصلی همون بازه کار هست تا بتونن به فانوس دریایی شون نزدیک و نزدیک تر بشن مقداری کار طراحی و برنامه ریزی میکنند و در نهایت در پایان هر تکرار releasable product increment که همه میدونن خروجی مفیدی هست و عملکرد مثبتی برای تیم و سازمان داره. خود این ها بهترین مستندات پروژه هستند.}

• کارهای انجام شده (Done)

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

• مقیاس‌گذاری (Scaling)

{چیزی که در مورد مقیاس گذاری یا مقیاس پذیری به ذهنم میرسه اینه که اسکرام قابلیت توسعه به ساختار های بزرگ تر رو داره و اگر تیم هایی بیشتر از 10 نفر دارید سعی کنید از قابلیت اسکرام مقیاس پذیر استفاده کنید و به زور تیم اسکرامی 20 یا 30 نفره ایجاد نکنید، چون دیگر صلاحیت اسکرامی نخواهید داشت.}

رشد و توسعه افراد و تیم ها

• تیم های خود مدیریتی (Self-Managing Teams)

{قدیما (راهنمای اسکرام 2017) میگفت Self-Organizing! و تعریف ش این بود که تیم ها خودشون تصمیم بگیرن که کارهای محول شده رو چطوری (How) انجام بدهند. اماااااا! از راهنمای جدید اسکرام که در با نسخه 2020 منتشر شد کلمه “خود مدیریتی” برای تیم ها استفاده میشه که شاید برای برخی مدیران مخصوصا اون هایی که علاقه فراوانی به Command-and-Control-ism دارن جذاب نباشه! بله Self-Managing دقیقا یعنی اینکه تیم های اسکرامی خودشون تصمیم بگیرن What!When!How! و یا به عبارت چه کاری و در چه زمانی و به چه نحوی انجام خواهند داد. اگر این موضوع با مرام منش شما سازگاری نداره یا فریم ورک تون رو عوض کنید یا خودتون رو! در غیر این صورت اسکرام شما تبدیل به شتر گاو پلنگی خواهد شد که با روش نوین مدیریت و توسعه نرم افزار درگیر عقاید سنتی خواهد شد و تیم درگیر اره ای خواهد شد که نه راه پس خواهد داشت نه راه پیش! این صلاحیت self-managing رو خیلی جدی بگیرید! }

• تسهیل گیری (Facilitation)

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

• سبک‌های رهبری (Leadership Styles)

{مهمترین سبکی که در مورد رهبری یا راهبری تیم های اسکرامی سال ها استفاده میشد سبک servant leader یا رهبر خدمت رسان بود که از راهنمای نسخه 2020 ببعد با استفاده از واژه true leadership کار رو برای مدیرانی که دوست دارن رهبران تیم های نرم افزاری باشند سخت و سخت تر کرد. مدیران سنتی و آکادمیک گاهی علاقه شدیدی به مدیریت آدم ها و نتایج دارن نه محصول و کار! با این صلاحیت مدیران باید در خدمت تیم ها باشند و تمام تمرکزشون بهبود محصول و هموار کردن مسیر تیم های اسکرامی برای عملکرد بهتر و بازده بالاتر باشه! توی این روزگار این هم صلاحیت سختی هست! مثل پوست عوض کردن.  }

• مربیگری و راهنمایی (Coaching & Mentoring)

{برای قسمت منتورینگ ش شاید همه مون بدانیم و بتوانیم با دانش و تجربه های گذشته مون همکارها و دوستامون رو منتورینگ کنیم و تقریبا ذاتا همه مون به این کار علاقه داریم. اما کوچینگ! واقعا تعریف متفاوتی داره که به طور خلاصه میشه گفت توانمند سازی افراد مبتنی بر مهارت ها و توانمندی های خودشون هست و هرگز نباید در تصمیم گیری افراد دخالت کرد یا در مورد توانایی شون قضاوت داشت. جداگانه در مورد موضوع کوچینگ در مقاله های بعدی بیشتر می نویسم}

• آموزش (Teaching)
• {تیم ها برای توسعه فردی و گروهی همواره نیاز به آموزش دارن وگرنه تبدیل به معادن ذغال سنگ خواهند شد که تعدادی فسیل فقط دارن محصولی رو تولید میکنند! این یک صلاحیت جدی برای اسکرام مستر و مدیران سازمان هست که همواره به آموزش چارچوب اسکرام یا آموزش های توسعه فنی تیم بپردازند و بدانند و آگاه باشند با پیشرفت تکنولوژی برای بهبود محصول باید همراه با دانش روز بود و بقول مانیفست اجایل “توجه مداوم به برتری فنی و طراحی خوب باعث افزایش چابکی می شود”. خلاصه که این صلاحیت هم به درستی رعایت نشه جای مشتش درد خواهد داشت! }

مدیریت محصولات همراه با Agility (چابکی)

• پیش بینی و برنامه ریزی جهت انتشار (Forecasting & Release Planning)

{انسان ها بعد از عصر یخبندان تا امروز همواره علاقه به تخمین زدن (Estimating) داشتن و دارند و احتمالا خواهند داشت. اما در دنیای تولید نرم افزار یکی از تفاوت های برجسته پروژه با محصول در راستای همین عدم تخمین پذیری محصولات هست که در این حوزه باید با تغییر رویکرد تلاش کنیم به سمت Forecasting یا پیش بینی محصول بریم و برای انتشار نسخه های آینده برنامه ریزی کنیم. دقت کنیم که در پیش بینی احتمالات با امکان بالا در نظر گرفته می شوند ولی عدم قطعیت همواره در آن وجود دارد، که برای مثال مطمئنا در پیش بینی آب و هوا تجربه کردید. }

• چشم انداز محصول (Product Vision)

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

• ارزش محصول (Product Value)

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

• مدیریت بک‌لاگ محصول (Product Backlog Management)

{ بک لاگ محصول مثل برنامه ریزی های زندگی خودمون برای روزهای آینده مون میمونه! هدف زندگی مون همیشه باید مشخص باشه و کارهایی رو انجام بدیم به درد آینده محصول مون بخوره و روند تکاملی رو حفظ کنیم. اگر مدتی از زندگی رو به بطالت یا کارهای هرز بپردازیم قطعا تاثیرش در روزهای آینده خواهد گذاشت.یه بک لاگ محصول خوب باید هدفمند و مفید باشه و همیشه در راستای چشم انداز محصول یا همون Product Vision توسعه و نگهداری بشه. همین ویژگی باعث میشه دولوپر و مالک محصول و سازمان همگی در یه راستا پارو بزنن و زودتر به سمت فانوس دریایی شون نزدیک بشن. }

• استراتژی کسب و کار (Business Strategy)

{استراتژی کسب و کار مشخص می‌کند که شرکت ها یا سازمان ها برای رسیدن به اهداف خود، ملزم به انجام چه کارهایی هستند. این امر می‌تواند به جهت‌دهی فرایند تصمیم‌گیری برای استخدام و تخصیص منابع کمک کند. یا در تعریف تخصصی تری: “استراتژی کسب و کار روشی مبتکرانه برای نمایش دارایی‌های منحصربه‌فرد، افزایش برتری و کمک به عملکرد اجزای شرکت است. این استراتژی خلاصه‌ای از اَعمال و تصمیم‌گیری‌هایی است که یک کمپانی آن‌ها را برنامه‌ریزی می‌کند تا برای رسیدن به اهداف تجاری خود انجامشان دهد”. داشتن و اجرای این صلاحیت کمک بزرگی به توسعه محصول در لایه مدیران خواهد کرد.}

• ذینفعان و مشتریان (Stakeholders & Customers)

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

توسعه و ارائه حرفه‌ای محصولات

• توسعه نرم افزار Emergent یا (Emergent Software Development)

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

• مدیریت ریسک فنی (Managing Technical Risk)

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

• کیفیت مستمر (Continuous Quality)

{ واقعا نیازی به توضیح داره؟ خودتون محصول بی کیفیت رو دفعه های دوم و سوم و … استفاده میکنید؟ بیایید جوری محصول تولید کنیم انگار عزیزان خودمون قراره ازش استفاده کنند!  و به صورت شخصی و تیمی و سازمانی همواره به حفظ و بهبود کیفیت محصولات و نسخه های ارائه شده به کاربران و مشتریان حساس باشیم. بقای هر محصولی در گرو رضایت مشتریان و “کیفیت مستمر” هست و لاغیر}

• یکپارچه سازی مداوم (Continuous Integration)

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

• • تحویل مستمر (Continuous Delivery)

{ آیا میشه سالی یه پابلیش داد؟ سالی 2 تا؟ هر سه ماه یه پابلیش؟ آیا میشه دقیقا فقط برای هر ماه یک پابلیش رو برنامه ریزی کرد؟ اگر جواب همه این موارد “خیر” هست تبریک میگم! شدیدا به تفکر و فرهنگ تحویل مستمر نیاز دارید و هر چه زودتر باید به فکر ابزار های DevOps باشد. این صلاحیت رو اگر رعایت نکنید مشتریان رو از دست خواهد داد و کم کم ذینفعان رو از محصول نا امید خواهید کرد. یه ویژگی خوبش هم اینه که آخر هفته ها بجای شرکت میرید در کنار خانواده و به امور شخصی و تفریحی می پردازید و دیگه نیازی نیست جمعه ها بیایید پابلیش کنید! نمیدونم باور کنید یا نه اما دستاوردهای این صلاحیت علاوه بر کیفیت محصول توی روح و روان خودتون و اعضای تیم بیشتر از دمنوش اسطوخودوس و روغن بنفشه یا عرق بیدمشک تاثیر مثبت داره. }

• بهینه‌سازی جریان (Optimizing Flow)

{چیزی که در زمان نوشتن این خط به ذهنم رسید فقط و فقط اصل 10 مانیفست اجایل بود: “سادگی — هنر به حداکثر رساندن مقدار کار انجام نشده — ضروری است” و ما همواره باید فرآیند ها و جریان های کاری رو بررسی و بهینه سازی کنیم تا از هدر رفتن (Waste) منابع جلوگیری کنیم. در همین راستا یه جمله دوست داشتنی هست از آنتوان دو سنت-اگزوپری نویسنده کتاب معروف شازده کوچولو هست که میگه: کمال به دست می آید، نه زمانی که چیزی برای اضافه کردن وجود نداشته باشد، بلکه زمانی که چیزی برای حذف باقی نمانده باشد. پس زودتر جریان های کاری مون رو بهینه کنیم. }

تکامل سازمان Agile

• طراحی و فرهنگ سازمانی (Organizational Design & Culture)

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

• برنامه ریزی پورتفولیو(Portfolio Planning)

{این مورد هم در آینده با مطالعه و آگاهی بیشتری با ترجمه یا به صورت دست نوشته پوشش داده خواهد شد. }

• مدیریت مبتنی بر شواهد (Evidence Based Management™)

{ نقطه تقابلی که plan-driven-management با اسکرام و سایر روش های اجایلی دارن اینه که همیشه سعی داشتن همه چیز رو از قبل برنامه ریزی کنند و پروژه رو مطابق اعداد و ارقام اولیه پیش ببرند! ولی واقعیت اینه که نمیشد و نمیشه و نخواهد شد. قیمت ها هر روز عوض میشن! آدم ها تغییر میکنند! روش ها عوض میشن! ذائقه ها عوض میشن و ….! خلاصه که دنیا هر روز و هر لحظه در حال تغییر هست و برای انعطاف پذیری و بهبود عملکرد محصول باید نگاه مدیران به سمت مدیریت مبتنی با داده ها و سوابق و شواهد عوض بشه. اگر خیلی مقاومت کنند جای مشت این صلاحیت هم بسیار بسیار دردناک هست، چون روش های توسعه نرم افزار اجایل اصولا با روش های مدیریت سنتی پروژه یا Taylorism نه تنها تطبیق نداره بلکه در اکثر موارد دارای تضاد هم هستند. }