https://virgool.io/feed/@amirhossein.bozorgkian برای اطلاعات بیشتر وب سایت شخصی bozorgkian.com در دسترس میباشد fa 2026-04-14 10:54:50 https://files.virgool.io/upload/users/1729022/avatar/pWNLVt.jpeg?height=120&width=120 https://virgool.io/@amirhossein.bozorgkian https://virgool.io/@amirhossein.bozorgkian/%D8%B5%D9%84%D8%A7%D8%AD%DB%8C%D8%AA-%D9%87%D8%A7-%D9%88-%D9%85%D9%87%D8%A7%D8%B1%D8%AA-%D9%87%D8%A7%DB%8C-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D8%AD%D8%B1%D9%81%D9%87-%D8%A7%DB%8C-v3hl3kqtnzfx موسسه 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 نه تنها تطبیق نداره بلکه در اکثر موارد دارای تضاد هم هستند. }امیدوارم براتون مفید بوده باشهبا تشکر، امیرحسین بزرگ کیان امیرحسین بزرگ کیان امیرحسین بزرگ کیان Wed, 17 Aug 2022 01:30:30 +0430 https://virgool.io/@amirhossein.bozorgkian/%D8%A8%D8%A7%D8%B2%D8%A8%DB%8C%D9%86%DB%8C-story-points-ryt4fdhk61fq دوست داشتم بگویم که Story Points را من ابداع کرده‌ام، اما در صورت انجام چنین کاری، در حال حاضر احساس شرمندگی می‌کنم .......این مقاله توسط Ron Jeffries نوشته شده است و در بلاگ ایشان وجود دارد. لینک.دوست داشتم بگویم که Story Points را من ابداع کرده‌ام، اما در صورت انجام چنین کاری، در حال حاضر احساس شرمندگی می‌کنم. بیایید با هم نظرات من را در مورد Story Points مورد بررسی قرار دهیم. حداقل یکی از ما به نظرات من درباره این موضوع علاقه مند است.در حقیقت Story ها، یک ایده از متدولوژی XP هستند و نه یک ایده که Scrum باشد. به نوعی، کارشناسان حوزه Scrum این ایده را پذیرفته‌اند، حتی اگر Scrum Guide (راهنمای اسکرام) به backlog item ها اشاره داشته باشد به هر حال استفاده از  backlog item ها به جای User Stories یک روش رایج در اسکرام است. حداقل تا اندازه‌ای که آنها به درستی متوجه موضوع شوند.در جای دیگری من در مورد نحوه صحیح استفاده عمومی از استوری‌ها مطالبی را نوشته‌ام. در اینجا ما به موضوع “Story Points”  خواهیم پرداخت.درXP در ابتدا Story ها بر مبنای زمان برآورد می‌شدند: زمان مورد نیاز برای اجرای یک Storyما به سرعت به سراغ چیزی رفتیم که به آن « Ideal Days» (روزهای ایده‌آل) می‌گفتیم. این اصطلاح به طور غیررسمی به این شکل تعریف می‌شد که اگر مدیران یا مزاحمین شما را تنها بگذارند، چقدر طول می‌کشد تا این کار را یک گروه دو نفره(pairs) انجام دهد. برای تبدیل Ideal Days به زمان واقعی اجرا، آن را در  “load factor” ضرب می‌کردیم. load factor تقریباً در اکثر موارد 3 بود: سه روز واقعی برای انجام یک کار Ideal Day و تمام کردنش.ما در مورد برآوردهای خود بر اساس تعداد روز‌ها صحبت کردیم و معمولاً توجهی به ویژگی «ایده آل بودن» نداشتیم. در نتیجه این نگرش یا رفتار ما، ذینفعان اغلب در مورد اینکه چگونه سه روز برای انجام یک کار یک روزه مورد نیاز است(تخمین زده می شود) یا با نگاهی به روی دیگر سکه، چرا نمی‌توان کار ۵۰ «روز» را در طی سه هفته انجام داد، دچار سردرگمی می‌شدند.بنابراین، تا جایی که به خاطر دارم، دیگر تصمیم گرفتیم به جای “Ideal Days” تنها از عبارت “points” استفاده کنیم. بنابراین یک Story در سه Point تخمین زده می‌شود به این معنی که تکمیل آن حدود ۹ روز طول می‌کشد. در حقیقت ما از Point ها تنها برای تصمیم‌گیری در مورد میزان انجام کار استفاده کردیم که باید در یک iteration انجام شود، بنابراین اگر بگوییم این مقدار حدود بیست Point است، هیچ کس با این گفته مخالفتی نداشت.ممکن است من پیشنهاد تغییر نام را داده باشم. اگر این کار را من انجام داده‌ام، در حال حاضر پشمان هستم. در اینجا برخی از نظرات فعلی من در مورد این موضوع، در قالب ایمیلی که به همکارم سایمون سوال پرسیده بود و من در پاسخ ارائه شده داده ام را مرور خواهیم کرد :– آیا واقعاً از ابداع آنها پشیمان هستید یا احساس تاسف شما به دلیل استفاده نادرست از آنها در زمانی است که اندازه نسبی به درستی درک نشده است؟من اینگونه پاسخ دادم که:• من قطعا از سوء استفاده آنها ابراز تاسف می کنم.(قطعا احساس تاسف من به دلیل است که از آنها استفاده نادرست می شود)• از نظر حتی  استفاده از آنها در بهترین حالت، برای پیش بینی «زمان اتمام کار» ایده ضعیفی است.• من فکر می‌کنم پیگیری یا ردیابی(tracking) نحوه مقایسه واقعیات با برآوردها در بهترین حالت کاری بیهوده است.• به نظر من مقایسه تیم‌ها بر اساس کیفیت تخمین‌ها یا سرعت، امری زیان بار است.اجازه دهید کمی عمیق‌تر به این موضوع نگاه کنیم.برخی از رویکردهای به “Agile” در واقع با هدف برنامه ریزی آسان‌تر، توصیه میکنند که نرمال سازی Story Point‌ها در تیم ها انجام شود. در حالی که ظاهرا این امر به اندازه کافی معقول به نظر می‌رسد، احتمال افتادن در دام مقایسه تیم‌ها بسیار بالا است و اغلب سازمان‌ها در چنین شرایطی قرار می‌گیرند.انجام مقایسه – Comparingقبل از هر چیز، حتی اگر آنها «از ظاهر یکسانی برخوردار باشند»، هر تیم دارای مهارت‌های خاص خود است و در محیط مختص به خود کار می‌کند. بنابراین، اگر آنها به دو استوری مشابه نگاه کنند، یکی از تیم ها بگوید این 2 و دیگری بگوید این 6 است، این مسئله چندان جالب نخواهد بود و مطمئناً روش مفیدی نیز برای مقایسه تیم‌ها محسوب نمی‌شود.اکنون من و شما با دیدن آن موقعیت، با کنجکاوی برای فهمیدن این موضوع به آن نزدیک می‌شویم که آیا موقعیت‌ها برای مقایسه شدن به اندازه کافی شبیه هستند یا خیر؟، و سپس بررسی می‌کنیم که آیا قادر به ارائه کمک به تیم دارای برآوردهای بالا‌تر هستیم یا خیر؟. این شاید خوب باشد(خوب به نظر برسد). به صورت ضمنی و یا صریح نتیجه‌گیری کنید که تیم «کند‌تر» ضعیف‌تر یا به نوعی در هم ریخته است! اما این بسیار بد است و متاسفانه امری رایج است.از نظر من، مقایسه دو تیم تولید کننده محصول برای بسیاری از مدیران وسوسه ای است که نمی‌توانند در برابر آن مقاومت کنند. همچنین معتقدم تا حدی این مسئله وسوسه انگیز است که در صورت امکان، مفهوم Story Point‌ها و حتی تصور برآورد کردن Story ها را کنار بگذارم. ما مجدد به این سوال خواهیم پرداخت که چگونه با برآورد‌های کمتری کار کنیم، در وبلاگ (ron jeffries) مقالات دیگری نیز وجود دارند که این موضوع را مورد بررسی قرار می‌دهند.پیگیری و ردیابی – Trackingبرای بسیاری از مدیران، وجود یک estimate ضروری می باشد و وجودش یک امر «واقعی» یا بدیهی هست و به این معنی است که شما باید برآوردها را با واقعیت‌ها مقایسه و اطمینان حاصل کنید که برآوردها و واقعیت‌ها با یکدیگر مطابقت دارند! و حتی خودداری از انجام این کار به این معنی است که افراد باید بهتر تخمین زدن را یاد بگیرند.به نظر من، نکته مهم در رابطه با Real Agile این است که چند کار بعدی را انتخاب کنیم و آنها را به سرعت انجام دهم. مسئله کلیدی یافتن با ارزش‌ترین کارها و انجام سریع آنها است. انجام سریع آنها در نهایت به انجام کارهای کوچک با ارزش بالا و تکرار سریع ختم می‌شود. برآورد هزینه story ها کمک چندانی به این موضوع نمی‌کند.بنابراین اگر وجود یک برآورد باعث شود که مدیریت مسئله ارزش را نادیده بگیرد( their eye off the ball of value) و به جای آن به دنبال بهبود برآوردها باشد، نسبت به هدف اصلی یعنی ارائه سریع ارزش واقعی (deliver real value quickly) بی‌توجه می‌شود.این مسئله باعث می‌شود به این نتیجه برسم که از برآوردها چه در Pointها و چه در زمان باید اجتناب شود.فشار – Pressureفشار مربوط به نگرانی ها در مورد estimate/actual، فشار طبیعی و قابل انتظار از سمت مدیران و به دلیل خواستن «بیشتر» است. هر چقدر هم که تیم کار بیشتری را انجام دهد کافی نیست و بیشتر و بیشتر و بیشتر مد نظر است!بهترین راه برای ارائه ارزش، انجام کار بیشتر و بیشتر و بیشتر نیست! بلکه انجام مکرر کارهای کوچک و البته با ارزش(small valuable things) است. اگر به‌جای برآورد Storyها آنها را  «به اندازه کافی کوچک»(small enough) برش دهیم (Slicing)، می‌توانیم به جریان روانی از ارزش (smooth flow of value) دست یابیم که به صورت مستمر ارائه می‌شوند.(delivering all the time)*** در این پاراگراف میشود به راحتی اشاره نویسنده به اصل دهم مانیفست اجایل رو به صورت کامل حس کرد: Simplicity–the art of maximizing the amount of work not done–is essentialتمرکز یا تاکید بر موارد بیشتر مانعی برای افزایش ارزش می‌شود. افزایش فشار برای انجام کارهای بیشتر در اکثر موارد به شکل اجتناب ناپذیری به نتایج بدی منتهی می‌شود: تیم تلاش می‌کند سریع‌تر پیش برود و این کار باعث کاهش کیفیت Code و Test ها می شود. خیلی زود bug های بیشتری در کار آنها مشاهده می‌شود و به دلیل افزایش نیاز به انجام مجدد کار برای رفع عیوب، سرعت کاهش می‌یابد، و در نهایت به دلیل افزایش سرعت و کاهش کیفیت کد این مشکلات تشدید و تکرار می‌شوند. به تدریج شرایط بد و بدتر می‌شود، فشار افزایش می‌یابد و به مسابقه‌ای تبدیل می شود که در نهایت نتیجه آن به فاجعه تبدیل می‌شود.از آنجایی که برآوردها حداقل در اعمال فشار بی مورد نقش دارند، ترجیح می‌دهم از آنها اجتناب کنم.من از این هم جلوتر خواهم رفت: ترجیح می‌دهم به طور کامل از iteration planning یا Sprint planning اجتناب کنم.زیرا ما برای خرج کردن بودجه در طی چند هفته آینده کار نمی‌کنیم بلکه باید دارای فهرستی از چند کار مهم بعدی باشیم.پیش بینی برای Doneتهیه فهرستی از Features (قابلیت‌های) ضروری کاری معمول است، مدتی در مورد آنها فکر کنید و سپس تصمیم بگیرید که کدام از آنها Release بعدی محصول ما را تعریف کنند. سوال بعدی که مطرح می‌شود این است که «تمام این کارها در چه زمانی انجام می شوند؟»هیچ کس پاسخ این سوال را نمی‌داند. ما می‌توانیم کارهای زیادی برای کاهش ندانستن‌های خود انجام دهیم، و در برخی زمینه‌ها و در برخی از مواقع تعدادی از این کارها ارزش انجام دادن را دارد، مانند زمانی که یک قرارداد بزرگ در انتظار پیشنهاد مناقصه است. اما زمانی که در حال توسعه راه‌حل‌هایی برای مشتریان داخلی یا خارجی هستیم، نهایت تلاش خود را می‌کنیم تا مقادیر کوچکی از ارزش را به صورت مکرر ارائه دهیم و منتظر release های پر سر و صدا نخواهیم بود که به نظر می‌رسد اغلب به صورت نامحدودی با گذشت زمان فروکش می‌کنند.بسیار بهتر است که برای مشتریان تاریخ نزدیکی را برای release بعدی انتخاب کنید و تا حد امکان موارد خوب را در آن release انتخاب کنید. انجام برآورد چه بر اساس Story Point‌ها و چه بر اساس زمان، مانع انجام این کار می‌شود. به عقیده من، در صورت امکان بهتر است از انجام آن اجتناب شود.برش دادن – Slicingسوالی که اکنون مطرح می‌شود این است که در صورتی که برآورد توسط Story رو دوست نداشته باشید، چه چیزی را دوست خواهید داشت؟(مناسب است). خوب، من به برش دادن Story به بخش‌های کوچکتر علاقه دارم، در این روش Storyهای بزرگ‌تر را به Storyهای کوچک‌تر تقسیم می‌کنیم به طوری که هر کدام تا حد امکان از ارزش بالایی برخوردار باشند اما انجام آنها نیازمند زمان بسیار کمی، در حالت ایده‌آل کمتر از یک روز و شاید تنها چند ساعت باشد.در حال حاضر، من به دنبال بحث کردن در مورد الزام وجود نوعی برآورد در برش نیستم. اگر شما یا اعضا‌ء تیم به صورت ذهنی برآوردهایی را انجام دهید و هرگز در مورد آن با کسی صحبت نکنید، احتمالاً مشکلات مربوط به برآوردها چه بر اساس Story Point‌ها وچه بر اساس زمان به وجود نمی‌آیند. مطمئناً دانستن تفاوت بین «probably small enough» و «probably not small enough» در مقایسه با از اطلاع داشتن از تفاوت بین «سه روز» و «یک روز» یکسان نیست و کار سختی نخواهد بود.به علاوه، یک ترفند وجود دارد که به آن در مقاله Getting Small Stories و Slicing, Estimating, Trimming اشاره شده است.  من آن را از Neil Killick آموختم: Story ها را تا زمانی برش دهید که تنها به یک acceptance test نیاز داشته باشند. با کمی تمرین این موضوع، هر چیزی به اندازه درستی برش داده می‌شود.البته مقالات دیگری نیز در مورد موضوع تخمین نوشته شده‌اند.پیش بینی آینده – Predicting the futureاما … آیا نیازی به مشروع دانستن(درست بودن) مدت زمان مورد نیاز برای release یک محصول وجود ندارد و آیا انجام برآورد برای آن ضروری است؟ ممکن است اینگونه باشد اما شاید این هدف با برآورد‌ کردن Story ها بدست نیاید. این احتمال وجود دارد که حتی سطح نیازهای خود را تا سطح استوری پایین نیاورید و اگر چنین کاری کنید، احتمالاً بسیار بزرگ و تا حد زیادی دچار اتلاف می‌شوند.البته، اگر مجبور به انجام این کار هستید، کاری را که می‌خواهید انجام دهید. هر کاری که من انجام می‌دهم یا تئوری‌هایی را که در مورد نحوه انجام کار مطرح می‌کنم تنها یک ایده هستند. در نهایت باید کاری را انجام دهید که با توجه به شرایطی که در آن هستید منجر به موفقیت شما شود. البته به نظر من، روشی که در ادامه به آن اشاره می‌کنم منجر به کسب نتایج بهتری می‌شود.در ابتدا در مورد یک یا چند قابلیت مهم برای release بعدی فکر کنید. در مورد مشکلاتی صحبت کنید که قادر به حل آنها هستید و اینکه چه نرم افزاری که دارید تولید می کنید در این فرآیند حل مشکلات می‌تواند کمک کند. در مورد ساده‌ترین قابلیت‌هایی صحبت کنید که ممکن است تا حدی قادر به ارائه کمک باشند. الزامی برای حل تمام مشکلات از سوی ما وجود ندارد: در اکثر موارد اگر بتوانیم کمی کمک کنیم کفایت میکند. فقط کافی است تا  هر چیزی در مسیر درست قرار گیرد.دوم، به یک ضرب‌الاجل نزدیک (close-in deadline) فکر کنید، به طوری که احساس کنید می‌توانید تا آن زمان به قابلیت‌های خوبی دست پیدا کنید. ضرب‌الاجل را تعیین کنید و دست به کار شوید.سوم، برش‌های کوچکی از قابلیت های مهم را ایجاد کنید و آنها را انجام دهید. باید بتوانید به راحتی آنها را در طی یک روز یا کمتر به انجام برسانید. تنها بر روی مهم‌ترین بخش‌های بعدی کار کنید:don’t try to fill out the first capability all the way to the tiniest frillسعی نکنید اولین قابلیت را با ریزترین امور غیر ضروری پر کنید. شما در حال تلاش برای وارد شدن به یک چارچوب ذهنی هستید که در آن فکر می‌کنید «اگر ما فقط این یک کار کوچک را انجام دهیم، آنگاه مشتری ما Jack، واقعا می‌تواند از آن استفاده کند». پس  آن کار کوچک را انجام دهید و اجازه دهید مشتری شما یعنی Jack آن را امتحان کند. ما می‌خواهیم تا حد امکان به سمت ارائه مستمر ارزش (continuous delivery of value) حرکت کنیم.علاوه بر این، قصد داریم ارزش کاری را که انجام می‌دهیم چنان نمایان کنیم که مالک محصول ما و سایر ذینفعان همیشه در انتظار بیرون آمدن محصول نمانند. به این ترتیب بایستی کار درست را با و یا بدون استفاده از برآورد‌های Story انجام خواهیم داد.جمع بندیبسیار خوب، اگر من Story Point‌ها را ابداع کرده‌ام، احتمالاً اکنون کمی دچار احساس تاسف هستم اما چندان از انجام این کار پشیمان نیستم. من فکر می‌کنم در اکثر موارد آنها به شکل نادرستی مورد استفاده قرار می‌گیرند  و ما می‌توانیم با عدم استفاده از برآوردهای Story از افتادن در بسیاری از دام ها اجتناب کنیم. اگر آنها از ارزش چندانی برای تیم یا شرکت شما برخوردار نیستند، توصیه می‌کنم آنها را به این دلیل که زاید و اضافی هستند کنار بگذارید. از طرف دیگر، اگر آنها را دوست دارید، بسیار خوب، با وجود آنها به کار خود ادامه دهید! امیرحسین بزرگ کیان امیرحسین بزرگ کیان Wed, 17 Aug 2022 00:27:30 +0430 https://virgool.io/@amirhossein.bozorgkian/%D9%85%D8%B1%D8%A7%D8%AD%D9%84-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%DA%AF%D8%B1%D9%88%D9%87-xrvudfmnhwzc این مراحل معمولاً تحت نام‌های زیر شناخته می‌شوند: Forming (شکل‌گیری)، Storming (درگیری)، Norming (هنجار سازی)، Performing (بهره‌وری گروهی) و Adjourning (فروپاشی).مدل Tuckman توضیح می‌دهد که بعد از رسیدن تیم به بلوغ و کسب توانایی، روابط برقرار می‌شوند و سبک رهبری به رهبری مشارکتی‌(collaborative leadership) یا رهبری مشترک(shared leadership) تغییر پیدا می‌کند.(در این مقاله واژه CORAL چند بار استفاده شده است که مخفف COLLABORATIVE ON-LINE RESEARCH AND LEARNING هست که به معنی تحقیق و یادگیری با رویکرد مشارکتی می باشد)آقای Tuckman در کار اصلی خود به سادگی روشی را توصیف می‌کند. در CORAL، ارزش واقعی در تشخیص این مسئله نهفته است که  یک تیم در چه مرحله ای از فرآیند توسعه قرار دارد و بتوان آن تیم را کمک تا به مرحله ای برسند که سازگار با سطح همکاری مشترک(collaborative work) آن ها مورد نظر است. در دنیای واقعی، تیم‌ها اغلب در حال شکل‌گیری و تغییر هستند و در هر مرتبه از این فرآیند می‌توانند به مرحله متفاوتی از مراحل Tuckman وارد شوند. ممکن است یک گروه با رغبت تمام در مرحله  Norming یا Performing باشد، اما یک عضو جدید ممکن است باعث شود آنها به اجبار به مرحله Storming بازگردند، یا یکی از اعضای تیم ممکن است جلسه‌ای را از دست بدهد و موجب بازگشت دوباره تیم به مرحله Storming شود. راهنماهای پروژه آماده مقابله با این مسئله هستند  و به تیم کمک می‌کنند تا در کوتاه‌ترین زمان ممکن به مرحله Performing بازگردد.مرحله Forming (شکل‌گیری)مرحله Forming اولیه در حقیقت فرآیند کنار هم قرار دادن ساختار تیم(structure of the team) است. اعضای تیم دچار احساس شک و تردید هستند و به دلیل نیاز به پذیرش در گروه، تحت هر شرایطی از درگیری اجتناب می‌کنند. اعضای تیم برای گرفتن راهنمایی و دستور به رهبر گروه نگاه می‌کنند که معمولاً راهنمای پروژه CORAL است.رفتارهای قابل مشاهده• ادب• پیوستن با شک و تردید• تطبیق دادن خود با دیگران• اجتناب از بحث و جدل• احتمال تشکیل دسته‌ها (گروه‌ها)• نیاز به امنیت و تایید• تلاش برای تعریف وظایف، فرآیندها و نحوه تصمیم گیری در اینجا• بحث در مورد مشکلات غیر مرتبط با کاراحساسات و افکار• بسیاری احساس هیجان، خوش بینی و انتظارات مختلفی را تجربه می‌کنند• برخی دیگر ممکن است در کار با دیگران دچار احساس تردید، ترس و اضطراب شوند• چه انتظاراتی از من دارند• چرا در اینجا حضور دارند• احساس عدم اطمینان و دلهرهنیازهای تیم• ماموریت و چشم انداز تیم• تعیین اهداف و وظایف خاص• مشخص کردن نقش ها و مسئولیت‌های اعضای تیم• ایجاد قوانین و اصول اولیه تیم• انتظارات اعضای تیم• دستورالعمل‌های عملیاتی برای تیم• تاثیر گذار بودن در جلسات کلاس• جلسات گفتگو نتیجه بخش• مجموعه اول بازخورد از دستورالعمل‌های پروژهالزامات رهبری• تدریس و یا راهنمایی در امور پروژه• ارائه ساختار و مدیریت کار• صرف زمان برای آشنایی• ایجاد فضای اطمینان و خوش بینی• مشارکت فعال• اعضای تیم معتقدند که وجود یک رهبر منصوب برای گرفتن تصمیمات ضروری است• ارتباط یک طرفه از سوی رهبر(leader) به اعضای تیمبرای عبور از این مرحله و رفتن به مرحله بعد، هر یک از اعضا باید منطقه آسایش موضوعات غیر تهدید کننده را رها کرده و خطر احتمال درگیری را بپذیرند. مرحله Storming (درگیری)این مرحله با فرآیند سازماندهی وظایف و فرآیندهای سطحی تعارضات بین فردی(interpersonal conflicts) آغاز می‌شود. رهبری، قدرت و مسائل ساختاری این مرحله را تحت سلطه خود دارند و غالب هستند.رفتارهای قابل مشاهده• مشاجره(Arguing) بین اعضا• رقابت برای رهبری• مشهود بودن تفاوت‌ها در نقطه نظرات و سبک و روش شخصی• عدم شفافیت نقش• خود سازماندهی تیم• ناسازگاری‌ها و درگیری‌های قدرت• عدم رفتارهای اجماع طلبی• عدم پیشرفت• تعیین اهداف غیر واقعی• نگرانی نسبت به انجام کار بیش از حداحساسات و افکار• احساساتی با ماهیت تدافعی• ایجاد احساس سردرگمی و از دست دادن علاقه• مقاومت در برابر انجام وظایف• تغییرات در نگرش نسبت به تیم• عدم اطمینان نسبت به ماموریت و هدف تیم• احساس تردید نسبت به خرد اعضای تیم• افزایش تنش و حسادت• عدم اطمینان به نفوذ شخصی و آزادی خود در تیم• تردید نسبت به موفقیت تیم (ما به جایی نمی‌رسیم)نیازهای تیم• تداوم و ارتقا روابط بین فردی و درون فردی• شناسایی تفاوت‌های فردی و سبک های انجام کار• گوش دادن موثر• ارائه و دریافت بازخورد• حل تعارض• شفاف کردن و درک درست از هدف تیم• برپایی مجدد نقش ها و اصول و قوانین اولیه• نحوه برخورد با برخی از اعضای تیم که ناقض قوانین رفتاری تیم هستند• دریافت بازخورد از راهنمای پروژهالزامات رهبری• تصدیق تعارض ها از سوی راهنمای پروژه و مربیان• پیشنهاد ایجاد اجماع بین اعضای تیم از سوی راهنماهای پروژه• ملزم ساختن اعضاء برای بر عهده گرفتن مسئولیت وظایف بیشتر• پدیدار شدن مفهوم رهبری مشترک• آموزش روش‌های حل تعارض• ارائه پشتیبانی و تمجید از اعضاء• مشورت فعال اعضای تیم با یکدیگر – ظهور رهبری مشترک با وجود مشکل در تصمیم گیریبرای ورود به مرحله بعد، اعضای گروه باید از ذهنیت و نگرش «آزمایش و اثبات (testing and proving) » به ذهنیت حل مسئله بروند. مهمترین ویژگی در کمک به تیم‌ها برای رفتن به مرحله بعد، توانایی اعضای تیم در گوش دادن به صحبت‌های هم تیمی‌های خودشان است – آنها تلاش میکنند دقیقا چه حرف‌ی را بزنند؟ مرحله Norming (هنجار سازی)در این مرحله، اعضای تیم به دنبال ایجاد راه‌های جدیدی برای انجام کار و بودن در کنار یکدیگر هستند. زمانیکه گروه به دنبال توسعه انسجام است (develops cohesion)، سبک رهبری از یک هم تیمی مسئول به رهبری مشترک تغییر(shared leadership) پیدا می‌کند. اعضای تیم یاد می‌گیرند اثربخش بودن رهبری مشترک مستلزم اعتماد آنها به یکدیگر است.رفتارهای قابل مشاهده• فرآیندها و رویه‌ها بر اساس توافق ها هستند• احساس راحتی در روابط• تمرکز و انرژی در انجام کارها• مهارت‌های حل موثر تعارضات• تلاش صادقانه برای اتخاذ تصمیمات توافقی• نفوذ و تاثیر سنجیده بر یکدیگر، حل مشکل مشترک• توسعه وظایف روزمره تیم• تعیین و دست یابی به نقاط عطف در کاراحساسات و افکار• احساس داشتن تعلق به یک تیم• اعتماد به نفس بالا• توانایی جدید اعضای تیم در بیان انتقادات سازنده• پذیرش کلیه اعضای تیم• حس عمومی اعتماد• اطمینان از انجام صحیح تمام امور• آزادی بیان و مشارکتنیازهای تیم• توسعه یک فرآیند تصمیم گیری• آمادگی برای ارائه ایده‌ها و پیشنهادات• حل مسئله با به اشتراک گذاری آن• استفاده از تمام منابع برای حمایت از تلاش تیم• بر عهده گرفتن مسئولیت در مهارت‌های رهبری مشترک توسط اعضای تیم• دریافت بازخورد از راهنماهای پروژهالزامات رهبری• رهبری مشترک (Shared leadership)• ارائه بازخورد و پشتیبانی از سوی راهنمای پروژه• در نظر گرفتن پیکربندی و ساختار کمتر• افزایش تعاملات تیمی• درخواست برای مشارکت تمام اعضای تیم• همکاری واضح تر می شود• تشویق دیگران به شرکت در تصمیم‌گیری‌ها• تداوم ایجاد و توسعه روابط قویعملکرد اصلی در مرحله سوم، گردش داده‌ها بین اعضای گروه است: آنها احساسات و ایده‌های خود را به اشتراک می‌گذارند، درخواست‌هایی را مطرح می‌کنند، بازخورد می‌دهند(feedback) و اقدامات مربوط به کار را بررسی(explore) می‌کنند. در این مرحله سطح خلاقیت(Creativity) بالا است و همکاری زمانی پدیدار می‌شود که اخلاق کار تیمی و رهبری مشترک(team work ethic and shared leadership) درک شود.اشکال اصلی مرحله Norming این است که اعضا ممکن است نسبت به فروپاشی اجتناب ناپذیر تیم در آینده دچار احساس ترس شوند، همچنین ممکن است در برابر هر نوع تغییر از خود مقاومت نشان دهند. مرحله Performing (عمل)وابستگی متقابل واقعی، معیار این مرحله از رشد گروهی است. تیم از انعطاف لازم برخوردار است زیرا افراد خود را با نیازهای سایر اعضای تیم سازگار می‌کنند. این مرحله از نظر شخصی و حرفه ای بسیار کارآمد است.رفتارهای قابل مشاهده• تیم های کاملاً حرفه‌ای• واضح‌تر شدن نقش‌ها• توسعه و افزایش استقلال تیم• توانایی تیم در سازماندهی خود• عملکرد مناسب اعضای انعطاف پذیر به صورت فردی، زیرگروه یا تیم• درک بهتر نقاط قوت و ضعف یکدیگر و آگاهی نسبت به فرآیندهای گروهیاحساسات و افکار• همدلی با یکدیگر• تعهد بالا• شروع به درک اخلاق کاری مشترک• ایجاد پیوندهای محکم• احساس شادی و هیجان• رشد فردی و خلاقیت بالا• احساس رضایت عمومی• کشف مداوم چگونگی حفظ ابتکار عمل و اشتیاقنیازهای تیم• اطمینان راهنمای پروژه از حرکت تیم در جهت مشارکت و تعامل• حفظ انعطاف پذیری تیم• اندازه گیری عملکرد و پیشرفت علمی• ارائه اطلاعات• ارائه و دریافت (تبادلات درون تیمی)• ارائه بازخورد و گفتگو با راهنمایان پروژهالزامات رهبری• پیاده سازی رهبری مشترک• مشاهده، پرس و جو و برآورده کردن نیازهای تیم• تلاش‌های مشترک بین اعضای تیم• ارائه دستورالعمل‌های محدود از سوی راهنماهای پروژه• حمایت مثبت و تشویق از سوی اعضای تیم• به اشتراک گذاری اطلاعات جدیدتمام گروه ها وارد مرحله Performing نمی‌شوند. اگر اعضای گروه بتوانند تا مرحله چهارم تکامل یابند، ظرفیت، دامنه و عمق روابط شخصی آنها به وابستگی متقابل واقعی گسترش می‌یابد. در این مرحله افراد می‌توانند به صورت مستقل و در گروه‌های فرعی و یا به صورت یک واحد کل با  مهارت‌های برابر کار کنند. مرحله Adjourning (فروپاشی)در این مرحله معمولاً اعضای تیم آماده ترک گروه (خاتمه دوره) هستند که این امر باعث ایجاد تغییرات قابل توجهی در ساختار تیم، عضویت، هدف و یا خود تیم در هفته آخر کلاس می‌شود. آنها تغییر و تحول را تجربه می‌کنند. در حالی که گروه به عملکرد موثر و کارآمد خود ادامه می‌دهد، اعضاء آن برای مدیریت احساسات خود نسبت به پایان کار و تحول و گذار از این مرحله به زمان نیاز دارند.رفتارهای قابل مشاهده• نشانه‌های قابل مشاهده غم و اندوه• کاهش سرعت حرکات (انجام کارها)• رفتار همراه با اضطراب و بی‌قراری• انفجار شدید انرژی و در اکثر موارد به دنبال آن کمبود انرژیاحساسات و افکار• غم و اندوه• شوخ طبعی (که از نظر افراد خارج از گروه ممکن است ظالمانه به نظر برسد)• احساس خرسندی به دلیل اتمام آن – آسایش خاطرنیازهای تیم• ارزیابی تلاش‌های تیم• انجام کارها و وظایف ناتمام• شناخت تلاش‌های تیمی و دادن پاداش به آنهاالزامات رهبری• کمک راهنماهای پروژه به تیم به منظور ایجاد گزینه‌هایی برای خاتمه کار• خوب گوش دادن• بازتاب و انتقال یادگیری مشارکتی به فرصت بعدیمرحله آخر، adjourning (فروپاشی) شامل خاتمه رفتارهای وظیفه مدار و متارکه روابط و عدم مشارکت می‌شود. یک پایان برنامه‌ریزی‌شده معمولاً شامل قدردانی از مشارکت و موفقیت و فرصتی برای خداحافظی اعضاء از یکدیگر می‌شود. پایان یک گروه می‌تواند منجر به ایجاد احساس دلهره – در واقع یک بحران غم انگیز – شود. خاتمه گروه یک حرکت واپسگرا از کنار گذاشتن کنترل تا پایان حضور در گروه است.با تشکر از توجه شماامیرحسین بزرگ کیان امیرحسین بزرگ کیان امیرحسین بزرگ کیان Wed, 17 Aug 2022 00:24:23 +0430 https://virgool.io/@amirhossein.bozorgkian/%D9%88%D8%A7%DA%98%D9%87-%D9%86%D8%A7%D9%85%D9%87-%D8%A7%D8%B5%D8%B7%D9%84%D8%A7%D8%AD%D8%A7%D8%AA-scrum-n9j9zdon2kae همیشه یکی از مشکلات ماها توی ارتباطات بین انسان ها و یا اعضای درون تیم درک متقابل از کلمات است و شناخت و دانستن معانی برخی از کلمات تاثیر بسیاری بر روی بهبود مکالمات و درک متقابل از یکدیگیر خواهد داشت. از همین رو تصمیم گرفتم که واژه نامه اسکرام رو ترجمه کنم تا اسکرام مستر ها و مالکین محصول و توسعه دهندگان یا حتی مدیران سازمان بتواندد با آگاهی بیشتر ارتباط بهتری داشته باشند.این واژه نامه به منظور ارائه یک مرور کلی از اصطلاحات مرتبط با اسکرام تهیه شده است. برخی از اصطلاحات ذکر شده در اسکرام الزام آور نیستند، اما به دلیل استفاده مکرر در اسکرام به این فهرست اضافه شده‌اند. به منظور کسب اطلاعات بیشتر در مورد چارچوب Scrum، شناسایی اصطلاحاتی که از مولفه‌های ضروری Scrum هستند و درک نحوه ارتباط عناصر ذکر شده، به شدت توصیه می‌کنیم که به Scrum Guide مراجعه کنید.علاوه بر این، برای کسب اطلاعات بیشتر در مورد اصطلاحات خاص تیم‌های توسعه نرم افزار با استفاده از تکنیک‌های توسعه نرم افزار Scrum و Agile، به واژه نامه توسعه دهندگان حرفه‌ای اسکرام (Professional Scrum Developer glossary) مراجعه کنید.نمودار Burn-downاین نمودار نشان دهنده میزان کاری است که تصور می‌شود در backlog باقی می‌مانند. زمان توسط محور افقی و کار باقی مانده در طول محور عمودی نشان داده می‌شوند. با پیشرفت زمان آیتم‌ها از بک‌لاگ ترسیم و تکمیل می شوند، و انتظار می‌رود خط رسم شده، نشان دهنده کار باقی‌مانده به صورت روندی کاهشی باشد. میزان کار ممکن است به چندین روش مانند story points یا ساعات کار مورد ارزیابی قرار گیرد. کارهای باقی مانده در Sprint Backlog و Product Backlog ممکن است با استفاده از یک نمودار burn-down نمایش داده شوند.واژه Burn-up Chartنموداری است که میزان کار انجام شده را نشان می‌دهد. زمان توسط محور افقی و کار تکمیل شده توسط محور عمودی نشان داده می‌شود. با پیشرفت زمان آیتم‌ها از بک‌لاگ تکمیل می شوند و روی نمودار ترسیم می شوند به نحوی که انتظار می‌رود خط رسم شده نشان دهنده مقدار کار انجام شده دارای روندی افزایشی باشد. میزان کار ممکن است به چندین روش مانند story points یا ساعات کار مورد ارزیابی قرار گیرد. مقدار کار در نظر گرفته شده در محدوده نیز ممکن است به صورت یک خط ترسیم شود. انتظار می‌رود که با تکمیل کار، burn-up به این خط نزدیک شود.واژه Coherent/Coherenceدر فارسی (منسجم/ انسجام) ترجمه میشود. کیفیت رابطه بین آیتم‌های معینی از Product Backlog که ممکن است باعث شود آنها در مجموع ارزش بررسی و توجه را پیدا کنند. علاوه بر این، به Sprint Goal مراجعه کنید.واژه Daily Scrumیکی از Scrum Event(رویدادها یا جلسات اسکرام)  می باشد که در فارسی جلسه روزانه ترجمه میشود. جلسه روزانه و محدود به ۱۵ دقیقه‌ای (a 15-minute time-boxed) است که هر روز برای توسعه دهندگان برگزار می‌شود. Daily Scrum در هر روز از اسپرینت برگزار می‌شود. در آن جلسه، توسعه دهندگان برای انجام کار در طی ۲۴ ساعت آینده برنامه ریزی می‌کنند. در طی این جلسه،  با بررسی کار آخرین Daily Scrum قبلی و پیش‌بینی کارهای پیش رو در sprint، همکاری و عملکرد تیم بهینه می‌شود. به منظور کاهش پیچیدگی، جلسه Daily Scrum هر روز در یک زمان و مکان مشابه برگزار می‌شود.واژه Definition of Doneبه اختصار DOD گفته میشود و توصیفی رسمی از وضعیت Increment (خروجی تولید شده) میباشد به صورتی که، معیارهای کیفی مورد نیاز برای محصول را برآورده می‌کندو در نهایت لحظه ای که یک آیتم Backlog محصول با DOD مطابقت دارد، یک  Increment ایجاد می‌شود. {زمانی که کارهای انجام شده تیم با معیار های DOD تطبیق داشته باشد میتوانیم آن واحد کار یا PBI رو تمام شده در نظر بگیریم و آماده انتشار برای عموم قرار گیرد}. در واقع DOD با ارائه یک درک مشترک از کار، شفافیت ایجاد می‌کند که دقیقا کدام بخش از کارهای مد نظر با چه شرایطی انجام شده اند و به عنوان بخشی از یک Increment تکمیل شده است. اگر یک آیتم بک‌لاگ محصول با Definition of Done مطابقت نداشته باشد، نمی‌توان آن را منتشر یا حتی در جلسه Sprint Review ارائه کرد.واژه Developerهر عضوی از تیم اسکرام که بدون توجه به تخصص فنی، عملکردی یا موارد دیگر متعهد به ایجاد هر جنبه ای از Increment قابل استفاده در هر اسپرینت است Developer نامیده میشود.واژه Emergenceبه معنای (ظهور) می باشد و فرآیند به وجود آمدن یا برجسته شدن حقایق جدید یا شناخت جدید از یک واقعیت و یا آگاهی نسبت به یک واقعیت به شکل غیر منتظره(unexpectedly) است.واژه Empiricismدر فارسی تجربه گرایی ترجمه می شود. تجربه گرایی  نوعی نوعی کنترل فرآیند است که در آن تنها گذشته به عنوان یک امر قطعی پذیرفته می‌شود و تصمیمات بر اساس مشاهده، تجربه و آزمایش گرفته می‌شوند. تجربه گرایی دارای سه رکن است: شفافیت(transparency)، بررسی (inspection) وانطباق(adaptation).واژه Engineering standardsمجموعه‌ای مشترک از استانداردهای توسعه و فناوری که توسعه دهندگان(Developers) برای ایجاد Increments قابل انتشار نرم افزاری مورد استفاده قرار می‌دهند.واژه Forecast -of functionalityانتخاب آیتم‌ها از بک‌لاگ محصول که توسعه دهندگان(Developers) آن را مناسب پیاده سازی (feasible) در یک اسپرینت می‌دانند.واژه Incrementیکی از Scrum Artifact ها که کار ارزشمند(valuable) و کامل شده(complete) توسط توسعه دهندگان (Developers) را در طول Sprint تعریف می‌کند. مجموع تمام Increment ها یک محصول را شکل می‌دهند.واژه Product Backlogیک Scrum Artifact که شامل فهرستی مرتب از کارهایی می‌شود که باید به منظور ایجاد، نگهداری و حفظ یک محصول انجام شوند و توسط مالک محصول مدیریت(Product Owner) می‌شود.واژه Product Backlog refinementفعالیتی است که در یک sprint از طریق آن مالک محصول و توسعه دهندگان جزئیات (granularity) را به Product Backlog اضافه می‌کنند.واژه Product Ownerمعادل فارسی آن مالک محصول می باشد و نقشی در اسکرام که وظیفه به حداکثر رساندن ارزش یک محصول، عمدتاً از طریق مدیریت تدریجی و بیان انتظارات تجاری و عملکردی از یک محصول به توسعه دهندگان(Developers) را بر عهده دارد.واژه Product Goalهدف محصول، وضعیت محصول در آینده را توصیف می‌کند و می‌تواند به عنوان هدفی برای Scrum Team در نظر گرفته شود که بر اساس آن برنامه‌ریزی کنند. هدف محصول در داخل بک‌لاگ محصول(Product Backlog) قرار دارد. باقی‌مانده بک‌لاگ های محصول برای تعریف «چه چیزی» (WHAT) وجود خواهند داشت تا هدف محصول را برآورده کنند.واژه Readyدرک مشترکی است که Product Owner و Developers با توجه به اولویت ها و توصیف یا بررسی Product Backlog items معرفی شده در Sprint Planning به آن رسیده‌اند.واژه Refinementبه Product Backlog Refinement مراجعه کنید.واژه Scrumاسکرام یک چارچوب سبک وزن(lightweight framework) است که به افراد، تیم‌ها و سازمان‌ها کمک می‌کند تا از طریق راه حل‌های تطبیقی(adaptive solutions) ​​برای مشکلات پیچیده(complex) تولید ارزش(generate value) کنند، همانطور که در Scrum guide نیز تعریف آن ارائه شده است.واژه Scrum Boardیک برد (ترجیحا فیزیکی) با هدف نمایش اطلاعات توسط تیم اسکرام، که اغلب برای مدیریت Sprint Backlog مورد استفاده قرار می‌گیرد. بردهای اسکرام یک پیاده سازی اختیاری در اسکرام برای نمایان سازی کردن اطلاعات(information visible) هستند.واژه Scrum Guide™تعریف اسکرام، توسط کن شوابر و جف ساترلند، خالقان مشترک اسکرام نوشته و ارائه شده است. این تعریف شامل مسئولیت‌پذیری‌های اسکرام(Scrum’s accountabilities)، رویدادها(events)، مصنوعات(artifacts) و قوانینی(rules) می‌شود که آنها را به هم پیوند می‌دهد.واژه Scrum Masterیک نقش(Role) در تیم Scrum است که وظیفه راهنمایی(guiding)، مربیگری(coaching)، آموزش(teaching) و کمک(assisting) به تیم اسکرام برعهده دارد تا محیط مناسب کار آن ها را به منظور درک و استفاده صحیح از اسکرام فراهم کند.واژه Scrum Teamیک تیم خود مدیریتی که متشکل از یک اسکرام مستر(Scrum Master)، یک مالک محصول(Product owner) و توسعه دهندگان(Developers) است.واژه Scrum Valuesارزش‌های اسکرام مجموعه‌ای از ارزش‌ها و کیفیت‌های اساسی هستند که در چارچوب اسکرام، تعهد-commitment، تمرکز-focus، صراحت-openness، احترام-respect و شجاعت-courage را شامل میشود.واژه Self-Managingتیم های اسکرام دارای عملکرد cross-functional هستند، به این معنی که اعضا از تمام مهارت های لازم برای ایجاد ارزش در هر اسپرینت برخوردار هستند. آنها همچنین “خودمدیریت”(self-managing) هستند، به این معنی که در داخل تیم تصمیم می‌گیرند چه کسی چه کاری را در چه زمانی و چگونه انجام دهد.(what, when, and how)واژه Sprintیک Scrum Event می باشد که با زمان بندی محدود(time-boxed) به یک ماه یا کمتر تنظیم می‌شود و به عنوان ظرفی برای سایر رویدادها(Event) و فعالیت‌های(activities) اسکرام عمل می‌کند. Sprint ها به صورت متوالی(consecutively) و بدون شکاف‌های میانی انجام می‌شوند.واژه Sprint Backlogیکی از Scrum Artifact ها و یک نمای کلی از کار توسعه را به منظور تحقق هدف Sprint، معمولاً پیش بینی عملکرد و کار مورد نیاز برای عرضه آن عملکرد ارائه می‌دهد و توسط توسعه دهندگان مدیریت می‌شود.واژه Sprint Goalبیان کوتاهی است از هدف Sprint و اغلب یک مشکل تجاری که -در طول Sprint- به آن پرداخته می‌شود. عملکرد ممکن است در طول Sprint به منظور دستیابی به Sprint Goal تنظیم و تطبیق داده شود.واژه Sprint Planningیکی از Scrum Event ها می باشد که برای شروع یک Sprint بر اساس محدودیت زمانی(time-boxed) برای 8 ساعت یا کمتر تنظیم می‌شود. این به تیم اسکرام برای بررسی ارزشمندترین کار بعدی از Product Backlog کمک می‌کند و آن را در Sprint backlog قرار می دهند.واژه Sprint Retrospectiveیکی از Scrum Event ها می باشد که در فارسی جلسه بازنگری گفته میشود و برای پایان دادن به Sprint بر اساس یک جعبه زمانی(time-boxed) حداکثر ۳ ساعت یا کمتر تنظیم شده است. نقش آن برای تیم اسکرام، بازرسی-inspection- اسپرینت گذشته و برنامه‌ریزی با هدف ایجاد اصلاحات و بهبود است که در طول Sprint های آینده اعمال می‌شوند.واژه Sprint Reviewرویدادی اسکرامی که برای پایان دادن به کار توسعه یک اسپرینت بر اساس جعبه زمانی ۴ ساعت یا کمتر تنظیم می‌شود. نقش آن برای تیم اسکرام و ذینفعان، بررسی Increment محصول حاصل از اسپرینت، ارزیابی تأثیر کار انجام شده بر پیشرفت کلی به سمت Product Goal (هدف محصول) و به روز رسانی بک‌لاگ محصول به منظور به حداکثر رساندن ارزش دوره بعدی است.واژه Stakeholderمعادل فارسی آن ذینفع است و در اینجا فردی خارج از تیم اسکرام با علاقه و دانش خاص در مورد محصولی که برای کشف تدریجی مورد نیاز است. مالک محصول(PO) نمایندگی از آن را بر عهده دارد و در بررسی Sprint به طور فعال با تیم اسکرام تعامل دارد.واژه Technical Debtمعادل فارسی آن بدهی فنی مییاشد ومعمولاً سربار غیر قابل پیش‌بینی نگهداری (unpredictable-overhead-of-maintaining) از محصول است که در اکثر موارد حاصل تصمیمات طراحی کمتر از حد ایده‌آل است و سهمی در کل هزینه مالکیت دارد. ممکن است به طور ناخواسته در  Increment وجود داشته باشد یا به طور هدفمند به منظور درک ارزش به صورت زود هنگام معرفی شود(به وجود بیاید).واژه Valuesزمانیکه ارزش‌های تعهد-commitment، شجاعت-courage، تمرکز-focus، گشودگی-openness  و احترام-respect در رفتار تیم اسکرام بوجود بیایند، *ستون‌های اسکرام* (Scrum pillars) شفافیت، بازرسی و سازگاری *رنگ واقعیت به خود می‌گیرند* (come to life) و *احساس اعتماد*(build trust) را در همه ایجاد می‌کنند. اعضای تیم اسکرام این ارزش‌ها را در حین کار با رویدادها، نقش‌ها و مصنوعات اسکرام (Scrum artifacts) یاد می‌گیرند و کشف می‌کنند.واژه Velocityیک مورد اختیاری است اما اغلب مورد استفاده قرار میگیرد و مقداری از Product Backlog را نشان می‌دهد که در طی یک Sprint توسط یک تیم اسکرام به Increment محصول تبدیل خواهد شد و توسط توسعه‌دهندگان برای پیگیری (tracked) کارها در تیم اسکرام استفاده می‌شود.همچنان سعی بر آن هست ادامه موارد آموزشی در وب سایت شخصی تداوم داشته باشدهمچنین این مقاله در بلاگ های موسسه رسمی اسکرام ایران و مدرسه اسکرام منتشر شده است امیرحسین بزرگ کیان امیرحسین بزرگ کیان Mon, 15 Aug 2022 15:21:37 +0430 https://virgool.io/Rocket/%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D9%85%D8%B3%D8%AA%D8%B1%DB%8C%D9%86%DA%AF-%D9%85%D9%88%D9%82%D8%B9%DB%8C%D8%AA%DB%8C-%D9%87%D8%AF%D8%A7%DB%8C%D8%AA-%D9%88-%D8%B1%D9%87%D8%A8%D8%B1%DB%8C-%DB%8C%DA%A9-%D8%AA%DB%8C%D9%85-%D8%A7%D8%AC%D8%A7%DB%8C%D9%84-call8vpati6r به قلم مایک کوهنچند سال پیش، در یک بازی گلف پس از اینکه تعدادی توپ گلف را به دریاچه انداختم، دوستی که با او بازی می‌کردم توصیه‌هایی به من کرد. دوستم گلف را بهتر از من بازی نمی‌کند، اما این مسئله باعث نشد که نظرات خود را با من در میان نگذارد. او گفت: «مشکل کار این است که باید توپ را دورتر بزنید». او ممکن بود به من بگوید که مشکل اصلی، تعداد بالای ضربه‌ها برای انداختن توپ به داخل حفره است. البته من نیاز داشتم به مسافت بیشتری در ضربه‌ها دست پیدا کنم. اما چگونه؟به طور مشابه، ممکن است به شما گفته شود که مدیریت پروژه اجایل – صرف نظر از اینکه توسط یک اسکرام مستر، مربی یا مدیر پروژه اجایل انجام شود – بیشتر از آنکه در مورد مدیریت یک تیم باشد، رهبری و هدایت تیم را شامل می‌شود. با این وجود، توصیه به یک اسکرام مستر برای «رهبری تیم به جای مدیریت آن» چندان راهنمایی مفید و آموزنده‌ای نیست. این توصیه مانند این است که به یک گلف باز بگوییم باید توپ را دورتر بزند. این یک راهنمایی معتبر اما غیر قابل اجرا است.یک روش بهتر برای درک این مسئله که چگونه اسکرام مستر‌ها می‌توانند به بهترین شکل ممکن تیم‌هایی را رهبری کنند که به دنبال اجایل شدن هستند، این است که از ابتدا نیاز‌های تیم را در رابطه با رهبری مشخص کنیم و سپس به چهار روش مختلف هدایت و رهبری تیم را بر عهده بگیریم.با نگاهی به مدل رهبری موقعیتی پل هرسی، به این موضوع بیشتر خواهیم پرداخت. مدل هرسی چهار سطح آمادگی را برای تیم‌هایی توصیف می‌کند که به دنبال پیدا کردن روش‌های جدید انجام کار هستند، در شکل ۱ خلاصه‌ای از این مدل ارائه شده است.به گفته هرسی، رهبران باید رفتار خود را مطابق با سطح آمادگی(readiness) تیم تنظیم(adapt) کنند. به عبارت دیگر، برای یک اسکرام مستر، نحوه هدایت و رهبری یک تیم توانا(Able) و متمایل (willing)، متفاوت از یک تیم ناتوان(unable) و نا‌مطمئن(unwilling) است. از نظر هرسی، رهبران خوب رفتارهای مرتبط با رهبری را با توجه دو بعد تنظیم میکنند: شکلرفتار تکلیف مدار و رفتار رابطه‌ مدار.رفتار تکلیف مدار(leader’s task behavior)، حدودی است که بر مبنای آن یک رهبر فعالیت‌های یک تیم را هدایت(directs) می‌کند.رفتار رابطه مدار(leader’s relationship behavior) حدودی است که با توجه به آن رهبر با استفاده از رابطه خود با تیم، وظیفه رهبری را انجام می‌دهد.این رفتار‌ها در کنار یکدیگر، چهار سبک رهبری (Leadership styles) متمایز را تشکیل می‌دهند:هدایتگری (telling)-(دراین متن در ترجمه از هدایتگری استفاده میشود، شاید گفتاری یا دستوری هم ترجمه شود)مربیگری (selling)- (دراین متن در ترجمه از مربی استفاده میشود، شاید توجیهی هم ترجمه شود)مشارکتی(Participating)تفویضی(Delegating)بنابراین، سبک رهبری «درست»، سبکی است که به بهترین وجه و از هر نظر مطابق با سطح آمادگی تیم (team’s readiness level) باشد.این انطباق به صورت گرافیکی در شکل ۲ نشان داده شده است.رفتار تکلیف محور (Task Behavior) در امتداد محور x و رفتار رابطه محور(Relationship Behavior) او در امتداد محور y ترسیم شده است. این تصویر به چهار ربع تقسیم می‌شود که هر یک نشان دهنده یکی از چهار سطح آمادگی هستند. هر بخش حاوی یک نام توصیفی برای سبک رهبری است که از بیشترین تناسب برای تیم های حاضر در آن ربع برخوردار است.شکل ۲. چهار سبک رهبری برای چهار سطح آمادگی تیمیشکل 2هدایتگر (telling)، مربیگری(selling)، مشارکتی(Participating)،تفویضی(Delegating)رفتار تکلیف مدار(leader’s task behavior)، رفتار رابطه مدار(leader’s relationship behavior)به عنوان مثال، تیم R1 که ناتوان(unable) و نا‌مطمئن(insecure) است، به راهنمایی بیشتر از سوی اسکرام مستر خود نیاز دارد. اسکرام مستر این تیم کمتر به ارتباطات دو طرفه two-way communication [یک رفتار با روابط بالا] تکیه دارد و در مقابل طرفدار ارتباط یک طرفه(one-way communication) است.اسکرام مستر ها همیشه نیازمند مهارت‌های بین فردی قوی هستند، اما یک تیم R1 (ناتوان و نامطمئن) به منظور کسب اعتماد به نفس کافی برای مشارکت سازنده در ارتباطات دو طرفه و ارتقا به عنوان یک تیم R2 به سطح بالایی از راهنمایی‌های کاری(task guidance) نیاز دارد.در مقابل، تیم‌های R3 و R4 با برخورداری از سطوح بالایی از توانایی‌های خود، به سطح بسیار پایین‌تری از هدایت کارها (direction) از سوی اسکرام مستر خود نیاز دارند.در ادامه این مقاله، به موارد خاصی می‌پردازیم که یک اسکرام مستر در هنگام رهبری تیم‌های حاضر در هر یک از این بخش ها ملزم به انجام آنها است.اسکرام مستر با سبک رهبری هدایتگری (telling) برای بخش R1قبل از اینکه یک تیم ناتوان(unable) و بی‌میل(unwilling) یا نامطمئن[insecure] یا همان تیم R1 واقعاً بتواند به یک تیم اجایل تبدیل شود، اعضای آن ابتدا باید اعتماد به نفس لازم را کسب کنند. به منظور کمک به آنها برای کسب اعتماد به نفس مورد نیاز، یک اسکرام مستر خوب بیشتر از آنکه به دنبال ایجاد روابط حمایتی و ارتباطی باشد و بر این تمرکز دارد که به اعضای تیم بگوید(telling) چه کاری را بهتر است که انجام دهند.[teaching]اگرچه این روش ممکن است مغایر با تاکید اسکرام بر خودسازماندهی(self-organizing) تیم‌ها باشد، اما واقعیت این است که تیم حاضر در ربع R1 هنوز از آمادگی لازم برای سازماندهی خود(self-organize) به روش بهینه برخوردار نیست. با این حال، اسکرام مستر‌ها و مر‌بیان می‌توانند زمینه را برای توانمند سازی تیم‌های حاضر در این وضعیت (R1) فراهم کنند تا به سرعت به یک تیم R2 (ناتوان اما متمایل یا مطمئن) [unable but willing or confident] تبدیل شوند – تیمی که از آمادگی لازم برای اجایل شدن برخوردار است.یک تیم در شرایط R1 برای انجام یک پروژه بزرگ یا اهداف جسورانه(aggressive goals) آماده نیست در حالی که برای رسیدن به چنین هدفی باید اعضای آن تیم توانایی لازم برای استفاده حداکثری(utmost) از توانمندی‌های خود(perform) را داشته باشند. در مقابل، این نوع تیم باید کار خود را با پیروزی‌های ساده و کوچکی آغاز کند که منجر به افزایش اعتماد به نفس در آنها ‌شوند.اسکرام مستر یک تیم R1 باید تصمیماتی برای تیم بگیرد که آن تیم را در مسیر پیروزی قرار دهداسکرام مستر یک تیم R1 باید تصمیماتی برای تیم بگیرد که آن تیم را در مسیر پیروزی قرار دهد (بله، منظور من دقیقاً همین است). این تصمیمات معمولاً در رابطه با ایجاد برخی از فرآیندهای اساسی هستند که به تیم کمک می‌کنند تا حدی به موفقیت دست یابد.ابتدا اصرار شما بر روی Sprint های یک تا دو هفته‌ای باشد. به هر میزان که Sprint کوتاه‌تر باشد بازخورد(feedback) اعضای تیم در مورد نحوه اجرای اسکرام بیشتر خواهد بود. در زمان معرفی اسکرام به یک تیم، استفاده از Sprint های کوتاه مدت می‌تواند به شکل ویژه‌ای مفید باشد. تیمی که به تازگی اجایل شده است باید دائما نحوه عملکرد خود را مورد سنجش قرار دهد. در اکثر موارد انتظار یک ماهه برای مشاهده نتایج یک Sprint بسیار طولانی است.در ادامه، بر روی مهارت‌های اساسی اجایل مانند تست کردن (TEST) کار کنید. توضیح دهید که مسئله کیفیت برای همه افراد و در تمام کارها بسیار حائز اهمیت است. قانونی ایجاد کنید که بر اساس آن برنامه نویسان باید قبل از check in کردن کد، unit test را اجرایی کند. نیازی نیست که تست‌ها برای این نوع از تیم‌ها خودکار سازی(automated) شوند، اما انجام آنها ضروری است.در عین حال، به تیم فرآیند مداوم یکپارچه سازی(CI-continuous integration) یا حداقل یک ساخت (نسخه) شبانه (a nightly build) را معرفی کنید(آموزش دهید). در حالت ایده‌آل، این ساخت‌ها باید همراه با مجموعه‌ای ساده از تست‌های خودکار، در سطح واحد(unit test) یا عملکرد(functional test)، ارائه شوند.انتظار می‌رود که در همان ابتدا تست‌های چندان زیادی وجود نداشته باشد و تست‌های موجود نیز ممکن است اغلب با شکست مواجه شوند. با این حال، در اکثر موارد، بعد از گذشت چندین هفته تعداد تست‌ها و تعداد خروجی های موفق(successful builds) افزایش می‌یابد. چندین هفته دریافت بازخورد‌های مثبت از ساخت‌های موفق متعدد (و کاهش نیاز به تکرار حاصل از آن) می‌تواند تاثیر مطلوبی بر روی روحیه(morale) و اعتماد به نفس(confidence) تیم داشته باشد.چند سال پیش، یک تیم کلاسیک R1، ناتوان و نامطمئن به من تحویل داده شد. همه اعضای تیم تقریباً برنامه نویس COBOL بودند که کارهای خود را توسط رایانه‌های شخصی انجام می‌دادند. مالک شرکت به تازگی تغییر یافته بود و مدیریت قبلی بارها به اعضای تیم گفته بود که امکان انجام کار توسط فناوری‌های جدیدتر یا جالب‌تر وجود ندارد.برنامه نویسان بسیار باهوشی در این تیم مشغول به کار بودند اما به دلیل چنین برخوردهایی تمام اعتماد به نفس خود را از دست داده و مهارت‌هایشان منسوخ شده بود. پس از چند ماه ارائه راهنمایی‌های(guidance) بسیار خاص به تیم در مورد انتخاب فناوری‌های مورد استفاده، نحوه انجام کار و غیره، اعتماد به نفس اعضای تیم افزایش یافت. تیمی که زمانی ناکارآمد(once-dysfunctional) بود، ویژگی‌های ربع R2 را کسب کرد.اسکرام مستر با سبک رهبری توجیهی برای بخش R2در ربع R2، اسکرام مستر با تیمی با توانایی پایین (low ability) اما متمایل (willing) یا مطمئن(confident) کار می‌کند. در این مرحله از توسعه تیم، هدف اصلی، تقویت و افزایش قابلیت‌های اعضای تیم است. اگرچه برخی از تیم‌ها پس از عبور از ربع اول و سبک رهبری telling به این نقطه می‌رسند، اما بسیاری از تیم‌ها ممکن است به عنوان تیم R2 کار خود را آغاز می‌کنند. تیم‌های حاضر در این ربع از ویژگی‌های لازم برای اجایل شدن(become agile) برخوردار هستند اما هنوز به قابلیت‌های آن دست نیافته‌اند. تیم‌های R2 نیازمند استفاده از سبک رهبری selling هستند –  سبکی که ترکیبی از رفتار تکلیف مدار هدایتگری زیاد و رفتار رابطه‌ مدار حمایتی زیاد را مورد استفاده قرار می‌دهد.اسکرام مستر در یک تیم R2 به درجاتی از اعتماد و اطمینان(trust and confidence) بین اعضای تیم رو مشاهده میکند. در چنین شرایطی سرمایه گذاری بر روی این روابط موجب افزایش قابلیت‌های اجایلی تیم می‌شود.در این مرحله به دنبال مشارکت بیشتر اعضای تیم در فرآیند تصمیم گیری باشید. در زمان گرفتن تصمیمات برای تیم، در صورت امکان از اعضای تیم برای شرکت در فرآیند تصمیم‌گیری دعوت کنید.ربع R2 آغاز فرآیند تبدیل شده به تیمی اجایل استعلاوه بر این، به دنبال کمک به اعضای تیم در جهت بهبود مهارت‌های آنها باشید. تمرکز بر روی فرآیند TEST را ادامه دهید، اما اعضای تیم را برای ایجاد تست‌های خودکار(automated tests) مورد چالش قرار دهید. به منظور آموزش(training) استفاده از ابزارهای مناسب تست خودکار به اعضای تیم، بر روی آموزش افراد سرمایه گذاری کنید – برگشت سرمایه(payback) در بسیاری از ابزارها در زمان کوتاهی انجام می‌شود.به منظور کمک به گسترش دانش و مهارت‌ها در گروه، برنامه نویسی جفتی(pair programming) را در دستور کار خود قرار دهید. من به ندرت اعضای تیم را ملزم به pair programming می‌کنم اما از آنها می‌خواهم آن را امتحان کنند و تشخیص دهند چه زمانی استفاده از این روش مناسب است.به منظور رساندن این پیام به اعضای تیم که فکر کردن در مورد کیفیت کد قابل قبول و مطلوب است، به دنبال ایجاد اعتماد رو به رشد در تیم باشید. بسیاری از اعضای تیم برای مدت طولانی و بارها کلمه سریعتر، سریعتر، سریعتر را شنیده‌اند که این مسئله باعث شده در شنیدن این پیام که نوشتن کد با کیفیت بالا موجب افزایش سرعت می‌شود، با مشکل مواجه شوند. به آنها (و هر فرد دیگری که وسوسه می‌شود تنها بر روی سرعت متمرکز شود) یادآوری کنید که اگر در بزرگراه با سرعت۱۲۰ مایل در ساعت حرکت کنید، از شانس بالایی برای جریمه شدن یا تصادف برخوردار خواهید بود. در هر صورت، اگر سریعتر از میانگین سرعت ایمن و با کیفیت ۷۰ مایل در ساعت حرکت کنید h به مقصد خود نخواهید رسید.در مرحله R2، از مشارکت اعضای تیم در فرآیند تصمیم گیری بهره‌مند شویدمن شخصاً هرگز به یک تیم (به ویژه یک تیم R2) توصیه نمی‌کنم که با سرعت بیشتری حرکت کند. با این حال، در اکثر موارد پیشنهاد من به آنها این است که می‌توانند نوشتن کدهای بهتر و با کیفیت بالاتر را از طریق برنامه نویسی دونفره(pair programming)، آزمایش خودکار(automated testing) و بازآفرینی(refactoring) یاد بگیرند.در ربع رهبری selling، تاکید شما همچنان بر Sprint کوتاه باشد. تیم‌های R2 همچنان از مزیت امکان ارزیابی پیشرفت خود در بازه های زمانی کوتاه برخوردار باشند. بسیاری از تیم‌هایی که به تازگی اجایل شده‌اند درپذیرش اینکه می‌توان نرم‌افزاری با کیفیت بالا را در هر Sprint ایجاد کرد با مشکل مواجه می شوند. آنها معمولا فاز تست را پس از کدنویسی انجام می دهند( به مشکل میخورند و نمیتونن خروجی در هر اسپرینت رو ایجاد کنند).به اعضای تیم یادآور شوید که در پروژه های اسکرامی، کدنویسی(coding) و آزمایش(testing) به صورت همزمان انجام می‌شود(concurrently) به طوری که ویژگی قابل انتقال بودن(shippable) در هر iteration ایجاد می‌شود. در ابتدا برای بسیاری از تیم‌ها این مسئله یک چالش بزرگ است که منجر به یک آخر هفته مملو از اضطراب می‌شود به طوریکه در آن همه افراد مجبور به اضافه کاری هستند. تیم‌ها در نهایت راهی پیدا می‌کنند که امکان ارائه نرم‌افزار باکیفیت را در هر Sprint فراهم آورند، اما یادگیری نحوه انجام این کار اغلب نیازمند صرف تعداد انگشت شماری (یا بیشتر) Sprint است. این Sprint ها نیز ممکن است کوتاه باشند بنابراین تسلط در مهارت، در اسرع وقت امری ضروری است.اسکرام مستر با سبک رهبری Participating برای بخش R3زمانیکه تیم شروع به بهبود قابلیت‌های خود می‌کند، فرآیند خروج از ربع R2 آغاز می‌شود. تیم‌های R3 قادر به انجام کار به شیوه ای واقعاً اجایل هستند. به این ترتیب، در این ربع، یک اسکرام مستر خوب روش خود را به سبک رهبری participating تغییر می‌دهد و از میزان هدایت کار کم میکند و در عین حال رفتارهای مرتبط با ایجاد رابطه را افزایش می‌دهد.به جای تصمیم گیری برای تیم بر اساس ورودی آن (مانند ربع R2/ selling)، تیم را تشویق کنید تا وظیفه گرفتن تصمیمات را برعهده بگیرد. این کار را در اسرع وقت انجام دهید – حتی قبل از اینکه تیم به این قابلیت جدید خود پی ببرد. در مواجهه با این افزایش مسئولیت‌ها، تیم‌های ربع R3 معمولاً به طور موقت دچار احساس عدم اطمینان می‌شوند. اما، بر خلاف تیم R1، تیم R3 از مهارت بسیار بالایی برخوردار است و می‌تواند به سرعت به یک تیم R4 تبدیل شود.برای کمک به تیم در حرکت به سمت تصمیم گیری، به طور کامل از فرآیند تصمیم گیری خارج شوید.(move completely out of the decision-making process)حضور شما برای تشویق و حمایت از تیم ضروری است اما برای اعضای آن کاملاً روشن کنید که تصمیم گیری با خود آنها است. طبیعی است که تیم ممکن است اشتباهاتی داشته باشد. اما، آیا این مسئله اهمیت دارد؟ اعضای تیم به یادگیری ادامه می‌دهند و سطح عملکرد آنها معمولاً بسیار بالا‌تر از R1 است به طوری که چند اشتباه بهای ناچیزی است که باید آن را بپردازند.در زمان کار با یک تیم R3، اعضای آن را تشویق کنید تا خود گرفتن تصمیمات را برعهده بگیرندزمانیکه تیم فرآیند خودسازماندهی(self-organize) را آغاز می‌کند و به توسعه مهارت‌های اجایل خود ادامه می دهد، اسکرام مستر طبیعتاً تمرکز کمتری بر روی عملکرد تیم دارد و بیشتر متمرکز بر عوامل مرتبط با وضعیت کلی خواهد بود. اعضای تیم به طرز دیوانه‌واری بر روی کار انتخاب شده برای iteration فعلی متمرکز خواهند شد – هدف کاری که بیش از یک تا چهار هفته طول نخواهد کشید. البته آنها ممکن است دارای یک  release plan باشند که احتمالاً کار سه یا چهار ماه آینده را پوشش می‌دهد، اما این طرح عمداً(deliberately) فاقد جزئیات کافی است. از آنجایی که آنها روی درخت‌های iteration فعلی(فیچر) متمرکز هستند، اعضای تیم باید به اسکرام مستر خود اعتماد کنند تا جنگل طولانی‌مدت‌تری (vision) را زیر نظر داشته باشند.در این رابطه کارهایی هستند که اسکرام مستر می‌تواند انجام دهد.ابتدا به دنبال مواردی باشید که باید در iteration فعلی برای آینده برنامه ریزی شوند.به عنوان مثال، یک تیم ممکن است از برگزاری جلسه با یک متخصص واقف به امور شرکت در مورد یک فناوری خاص بهره‌مند شود. متأسفانه او در دفتری در فاصله ۲۰۰۰ مایلی کار می‌کند. به منظور رعایت دستورالعمل‌های مربوط به سفرهای کاری، بلیط او باید از دو هفته قبل خریداری شود. یا شاید در چندین Sprint، تیم قصد دارد user story خاصی را پیاده‌سازی کند که نیازمند مقدار مناسبی ورودی از سوی معاون فروش، معاون بازاریابی و مدیر کل بخش است. هماهنگی زمانی با آن سه نفر نیاز به برنامه ریزی قبلی دارد.در مرحله بعد، اطمینان حاصل کنید که در هر Sprint تمرکز تقریباً بر روی user stories خاص از موضوعات بزرگ‌تری است که برای انتشار(release) انتخاب شده‌اند.از آنجایی که Scrum امکان ارزیابی مجدد اولویت کار برنامه ریزی شده را در شروع هر Sprint فراهم می‌سازد، ممکن است PO و تیم به تدریج از آنچه که برای یک نقطه عطف یا انتشار(release) بزرگتر در نظر گرفته شده است دور شوند.اگر این جابجایی عمدی و نتیجه به کار‌گیری تجربیات آموخته شده Sprint های قبلی باشد، می‌تواند امری بسیار عالی باشد. با این حال، اگر حاصل از دست دادن دید جنگل از سوی تیم و PO به علت تمرکز بیش از حد بر روی درختان باشد، به اصلاح مجدد(realign) پروژه کمک میکند.آخرین اما نه کم اهمیت ترین مورد، اطمینان از کار کردن همیشگی تیم بر روی پروژه‌هایی با بالاترین ارزش ممکن(highest-valued work) است. یکی از راه‌های انجام این کار، پیشنهاد همکاری با PO برای اولویت‌بندی و تنظیم product backlog  با پیشرفت پروژه است.اسکرام مستر با سبک رهبری Delegating برای بخش R4بعد از رسیدن تیم به سطح آمادگی R4، سبک رهبری یک اسکرام مستر خوب از participating به Delegating تغییر خواهد کرد. در این مرحله، تیم نیازمند حداقل راهنمایی در زمینه کاری است. در صورت درخواست کمک، راهنمایی‌های لازم را ارائه دهید اما نحوه انجام کار را مشخص نکنید.(but do not specify how work should be accomplished)ابتدا، با نمایش نحوه به تعویق انداختن تصمیمات تا زمان ممکن، از واگذاری مسئولیت تصمیم گیری ها برای تیم فراتر بروید. وقتی یک تیم تصمیم گیری را به تعویق می اندازد،تیم گزینه‌های خود را باز نگه می‌دارد و می‌‌تواند از دانش جدید در تصمیم گیری نهایی استفاده کند. ما از توسعه دهندگان می‌خواهیم که این کار را با Design ها و کدهای خود انجام دهند. در یک پروژه Scrum، از آنها می‌خواهیم تنها مقدار کدهای لازم را برای پیاده‌سازی هر ویژگی بنویسند که بر روی آن کار می‌کنند(نه بیشتر و نه کمتر). ما از آنها نمی‌خواهیم که به‌طور فرضی لایه‌هایی از ویژگی‌های غیرضروری را بسازند که ممکن است «روزی» به آ‌نها نیاز داشته باشیم.به عنوان مثال، فرض کنید یکی از شرکای ما قصد ارسال یک فایل تراکنش هفتگی را دارد که می‌خواهد در سیستم ما بارگذاری کند. ما هنوز نمی‌دانیم که آیا آن یک فایل CSV یا XML خواهد بود یا ویژگی‌های دیگری دارد. به جای نوشتن یک واردکننده که از هر سه ورودی پشتیبانی می‌کند، تصمیم‌گیری را به تعویق می‌اندازیم. این ممکن است به این معنی باشد که ما برای هیچ یک از واردکننده‌ها کد نویسی را انجام نمی دهیم. همچنین ممکن است به این معنی باشد که با این فرض کد نویسی را آغاز می‌کنیم که داده های ورودی از جایی می‌آیند و از آن قسمت دارای مشکل کدنویسی می‌کنیم.زمان رسیدن تیم به سطح آمادگی R4، سبک رهبری یک اسکرام مستر خوب از participating به Delegating تغییر خواهد کردمهم‌ترین مولفه در تصمیم‌گیری، زمان بندی است. در روزهای اولیه معرفی جاوا، مدیریت پروژه‌ای بر عهده من بود که می‌توانست به عنوان یک کلاینت جاوا یا یک کلاینت محلی ویندوز ارائه شود. هر یک از رویکردها مزایا و معایب خود را داشت. ما به تازگی کار بر روی پروژه را آغاز کرده بودیم و «تصمیمگیری پلتفرم UI» در لیست مسائل باز قرار داشت. بنابراین، من از توسعه دهندگان اصلی دعوت کردم به سرعت در این مورد تصمیم گیری کنیم.البته ما تصمیم اشتباهی گرفتیم. با این حال، حتی اگر پلتفرم دیگری را انتخاب کرده بودیم باز هم می‌گفتم که تصمیم اشتباهی گرفته بودیم. در این مورد، تصمیم درست به تعویق انداختن زمان تصمیم گیری بود. در روزهای اولیه شروع آن پروژه هیچ دلیلی برای گرفتن آن تصمیم وجود نداشت. مطمئناً باید تصمیم گیری انجام می‌شد اما در هفته دوم پروژه انجام این کار چندان درست نبود. بنابراین اجازه دهید تیم خود تصمیم گیری کند اما آنها را راهنمایی و به آنها توصیه کنید تا جایی که امکان دارد گرفتن تصمیمات را به تعویق اندازند.نکته مهم بعدی، کار کردن بر روی به حداکثر رساندن(maximizing) نرخ توان کلی تیم است. اغلب به نظر می‌رسد پروژه‌ای که به‌طور سنتی مدیریت می‌شود، یک مسابقه‌ مانند مسابقه دو ده هزار متر یا یک مسابقه دوچرخه‌سواری ۵۰ مایلی  با خط پایان مشخص است. از سوی دیگر، Scrum بیشتر مانند مسابقه‌ای است که در آن مسئله مهم این است که مشخص شود در طی ۲۴ ساعت چقدر می‌توانید بدوید.اغلب هیچ خط پایانی برای پروژه اسکرام وجود ندارد.There’s often no finish line on a Scrum project.در مقابل، بعد از اتمام زمان شما دست از فعالیت می‌کشید. در صورت نیاز به ویژگی‌های بیشتر، دوباره کار خود را ادامه می‌دهید. در غیر این صورت، شما کار خود را به صورت کامل انجام داده‌اید. این تمایز منجر به ایجاد تفاوت‌هایی در نحوه برخورد مدیران سنتی و تیم های اسکرام با پروژه های خود می‌شود.مدیر پروژه سنتی به طور کامل بر روی دستیابی به یک هدف نهایی متمرکز است و مجموعه ای از عملکردها را در یک تاریخ خاص انتشار(releasing) می‌دهد. هیچ چیز فراتر از این هدف وجود ندارد. در ابتدا ممکن است این یک نقطه قوت برای مدیریت پروژه سنتی محسوب شود. با این حال، پاسخ احتمالی مدیر پروژه سنتی را زمانی در نظر بگیرید که یک توسعه‌دهنده یک ماه قبل از ضرب‌الاجل تعیین شده  با این نگرانی به او مراجعه و این مسئله را مطرح می‌کند که با وجود عملکرد صحیح کد در یک بخش، آسیب پذیر است و در چند ماه آینده به منبعی برای بروز مشکلات تبدیل خواهد شد. مدیر پروژه سنتی به احتمال زیاد یک تصمیم کوتاه مدت می‌گیرد و شانس خود را در رابطه با این کد آسیب پذیر امتحان می‌کند.یک اسکرام مستر باید بیشتر به دنبال به حداکثر رساندن توان عملیاتی تیم باشدبا این وجود، یک اسکرام مستر باید بیشتر به دنبال به حداکثر رساندن توان عملیاتی تیم باشد. در موارد خاص، ممکن است تیم، یک ضرب الاجل یک ماهه را نسبت به refactoring کد آسیب پذیر ترجیح دهد. با این حال، به طور کلی، کار درست حفاظت از توان عملیاتی کلی تیم و سازماندهی مجدد کد(refactor the code) است. وظیفه اسکرام مستر تشویق و هدایت تیم در آن جهت و محافظت از آنها در برابر مخالفت‌های بیرونی است.این تنها یک مثال از بسیاری از موارد دیگر است. تمایز اصلی در اینجا این است که پروژه سنتی تنها با هدف رسیدن به یک ضرب الاجل و کسب مجموعه‌ای مشخص از ویژگی ها مدیریت می‌شود. در مقابل، پروژه اجایل ممکن است از تعدادی ضرب الاجل‌های مختلف با قابلیت‌های وعده داده شده برخوردار باشد، اما توان عملیاتی پایدار تیم در بلند مدت نیز حائز اهمیت است.استفاده از اسکرام مسترینگ موقعیتیرهبری، مجموع تعاملاتی است که اسکرام مستر ها با تیم‌های خود دارند:آنچه بیان می‌کنند، آنچه که نمی‌گویند، نحوه بیان و چگونگی گوش دادن.مشخصه یک رهبر خوب تیم اسکرام فریاد زدن و گفتن «لعنت به اژدرها» نیست. همچنین مستلزم کناره گیری از تیم و اطلاع یافتن از به‌روزرسانی‌های روزانه اسکرام نیست. در مقابل، یک رهبر اجایل خوب – یک اسکرام مستر خوب – نیازمند آموختن است، اغلب اوقات در کنار تیم هایی که خودشان یاد می گیرند چگونه اجایل شوند.افزایش مهارت‌های مورد نیاز برای تبدیل شدن به یک اسکرام مستر و کمک به یک تیم برای اجایل شدن کار چندان دشواری نیست. انجام این کار به داشتن یک چارچوب ذهنی در مورد آمادگی تیم و سبک رهبری مورد نیاز برای یک تیم خاص کمک می‌کند. مدل رهبری موقعیتی، این چارچوب را در اختیار ما قرار می‌دهد. از آنجایی که اعتماد و قابلیت‌های تیم‌ها با کسب موفقیت افزایش می‌یابد باید به روش‌های مختلف آنها را هدایت و راهنمایی کرد.تیم‌های دارای توانایی محدود و اعتماد به نفس محدود(limited ability and limited confidence) معمولاً نیازمند یک سبک رهبری telling هستند. وقتی تیم‌های R1 را رهبری می‌کنید، معرفی Sprint های کوتاه مدت و آماده کردن تیم برای یک سری بردهای کوچک(small wins)، موجب افزایش اعتماد به نفس آنها می‌شود. روش‌های اساسی مرتبط با اجایل مانند افزایش تمرکز بر تست(testing) و continuous integration را معرفی کنید. با معرفی این روش‌ها، اعتماد تیم به مهارت‌ها و توانایی خود برای کار به شیوه‌ای جدید و اجایل‌تر افزایش پیدا می‌کند.از آنجایی که اعتماد و توانایی تیم‌ها با کسب موفقیت افزایش می‌یابد، باید هدایت(led) آنها به روش‌های مختلفی انجام شودیک تیم با توانایی‌های محدود اما متمایل و مطمئن، از سبک رهبری مربیگری بهره می‌برد. هنگام هدایت تیم‌های R2، به جای تمرکز صرف بر روی هدایت وظایف و کارها(just directing tasks)، به رابطه با اعضای تیم نیز توجه داشته باشید. تیمی با این ویژگی‌ها، برای بهبود مهارت‌های خود تنها به زمان، انگیزه و تمرین نیاز دارد.به منظور فراهم آوردن فرصت‌هایی برای یادگیری، بر نیاز به تحویل(deliver) یک محصول (product) با کیفیت در پایان هر Sprint تاکید کنید. اعضای تیم از طریق کار در iteration های کوتاه و تمرکز بر ایجاد نرم افزار بالقوه قابل انتشار(releasable) در پایان هر iteration، قاعدتاً به دنبال راه هایی برای بهبود مهارت‌های خود خواهند بود.تیم هایی که توانایی‌های آنها به طور قابل توجهی افزایش یافته است، از آمادگی بیشتری برای پذیرش سبک رهبری participating برخوردار هستند. با این حال، زمانی که وظیفه تصمیم گیری به خود تیم‌ها محول می‌شود، دست پاچه و عصبی می‌شوند و در مورد کافی بودن مهارت‌های تازه کسب شده‌ خود فکر می‌کنند. تیم‌های R3 را در طول این فرآیند انتقال با حمایت از آنها در زمان تصمیم گیری‌ها و تمرکز بر روی افق بلندمدت (۳ تا ۶ ماه) راهنمایی کنید و به تیم فرصت دهید تمام توجه خود را صرف Sprint فعلی کند.یکی از راه‌های انجام این کار، اطمینان از تمرکز Sprint ها بر روی اهداف ارائه (نسخه)(release) بعدی حتی در صورت اولویت‌بندی مجدد کار هر Sprint در شروع آن است. در مقابل، اطمینان حاصل کنید که شرکت با همکاری با PO، کاری با ارزش را برای تیم انتخاب می‌کند و به این ترتیب مطمئن شوید که product backlog به درستی اولویت بندی می‌شود.برای یک تیم خاص معرفی و اصلاح تکنیک‌ها در زمان مناسب امری ضروری استبرخی از اسکرام مستر ها از شانس بالای کار کردن با یک تیم R4 برخوردار هستند، تیمی ماهر(skilled) و متمایل(willing) که آماده ارتقا به سطوح بالاتری از مسئولیت است. در این موارد، سبک رهبری delegating را اتخاذ کنید. در پروژه های اسکرام، این امر شامل تمرکز بر به حداکثر رساندن توان عملیاتی در افقی فراتر از حدود یک پروژه است. همچنین به معنای کمک به تیم برای یادگیری زمان به تعویق انداختن تصمیمات است به شکلی که گزینه‌ها تا زمان ممکن در دسترس باشند.برخلاف توصیه دوستم در بازی گلف که تنها «توپ را دورتر بزنید»، این مقاله به نکاتی می‌پردازد که با تکیه بر آنها یک اسکرام مستر می تواند به یک رهبر تاثیر‌گذار‌تر برای تیم اجایل تبدیل شود. با توجه به اینکه هر یک از تکنیک‌های ذکر شده در اینجا می‌توانند برای یک تیم با هر سطح از آمادگی مورد استفاده قرار گیرند، من آنها را با توجه به ویژگی سطوح آمادگی در جایی توصیف کرده‌ام که از نظر من بیشترین سود را به همراه دارند. معرفی و اصلاح تکنیک‌ها در زمان مناسب برای یک تیم خاص، بهترین روش برای یک اسکرام مستر است که از طریق آن می‌تواند به شاه کلید تیم R4 و سبک رهبری delegating دست یابد. امیرحسین بزرگ کیان امیرحسین بزرگ کیان Sat, 13 Aug 2022 01:00:05 +0430