https://virgool.io/feed/@alin096 Agile, Scrum, Kanban, OKR fa 2026-04-14 18:35:14 https://files.virgool.io/upload/users/1165257/avatar/JbV9OV.jpeg?height=120&width=120 https://virgool.io/@alin096 https://virgool.io/@alin096/%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%AF%D8%B1-%DB%8C%DA%A9-%D8%B4%D8%B1%DA%A9%D8%AA-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%DB%8C-okr-%D8%B1%D8%A7-%D9%BE%DB%8C%D8%A7%D8%AF%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C-%DA%A9%D9%86%DB%8C%D9%85-mnhdn0thtwrn عبارت OKR به اهداف و نتایج کلیدی (Objective and Key Results) گفته می شود؛ OKR ها یکسری اهداف موثر و ابزار مدیریتی برای برقراری ارتباط در خصوص آن چه که میخواهیم انجام بدیم هستن و همین طور بیانگر مایلستون هایی هستن که باید آن ها را انجام دهیم. حتی OKR ها توسط بعضی از سازمان های پیشرو جهانی برای تدوین و انجام استراتژی ‏هایشان استفاده می شود.به عبارت دیگر OKR یک روش مشارکتی ست کردن اهداف هست که توسط افراد و یا تیم ها استفاده می شود تا اهداف چالشی و جاه طلبانه با نتایج قابل اندازه گیری ایجاد شود. OKR ها سبب مسیریابی، منطبق کردن، و همچنین برانگیزاننده مشارکت جویی در زمینه اهداف قابل سنجش هستند.Objective and Key Resultsفرقی نمی کنه که درباره کارهای اداری، مهندسی نرم افزار، کارهای غیر انتفاعی، و یا غیره صحبت کنیم، OKR ها برای ست کردن اهداف در سطوح مختلف سازمان ها به گونه ای یکسان عمل می کنند؛ OKR ها برای اهداف فردی هم کار می کنه و حتی وقتی که رهبران شرکت ازش استفاده نکنن شما می تونین برای انجام کارهاتون ازش استفاده کنین.تعریف اهداف و نتایج کلیدیهدفتعریف ساده هدف چیزیه که میخواهیم بهش برسیم، نه بیشتر و نه کمتر؛ بنا به تعریف، اهداف واضح، واقعی، انجام شدنی (عملگرا)، و به طور ایده آل الهام بخش هستند. اهداف وقتی به درستی طراحی و ایجاد شوند، عملا در برابر تفکرات فازی و اجرای غیر موثر مثل واکسن عمل می کنند!نتایج کلیدینتایج کلیدی معیار و نمایشگر و مانیتور کننده روندی هست که ما رو به اهداف مون میرسونه؛ ویژگی های نتایج کلیدی موثر «خاص و زمان دار بودن، نیازمند تلاش اما واقعی بودن» هست. علاوه بر این موارد باید قابل اندازه گیری و بررسی باشند. شما ممکنه به نیازمندی های یک نتیجه کلیدی تون برسین یا نه (نکته مهم اینه که هیچ فضای خاکستری یا جای شکی نباید توش باشه). در پایان یک دوره طراحی شده- که معمولا یک فصل هست- ما یک بررسی قاعده مند انجام میدیم و امتیاز نهایی حاصل از اون نتیجه کلیدی رو بررسی می کنیم که به نتیجه رسیده یا نه.یه جمع بندی کوچیک داشته باشیم یک هدف میتونه بلند مدت زندگی کنه، یک سال یا بیشتر، نتایج کلیدی اون هدف با پیشرفت کار تکامل پیدا می کنند؛ وقتی همه اون نتایج کلیدی کامل بشن هدف شون تحقق پیدا می کنه.اهداف و نتایج کلیدی در یک نگاه (Objective and Key Results)نکات کلیدی که باید در تدوین اهداف و نتایج کلیدی شرکت در نظر بگیریمتو نوشتن این نکات مثال هایی که میگم رو بیشتر با شرکت های نرم افزاری در نظر می گیرم:به ازای هر هدف بین 3 تا 5 نتیجه کلیدی در نظر بگیریم.نتایج کلیدی باید طوری طراحی بشن که حتما توی اون ها قابلیت اندازه گیری داشته باشیم؛ یکی از دغدغه هایی که تو شرکت های نرم افزاری بیشتر هست مربوط به کارهایی مثل پشتیبانی هست که همیشگی وجود داره و براش پلن خاصی هم نمیشه گذاشت، این جور موارد رو میشه به صورت های زیر KR کرد:مثال1، KR: کاهش تعداد تسک های پشتیبانی باز باقیمانده شرکت از 87 به 35مثال 2، KR: کاهش تعداد تسک های پشتیبانی باز باقیمانده شرکت به میزان 40 درصد (مدل دیگه ای که برای نوشتن KR بالا میشه استفاده کرد)بعضی وقت ها لازم هست برای تحقق یک Object، یک KR رو با یک KR دیگه جفت (Pair) کنیم؛ یا به عبارت دیگه چفت و بست کنیم؛ مثل مثال های 3 و 4 که صرفا منظور مون تولید FAQ نیست، بلکه علاوه بر ارزش تولید، نیاز داریم که FAQ ها بررسی و تایید شده هم باشند:مثال 3، KR: تعداد FAQ های تولید شده از 0 به 80 عددمثال 4، KR: افزایش درصد FAQ های تایید شده از 0 به 35 واحد های سنجش متفاوتی میشه برای KR ها در نظر گرفت که بعضی از اون ها شامل «عدد، تومان، روز، ماه، هفته، فصل، سال، و . . .» هست.مثال 5، KR: افزایش درآمد حاصل از فروش ناشی از اپلیکیشن فروشگاهی از مبلغ 20 میلیارد ریال به مبلغ 25 میلیارد ریالمنطق زمان های گزارش دهی ما میتونه شامل «هفتگی، ماهانه، فصلی، هفتگی شناور، و . . .» باشه (هفتگی شناور یعنی از روز گزارش تا هفت روز قبل نه از شنبه تا آخر هفته)؛ وقتی منطق گزارش دهی ما بیش از هفتگی باشه تعداد/ مبلغ/ . . . مندرج در گزارش هر هفته به هفته های قبل اضافه میشه.مثال 6، KR: افزایش درآمد حاصل از فروش ناشی از اپلیکیشن فروشگاهی از مبلغ 20 میلیارد ریال به مبلغ 25 میلیارد ریال (با منطق فصلی) --------> گزارش هفته اول: 20.5 میلیارد ریال/ گزارش هفته دوم: 20.6 میلیارد ریال/ . . .نکات کلیدی که باید در فرآیند پیاده سازی OKR شرکت در نظر بگیریممثل همه کارهای شرکت ها مادامی که حمایت مدیران ارشد سازمان باهاتون باشه این موضوع رو میتونین کم نقص تر اجرا کنید، در غیر این صورت تنها در اسکوپ کوچک تر مثل فردی یا یک مدیریت و . . . میشه اجراش کرد.از اون جایی که رویکرد این روش ایجاد هماهنگی و همراستایی اهداف و اجزای سازمان هست بهتر اینه که شرکت دارای استراتژی تعریف شده باشه، اما بدون اون هم میشه کار رو شروع کرد.در گام اول نیاز هست اهداف و نتایج کلیدی سطح بالای شرکت (و ترجیحا در راستای استراتژی های شرکت) تدوین بشه و بعد از اون اهداف و نتایج کلیدی تیم های شرکتهمراستایی عمودی اهدافدو رویکرد برای ایجاد همراستایی عمودی بین اهداف شرکت و تیم ها وجود داره؛ یکی این که بگیم هر هدف از تیم در راستای کدوم هدف از شرکت هست، و دیگری اینه که به ازای یک یا چند نتیجه کلیدی از اهداف شرکت بتونیم یک هدف در یک (یا چند) تیم شرکت ایجاد کنیم (با رویکرد دوم مطمئن میشیم که هیچ کدوم از KR های شرکتی دور زده نشدن!)همراستایی افقی اهدافگاهی بین تیم های درون سازمان مطالباتی وجود داره که گیر کرده و شاید یکی از تیم ها به درستی پاسخگوی تیم دیگر نباشه؛ تو این مواقع لازم هست برای اون ها هم نتایج کلیدی در نظر گرفته بشه تا موضوعات فی ما بین رو بتونن از این طریق ثبت و تبادل کنند.مثال 7، KR: کاهش مطالبات تیم A از تیم B از 8 به 3 عددبرای فراگیر شدن OKR در سطح شرکت پیشنهاد میشه که همه افراد سازمان در فرآیند ایجاد اهداف و نتایج کلیدی مشارکت داشته باشند (همچنین بعد از تدوین هر فردی از شرکت دست کم مسوول یک KR باشه)تدوین اهداف و نتایج کلیدی (Objectives and Key Results) هر سازمان یا شرکت به اقتضای خودش باید انجام بشه اما یه سری اهداف و نتایج کلیدی هم وجود داره که میشه از اون ها در شرکت های مختلف استفاده کرد.گزارش وضعیت اهداف و نتایج کلیدی هر هفته باید هم در یک سامانه ثبت بشه و هم در یک جلسه ارایه بشه.سیستم OKR به صورت فریبنده ای ساده هست، ولی این سادگی تا زمانی ادامه داره که به درستی استفاده شود: در این خصوص OKR های خوب سازمان شما رو با قدرت های بسیار بالا برای ساختن خروجی های سطح بالای مدیریت در تمام اهداف کسب و کار تون مجهز می کنند.حضور یک مربی با دانش و سابقه مرتبط در راه اندازی و پیاده سازی OKR بسیار کمک کننده هست.وجود یک نرم افزار تخصصی OKR در راه اندازی و پیاده سازی OKR بسیار کمک کننده هست (اولش همه با اکسل شروع می کنیم :) )در خصوص پیاده سازی OKR موضوعات خیلی زیادی هست که باید یاد بگیریم، اما این بخش از دانسته هام رو دوست داشتم با شما هم به اشتراک بزارم تا هم بتونین استفاده کنین و هم بهم بازخورد بدین تا من هم در این چالش ها بیشتر یاد بگیرم.تو فرصت های بعدی مطلب های جدیدی در این خصوص با شما هم به اشتراک میزارم. علی نیک روش علی نیک روش Sat, 21 Dec 2024 17:51:04 +0330 https://virgool.io/@alin096/%D8%AA%D8%AE%D9%85%DB%8C%D9%86-%DB%8C%D9%88%D8%B2%D8%B1-%D8%A7%D8%B3%D8%AA%D9%88%D8%B1%DB%8C-%D9%87%D8%A7-%D8%A8%D9%87-%D8%B1%D9%88%D8%B4-%D8%BA%DB%8C%D8%B1-%D9%85%D8%B3%D8%AA%D9%82%DB%8C%D9%85-%DB%8C%D8%A7-%D8%A7%D8%B3%D8%AA%D9%88%D8%B1%DB%8C-%D9%BE%D9%88%DB%8C%D9%86%D8%AA-zcafzgvmianh Story Points with Fibonacciروش های مختلفی برای تخمین بک لاگ ها (Product Backlog Items) یا استوری ها (User Stories) در بوردهای اجایل (Agile) و اسکرام (Scrum) و . . . وجود داره که کم و بیش باهاش آشنا هستیم و جای دیگه بهش می پردازیم.میدونیم که روش تخمین استوری پوینت روش غیر مستقیم هست (برای ترجمه Relational تو این مورد ترجمه بهتری به ذهنم نیومد)، و بنابراین برای امتیاز دادنش ممکنه دچار کمی ابهام بشیم. چه کار کنیم تا با استوری پوینت ها ارتباط بهتری برقرار کنیمبرای دادن امتیاز استوری پوینت سه عامل «پیچیدگی، ناشناختگی یا ابهام، و میزان تلاش» رو باید در نظر بگیریم؛ بریم بررسی کنیم: پیچیدگی (Complexity): وقتی یه کار از عوامل متعدد و گوناگون، در مقیاس‌های متفاوت، با اتکا و وابستگی ذاتی و جدایی‌ناپذیر عوامل بر همدیگر وجود داشته باشد، و بالاتر از همه این ها، اگر نشه با حذف و قطع برخی از مولفه‌ها و اعضا، به کوچک‌تر ساختن آن مجموعه پرداخت، با پیچیدگی روبرو هستیم.تو ذهن تون ساخت یه مبل راحتی با مبل سلطنتی (!) رو مقایسه کنید :)ناشناختگی (Unknown): ناشناختگی در برابر شناخت هست (عجب جمله ای گفتم!)؛ در متدولوژی های مختلف اجایل روش های متنوعی برای بالابردن میزان شناخت روی بک لاگ ها وجود داره، ولی در چارچوب اسکرام از جلسات Refinement برای ایجاد شناخت بیشتر یوزر استوری ها استفاده میشه که دست کم ناشناختگی های یک بک لاگ از دید بیزنسی حل بشه و دولوپر ها دیگه بیشتر روی مسایل تکنیکال وقت و انرژی بزارن.(تو بعضی از مستندات فاکتور دوم رو عدم قطعیت (Uncertainty) یا شفافیت (Clarity) هم عنوان می کنند.)میزان تلاش (Effort): فعالیت آگاهانه برای انجام یک کار یا به عبارت دیگه فعالیت ذهنی یا فیزیکی لازم برای به دست آوردن یک چیز.خب این تعاریف رو که بلد بودیم، به چه درد مون میخوره تو استوری پوینت دادن؟میدونیم یکی از بهترین روش ها برای دادن استوری پوینت ها استفاده از دنباله فیبوناچی هست؛ چرا؟چند فاکتور جالب تو این دنباله وجود داره:غیر خطی هستندهر عدد از جمع دو عدد قبلیش به دست میادهر عدد این دنباله به نسبت عدد قبلی حدود 60 درصد بیشتر هست؛ یعنی عدد هایی که میگن خیلی به هم نزدیک نیست (به غیر از سه جمله اول دنباله) و معنا دار خواهد بود.میتونیم از عبارت کمتر یا بیشتر براشون استفاده کنیم و باز به عدد معنا داری نسبت به قبلی میرسیم.دنباله فیبوناچی: 1, 2, 3, 5, 8, 13, 21, 34, 55, . . .آخرش چطور امتیاز بدیم؟میتونیم هر کسی تو ذهن مون برای هر کدوم از این سه عامل بر مبنای همون دنباله فیبوناچی تقسیم بندی داشته باشیم و بعد جمع اون ها نزدیک هر کدوم از اعداد فیبوناچی شد همون رو بهش تخصیص بدیم و بعد هم نظر جمعی رو از برآیند استوری پوینت هایی که اعضای تیم میدن داشته باشیم؛ چند تا مثال تو جدول آوردم و عمدا هم اعداد رو خیلی میزون ندادم که تقریب هم توش داشته باشیم.Story Points Based on Fibonacci FAQآیا نیاز هست به ازای هر یوزر استوری هر کدو از اعضای تیم دولوپ امتیاز هاشون رو به این سه فاکتور تجزیه کنن و روی اون ها هم بحث کنیم؟به نظر من خیلی ضروری نیست مگر این که اختلاف بین اعداد کلی که میدن بیشتر از یک کارت باشه که بعد دلیلش رو با هم مرور کنن و لازم شد وارد جزییات بشن.بهتر نیست به جای عدد نهایی روی این سه عامل از دولوپرها بپرسیم؟نه، بهتر هست که این موضوع رو پیچیده نکنیم؛ ولی میشه تو سه چهار تا اسپرینت این طور پیش رفت تا نظرات بچه ها با هم منطبق بشه و بعد دیگه خیلی وارد این جزییات نشد.چطور بفهمیم که استوری پوینت هایی که دولوپر ها میدن خیلی واگرا نیست و تخمین درستی از کار هست؟تو سه یا چهار تا اسپرینت هم اولش به بک لاگ ها استوری پوینت بدن (Original Story Point) و هم بعد از دان کردن بک لاگ تا معیار تخمین برای همه ملموس تر بشه.دولوپر هایی که تو اسپرینت نقش دولوپری ندارن هم میتونن استوری پوینت بدن؟خیر، اون ها چه کاره هستن که بخوان پوینت بدن! تخمین مال کسی هست که تو پیاده سازی اون نقش داره؛ بنابراین، مالک محصول و یا اسکرام مستر هم بشینن قهوه شون رو بخورن به جای پوینت دادن.آیا میشه بیشتر از 13 استوری پوینت به یک بک لاگ امتیاز داد؟شما هر چقدر دوست داری امتیاز بده، ولی وقتی عدد بالا میره یعنی یه مشکلی تو اون یوزر استوری وجود داره که معمولا لازم هست مالک محصول و دولوپر ها اون رو دوباره مورد بررسی قرار بدن (اگه لازم شد میتونن از Domain Experts هم دعوت کنن و ازش برای شفاف تر کردن بک لاگ کمک بخوان؛ نه امتیاز دادن) علی نیک روش علی نیک روش Sun, 19 Jun 2022 18:24:31 +0430 https://virgool.io/@alin096/%D8%AA%D8%B3%DA%A9-%D8%A8%D8%B2%D9%86%D9%85-%DB%8C%D8%A7-%D9%86%D9%87-%DA%86%D8%B7%D9%88%D8%B1-%D9%85%DB%8C%D8%B4%D9%87-%D9%81%D9%87%D9%85%DB%8C%D8%AF-%D8%AA%D8%B3%DA%A9-%D8%AE%D9%88%D8%A8%DB%8C-%D8%B2%D8%AF%D9%85-vt0q4wvk0kit شکل1- تسکت رو بزن!!!همیشه با مدیر پروژه، PO و اسکرام مستر مون درگیر هستم؛به من میگن باید تسک هات رو تو بورد بزنی، ولی من خودم میدونم چه کارهایی رو باید انجام بدم، دلیلی نداره بخوام تسک بزنم،تازه از من میخوان که جزییاتش رو هم بزنم!؟اصلا من از Jira، Trello، Azure Devops و هر چی Task Manager هست خوشم نمیاد!وقتی خودم کار هام رو میدونم چه لزومی داره تسک هام رو بگم؟ مهم اینه که کار رو تحویل بدم دیگه . . . تازه از اون بدتر! از من میخوان که رو تسک تخمین هم بزنم!!!واسه همینه که اصلا از اجایل و اسکرام و اسکرام مستر و PO خوشم نمیاد!راستش اگه میدونستم جزییاتش چیه دنیا خیلی بهتر بود!خب شاید واقعا مشکلی نبود؛ هم تسک میزدم و هم تخمین میدادم.شکل2- نمونه شکستن یک User Story به Tasksاگه کمی فرصت دارین با هم بریم ببینیم میشه دنیای بهتری بین دولوپر ها و سایر اعضای تیم ساخت!؟شفاف سازی تسک هاهر تسک نمایان گر چشم انداز و هدف یک کار هست.هر چه تسک ها رو واضح تر بنویسیم، یعنی واضح تر فکر می کنیم.شفافیت در نوشتن تسک ها تمرین مفیدی است.چرا باید تسک ها شفاف باشه؟وقتی دوباره به یک تسک بر می گردیم باید وضوح لازم رو داشته باشه تا یادمون نره موضوع تسک چی بوده.چه مقدار جزییات نیاز داریم؟وقتی یه تسکی رو مینویسیم فکر کنیم که میخوایم اون رو به دیگری بدیم انجام بدهشکل 3- سپردن تسککار رو به اجزای قابل انجام بشکونیموقتی صرفا هدف نهایی کار و وظایف کلی رو تو ذهن مون در نظر بگیریم چون نمیدونیم کار از کجا باید شروع بشه و چه مراحلی داره احساس گنگی و یا گیجی تو کار می کنیم و بنابراین شروعش برامون سخت تر میشه از طرفی اگه تسک ها رو بیش از حد جزیی هم کنیم ممکنه فکر کنیم خیلی ساده و خسته کننده هست و هرگز اون ها رو شروع نمی کنیم.اگه تسک ها خیلی مبهم، چکیده (Abstract)، یا سخت باشه، باز هرگز اون ها رو شروع نمی کنیم چون احساس می کنیم نمیتونیم انجامش بدیم.چند نکته برای تسک ها طوری هدف گذاری کنید انگار که %4 از منطقه امن خودتون بیرون میاین.به طور ایده آل یه تسک باید مثل یه بلوکی باشه که اون رو بردارین و تا زمانی که انجام نشده اون رو پایین نزارین.تسک های تک مرحله ای در برابر تسک های چند مرحله ایهر تسکی باید با یک فعل آغاز شود؛ اگه فعلی وجود نداشته باشد در حقیقت کاری برای انجام وجود ندارد.در صورتی تسک های چند مرحله ای قابل پذیرش هستن که شما همه اون ها رو بتونین در یک بلاک انجام بدین.چند مثال از فعل های یک مرحله ای:رزرو کردن، خرید کردن، تماس گرفتن، کپی کردن، ویرایش کردن،ایمیل زدن، پر کردن، پیدا کردن، جمع کردن، بار گزاری کردن،چاپ کردن، پاکسازی کردن، خواندن، ضبط کردن، ثبت کردن،نوشتن، مرور کردن، زمان بندی کردن، فرستادن، به روز رسانی کردن (یک مرحله ای)، تایید کردن،منتظر ماندن، نوشتنچند مثال از فعل های چند مرحله ای:تحلیل کردن، کامل کردن، تصمیم گرفتن، استقرار دادن،طراحی کردن، تمام کردن، هندل کردن، پیاده سازی کردن،نصب کردن، سازماندهی کردن، تحقیق کردن، حل کردنبه روز رسانی کردن (چند مرحله ای)فعل هایی رو که بیان کردم شاید چند تا مثال پر کاربرد باشه ولی قطعا شما تو کار خودتون خیلی موارد دیگه رو میتونین به این ها اضافه کنید.از واژگان ساده استفاده کنید که قابل فهم برای همه باشد.واژه های مبهم را با واژه های مشخص و خاص جایگزین کنید:همیشه بپرسین چه چیزی نیاز هست در این مرحله انجام بشه؟هدف تعیین شده یا نتیجه چی هست؟اگه شما به طور واضح ندونین که تسک تون چیه، پس باید سراغ ریسرچ یا توفان مغزی برین حالا با هم یه مثال بزنیم: تسک بد: بهبود تجربه کاربری وب سایت تسک خوب: کاهش زمان بارگزاری وب سایت برای بهبود تجربه کاربر نهایی تسک بهتر: کاهش سایز عکس ها برای کاهش زمان های بارگزاری وب سایت که منجر به بهبود تجربه کاربر نهایی می شود.از کلمات تاکیدی به جای کلمات منفی استفاده کنید:به جای استفاده از واژگان منفی که نیاز به تفسیر جمله ایجاد می شود، از کلمات مثبت و تاکیدی استفاده کنید.مثال: تسک بد: بررسی متن برای جزییات بی ربط که مخاطب قدردانی نخواهد کرد. تسک خوب: بررسی متن برای اطمینان یافتن از این که جزییات مرتبط با مخاطب است.از به کارگیری اسم های پی در پی اجتناب کنید:استفاده از اسم های پی در پی (رشته اسم ها) در جمله باعث سر در گمی می شود.تسک بد: نوشتن روال های آخر روز برای ناوگان وسایل نقلیه حمل و نقل عملیات عمومی تسک خوب: نوشتن روال های آخر روز برای ناوگان حمل و نقل عمومیحواس تون به طول عنوان تسک باشه:عنوان رو متناسب بنویسید و جزییات رو توی توضیحات اضافه کنید.مثال کلی: کامل کردن یک پست بلاگComplete a blog post on clear task writing:Outline blog post with introduction, major bullet points and conclusion in Google Docs.Research supporting bullet points filling the bullet points with notes.Write introduction and a conclusion to the post.Write fleshed out supporting bullet points from research.Edit post after stepping away for at least an hour.Wait for 3rd party review of post.Format post in blogging system.Publish post as per scheduled time. علی نیک روش علی نیک روش Sun, 24 Apr 2022 00:17:26 +0430 https://virgool.io/@alin096/%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%A7%D8%B2-%D8%A7%D8%B1%D8%B2%D8%B4-%D9%87%D8%A7%DB%8C-%D8%A7%D8%AC%D8%A7%DB%8C%D9%84-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D9%85%DB%8C-%DA%A9%D9%86%D8%AF-hiw3uo7fv7c3 همه مون میدونیم که اسکرام در کنار روش هایی مثل XP و Kanban یکی از چارچوب های دنیای اجایل هست؛ به همین خاطر میخوایم ببینیم که ارزش های اجایل در کجای اسکرام نمود پیدا می کنه؟رویدادهای اسکرام (Scrum Events)نخستین ارزش اجایل، افراد و تعاملات بالا تر از فرآیند و ابزار ها هست؛ اسکرام پیاده سازی این ارزش رو از طریق تیم های خود سازماندهی شده (و یا خود مدیریت شده) محقق می کنه.ارزش دوم اجایل، نرم افزاری که کار می کنه بالا تر از اسناد جامع و کامل هست؛ اسکرام تحقق این ارزش رو در اسپرینت ها دنبال می کنه: اسپرینت بازه چند هفته ای از کار توسعه نرم افزار هست که در اون یک فرآورده افزایشی "انجام شده"، قابل استفاده و آماده ریلیس خلق میشه. نشونه ای که مار رو مطمئن می کنه که کار به درستی پیش رفته و به انجام رسیده هم خلق محصول هست نه خلق مستندات.سومین ارزش اجایل، مشارکت مشتری رو بالا تر از مباحث قرارداد میدونه؛ اسکرام این ارزش رو از طریق مالک محصول (Product Owner) ایجاد می کنه: مالک محصول از طریق ارتباط مستمر با تیم توسعه، ارزش محصولی که داره توسعه پیدا می کنه رو بیشینه و کار تیم رو هم بهینه می کنه.چهارمین و آخرین ارزش اجایل، پاسخ دهی به تغییرات رو بالا تر از دنبال کردن یه طرح ارزش گذاری می کنه؛ اسکرام از طریق رویداد های خودش این ارزش رو محقق می کنه: هر کدوم از رویداد های اسکرام فرصتی برای بازبینی و سازگاری طرح هستن. همچنین هر کدوم از رویداد ها، با هدف حذف طرح ریزی های کش اومده و غیر ضروری از تایم باکس استفاده می کنن.مانیفست اجایل تاکید می کنه که طرف دوم هر یک از عبارت ها (که در این متن به صورت ایتالیک نوشته شده) هم با ارزش هستن، ولی طرف اول (که در این متن به صورت بولد نوشته شده) بسیار با ارزش تر هستند.خوبه که سطحی از این مساله نگذریم و کمی دقیق تر به عبارات و ارزش ها نگاه کنیم؛ در اجایل به یک سری از ارزش ها ارجحیت داده شده، و تاکید روی اون ها به این خاطر هست که خیلی درگیر بروکراسی نشیم و با توجه به این که روح اجایل مشتری مداری هست بتونیم با خلق محصول های با ارزش و ارایه مستمر اون (حداکثر هر چند هفته یک بار) متناسب با نیاز های مشتری، کاربران رو راضی و خشنود نگه داریم. وگرنه در حد نیاز، اهمیت استفاده از ابزار ها و فرآیندها، مستند سازی محصول و کد ها و . . .، بستن قرارداد، و همچنین طرح مشخص داشتن برای محصول بر کسی پوشیده نیست و اگه جایی هم میخوایم ازش در بریم صرفا به خاطر تنبلی و یا عدم شفافیت هست و نه هیچ چیز دیگه.ارزش های چهار گانه اجایلتو بررسی هایی که می کردم به چند تا تعریف خوب از اجایل برخوردم که اون ها رو هم باهاتون به اشتراک میزارم:اجایل یک روش توسعه نرم افزار هست و به ما یادآوری می کنه اگرچه کامپیوتر ها کد ها رو اجرا می کنن، افراد هستند که اون ها رو خلق می کنن، ازشون نگهداری می کنند و اون ها رو توسعه میدن.تو یه تعریف دیگه اجایل به اندازه کافی شجاع و صادق بودن نسبت به پذیرش پیچیدگی نرم افزار هست و بیان می کنه که نرم افزار تا جایی که نیازمندی ها تغییر می کنن به صورت کامل قابل برنامه ریزی نیست.همون طور که میدونیم اجایل دوازده اصل هم داره که اون ها و نحوه به کار گیری شون در اسکرام رو هم تو یه مقاله دیگه با هم مرور خواهیم کرد.ممنونم از این که این مطلب رو هم خوندین و مشتاقانه منتظر دریافت بازخور از شما هستم تا بتونم دید و درکم رو گسترش بدم و در سفر اجایل و اسکرام همراه داشته باشم. علی نیک روش علی نیک روش Fri, 15 Oct 2021 00:45:53 +0330 https://virgool.io/@alin096/%D9%86%DA%AF%D8%A7%D9%87%DB%8C-%D8%AF%DB%8C%DA%AF%D8%B1-%D8%A8%D9%87-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-%D8%AA%D8%A7%DB%8C%D9%85-%D8%A8%D8%A7%DA%A9%D8%B3-%D8%AF%D8%B1-%D8%A7%D8%AC%D8%A7%DB%8C%D9%84-%D9%88-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-wslskkghpoeg اگه تو گوگل بزنیم تایم باکس، چند تا مقاله که اهمیت تایم باکس توش تعریف شده رو میتونیم ببینیم؛ مواردی که به نظر من اطلاعات بهتری بهمون میده یکیش عنوان "تایم باکسینگ، مدیریت زمان با نگاه روانشناسانه" هست و دیگری "تایم باکسینگ چگونه کارآیی شما را افزایش می دهد" که خوندن هر دو رو بهتون توصیه می کنم.تو مقاله اول که کار آقای "ابوالقاسم حبیبی" هست اومده مواردی که تایم باکسینگ روش تاکید داره رو بیان کرده:کارهای بزرگ رو آهسته پیش ببریمسعی کنیم از شر وظایف آزار دهنده خلاص بشیمجلوگیری از تنبلیکمال گرایی در برابر تعللخط زدن کارهای انجام شده از لیست کارها مونمقاله دوم که اثر خانم "پویش پور محمد" هست هم درباره اهمیت تایم باکسینگ صحبت کرده و اون رو به عنوان مفید ترین روش افزایش بهره وری معرفی کرده.بنابراین، من از اهمیت و تعاریف میگذرم و اگر مجبور به این کار شدم کمی توضیح رو چاشنی کارم می کنم.زمان دو وجه داره:یه وجهش محدود کننده هست که در کنار انسان و تجهیزات به عنوان یکی از منابع پروژه در نظر گرفته میشه (از اون جایی که منابع نامتناهی نیستند، با نگاه دیگه به منابع میشه محدودیت ها هم گفت).وجه دومش برانگیزاننده هست، اگه به عنوان یه هدف در نظر گرفته بشه و برای مثال قرار باشه در زمان مشخصی کاری انجام بشه (به خصوص اگه قرار داشته باشی و منتظر رسیدن کسی در تایم مشخصی باشی!).کمی به عقب برگردیم و ببینیم از کجا تایم باکس وارد زندگی ما شده؟ورود تایم باکس به زندگی!اگه یکم دقت کنیم متوجه میشیم کل دوازده سال تحصیلی و بعدش هم دانشگاه ما تایم باکس داشتیم:زنگ اول ریاضی (معمولا اولین زنگ روز شنبه اول هفته رو باید با ریاضی شروع می کردیم و خیلی ها از این موضوع خوشش شون نمیامد)زنگ دوم فارسیزنگ . . .در حقیقت زنگ ها به عنوان محرک های خارجی بودن که به ما و معلم ها و اساتید یادآوری می کرد اون کلاس تموم شده و بعد از کمی استراحت باید سراغ کار جدید بریم (ممکن بود دو زنگ متوالی هم یه درس رو داشتیم)؛ یه لحظه فکر کنیم اگه تایم باکس های کلاس ها نبود چه اتفاقی میفتاد؟ اصلا میشد نظم و ترتیبی به کار ها داد؟ تا کی باید سر یه کلاس می نشستیم و اساسا آیا دنباله دار شدنشون بازدهی هم داشت؟پس متوجه شدیم که ادبیات تایم باکس از خیلی وقت پیش وجود داشته و نباید اون رو به اجایل و اسکرام نسبت داد، اما نکته مهم اینه که به کار گیری تایم باکس در همه متد ها و چارچوب های پروژه از جمله مدیریت پروژه و همین طور اجایل و اسکرام و . . . توصیه شده.آیا در اسکرام تایم باکس داریم؟صد در صد! اگه افتخار این رو دارم که مقاله های قبلی من رو هم مطالعه کردین، تو بخش های آخر مقاله "تیم خود سازماندهی شده از دید اسکرام" در باره این که تایم باکس چطور میتونه به خود سازمانده شدن تیم کمک کنه صحبت کردم، و همین طور در مقاله "تعریف کار انجام شده یا DoD در اسکرام" در باره تایم باکس های اصلی چارچوب اسکرام، که اینجا جدولش رو دوباره میزارم تا در دسترس مون باشه:جدول تایم باکس های اجباری در اسکرامبد نیست به اون هایی که فکر می کنن تو اسکرام تایم و تخمین و این حرف ها مطرح نیست از همین جا سلامی هم عرض بکنیم . . .در حقیقت شش تایم باکس تعریف شده در اسکرام وجود داره که رعایت اون ها باعث ایجاد تمرکز در کار و پرهیز از واگرایی مباحث و پرداختن به اصل مطلب که توسعه نرم افزار قابل استفاده هست، خواهد شد.خیلی دوست داشتم ببینم که مستندات خود اجایل در خصوص تایم باکس چی میگه؟"تایم باکس یک دوره زمانی است که قبلا توافق شده و طی آن شخص یا تیمی به طور پیوسته در جهت تکمیل هدف تلاش می کند. به جای این که اجازه دهید کار تا رسیدن به هدف ادامه پیدا کند و زمان مورد نیاز را ارزیابی کنید، رویکرد تایم باکس شامل متوقف کردن کار هنگام رسیدن به محدودیت زمانی و ارزیابی آنچه انجام شده است می باشد.تایم باکس ها میتونن در اندازه های زمانی متفاوت به کار برده بشن [بسته به کار تعریف میشه]"نکته مهمی که از مفاهیم اسکرام و همین طور از این تعریف میشه برداشت کرد اینه که برای انجام هر کاری با توجه به دانش، تجربه و مهارت های هر فرد یا تیم زمانی در نظر گرفته میشه (تخمین زده میشه== Estimation) و بعد از اتمام تایم در نظر گرفته شده باید کار رو متوقف کرد، مورد ارزیابی قرار داد و بعد اون در صورت نیاز برنامه ریزی مجدد برای اتمامش رو بر اساس Acceptance criteria و همین طور DoD انجام داد.مشکل کجاست که ما نمیتونیم به درستی از تکنیک تایم باکس استفاده کنیم؟باز یک مثال آشنا، برگردیم به زمان مدرسه:معلم ها برای هر جلسه کلاس طرح درس داشتن و بر مبنای اون سعی می کردن مطالب رو ارایه کنن و به ما یاد بدن؛ بنابراین، باید برای هر تایم باکس یه خروجی مناسب (هدف) در نظر گرفت تا در پایان اون بتونیم از کار مون یه ارزیابی داشته باشیم و به اصطلاح امروزی ها ببینیم با خودمون "چند چندیم"، اگه از خودمون (برنامه) عقب بودیم با برنامه ریزی مجدد بریم سراغش و تمومش کنیم (Done) اگه جلو هم بودیم که خیلی عالی به خودمون یه آفرین بگیم و اگه دوست هم داشتیم استراحت کنیم تا برای کار بعدی (که تایم باکس خودش رو داره) آماده تر بشیم.کلاس درس، نمونه ای از time-boxingامیدوارم مطالب گفته شده براتون مفید بوده باشه و بی صبرانه منتظرم تا ایده و دیدگاه های ارزشمندتون رو در خصوص این مطالب تو کامنت ها بزارین تا من هم بتونم درک خودم از مسایل اسکرام رو بهبود بدم. علی نیک روش علی نیک روش Wed, 06 Oct 2021 01:10:17 +0330 https://virgool.io/@alin096/%D8%A7%D8%AC%D8%B2%D8%A7%DB%8C-%D8%AA%D8%B9%D8%B1%DB%8C%D9%81-%DA%A9%D8%A7%D8%B1-%D8%A7%D9%86%D8%AC%D8%A7%D9%85-%D8%B4%D8%AF%D9%87-%DB%8C%D8%A7-dod-%D8%AF%D8%B1-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-znumyqmssby1 تو مقاله قبلی راجع به تعریف کار انجام شده با هم صحبت کردیم و اهمیت و نقش اون در اسپرینت رویو رو با هم مرور کردیم. اما یه DoD خوب باید چه اجزایی داشته باشه و یا چه مواردی رو در بر بگیره، چیزی هست که تو این مقاله بهش می پردازم و سعی می کنم با ارایه مثال تصویر بهتری از DoD رو بتونم ارایه بدم.تمام نا تمام من با تو تمام می شود!اگه بخوایم DoD رو تو یه جمله تعریف کنیم باید بگیم درک مشترک اعضای تیم از تکمیل بودن خروجی ای که باید در یک اسپرینت قابل ارایه و استفاده باشه.بدون تعریف واضح از کار انجام شده، تیم توسعه نمیدونه در حال انجام چه کاری است، ذی نفعان در افزایش دامنه مختار میشن و کاربران هم به احتمال زیاد با محصولی شلوغ، گیج کننده و غیرقابل استفاده رو به رو میشن؛ در حقیقت بدون DoD ما تصوری از این که کار کی به پایان میرسه نداریم.بدون داشتن یک هدف مشخص، کارهای ناتمام به راحتی روی هم انباشته می شوند و در نهایت با یک "بدهی کاری" مواجه میشیم که باید پیش از اسپرینت های بعدی اون ها رو تموم کنیم و بنابراین سرعت حرکت رو پایین میاره.از طرف دیگه، تعریف واضح انجام شده (DoD) یکی از مهمترین عناصر توسعه محصول چابک است. اگر هدف Agile ریلیس نرم افزارهای قابل استفاده هست، باید قبل از شروع به کار بدونیم که چطور به نظر میرسه. تعریف کار انجام شده باید در ابتدای پروژه توسط "تیم اسکرام" به بحث گذاشته شده باشه و مورد موافقت قرار گرفته باشه تا نسخه های افزایشی (فرآورده های) آتی قابل ریلیس باشن؛ در این جا "Done" میتونه معنی تمام شدن برنامه نویسی، تست کردن، استقرار، مستند سازی، و یا هر ترکیبی از این ها باشه.برای حرکت رو به جلوی تیم، رسیدن به اهداف، و انتشار نرم افزار قابل استفاده، ما نیاز داریم که به طور دقیق بدونیم کجای توسعه نرم افزار و همین طور کجای هدف مون هستیم. این همون جایی که "تعریف کار انجام شده" وارد بازی میشه.چرا از Acceptance Criteria به جای Definition of Done استفاده نکنیم؟تفاوت عمده ای که بین این دو تا هست اینه که AC برای هر User Story، Feature و یا Issue منحصر به فرد هست ولی DoD برای تمامی آن چه که تیم توسعه در یک اسپرینت باید ارایه کنه یکسان هست.تفاوت AC و DCمعمولا تعریف کار انجام شده (تکمیل شده) شامل اجزای زیر هست:فرآیند های توسعه (مثل برنامه نویسی، تست، و مستند سازی)فیچر های غیر عملکردی (مثل امنیت، قابلیت نگهداری، قابلیت توسعه)شرایط کیفی و شرایط پذیرشحالا با یه مثال ببینیم دنبال چی می گردیم (البته این مثال حداقل هایی هست که با بلوغ تیم توسعه و محصول میشه تقویتش کرد و برای رسیدن به محصول با کیفیت تر ازش بهره برد)؟Code is DocumentedUnit Test PassedCode ReviewedAcceptance criteria for each issue metFunctional tests passedNon-functional requirements metProduct owner accepts the User Storyبه طور معمول ما انتظار داریم که DoD از طرف سازمان ابلاغ شده باشه که این به عنوان حداقل هست و تیم توسعه میتونه مواردی رو بهش اضافه کنه تا اون رو برای پروژه مناسب تر کنه. اگه توی سازمان اصلا DoD وجود نداشته باشه کل موضوعات از سمت تیم توسعه مشخص میشه.افراد اغلب ایده های متفاوتی از آنچه باید انجام شود دارند، و واقعا این که بتونیم همه اعضای تیم رو روی این موضوع هماهنگ کنیم خیلی سخته، اما حتی دشوارتر از تصمیم گیری در مورد تعریف انجام شده، متعهد موندن افراد نسبت به قرارداد هست!برای ایجاد این تعهد باید همه اعضای تیم رو درگیر فرآیند تعیین تعریف کار انجام شده کنیم و بعد نیازمندی ها رو شفاف، قابل انجام، و همیشه در دسترس کنیم.شرکت های مختلف و تیم های توسعه تصمیم می گیرند که معنی "انجام شده" برای آنها چیه؟ با این حال، تو بیشتر موارد، "انجام شده" به همان قانون طلایی برمی گردد: کد آنچه را که باید انجام دهد انجام دهد و هیچ چیز دیگری را در این فرآیند نقض نکند.از اون جایی که تو مقاله قبلی هم راجع به این موضوع صحبت کرده بودم، تو این مقاله خواستم کمی بیشتر با هم در مورد اهمیت DoD و اجزای اون صحبت کنیم و امیدوارم که تونسته باشم برای درک بهتر این موضوع کمک کنم؛ در همین راستا از شما هم درخواست می کنم تا دیدگاه تون در این خصوص رو با من به اشتراک بزارین تا من هم بتونم به درک مناسب تری از مطلب برسم. علی نیک روش علی نیک روش Sun, 19 Sep 2021 00:22:49 +0430 https://virgool.io/@alin096/%D8%AA%D8%B9%D8%B1%DB%8C%D9%81-%DA%A9%D8%A7%D8%B1-%D8%A7%D9%86%D8%AC%D8%A7%D9%85-%D8%B4%D8%AF%D9%87-%DB%8C%D8%A7-dod-%D8%AF%D8%B1-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-u3uh76dgq2vk توی مقاله قبلی با عنوان "تیم خودسازماندهی شده از دید اسکرام" به DoD اشاره کرده بودم و قرار بود که درباره اون با هم بیشتر صحبت کنیم، بریم جلو ببینیم چی میشه . . .تا به حال شده یه کاری از دید خودتون تموم شده به نظر برسه ولی وقتی به مشتری نشون میدین بگه چیزی نیست که من میخواستم؟میدونیم اسکرام طبق تعریف خودش یه چارچوب سبک (Light Weight) ارایه داده و چون متدولوژی نیست، توی جزییات انجام کار کمتر وارد میشه و به اصطلاح نسخه نمیپیچه که همین کار باعث میشه هر کسی بخواد از منظر خودش تفسیری روی موضوعات داشته باشه و بنابراین با توجه به جایی که اسکرام در اون استفاده میشه و نفرات متفاوتی که دارن اون رو پیاده سازی می کنند بلوغ های متفاوتی خواهد داشت.به همین خاطر تو این نوشته سعی می کنم بررسی کنم از دید اسکرام برای رفع این موضوع چه چیزهایی پیش بینی شده و چه کار باید بکنیم تا این مشکل که خیلی وقت ها هم اتفاق میفته به حداقل برسه؟ میدونیم اسکرام بر مبنای پنج رویداد که شامل "اسپرینت پلنینگ، دیلی اسکرام، اسپرینت رویو، و رترو اسپکتیو" هست برنامه ریزی میشه. البته این ها رو که بشمریم میشه چهار تا، اون یکی کجاست؟- اولین و در حقیقت اصلی ترین اون ها که بقیه تو دل اون هستند در حقیقت همون اسپرینت هست و با اون، پنج رویدادی که گفتیم کامل میشه:پنج رویداد اسکرامبزارین از آخر بیایم اول؛ در اسپرینت رویو که توی اون دولوپر ها (تیم توسعه دهنده)، مالک محصول، مشتری ها و البته اسکرام مستر حضور دارن نتیجه تلاش تیم اسکرام در یک اسپرینت بررسی میشه (تمام فتنه ها و مشکلات تیم هم از همین جا شروع میشه :))جلسه اسپرینت رویو- خوب بیارین ببینیم چی کردین؟ خروجی دو هفته کارتون چی بوده؟ ما بی صبرانه منتظر این جلسه هستیم . . .خوب ما توی این اسپرینت داشتیم رو فیچر های A و B کار می کردیم و تونستیم فیچر A رو Done کنیم و حدود %70 فیچر B هم دان شده.-ببینیم . . .یک نفر از اعضای تیم محصول رو ارایه می کنه . . .-این چرا این جوریه؟ کی گفته بود این طوری تحویل بدین؟ آقای Product Owner ما به شما اعتماد کردیم، سرمایه گذاری کردیم و دو هفته وقت دادیم که آخرش این رو به ما تحویل بدین؟یعنی چی آقا، این که داره کار می کنه، مشکلش چیه؟-نه این چیزی نیست که میخواستیم. نه درست کار می کنه و نه مطابق طرحی بوده که بهتون گفته شده، فکر می کنیم باید در توانایی شما برای جمع کردن این پروژه تجدید نظر کنیم و شاید داریم جای نادرستی سرمایه گذاری می کنیم؟این گوشه ای از مکالمات در یک اسپرینت رویوی ناموفق بود که کم و بیش همه مون باهاش آشنایی داریم . . .[یادم باشه بعدا راجع به این که چطور اسپرینت رویوی موفقی داشته باشیم هم صحبت کنیم]حالا بریم سراغ اسکرام:اسکرام اولین چیزی رو که برای تیم اسکرام در چارچوب خودش پیشنهاد می کنه و حتی ضروری میدونه رعایت تایم باکس هایی هست که گفته برای یک اسپرینت حداکثر میتونه یک ماه باشه، یه جدول خوب براتون میزارم که نیاز به توضیح اضافی نباشه (درباره تایم باکس ها بعدا خیلی مفصل تر با هم صحبت خواهیم کرد):جدول تایم باکس های الزامی در اسکرامفرض کنیم یه تیم شش نفره دولوپری هستیم (دو تا بک اند، یه فرانت، دو تا اندروید و یه دیزاینر) که یه PO و یه اسکرام مستر هم داریم (تیم اسکرام هشت نفره) و یه اسپرینت دو هفته ای رو برنامه ریزی کردیم (هر نفر در طول هفته 44 ساعت باید کار کنه رندش می کنیم 40 ساعت، بنابراین در طول دو هفته یا نصف ماه 2*40*8 نفر ساعت 640 نفر ساعت کار انجام شده) و این زمان ارزش این رو داره که هر کاری کنیم تا نتیجه اش به بهترین نحو ارایه داده بشه و از اون طرف تیم بتونه برای اسپرینت بعدیش انرژی لازم رو کسب کنه.برای این که اسپرینت رویوی درستی داشته باشیم، تا نتیجه تلاش های یک تیم که بالا زمانش رو محاسبه کردیم و به میزان اهمیتش کم و بیش پی بردیم لازم هست که از اول درست برنامه ریزی کرده باشیم.کجا برنامه ریزی کردیم؟ تو اسپرینت پلنینگ.ورودی های ما چی بوده؟ Product BacklogDefinition of DoneRetrospective Improvements. . .ورودی ها و خروجی های اسپرینت پلنینگمیبینیم دومین ورودی ما برای برنامه ریزی اسپرینت مون "تعریف کار انجام شده" یا DoD هست و بنابراین یکی از ابزارهای مهم کارمون هست، چون برنامه ریزی از اون جا شروع میشه؛ حالا ببینیم اساسا DoD چیه؟وقتی بیان میشه یک PBI یا یک Increment تمام شده یا انجام شده (یا دان شده)، همه اعضای تیم اسکرام باید فهم مشترکی از این موضوع داشته باشن (که یکی از اجزای شفافیت یا Transparency در اسکرام هم هست که بعدا بهش خواهیم پرداخت). منظرهای تعریف کار انجام شدهاساس تعریف کار انجام شده برای رسیدن به کیفیت هست؛ یعنی ما با تعریف DoD داریم برای کار خودمون یه حد کیفی در نظر می گیریم بنابراین کارمون خیلی با ارزش هست. میدونیم که کیفیت چند بعدی هست (مثلا وقتی میگیم فلان لباس خوبه مجموعه عواملی مثل رنگ، جنس پارچه، دوخت، . . . و حتی یه وقت هایی با توجه به جایی که میخوایم ازش استفاده کنیم خوبیش یا همون کیفیتش سنجیده میشه) بنابراین لازمه که معیار های مختلفی برای کارمون در نظر بگیریم و تا به اون ها نرسیم یعنی کار مون دان نشده و هنوز کار داره، حتی اگه %99.999 هم انجام شده باشه.تعریف کار انجام شده (DoD)شرایط مشخص شده کار انجام شده به تیم توسعه کمک می کنه بتونن در رویداد اسپرینت پلنینگ پیش بینی بهتری برای کارشون داشته باشن.تعریف کار انجام شده شفافیت ایجاد می کنه و بنابراین بازرسی و سازگاری که ستون های اسکرام هستن رو تسهیل می کنه.تعریف کار انجام شده "فهم مشترکی از یه نرم افزار قابل ریلیس ایجاد می کنه" و "به دولوپر ها برای این که چه مقدار از PBI ها رو میتونن برای یه اسپرینت در نظر بگیرن هم کمک می کنه"حتی نیازمندی های غیر عملکردی (nonfunctional requirements) رو هم میشه به DoD اضافه کرد.یه تیم اسکرام بالغ دنبال فرصت میگرده تا بتونه همیشه تعریف کار انجام شده خودش رو بهبود و ارتقا بده.یه DoD خوب، میتونه به کاهش زمان پایدار کردن ریلیس ها، هزینه های کلی مالکیت (TCO)، و کاهش بدهی های فنی (Technical Debt) کمک کنه.متعهد نبودن به DoD توسط تیم توسعه، به طور معمول باعث افزایش بدهی های فنی میشه چون تیم بر مبنای پیش فرض های خودش جلو میره و بعد اون اتفاقی که توی اسپرینت رویو اول این مقاله مثال زدم رخ میده؛ همین طور باعث تشدید نارضایتی مشتری میشه.تعریف کار انجام شده همه اون چیزی هست که تیم توسعه برای دان کردن PBI ها روی اون به توافق میرسن به اضافه Acceptance Criteria برای هر PBI برای اطمینان از این که محصول افزایشی قابل ریلیس از کیفیت خوبی برخوردار هست.تعریف کار انجام شده با بلوغ تیم توسعه نرم افزار به طور تدریجی تکامل می یابد.و اما بریم سراغ این که چه کسی DoD رو ایجاد می کنه و چه حالت هایی داره؟تعریف کار انجام شده توسط تیم توسعه خلق میشه و در مالکیت اون ها هست؛ اما اگر سازمان انتظارات مشخص و ویژه ای از کیفیت داشته باشه، تیم توسعه باید از اون آگاه باشه (یعنی تیم توسعه باید در راستای برآورده شدن و تحقق اون گام برداره)؛ همون طور که کمی بالاتر به این موضوع پرداختیم، به تدریج باید تمام معیار های مشخص شده کیفی سازمان توسط دولوپر ها تحقق پیدا کنه و همین طور تیم توسعه منسجم تر و ماهر تر میشن به کیفیت کارشون هم اضافه می کنن (یعنی DoD خودشون رو تقویت و سختگیرانه تر می کنن).طبیعی هست که هر چه DoD ساده تر باشه، کیفیت کار رو پایین تر میاره و کمیت کار رو می تونه افزایش بده.توصیه اکید می کنم که DoD نوشته بشه و در دسترس همه و جلوی چشم شون باشه تا هر کسی بدونه که معنی کار انجام شده چی هست و کارش رو تا چه حدی باید بهبود بده.تیم هایی که دارن روی یک پروژه کار می کنن (Scale Scrum)، علاوه بر این که باید خودشون DoD داشته باشن، باید از یک DoD مشترک هم استفاده کنن تا خروجی های اسپرینت شون یک دست باشه.از اون جایی که این مقاله کمی طولانی شد سعی می کنم توی مقاله بعدی که در همین خصوص مینویسم به اجزای DoD با ارایه مثال بپردازم؛ امیدوارم مطالب گفته شده براتون مفید بوده باشه و بی صبرانه منتظرم تا ایده و دیدگاه های ارزشمندتون رو در خصوص این مطالب تو کامنت ها بزارین تا من هم بتونم درک خودم از مسایل اسکرام رو بهبود بدم. علی نیک روش علی نیک روش Sun, 12 Sep 2021 01:11:05 +0430 https://virgool.io/@alin096/%D8%AA%DB%8C%D9%85-%D8%AE%D9%88%D8%AF-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86%D8%AF%D9%87%DB%8C-%D8%B4%D8%AF%D9%87-%D8%A7%D8%B2-%D8%AF%DB%8C%D8%AF-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-nmyramchp3ph توی شرکت ها و تیم هایی که با هاشون تا به حال کار کردم، و همین طور بین چیز هایی که بعضا از اسکرام مستر ها و یا حتی اجایل کوچ ها و . . . شنیدم خیلی وقت ها به این نکته اشاره شده که تیم ها رو باید راحت گذاشت تا خودشون کار ها رو انجام بدن و به اصطلاح Self-organize هستن. از طرفی خیلی وقت ها میبینیم که تیم ها مشکلات زیادی دارن و عملا نمیتونن به تعهدات خودشون توی چارچوب های زمانی که بهشون اسپرینت میگیم برسن. به همین خاطر اول از همه میخوایم با هم ببینیم که مراجع اصلی اسکرام چه دیدگاهی در این خصوص دارن و بعد از اون ببینیم که چه راه حل هایی برای رفع مشکلات تیم ها برای رسیدن به تیم های خود سازماندهی شده وجود داره.تیم اسکراماولین چیزی که برای این موضوع باید بهش توجه کنیم معنی خود تیم از دیدگاه اسکرام هست؛ «تیم اسکرام» از از سه نقش اصلی تشکیل شده: مالک محصول (Product Owner)اسکرام مستر (Scrum Master)تیم توسعه (Development Team) که در راهنمای اسکرام 2020 ساده ترش کرده و بهش توسعه دهندگان (Developers) گفته میشه.همون طور که میدونیم، اسکرام مستر وظیفه خدمت رسانی به تیم توسعه و مالک محصول رو داره، تیم توسعه وظیفه سرویس دهی به مالک محصول رو داره، و مالک محصول هم باید به ذی نفعان خدمت رسانی کنه.با توجه به تعریف، اسکوپ کار و منظور ما «تیم توسعه» هست؛ بنابراین، خوبه که اول بدونیم تیم توسعه باید چه ویژگی هایی داشته باشه و یا به عبارتی از پس چه مسوولیت هایی به خوبی بر بیاد که چند تا از مهمترین شون رو براتون میزارم: تیم توسعه به صورت خود سازماندهی شده و خود مدیریت شده (Self-organized & Self-managed) کارش رو برای اسپرینت انجام میده و به تنهایی مسوول تحویل یک فرآورده محصول (Product Increment) در پایان هر اسپرینت هست که در این راه مالک محصول از طریق مرتب سازی بک لاگ های محصول و اسکرام مستر هم از طریق پایش درست انجام شدن فرآیند اسکرام به تیم توسعه در این مسوولیت (خطیر!) کمک می کنند.تیم توسعه مسوول تحقق «کیفیت» محصول منطبق با «تعریف کار انجام شده» یا همون DoD در انتهای هر اسپرینت هست (به دعوای این که چه کسی DoD رو باید تهیه کنه توی یه مطلب جداگانه رسیدگی می کنیم!).تیم توسعه باید بتونه هر تعارض درون تیمی رو حل کنه، یعنی اعضای تیم باید «مدیریت تعارض» رو یاد بگیرن (البته اگه لازم شد میتونه کمک اسکرام مستر های خوب رو هم برای رفع مشکلاتش بپذیره)؛ سازمان ها و HR های مهربون هم اینجا می تونن از طریق برگزاری دوره های آموزشی مدیریت تعارض به کاهش مشکلات تیم ها کمک کنند.تیم توسعه «تعیین می کنند» در هر اسپرینت کار چگونه باید انجام بشه (دید فنی و تخصصی)؛ همین طور تخمین زمانی انجام کار روی PBI ها هم با خودشون هست (که در این راه مالک محصول از طریق تشریح کار میتونه به تیم توسعه برای رسیدن به تخمین درست تر کمک کنه).. . .و اما برسیم به دو ساختار اصلی «تیم توسعه» در اسکرام که دومیش «کامپوننت بیس» هست، ولی آن چه که مرسوم تر هست و معمولا در شرکت ها و سازمان ها دیده میشه تیم های «فرا وظیفه ای یا کراس فانکشنال (Cross Functional)» هستند که از ظرفیت های سه تا نه نفر تشکیل میشن و هر تیم باید بتونه تمامی عملکرد های مورد نیاز یه محصول رو در هر اسپرینت پوشش بده؛ بنابراین، افراد اون تیم ها هم باید Cross-Skilled باشن (یعنی توی این تیم ها افرادی موفق تر هستن که علاوه بر داشتن تخصص در یک بخش مثل بک اند، از سایر بخش ها هم سر در بیارن و به اصطلاح فول استک باشن؛ بماند که اینجا سافت اسکیل ها هم میتونه خیلی بهمون به عنوان اعضای تیم توسعه کمک کنه که اسکرام سعی می کنه به اون ها هم در رویداد های پنج گانه خودش نیم نگاهی داشته باشه و من هم در مقالات بعدی بهشون خواهم پرداخت).این موضوعات ادامه داره، اما نکاتی که بسیار مهم هست و در کتاب (Scrum Insights for Practitioners) از آقای Hiren Doshi که یکی از منابع اصلی آزمون های اسکرام هست بیان شده رو با هم مرور می کنیم تا با ایجاد چند سوال و پاسخ اون ها بفهمیم منظور دقیق تر اسکرام در این خصوص چیه . . .اسکرم مسترپرسش اول: اسکرام چطور میتونه خود سازماندهی رو ترویج کنه؟در پاسخ به این پرسش سه موضوع مطرح میشه: اسکرام یه چارچوب سبکه که از: سه نقش، پنج رویداد، و سه خروجی اصلی تشکیل شده.با برداشتن عناوین از اعضای تیم توسعه، که همه رو در یک سطح می بینه و بینشون سلسله مراتبی وجود نداره.با توانمند سازی تیم توسعه و تعیین بهترین روش برای انجام کارش.در این راستا خوبه که بدونیم خود سازماندهی تقویت کننده «خلاقیت، مسوولیت پذیری، و تعهد افراد» برای رسیدن به اهداف تیم اسکرام هست.همون طور که میدونیم خود سازماندهی چیزی نیست که بشه به تیم تحمیل کرد و در حقیقت افراد تیم باید بتونن به اون بلوغ برسن.تو صفحه 61 همون کتاب میگه که خود سازماندهی به معنای یک فضای باز نیست که اعضای تیم توسعه بتونن هر چیزی که دوست دارن رو انجام بدن. خود سازماندهی با گذاشتن مرزهای واضح و روشن برای این که هر کدوم از "اعضای توانمند" تیم باید بتونن کار خودشون رو سازماندهی کنن اتفاق میفته.بعضی فاکتور ها که خود سازماندهی رو ترویج می کنه رو با هم مرور کنیم:اطمینان: افراد تیم باید بتونن به همدیگه اعتماد کنن، آزادانه صحبت کنن، به بینش لازم برای انجام کار دست پیدا کنن، و بتونن با هم مشارکت کنند.چارچوب زمانی (Time-Boxing): این قاعده اسکرام به تمرکز و مدیریت ریسک ها کمک می کنه.ثابت بودن طول اسپرینت: این فاکتور کمک می کنه خروجی مستمر ارزش کسب و کار در هر تایم باکس اسپرینت تحویل بشه.بهینه بودن اندازه تیم توسعه: یک تیم سه تا نه نفره چند تخصصی بر اساس راهنمای اسکرام کمک می کنه پیچیدگی های غیر ضروری و ارتباطات اضافی از بین بره.تعریف کار انجام شده (Definition of Done): ایجاد شفافیت برای کار قابل قبول انجام شده که باعث می شود تمام افراد تیم نسبت به تعریف کار انجام شده به نظر مشترکی برسند.ارزش های اسکرام: ارزش های اسکرام شامل "شجاعت، تمرکز، تعهد، احترام، و گشودگی" هستن و باید به گونه ای در افراد نهادینه بشه که باهاش زندگی کنن.پرسش دوم: بعضی نشانه های تیم خود سازماندهی شده چیست؟اعضای تیم توسعه با اشتیاق و میل بالا در حین اسپرینت برای انتخاب کارشون مشارکت می کنن و در صورت نیاز براش برنامه ریزی مجدد می کنند (میتونه یکی از خروجی های دیلی شون باشه).برای تحقق DoD تمام تلاش شون رو میکنن.خودشون نسبت به این که چطور PBI ها رو به فرآورده های قابل ریلیس تبدیل کنن مسوول هستن و نیاز ندارن کسی بهشون بگه که چطور باید این کار رو انجام بدن.پرسش سوم: تایم باکس چطور به خود سازمانده شدن تیم اسکرام کمک می کند؟Time-Boxing!چارچوب های زمانی کمک می کنه هر یک از افراد روی هدف اسپرینت با یک هدف مشترک که ساخت یک نسخه افزایشی قابل ریلیس متعهد به DoD در پایان هر اسپرینت هست هم راستا و متمرکز شوند.چارچوب های زمانی مشوق اعضای تیم توسعه هستند که تمرکز شون رو روی حل مشکلات کاری که دست گرفتن بزارن تا بهترین دستاورد رو در زمان اختصاص داده شده و در زمینه کار مشخص شده خلق کنند.تایم باکس ها مانند گارد ریل های کنار جاده هستند که امنیت تیم رو از طریق محدود کردن ریسک فراهم می کنن.سخن آخربا توجه به مطالبی که مطرح شد میشه گفت تیم های خود سازماندهی شده (البته در نسخه 2020 اسکرام پا فراتر گذاشته شده و تبدیل به تیم های خود مدیریتی شده که بعدا درباره اون هم صحبت خواهیم کرد) چند ویژگی اصلی رو نیاز دارن تا به شرایط مطلوب برسن: از نظر اندازه کوچک هستند.حرفه ای هستند (هم دانشی، هم مهارتی و هم رفتاری)کراس فانکشنال یا فرا وظیفه ای هستند تا بتونن خودشون از پس تمامی موضوعات فنی در هر اسپرینت بر بیان.باید بتونن تصمیم بگیرن توی تیم شون «چه کسی؟ چه کاری رو؟ در چه زمانی؟» انجام بده.به DoD متعهد هستن.به چارچوب های زمانی اسکرام متعهد هستن (زمان و مسوولیت براشون اهمیت داره)اشتیاق لازم برای انجام کار و به پایان رسوندن اون رو دارن.بنابراین، هر جا که این افراد رو دیدین قدرشون رو بدونین و مطمئن باشین که کارهاتون به درستی پیش خواهد رفت.از طرفی اگه تیمی این ویژگی ها رو نداشته باشه شاید بتونیم از راه های مختلف مثل آموزش سافت اسکیل های مرتبط با رفتار های تیمی، استفاده از مربی و منتوری که هم به کار تیمی اشراف داشته باشه و هم به اسکرام، ... و یا حتی در صورت نیاز بهینه کردن ترکیب تیم نسبت به تقویت اون ها اقدام کنیم.امیدوارم مطالب گفته شده براتون مفید بوده باشه و بی صبرانه منتظرم تا ایده ها و دیدگاه های ارزشمندتون رو در خصوص این مطالب تو کامنت ها بزارین تا من هم بتونم درک خودم از مسایل اسکرام رو بهبود بدم. علی نیک روش علی نیک روش Fri, 03 Sep 2021 23:28:32 +0430