[TOC] ###ماهیت انجام کارهای فنی اگر تاکنون تجربه پشتیبانی فنی به صورت 24 ساعته در 2 روز هفته را داشته‌اید، پس احتمالا برداشت درستی از داشتن مسئولیت در محیط محصول دارید؛ از شما انتظار می‌رود تا شرایط را در نیمه شب، فارغ از اینکه مقصر هستید یا خیر، تحت کنترل داشته باشید. هیچ‌‌کس نمی‌داند (مشکل چیست)، برای همین است که شما را صدا میکنند. این مسئله کمی چالش‌برانگیز است چرا که شما تولیدکننده آن سخت‌افزار، درایورها، سیستم عامل و یا نرم افزار سفارشی نبوده‌‌‌‌‌اید. گزینه‌هایتان معمولا محدود به نزدیک‌شدن به مشکل اصلی، کاستن عوارض، جمع‌‌‌‌آوری شواهد جهت بازسازی مشکل و منتظر ماندن برای فردی است که مشکل ایجاد کرده است تا موفق به تولید مجدد یا حل مشکلی که مشاهده کردید شوید. برای پشتیبان‌‌های فنی، هم سرعت و دقت در پاسخگویی و هم قدرت حل مسئله کلیدی هستند. <p> </p> <br> ###چرا تغییر؟ در سال 2008 یک شرکت بازیسازی اسکاندیناویایی، اقدام به انجام یک سری بهبودهای کلی نمود. یکی از آن کارها عبارت بود از استفاده از اسکرام و حل پاره‌ای از مشکلاتی که تیم پیادهساز را در تحویل به موقع محصول دچار مشکل کرده بود. با افزایش چرخش کار و بازدهی، فشار روی تیم پشتیبان هم افزایش چشم‌‌‌‌‌‌‌‌‌گیری یافت. پیش از این، تیم پشتیبان، معمولا تنها نظاره‌‌‌‌‌‌گر بودند، اما اکنون آنها به عنوان یک بخش فعال در قسمت پیادهسازی درگیر شده بودند.  شکل 1. ساختار پشتیبان فنی شامل سه تیم است: مدیران پایگاه داده (DBAs)، مدیران سیستم (System Admins) و پشتیبان‌‌های لایه دوم (Second Line Support) در نتیجه، فقط کمک به تیم پیادهساز کافی نبود. با تمرکز بر تیم پیادهساز، در بحث ارتقای زیرساختها که توسط تیم پشتیبان صورت میگرفت تأخیر زیادی اتفاق می‌افتاد. پس بهبود در هر دو زمینه نیاز بود. بعلاوه، پیشرفت در تیم پیادهسازی به این معنی بود که از مدیران خواسته میشد تا به تحلیل کمک کرده و اقدام به بیان بازخور بیشتر نمایند، در نتیجه آنها وقت کمتری برای اولویت‌بندی کارها و حل مشکلات داشتند. تیم مدیریت متوجه شد که نیاز دارند تا قبل از اینکه اوضاع غیرقابل مدیریت شود اقدامی صورت دهند. <p> </p> <br> ###از کجا شروع کنیم؟ پرسیدن این سؤال از تیم پیادهسازان که «چه کسی مشتری افراد فنی عملیاتیسازی است؟» میتواند شروع خوبی باشد. **دیدگاه پیادهسازان درباره عملیاتیسازی** - «سیستم گردش کاری آنها افتضاح است.» - «تخصص‌های متفاوت» - «اونها واقعا چکار میکنند؟» - «خیلی حیاتی وقتی پای زیرساخت باز میشود.» - «کلی ایمیل لازم است تا یک کار ساده انجام پذیرد.» - «اونها دلشون می‌خواد کمک کنند اما کمک کردن کار آسانی نیست.» - «ارتباط با آنها سخت است» - «پروژهها خیلی طولانی خواهند شد.» جملات بالا برخی از نظرات افراد پیادهساز درباره عملیاتیسازی بود. اکنون، اجازه دهید تا دیدگاه عملیاتی‌سازان درباره پیادهسازان را هم بدانیم: **دیدگاه عملیاتی‌سازان درباره پیادهسازان**  - «چرا از مزایای پلتفرم موجود استفاده نمی‌‌کنید؟» - «بیایید منتشرسازی را کمی سبک‌تر کنیم!» - «ما بخاطر کیفیت بد کاری شما اذیت می‌‌شویم!» «آنها باید تغییر کنند» راه‌‌‌حلی بود که از جانب هر دو طرف مطرح میشد. مشخصا اگر بخواهیم مشکلات را برطرف کنیم نیاز است این طرز فکر اصلاح شود. با دیدی مثبت، جمله «خیلی حیاتی وقتی پای زیرساخت باز میشود.» (نشانه حقیقی بودن و التزام مساله) میتواند مشکل «ما در مقابل آنها» را با فراهمآوری محیط و بستر مناسب حل نماید. حذف کردن اضافه کار و تمرکز بر کیفیت یکی از گزینه‌های مناسب بود. <p> </p> <br> ###چطور ادامه دهیم؟ در هر صورت باید به مسیر ادامه میدادند، اما نقطه شروع مهم بود. نیاز به شروع طوفانی و تغییر همه‌چیز نبود، بلکه نیاز به یک روش ملایم‌‌‌‌‌‌‌تر بود که موارد نامربوط را دور نگه دارد و موضوعات مرتبط را به آسانی یاد بدهد. کاندیداها عبارت بودند از: 1. اسکرام- این برای تیم پیادهسازان به خوبی جواب داده بود. 1. کانبان- جدید و تست نشده، اما سازگار با مفاهیم Lean که کمبودش احساس میشد. از نظر مدیران، مفاهیم کانبان و Lean سازگاری زیادی با مشکلات جاری داشت. از دید آنها اسپرینت خیلی منطبق با نیازهایشان نبود چرا که به صورت روزانه اولویت‌ها را تغییر میدادند. بنابراین کانبان یک شروع منطقی بود، هرچند که موجود جدیدی برای همه بود. <p> </p> <br> ###نحوه راه‌اندازی تیمها تیمها چطور تشکیل میشوند؟ هیچ قانون نوشته‌‌‌‌‌‌‌شده‌‌‌‌‌‌ای درباره چگونگی تشکیل تیم وجود ندارد. اشتباه انجام‌دادن آن هم ریسک بسیار بالایی دارد، به جز جلوگیری از بهبود، با پلتفرم تولید سروکار داشتند که دارای نیروهای خبره و فنی بود و پیدا کردن جایگزین برای آنها دشوار بود، همچنین منتقل‌کردن آنها ایده بسیار بدی بود. - آیا باید به راهشان ادامه میدادند و با اتفاقات احتمالی برخورد می‌کردند؟ - یا نیاز بود تا ابتدا یک کارگروه برگزار کنند؟ واضح بود که ابتدا باید کارگروه برگزار می‌کردند، اما چگونه؟ جمع کردن تمام افراد تیم عملیاتیسازی در یک کارگروه دشوار بود. (اگر یک نفر تماس میگرفت چه کسی پاسخگو بود؟) نهایتا یک کارگروه نصفه روزه برگزار کردند و آن را ساده و بر اساس تمرین اجرا کردند. **کارگروه** یکی از مزایای کارگروه، شناسایی به موقع مشکلات بود. ضمن اینکه محیطی را فراهم می‌کرد تا در فضایی قابل اعتماد، مفاهیم بطور مستقیم با مدیران در میان گذاشته شوند. اگرچه همه افراد از تغییر روال کاری راضی نبودند اما اکثر افراد تیم تمایل به انجام آن داشتند. بنابراین در یک کارگروه اکثر مفاهیم مهم کانبان برای آنها شبیه‌سازی شد.  <p> </p> <br> ###توجه به ذی‌نفعان ممکن بود کانبان روی ذی‌نفعان هم تأثیر بگذارد. اگرچه این تغییر باعث بهبود بود، یعنی تیم به کارهایی که نمی‌تواند انجام دهد «نه» بگوید، از کیفیت طرفداری کرده و کارهای با اولویت پایین را از مخزن کار خود خارج نماید. نزدیک‌ترین ذی‌نفعان، تیم خط اول پشتیبانی و مدیران دپارتمان‌ها بودند. چون آنها در کارگروه شرکت کرده بودند از قبل دید مثبتی به کانبان داشتند. همین‌طور برای پیادهسازان (که به نوعی انتظار بهبود داشتند) اما، برای یک تیم پشتیبانی، قضیه فرق می‌کرد. مشکل اصلی آنها، کار بیش از حد بود. همچنین، آنها مسئول مشکلات مشتریان بودند و شرکت تعهد داده بود تا به همه مشکلات رسیدگی نماید. ولی اگر فعالیت‌های در حال انجام محدود میشد قضیه فرق می‌کرد. دیدار با ذی‌نفعان اصلی باعث شد هدف، انتظارات و مشکلات احتمالی آنها مطرح و بررسی شود. ایده‌ها به خوبی به آنها منتقل شد و گهگاهی با نظراتی مثل «اگر این مسائل را به دیگران واگذار می‌کردیم عالی میشد» همراه بود. <p> </p> <br> ###ساختن اولین بورد یک روش خوب برای ساختن بورد استفاده از نقشه مدل-ارزش است. این نقشه اصولا زنجیره ارزش است که بصورت بصری به نمایش درآمده است و تصویر خوبی از حالت‌های فعالیت‌ها، گردش و همچنین زمانبندی آنها در سیستم ارائه می‌دهد.  اما به روش ساده‌تری کار شروع شد. یک بورد کانبان ساده که با کمک مدیران بر روی کاغذ کشیده شد، چندین بار آن را بررسی کرده و سپس شروع بکار کردند، سوالاتی که در این فاز مطرح بود شامل: - چه نوع کارهایی برای انجام داریم؟ - چه کسی آن را انجام می‌دهد؟ - آیا باید مسئولیت‌ها را بین کارهای مختلف به اشتراک بگذاریم؟ - چطور مسئولیت‌های اشتراکی را که نیازمند تخصص خاصی هستند مدیریت و اجرا می‌کنیم؟ از آنجا که هر کاری دارای توافقنامه سطح سرویس (SLA) متفاوت است، طبیعی است که هر تیم بورد خود را طراحی کند. آنها سطرها و ستون‌ها را خود طراحی کردند. تصمیم بزرگ بعدی این بود که آیا از مسئولیت‌های اشتراکی استفاده کنند یا خیر. «آیا باید به قسمتی از تیم اجازه میدادند تا به مسائل مربوط به سوالات (کارهای واکنشی) پرداخته و بقیه تیم مسئولیت کارهای پروژه (کارهای فعال) را بعهده گیرد؟» ابتدا تصمیم گرفتند از مسئولیت اشتراکی استفاده کنند. چون خودمدیریتی و آموزش مداوم و انتقال دانش برای اعضای تیم امری حیاتی به منظور تقویت گسترش بود. نقطه منفی این تصمیم، پتانسیل‌های محتمل برای مختل کردن همه افراد بود. این بهترین تصمیم برای شروع بود. یک نکته کوچک: وقتی کارگروه شروع شد، تیمها خودشان این مسئله را مدیریت کردند. آنها اجازه دادند یک نفر به درخواست‌های اضطراری جواب دهد و دیگران به مسائل بزرگتر بپردازند. **اولین مدل کانبان** اساس مدلی که برای کانبان استفاده شده در زیر نشان داده شده است. دقت کنید که تیم تصمیم گرفته تا جریان کاری را از پایین به بالا (مثل حباب‌های آب) مدل کند، بجای اینکه آنها را از چپ به راست نمایش دهد.  شکل 2. این اولین مدل از تخته کانبان است. اولویت‌ها از چپ به راست و جریان کاری از پایین به بالا حرکت خواهند کرد. تعداد فعالیت‌های در حال انجام معادل حاصل جمع فعالیت‌ها در سطر «در حال انجام» است (دایره مشکی). این مدل تحت تاثیر تجربیات گزارش شده توسط لیندا کوک طراحی شده است.  شکل 3. اولین بورد کانبان برای تیم راهبری ردیف‌های استفاده شده: <table style="border-collapse: collapse; width: 100%; height: 380px;" border="1"> <tbody> <tr style="height: 18px;"> <th style="width: 50%; height: 18px;"><strong>چطور آن را تعریف کردند؟</strong></th> <th style="width: 50%; height: 18px;"><strong>وضعیت فعالیت (ردیف)</strong></th> </tr> <tr style="height: 100px;"> <td style="width: 50%; height: 100px;">Storiesهایی که مدیر تشخیص داد به آنها نیاز است.</td> <td style="width: 50%; height: 100px;">مخزن کارهای محصول</td> </tr> <tr style="height: 18px;"> <td style="width: 50%; height: 18px;">Storiesهایی که تخمین زده شده‌اند و به کارهای کوچکتر و حداکثر 8 ساعته تقسیم شده‌اند.</td> <td style="width: 50%; height: 18px;">در انتظار انجام</td> </tr> <tr style="height: 18px;"> <td style="width: 50%; height: 18px;">ردیفی که محدودیت تعداد فعالیت در حال انجام داشت. با فرمول: 2 ضربدر تعداد نفرات تیم منهای 1 شروع کردند. (منهای 1 برای ارتباطات لحاظ شده است.) بنابراین یک تیم 4 نفره، محدودیت 7 را برای فعالیت‌های در حال اجرا داشت.</td> <td style="width: 50%; height: 18px;">در حال انجام</td> </tr> <tr style="height: 18px;"> <td style="width: 50%; height: 18px;">قابل اجرا توسط کاربر</td> <td style="width: 50%; height: 18px;">تمام شده</td> </tr> </tbody> </table> ستون‌های استفاده شده: <table style="border-collapse: collapse; width: 100%; height: 64px;" border="1"> <tbody> <tr style="height: 18px;"> <th style="width: 50%; height: 18px;"><strong>چطور آن را تعریف کردند؟</strong></th> <th style="width: 50%; height: 18px;"><strong>نوع کار</strong></th> </tr> <tr style="height: 18px;"> <td style="width: 50%; height: 18px;">کمک کردن به تیم پیادهساز برای منتشرسازی نرم‌افزار</td> <td style="width: 50%; height: 18px;">منتشرسازی</td> </tr> <tr style="height: 18px;"> <td style="width: 50%; height: 18px;">درخواست‌های کوچکتر از طرف تیم‌های دیگر</td> <td style="width: 50%; height: 18px;">پشتیبانی</td> </tr> <tr style="height: 10px;"> <td style="width: 50%; height: 10px;">کارهای پیش‌بینی نشده که نیاز است انجام شود اما مسئول مشخصی ندارد مثلا تقویت جزئی زیرساختها</td> <td style="width: 50%; height: 10px;">برنامه‌ریزی نشده</td> </tr> <tr> <td style="width: 50%;">پروژه‌ای بزرگتر مثلا تعویض سخت افزار یکی از سایتهای زیرساختی</td> <td style="width: 50%;">پروژه الف</td> </tr> <tr> <td style="width: 50%;">یک پروژه بزرگ دیگر</td> <td style="width: 50%;">پروژه ب</td> </tr> </tbody> </table> همه بوردهای کانبان یک شکل نیستند. همگی از یک نسخه ساده اولیه شروع شده و به مرور تکمیل میشوند. <p> </p> <br> ###تعیین نخستین سقف برای تعداد فعالیت در حال انجام اولین محدودیت تعداد فعالیت‌های در حال انجام خیلی کلی بود. با این استدلال که با ترسیم گردش (کار) می‌توان فهمید که چه اتفاقی افتاده است و احتمال حدس بهترین محدوده برای شروع کم خواهد بود. با گذر زمان، می‌توان تعداد فعالیت‌های در حال انجام را هر وقت که دلیل خوبی پیدا شد تنظیم نمود (تنها کار لازم نوشتن آن روی بورد بود). اولین محدودیتی که استفاده کردند 2n-1 بود (n تعداد افراد تیم و منهای یک تشویق برای تعاملات و ارتباطات لحاظ شد) چرا؟ واضح است، ایده بهتری نداشتند! بعلاوه اینکه برای شروع نظر بدی هم نبود. این فرمول یک توضیح ساده و منطقی برای هرکس که می‌خواست کار برای تیم تعریف کند ارائه می‌داد: «... با توجه به اینکه هر فرد میتواند نهایتا روی 2 کار فعالیت کند، یکی در حال انجام و دیگری در انتظار انجام. پس چرا شما انتظار دارید که آنها یک کار دیگر هم بکنند؟» با توجه به مطالب قبل هر محدودیتی می‌توانست برای شروع کار مناسب باشد. با نگاه کردن به بورد کانبان، می‌توان براحتی فهمید که باید محدودیت چقدر باشد.  شکل 4. نحوه محدود کردن فعالیت‌های در حال انجام برای مدیران پایگاه داده و تیم مدیریت سیستم، یک محدودیت برای هر نوع کار. طبق مشاهدات معلوم شد تعریف محدودیت برایstory points ها بیهوده است و کنترل و رصد آن بسیار سخت است. تنها محدودیتی که رصد آن مشکل‌ساز نبود تعداد فعالیت‌های تعریف شده برای هر فرد است= (فعالیت‌های موازی). برای تیم پشتیبانی از ستون برای «تعداد» فعالیت‌های در حال انجام استفاده شد، چون نیاز به سرعت پاسخگویی بالا با تنظیم بد محدودیت حاصل نمی‌شد. <p> </p> <br> ###توجه به سقف تعداد فعالیت در حال انجام با اینکه پیروی از محدودیت در تعداد فعالیت‌های در حال انجام، امری آسان به نظر می‌آید اما پایبندی به آن در واقعیت کار سختی است. این کار معادل آن است که در بعضی مواقع «نه» بگوییم اما روش‌های مختلفی را برای به ثمر رساندن آن امتحان کردیم. **مذاکره در پای بورد** اگر تخلفی صورت میگرفت، از ذینفع درخواست می‌کردند تا پای بورد بیاید و از خواسته‌هایش بگوید. در ابتدا این تخلفات بخاطر بی‌تجربگی بود. گاهی هم مواردی از اختلاف دیدگاه بر سر اولویت‌بندی مشاهده میشد، یک نمونه استثنایی از تجربه اصطکاک و اختلاف، یک فرد خبره بود که در یک حوزه تخصصی کار می‌کرد، در اکثر مواقع مشکلات با بحث در پای بورد حل میشد. **اختصاص یک بخش «سرریز»** اگر گفتن «نه» خیلی جنجال‌برانگیز بود و جابجایی فعالیت‌ها (از روی بورد) سخت بود، برای مقابله با مشکل، زمانی که محدودیت برای انجام فعالیت جدید وجود داشت، فعالیت‌های کم‌اولویت را به بخش «سرریز» منتقل می‌کردند. دو قانون بر فعالیت‌های سرریزشده حاکم بود: 1. آنها فراموش نمی‌شوند. هر وقت زمان داشتیم به سراغ آنها خواهیم رفت. 1. اگر قرار بر حذف آنها شد، شما را (ذینفع) در جریان قرار خواهیم داد. تنها بعد از دو هفته، به وضوح مشخص بود که با کمک مدیران دیگر نیازی به بخش سرریز نیست.  شکل 5. یک نسخه از بورد کانبان برای تیم پشتیبانی. قسمت سرریز در بخش راست بورد مشخص است. <p> </p> <br> ###کدام فعالیت روی بورد قرار گیرد؟ در ابتدا تمامی کارهایی که توسط تیم انجام میشد روی بورد قرار نگرفت، رصد مواردی مثل پاسخگویی به تلفن و نوشیدن قهوه، بورد را به یک غول فعالیت‌های اداری تبدیل می‌کرد. باید مشکلات موجود حل میشد نه اینکه مشکل جدید اضافه شود. بنابراین تصمیم گرفتند هر فعالیتی که بیشتر از 1 ساعت زمان می‌برد روی بورد قرار داده و موارد کوتاه‌تر را «نویز سفید» تلقی کنند. محدودیت یک ساعت، یکی از مواردی بود که بسیار خوب جواب داد و تغییر داده نشد. (این فرضیه که «نویز سفید» چه عواقبی میتواند داشته باشد، بعدا ویرایش شد»  شکل 6. با این فرض کار شروع شد که اکثر ظرفیت توسط دو نوع کار مصرف میشد: کارهای بزرگ (مربوط به پروژه) و کوچک (پشتیبانی). رصد کردن سرعت پروژه این امکان را می‌دهد که بتوان زمان تحویل محصول را تشخیص داد. «نویز سفید» از مسائلی است که همیشه وجود آن انتظار می‌رود. <p> </p> <br> ###چگونه تخمین بزنیم؟ این موضوعی است که همچنان درباره آن صحبت میشود و قطعا بیش از یک جواب برایش وجود دارد: - به صورت دوره‌ای تخمین بزنید. - وقتی نیاز است تخمین بزنید. - از ideal days-story برای تخمین استفاده کنید. - تخمین مطمئن نیست، از سایز استفاده کنید (کوچک، متوسط، بزرگ) - تخمین نزنید، یا فقط زمانی این کار را انجام دهید که هزینه‌ای برای تاخیر وجود دارد. کمی متاثر از اسکرام، تصمیم گرفتند تا با story point شروع کنند. اما در عمل، افراد تیم story point را معادل نفر - ساعت در نظر گرفتند. (این برای آنها طبیعی‌تر به نظر می‌آمد.) در ابتدا تمامstory ها تخمین زده شد. به مرور زمان مدیران یاد گرفتند اگر تعداد پروژه‌های همزمان را کم نگه دارند، ذی‌نفعان خیلی منتظر نخواهند ماند. آنها همچنین یاد گرفتند که در صورت بروز تغییرات، می‌توانند اولویت‌بندی را جابجا کرده تا مشکل را حل نمایند. نیاز به تخمین زدن درباره زمان تحویل محصول، دیگر مشکل مهمی نبود. این باعث شد تا مدیران کمتر در باب تخمین زمانی، مورد پرسش قرار گیرند. آنها فقط زمانی که ترس منتظر ماندن مشتریان را داشتند این کار را می‌کردند. **یک تجربه:** *مدیری پای تلفن از روی استرس قول داد که محصول را یک هفته‌ای تحویل دهد. با نگاه به بورد کانبان میشد به راحتی تشخیص داد که تا آخر هفته 22 % از کار تحویل داده خواهد شد. بنابراین 3 هفته دیگر نیاز بود برای اتمام کار. با مشاهده این وضعیت، مدیر کارهای موازی را متوقف و اولویت‌ها را جابجا کرد تا موفق شدند محصول را به موقع تحویل دهند. همیشه بورد را بررسی کنید.* **اندازه تخمین زده شده چه معنایی می‌دهد؟ زمان پیشروی یا زمان کار؟** Story point ها بیانگر زمان کار هستند که عبارتست از چند ساعت وقت لازم است تا این فعالیت بدون وقفه پایان پذیرد و نه زمان پیشروی (یا زمان تقویمی، یا چقدر صبر لازم است؟). با اندازه گیری تعدادstory point های به اتمام رسیده در هر هفته (سرعت) می‌توان سرعت پیشروی را کاهش داد. هر story point فقط یکبار تخمین زده شد و هنگام اجرا مورد بازنگری قرار نگرفتند، این باعث شد تا زمان تخمین‌زدن بهینه شود. <p> </p> <br> ###در واقعیت چگونه کار می‌کنیم؟ کانبان حقیقتا محدودیت نداشته و میتواند به هر شکلی کار کند. می‌توانید اجازه دهید تیم زمان محور فعالیت‌ها را انجام دهد، یا می‌توانید زمانی که به اندازه کافی کار جمع شد، اقدام به انجام آنها نمایید.  شکل7. وقتی سه فعالیت به مخزن رسید، شروع برنامه ریزی و یا تخمین شروع خواهد شد. تصمیم گرفتند دو نوع جلسه داشته باشند: - جلسات استندآپ- تیم مقابل بورد ایستاده و درباره مشکلات باهم صحبت میکنند تا بتوانند آنها را بایکدیگر به اشتراک بگذارند. - برنامه‌ریزی‌های هفتگی دوره‌ای، با هدف زمانبندی و برنامه‌ریزی و بهبود مستمر.  این کار بسیار خوب جواب داد. **جلسات استندآپ روزانه** این جلسات بسیار شبیه جلسات استندآپ اسکرام است. این قضیه بعد از جلسات روزانه“scrum of scrum” با حضور تمامی افراد تیمها اتفاق افتاد. یکی از ورودی‌های مهم scrum of scrum این بود که میشد فهمید ابتدا کدام مشکل باید رسیدگی شود یا کدام تیم پیادهساز در معرض بیشترین فشار است. در ابتدا، مدیران به صورت مستمر در این جلسات شرکت کردند و به ارائه راه‌حل‌ها و اولویت‌بندی آنها پرداختند. با گذر زمان وقتی تیمها به بلوغ بیشتری رسیدند، حضور مدیران هم کمتر شد (اما در صورت نیاز حضور داشتند). <p> </p> <br> ###برنامه‌ریزی دوره‌ای یکبار در هفته، جلسات دوره‌ای برنامه‌ریزی برگزار می‌کردند. اگر این جلسات هفته‌ای یکبار و در زمان مشخصی برگزار نمی‌شد کارهای با اولویت دیگری انجام میشد! بعلاوه نیاز به صحبت داخل تیمی بیشتری هم داشتند. موضوعات موردبحث عبارت بودند از: - بروز رسانی بورد (پروژه‌هایی که تمام شده بودند به بورد انجام شده‌ها منتقل میشدند) - نگاهی به هفته گذشته و آنچاه که اتفاق افتاد. چرا اتفاق افتاد؟ چه کار می‌توان کرد تا آنرا بهبود بخشید؟ - تنظیم مجدد محدودیت برای تعداد فعالیت‌های در حال انجام (در صورت نیاز) - شکست پروژه و تخمین آن (در صورت نیاز) اساسا برنامه‌ریزی‌های دوره‌ای ترکیبی از تخمین زدن و بهبود مستمر بود. مشکلات کوچک و یا متوسط سریعا توسط مدیران فنی حل میشدند. اما پیگیری مشکلات پیچیده‌تر مربوط به زیرساخت، سخت بود. برای مواجه شدن با آنها به تیمها این امکان داده شد تا 2 مشکل تیم را به مدیران معرفی کنند.  قوانین اینطور بودند: 1. مدیران می‌توانند در هر زمان تنها روی دو مسئله کار کنند. 1. اگر هر دو مسئله از قبل تعریف شده بود، می‌توان مورد با اولویت پایین را حذف و مورد جدید را جایگزین کرد. 1. تیم تصمیم می‌گیرد چه زمانی مشکل حل شده است. این یک تغییر مثبت بود. ناگهان تیمها مشاهده کردند که مدیران برای حل مشکلات (حتی موارد سخت) تلاش می‌نمایند. آنها می‌توانستند پیگیر مشکلات مطرح شده برای مدیر شوند و بپرسند که کار به کجا رسیده است؟ آن مشکلات با پیدایش کارهای جدید یا با اولویت بالا به کلی پاک نمی‌شد. یک مثال از اینگونه مشکلات این بود که تیم عملیاتیسازی هنگام بروز باگ در عملیات‌ها، کمک لازم را از تیم پیادهساز دریافت نمی‌کرد. آنها نیاز داشتند پیادهساز کمک کند تا بفهمند کدام قسمت از برنامه، عامل اصلی مشکل است در حالیکه آنها درگیر پیادهسازی خود در اسپرینت بوده و مشکل باز باقی می‌ماند. طبیعتا، تیم عملیاتیسازی این طور برداشت می‌کرد که پیادهسازان به اندازه کافی به کیفیت اهمیت نمی‌دهند. وقتی این مشکلات ظاهر شد، به مدیر فنی و سپس به مدیر دپارتمان منتقل شد. او یک جلسه با مدیر تیم پیادهساز ترتیب داد. با بحثی که صورت گرفت مدیر موافقت کرد کیفیت را در اولویت اول قرار دهد، آنها توافق کردند تا از روش پشتیبانی round-robin استفاده کنند. در هر اسپرینت یک تیم پیادهساز on call بوده و بطور لحظه‌ای آماده کمک کردن. بعد از حصول اطمینان از مدیر، مدیر تیم پیادهساز لیستی از افراد را در اختیار تیم پشتیبانی قرار داد. آنها سریعا راه حل را برای تست اجرایی کردند، هرچند که شک داشتند این برنامه‌ریزی کمکی کند اما این بار به صورت واقعی مقدمات چیده و مشکلات حل شد. این کار یک آسودگی خیال را برای تیم عملیاتیسازی فراهم آورد. بعد از حصول اطمینان از مدیر، مدیر تیم پیادهساز لیستی از افراد را در اختیار تیم پشتیبانی قرار داد. آنها سریعا راه حل را برای تست اجرایی کردند، هرچند که شک داشتند این برنامه‌ریزی کمکی کند اما این بار به صورت واقعی مقدمات چیده و مشکلات حل شد. این کار یک آسودگی خیال را برای تیم عملیاتیسازی فراهم آورد. <p> </p> <br> ###یافتن اصولی در برنامه‌ریزی که به خوبی جواب داده‌اند. **یک داستان** *من یکی از نقاط چرخش یکی از تیمها را به یاد می‌آورم. در جلسه دوم تخمین با آنها نشسته بودم. تیم در رابطه با تخمین زمانی یکی از پروژهها دچار دردسر شده بود. تعداد زیادی مسائل ناشناخته وجود داشت که امر تخمین‌زدن را دچار مشکل کرده بود. به جای اینکه من وارد ماجرا شوم از آنها خواستم فرآیند را بهبود بخشند تا بتوانند راه حل بهتری پیدا کنند. با هدایت مدیر خود، شروع به ارائه و طراحی راه‌حل برای مشکل خود کردند. این اتفاق یک نقطه چرخش مهم بود، یک پیروزی بزرگ که تیم توانست آن را با اعتماد بنفس بدست آورد. بعد از این اتفاق پیشرفت آنها سرعت گرفت، آنچنان که ما مجبور شدیم خودمان را از سر راه آنها کنار بکشیم. دوماه بعد، مدیر آنان پیش من آمد و گفت: «ما یک مشکل داریم»، به بورد کانبان اشاره کرد و گفت: «برای ما هیچ مشکلی پیش نمی‌آید، حالا باید چه کار کرد؟ * **بازسازی برنامه‌ریزی** استفاده از روش تخمینی پوکر که همه اعضای تیم در آن درگیر هستند، برای هیچ‌کدام از تیم‌های عملیاتیسازی جواب نداد. به چند دلیل: 1. دانش و اطلاعات در درون تیم خیلی پراکنده بود. 1. اکثر اوقات فقط یک نفر صحبت می‌کرد. 1. اعضای تیم تمایل داشتند تا هرچه سریعتر به کارهای باقیمانده خود بپردازند. اما با کسب تجربه، تیمها با دو روش مجزا تخمین زدن را شروع کردند. هریک برای تیم مربوطه به خوبی جواب داد. **روش 1. انتقال و بررسی**  - برای هر پروژه/ story یک زوج مدیر ارشد به همراه یک تازه‌کار را برای تخمین زدن تخصیص دهید. (اینطور که یک نفر که آن story را به خوبی می‌شناسد و یک نفر که شناخت خوبی به آن ندارد) این کمک را می‌کند تا دانش به بقیه منتقل شود. - بقیه اعضای تیم انتخاب میکنند که دوست دارند در تخمین کدام story شرکت کنند (اما محدودیت 4 نفر به ازای یک story لحاظ شود تا بحث‌ها موثر باشند.) - هر تیم تخمین‌زننده، story را در صورت نیاز خرد کرده و آن را تخمین می‌زند. - سپس تیمها storyها را با یکدیگر تعویض کرده و کارهای یکدیگر را مرور میکنند (یک نفر در هر تیم مسئولیت چگونگی کارهای مربوط به مرور را به عهده می‌گیرد). - تمام! معمولا جلسات برنامه‌ریزی تکراری حدود 45 دقیقه طول می‌کشید و انرژی افراد در طول جلسه بالا باقی می‌ماند. به علاوه اینکه بعد از هر مرور 2-1 تغییر در storyها اتفاق می‌افتاد. **روش 2. فرد ارشد مراحل بالایی را تایید کرده، سپس تخمین زده میشود.** دو فرد ارشد، پروژه یا story را قبل از برنامه‌ریزی مرور میکنند. آنها معماری و راه‌حل را بررسی کرده و یکی را انتخاب میکنند. بعد از آنکه قطعی شد، تیم وارد کار شده، آنstory را خرد کرده و از راه حل ارائه شده به عنوان یک نقطه شروع استفاده میکنند.  شکل 8. خرد کردن فعالیت با استفاده از تکنیک peer-review توسط یک تیم دیگر در برنامه‌ریزی‌های تکراری. <p> </p> <br> ###چه چیز را اندازه بگیریم؟ چیزهای زیادی هستند که می‌توان آنها را اندازه گیری کرد: چرخه زمانی (از زمانی که نیاز جدید کشف شده تا زمانی که آن نیاز برطرف میشود)، سرعت، صف‌ها،نمودار burndownو غیره. سوال مهم این است: کدام مولفه اندازه‌گیری میتواند برای بهبود پروسه، انتخاب و اندازه‌گیری شود؟ بهتر است خودتان تجربه کنید و ببینید چه چیز برای شما نتیجه بهتری می‌دهد. پیشرفت کلی را می‌توان با یک نگاه ساده به بورد کانبان متوجه شد (چند story در داخل مخزن باقی مانده و چه تعداد آن به اتمام رسیده است). <table style="border-collapse: collapse; width: 100%; height: 118px;" border="1"> <tbody> <tr style="height: 18px;"> <th style="width: 50%; height: 18px;"><strong>نقاط ضعف</strong></th> <th style="width: 25%; height: 18px;"><strong>نقاط قوت</strong></th> <th style="width: 50%; height: 18px;"><strong>کاندیداهای معیار سنجش</strong></th> </tr> <tr style="height: 18px;"> <td style="width: 50%; height: 18px;">اندازه را لحاظ نمی‌کند.</td> <td style="width: 25%; height: 18px;">اندازه‌گیری آسان، عدم نیاز به تخمین، شروع و پایان توسط مشتری.</td> <td style="width: 50%;">چرخه زمان</td> </tr> <tr style="height: 18px;"> <td style="width: 50%; height: 18px;">به امر پیش‌بینی زمان تحویل نوع خاصی از کارها کمکی نمی‌کند.</td> <td style="width: 25%; height: 18px;">معیاری تقریبی، اما آسان برای سنجش جهت بهبود و متغیرها.</td> <td style="width: 50%;">سرعت مجموع (تجمیع تمامی انواع کارها)</td> </tr> <tr style="height: 10px;"> <td style="width: 50%; height: 10px;"> <p>برای مفید بودن، نیاز به شروع از یک نیاز کاربر تا زمان تحویل آن است.</p> برای رصد کردن آن نیاز به زمان بیشتری است در مقایسه با سرعت مجموع.</td> <td style="width: 25%; height: 10px;">دقیق‌تر از سرعت مجموع</td> <td style="width: 50%;">سرعت به ازای هر نوع از کار</td> </tr> <tr style="height: 36px;"> <td style="width: 50%; height: 36px;"> <p>به شما نمی‌گوید که آیا دلیل اصلی (مشکل) درخواست غیرعادی بوده یا عدم توانایی.</p> صف خالی ممکن است در واقع به دلیل عدم وجود ظرفیت خالی باشد.</td> <td style="width: 25%; height: 36px;"> <p>مولفه‌ای سریع به منظور منعکس ساختن تغییرات نیازمندی‌ها.</p> آسان برای نمایش دادن.</td> <td style="width: 50%;">طول صف</td> </tr> </tbody> </table> با اندازه‌گیری «سرعت به ازای هر نوع کار» و «طول صف» کار را شروع کردند. اندازه‌گیری سرعت به ازای هر نوع از کار، آسان بوده و نیاز مدنظر را برطرف می‌نماید. طول صف هم یک معیار خوب اندازه گیری با قابلیت هدایت است، چرا که میتواند بصورت لحظه‌ای محاسبه و نمایش داده شود (زمانی که متوجه شدید باید کجا بدنبال آنها بگردید).  شکل 9. گلوگاه‌ها و موقعیت‌ها. قسمت تیره نشان می‌دهد که صف‌ها چگونه گلوگاه‌های تست را بیان میکنند. عدم وجود صف در ستون پشتیبانی مخزن، نشان‌دهنده این است که هیچ‌گونه زمان انتظاری برای کارهای جدید پشتیبانی وجود ندارد. این یک نشانه خوب از یک سرویس پشتیبانی با کیفیت بالا است.  از نمودار تجمیعی استفاده نکردند چرا که بورد کانبان و چارت سرعت، حداقل در فازهای شروع، به کار اطلاعات کافی میدادند. <p> </p> <br> ###تغییرات چطور اتفاق می‌افتند؟ سه ماه بعد از معرفی کانبان، تیم راهبری سیستم بعنوان بهترین تیم از منظر بازدهی از طرف دپارتمان فناوری اطلاعات شناخته شد. در همان زمان، این تیم به عنوان یکی از سه تجربه مثبت «گذشته نگرانه» در شرکت انتخاب شد. گذشته نگرانه یک مناسبت گسترده در شرکت بود که هر 6 ماه یکبار اتفاق می‌افتاد و این برای اولین بار بود که یک تیم در لیست بهترین‌های این مراسم انتخاب میشد. در صورتی که 3 ماه قبل از آن، این تیم به عنوان گلوگاه شرکت محسوب شده و بسیاری از این تیم شکایت داشتند. کیفیت سرویس به وضوح افزایش یافته بود. چطور این اتفاق افتاد؟ لحظه حیاتی زمانی بود که تلاش تمامی افراد شروع شد. به مدیران اجازه تمرکز داده شد و تیم از دریافت کارهایی که به آنها مربوط نبود معاف شد و مسئولیت کیفیت و فرجه‌ها را به عهده گرفت. سه الی چهار ماه طول کشید تا این قضیه اتفاق بیافتد اما بعد از آن، یک جریان روانی شکل گرفت. مشکل رفع شد اما با چالش جدیدی روبرو شدند «چطور انگیزه یک تیم را برای بهبود بالا نگه دارند؟ (وقتی که دیگر این تیم گلوگاه محسوب نمی‌شود).» یکی از قطعات پازل تیم‌های «خودگردان» معرفی مفهومی تحت عنوان «یک قرارداد عملیاتیسازی به ازای هر تیم» بود. این یعنی به هر تیم پیادهساز یک نفر مسئول پشتیبانی و ارتباط با واحد عملیاتیسازی را تخصیص دهیم. کانبان این کار را با دادن قابلیت مدیریت شخصی کارها به فرد مشغول در تیم عملیاتیسازی تسهیل کرده، مانع از انباشته شدن کار زیاد برای فرد شده و همچنین امکان ارتقاء را برای فرد مهیا می‌سازد. قبلا، یک نفر به صورت تصادفی برای انجام کار (فعالیت‌های مربوط به عملیاتیسازی) انتخاب میشد. کار را از صف فعالیت‌ها برداشته، آن را در حد توانایی خود انجام می‌داد و سپس فردا این فرآیند مجدد تکرار میشد. هرگونه برداشت اشتباه منجر به شروع دوباره میشد. وقتی مفهوم یک به یک عملیاتی شد، تیم پشتیبان ناگهان این فرصت را یافت تا بتواند هنگام بروز مشکلاتی که تیم را تهدید می‌کرد، سریعتر پاسخ دهد. پروتکل ارتباط با مشتری سریعا تکامل یافت. نیروهای عملیاتیسازی از چت های آنلاین برای ارتباط با پیاده‌سازهایی که می‌شناختند استفاده کردند، به آنهایی که در نوشتن بهتر بودند ایمیل می‌زدند و در صورتی که سریع‌ترین راه برای حل مشکل تلفن بود، با آنها تماس تلفنی می‌گرفتند.  شکل 10. قبل: مدیر خط اول اصلی‌ترین نقطه ارتباط بین تیمها بود، نیاز بود هرآنچه که مهم تلقی میشد از طریق این مدیر صورت پذیرد. مشکلات کوچکتر و مشکلات روتین پیادهسازان از طریق سیستم issue tracking رفع میشد. ارتباط فرد به فرد کم بود. و بعد  شکل 11. بعد: مفهوم «یک عضو تیم عملیاتیسازی برای یک تیم» پیاده شد. تیم پیادهساز مستقیما با فرد تعیین‌شده در تیم عملیاتیسازی صحبت می‌کردند. در نتیجه ارتباط فرد به فرد به کرات اتفاق می افتد، افراد تیم عملیاتی‌ساز از بورد کانبان برای مدیریت کارهای خود استفاده میکنند و مدیر تمرکز خود را روی اولویت‌بندی پروژه‌های بزرگتر و همچنین فراهمآوری نسخه پشتیبان در شرایط سخت می‌گذارد. پس تاثیر روی بازدهی تیم چه شد؟  شکل 12. سرعت کل و همچنین سرعت پروژه با استفاده از story point و بصورت هفتگی اندازه‌گیری میشوند. جمع کل، معادل مجموع کل ستون‌ها است، سرعت پروژه بیانگر قسمت‌هایی متعلق به پروژه است (قسمت اعظم کار، مثلا بروزرسانی پلتفرم سخت‌افزاری). دو افتی که رخ داده مرتبط هستند به: 1. هفته‌ای که تقریبا تمام اعضای تیم در مسافرت بودند . 1. منتشرسازی یک نسخه اصلی از طرف پیادهسازان بنابراین، در مجموع تیم روند مثبتی را نشان داده است. بطور همزمان هم، هزینه زیادی برای به اشتراک گذاشتن دانش خود با یکدیگر هنگام استفاده از روش برنامه‌نویسی Pair-Programming پرداخت کرد. حال که در این بحث هستیم اجازه دهید نگاهی به بازدهی تیم DBA داشته باشیم.  شکل 13. سرعت کلی و کارهای پشتیبانی کوچک. افت رخ داده در وسط نمودار بابت تعطیلات کریسمس است. سرعت کلی رو به افزایش بوده اگرچه نوسانات قابل توجه است. اندازه این تغییرات، تیم را به این فکر انداخت تا تعداد فعالیت‌های کوچک را رصد کند (فعالیت‌های کوچک‌شده به اندازه‌ای که قابل انجام بر اساس کانبان باشد). همانطور که می‌بینید، نمودار به وضوح رابطه معکوسی را بین تعداد کارهای پشتیبانی کوچک و سرعت کل نشان می‌دهد. تیم پشتیبان خیلی دیرتر از دو تیم دیگر شروع به استفاده از کانبان کرد، در نتیجه اطلاعات قابل استنادی از آن در دست نیست. **گسترش بلوغ** در ابتدا یافتن محدوده مشکلات آسان بود اما به سختی فرصتی برای بهبود پیدا میشد. بورد کانبان، سطح بزرگ و جدیدی از شفافیت ارائه داد و علاوه بر یافتن آسان مشکلات، یافتن جواب برای سوالات مهمی که درباره گردش کار و همچنین صف‌ها و انحراف از معیارها مطرح بود را هم تسهیل کرد. از صف به عنوان ابزاری برای مشخص‌سازی مشکلات استفاده شد. چهار ماه بعد از شروع کانبان، مدیران موفق به رفع عاملان اصلی انحراف از معیارهایی شدند که تیم را اذیت می‌کرد. وقتی که تیمها حرکت از فردمحوری به واحدهایی با قابلیت مدیریت خود را شروع نمودند، مدیران متوجه شدند که با یک چالش جدید در زمینه هدایت مواجه‌اند. آنها نیاز داشتند تا بیشتر به مسائل انسانی (پرداختن به شکایات، تعریف اهداف مشترک، حل تضادها و چانه‌زنی بر سر توافقات) بپردازند. این کار کم‌دردسر نبود آنها به طور واضح بیان کردند که انجام این امور نیاز به تخصص و انرژی داشت. اما این چالش را پذیرفتند و نهایتا هدایت‌کنندگان بهتری شدند.