نقد و بررسی دیوید اندرسون کنبان. دیوید اندرسون - کانبان

30.08.2020

درباره کتاب
راهنمای جامع Kanban از شخصی با 30 سال تجربه که در تولید نرم افزار پیشگام این روش بوده است.

دیوید اندرسون ، که روش kanban را در چندین شرکت پیاده سازی و بهبود یافته است ، توضیح می دهد که چگونه ایده های Lean را در توسعه فناوری و عملیات فناوری اطلاعات - با حداقل مقاومت در برابر تغییر ، ادغام کنید ، در حالی که سرعت بهینه برای همه کارکنان درگیر است.

کانبان به سرعت مسائل مربوط به عملکرد را شناسایی کرده و تیم را وادار می کند تا بر روی حل آنها تمرکز کند تا جریان مداوم کار را حفظ کند. با تجسم مسائل کیفیت و فرآیند ، کانبان فرصتی را برای ارزیابی تأثیر نقص ها ، محدودیت ها ، تغییرپذیری و هزینه های اقتصادی بر جریان کار و توان کارکنان فراهم می کند.

محدود کردن مشاغل ناتمام با kanban منجر به کیفیت کار و بهره وری بهتر می شود. ترکیبی از بهینه سازی گردش کار و بهبود کیفیت به کاهش زمان سربازی کمک می کند و پیش بینی و احتمال انجام به موقع کار را افزایش می دهد. Kanban با ایجاد شواهد آزادسازی منظم و رعایت یک برنامه ثابت ، به اعتماد سازی با مشتریان و دیگران در جریان ارزش کمک می کند - سایر بخش ها ، فروشندگان و شرکای وابسته به شما.

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

این کتاب به س questionsالات پاسخ می دهد:

- کانبان چیست؟
- چرا شرکت شما به آن نیاز دارد؟
- چگونه آن را پیاده کنیم؟
- چگونه فرصت های بهبود تجارت را تشخیص دهیم - و با آنها چه کنیم؟

این کتاب مال کیه
برای مدیران و روسای شرکتهای IT.

درباره نویسنده
دیوید اندرسون بنیانگذار دانشگاه Lean Kanban و دانشکده مدیریت David J Anderson است که به مدیران و مدیران کمک می کند تا از طریق بهترین روش ها نتایج بهتری کسب کنند.

اندرسون 30 سال سابقه کار در شرکت های فناوری دارد. وی شیوه های مدیریت چابک را در شرکت هایی مانند موتورولا و مایکروسافت پیاده سازی کرده است.

دیوید اولین نفری بود که در سال 2005 از Kanban در توسعه نرم افزار استفاده کرد.

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

با تصاویر ، نمودارها و نتیجه گیری هابیوگرافی متراکم دیوید روش Kanban را برای طرفداران مدیریت پروژه های سالم نشان می دهد. مدیریت پروژه زمانی جالب توجه است که توسط توسعه دهنده مستقیم روش در اول شخص گفته شود.

درباره نویسنده

وبلاگ رسمی David J Anderson به عنوان n ذکر شده است رئیس شرکت Lean Kanban Inc. او همچنین tاجاره دهنده و مشاور مدیریت از سال 2000 ، سخنران و میزبان کنفرانس از سال 2005. وی برای اولین بار در سمت رهبری ، در سال 1991 بود ، بنابراین تجربه وی به ما اجازه می دهد صادقانه روش های مدیریت کنبان و آبشار ، چابک ، اسکرام و سایر پروژه ها را مقایسه کنیم.

وی کانبان را برای بالا بردن سطح کار فکری و خلاق ایجاد کرد. هدف دیوید تحویل به موقع ، همسو سازی کار با اهداف تعیین شده و مدیریت کافی شرکتهای مدرن به طور کلی بود.

وی با استفاده از مثالهای واقعی از زندگی مایکروسافت ، موتورولا و کوربیس ، اصول ، روشها و دستورالعملهای اجرای kanban را در شرکت بیان و نشان داد.

بار معنایی و ماهیت کتاب

کتاب ... راه جایگزین برایAgile توسط شخصی که اصلاً کانبان را اختراع کرده نوشته شده است.این کتاب بسیار جالب و آموزنده است. در اینجا مرز بین فلسفه کایزن ( پیشرفت مداوم)، روش ( لاغر) و Kanban (روشی برای صرفه جویی در منابع انسانی و مادی).

کایزن فلسفه و اخلاق رابطه بین کارگران در بخش تولید و اداره است.

تولید ناب استیک سیستم مدیریت پروژه ایجاد شده در تویوتا برای از بین بردن تمام اتلاف وقت و منابع از فرایندهای شرکت.

کنبانآیا یک روش مدیریت پروژه است که راهی ارائه می دهدکارهای همزمان را محدود کنید. اگر در افراد ، ابزارها یا زمان محدودیت دارید ، Kanban به شما در توزیع وظایف و پروژه ها کمک می کند.

اندرسون در نگارش این کتاب بسیار تحت تأثیر نظریه محدودیت ها قرار گرفت. این کتاب درباره محدودیت های WIP ، گلوگاه ها و توانایی های زیادی داردصادقانه حداکثر بار را در واحد زمان تعیین کنیدکه در آن کیفیت در سطح مطلوب حفظ می شود.

نظریه محدودیت های دکتر الیاهو گلدرات (TOC) یک روش مدیریت کسب و کار تولیدی است. این فیزیکدان اسرائیلی یک نظریه و روش عملی برای مدیریت سازمان ها ، الگوریتم های مربوط به عملکرد تولید ، تدارکات و فروش کالاها ایجاد کرده است. یک رویکرد سیستماتیک برای شناسایی محدودیت ها در شرکت ها به تنظیم همه چیز کمک می کند. در تجربه گلدرات ، اغلب اوقات سیاست شرکت به محدودیت تبدیل می شود.

محدودیت WIP (کار در حال انجام است) - تعداد کارهایی که می توانند به طور همزمان باز شوند.

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

کلیشه های کانبان

وقتی از کانبان می شنویم ، اغلب تخته ای با برچسب را تصور می کنیم - این کلیشه توسط رسانه ها به ما تحمیل می شود. به صورت مجزا ، بر روی دیوار لیستی از کارهای برچسب باز ، مداوم و تکمیل شده وجود دارد ... شما می توانید از دیوارها و برنامه های مجازی برای مدیریت پروژه استفاده کنید ، جایی که لیست کارها ، اولویت ها و سایر ظرایف وارد می شوند.

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

کانبان تابلوی برچسب نیست، برچسب ها فقط شاخص بار کاری هستند.

اندرسون کانبان را طوری طراحی کرد که تا قبل از اتمام پروژه های قبلی ، پروژه جدید را شروع نکنیم. بنابراین ، تعداد برچسب ها برای هر توسعه دهنده انتخاب می شود - به عنوان مثال 3-5 ، و دقیقاً همان تعداد کار در هر واحد زمان می تواند برای او باز شود. فقط پس از انجام هر یک از کارها ، او می تواند یک کار جدید را بر عهده بگیرد.

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

چابک ، اسکرام و کنبان

اندرسون متقاعد شده است که چابک و اسکرام فرمول هستند و استخوان بندی می شوند. به نظر وی ، مدیریت پروژه باید در هر شرکت منفرد باشد. بنابراین ، Agile و Scrum با الگوریتم های استاندارد خود برای اقدامات منسوخ شده اند ، مانند روش کلاسیک مرحله به مرحله آبشار. ممنوعیت کان - روش چنین است با مشخصات شرکت سازگار استکه مردم چابک را می ترساند!

چابک یک روش چابک است که به طور تاریخی برنامه نویسی با قالب به روزرسانی برنامه ها هر دو ماه یکبار آغاز می شود. برنامه نویسی تکرار چند هفته ای برای افزودن هر ویژگی ، روند توسعه را تسریع می کند و خطر را کاهش می دهد.

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

دیوید جی اندرسون

تغییر تکاملی موفقیت آمیز برای تجارت فناوری شما

منتشر شده با اجازه از Lean Kanban Inc.

ما می خواهیم از انجمن ناب کانبان روسیه به نمایندگی از الکسی پیمنوف ، ویاچسلاو تسیرولنیک ، آنتون مانین ، سرگئی بارانوف و ایگور فیلیپیف برای کمک در تهیه مقاله تشکر کنیم.

کلیه حقوق محفوظ است

بدون اجازه کتبی دارندگان حق چاپ ، هیچ بخشی از این کتاب به هیچ وجه به هیچ وجه قابل تولید نیست.

* * *

تقدیم به نیکولا و ناتالی

پیش گفتار

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

بعداً ، در مارس 2005 ، من از دیوید در مایکروسافت دیدن کردم ، در آن زمان او از نزدیک با نمودارهای جریان تجمعی کار می کرد. بعداً ، در آوریل 2007 ، من فرصتی پیدا کردم که ببینم سیستم kanban دستیابی به موفقیت که در Corbis پیاده سازی کرد ، چگونه کار کرد.

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

البته اگر در مسیر درست نشان داده شود سرعت خوب است و من مطمئن هستم که دیوید در مسیر درست حرکت می کند. من به خصوص آخرین کارها را با سیستم های kanban تحسین می کنم. من همیشه اعتقاد داشتم که برخلاف ایده های TOC می توان اصول ناب را مستقیماً در توسعه محصول به کار برد. علاوه بر این ، در اکتبر 2003 ، موارد زیر را به دیوید نوشتم: "یکی از نقاط ضعف اصلی TOC دست کم گرفتن اهمیت اندازه قطعه.

اگر اولویت اصلی شما یافتن و رفع محدودیت است ، این اغلب به این معنی است که شما به سادگی در حال حل یک مسئله اشتباه هستید. " من هنوز هم معتقدم که این گفته درست است.

در جلسه ما در سال 2005 ، من مجدداً به دیوید پیشنهاد دادم که فقط به تمرکز بر تنگناها در CBT نگاه کند. من برای او توضیح دادم که موفقیت پر سر و صدا سیستم تولید تویوتا (PST) هیچ ارتباطی با یافتن و رفع گلوگاه ها ندارد. افزایش بهره وری تویوتا از اندازه های دسته ای کمتر و تنوع کمتر حاصل می شود که میزان موجودی مورد نیاز را کاهش می دهد. کاهش این سهام است که به منافع اقتصادی منجر شده است ، و این توسط سیستم هایی برای کاهش کار در حال انجام مانند کانبان امکان پذیر است.

در سال 2007 از کوربیس دیدن کردم. نتیجه اجرای سیستم Kanban چشمگیر به نظر می رسید. من به دیوید اشاره کردم که او روش Kanban را که در تویوتا به کار رفته بسیار بهبود بخشیده است. چرا من اینطور فکر کردم؟ سیستم تولید تویوتا برای انجام کارهای تکراری و قابل پیش بینی با همان مدت و هزینه تأخیر یکنواخت بهینه شده است. در این شرایط ، استفاده از رویکردهایی مانند اولویت بندی FIFO کاملاً صحیح است ("اول در ، اولین بار"). همچنین در صورت رسیدن به حد مجاز کارهای ناتمام ، مسدود کردن دریافت کار کاملاً صحیح است. با این حال ، اگر با فعالیت های غیر تکراری ، غیرقابل پیش بینی با مدت زمان متفاوت و هزینه های مختلف تأخیر روبرو هستیم ، نمی توان این رویکردها را بهینه دانست - و این دقیقاً در مورد توسعه نرم افزار وجود دارد. ما به سیستم های پیشرفته تری نیاز داریم و این اولین کتابی است که آنها را با جزئیات عملی شرح می دهد.

من می خواهم در مورد برخی موارد به خوانندگان هشدار دهم. اول ، اگر فکر می کنید می دانید سیستم های kanban چگونه کار می کنند ، پس احتمالاً منظور شما از مواردی است که در تولید ناب استفاده می شود. ایده های توصیف شده در این کتاب بسیار پیشرفته تر از سیستم های ساده ای هستند که از محدودیت های WIP ثابت استفاده می کنند. 2
WIP - کار در حال انجام ، تعداد کارهای ناتمام. تقریباً ویرایش شده

برنامه ریزی FIFO و کلاس یکنواخت خدمات. لطفاً به این تفاوت ها توجه داشته باشید.

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

سوم ، فقط به این دلیل که استفاده از آنها بسیار آسان به نظر می رسد تخفیف ندهید. سهولت استفاده ، نتیجه بینش دیوید در مورد چگونگی به دست آوردن بیشترین ارزش با کمترین نتیجه است. او نیازهای پزشکان را به خوبی می داند و به آنچه واقعاً م worksثر است توجه جدی کرده است. روش های ساده پایداری بالایی را نشان می دهند و تقریباً همیشه به بهترین نتایج طولانی مدت منجر می شوند.

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

دون راینرتسن ،

قسمت اول
اصول اولیه

فصل 1
رفع معضل مدیر چابک

در سال 2002 ، من یک مدیر توسعه در دفتر راه دور بخش تلفن همراه موتورولا در سیاتل (PCS) نام داشتم و در شرایط سختی قرار گرفتم. بخش من بخشی از استارتاپی بود که موتورولا یک سال زودتر آن را خریداری کرد. ما نرم افزار شبکه ای را برای انتقال داده های بی سیم مانند بارگیری بی سیم و کنترل ابزار توسعه داده ایم. این برنامه های سرور بخشی از سیستم های یکپارچه بودند که کاملاً با کد سرویس گیرنده تلفن های همراه و همچنین سایر عناصر موجود در شبکه های مخابراتی و زیرساخت های عملیاتی مانند صورتحساب همراه بودند. مهلت تعیین شده توسط مدیرانی تعیین می شود که از پیچیدگی مهندسی پروژه ، خطرات یا مقیاس آن غافل باشند. هسته اصلی این کد از یک شرکت تازه تأسیس تکامل یافته و بسیاری از ویژگی های برنامه ریزی شده اولیه به تأخیر افتاده است. یکی از توسعه دهندگان ارشد اصرار داشت که محصولات ما "نمونه های اولیه" نامیده شوند. ما برای تأمین خواسته های تجاری به شدت به بهبود بهره وری و کیفیت محصول نیاز داشتیم.

در فعالیت های روزمره من در سال 2002 و در روند کار بر روی یک کتاب قبلی 1
اندرسون ، دیوید جی مدیریت چابک برای مهندسی نرم افزار: اعمال نظریه محدودیت ها برای نتایج کسب و کار... رودخانه فوقانی زین ، نیویورک: سالن Prentice ، 2003.

من عمدتاً نگران دو موضوع بودم. اول ، چگونه می توان تیم را از خواسته های روزافزون تجارت محافظت کرد و به آنچه جامعه چابک اکنون "سرعت مطلوب" می نامد ، دست یافت. و دوم اینکه ، چگونه می توانم ضمن تحقق مقاومت اجتناب ناپذیر در برابر تغییر ، چابک را در سراسر سازمان پیاده کنم؟

پیدا کردن سرعت عالی

در سال 2002 ، جامعه چابک سرعت بهینه را "هفته کار 40 ساعته" درک کرد 2
بک ، کنت برنامه نویسی افراطی توضیح داده شده: تغییر را در آغوش بگیرید. بوستون: آدیسون وسلی ، 2000. نسخه روسی: Beck K. Extreme Programming. SPb.: Peter، 2002.

اصول مانیفست چابک 3
بک ، کنت و همکاران ، "اصول پشت مانیفست چابک". http://www.agilemanifesto.org/principles.html. ترجمه به روسی: http://agilemanifesto.org/iso/ru/principles.html.

آنها گفتند که "فرآیندهای چابک برای توسعه مطلوب مناسب هستند. حامیان مالی ، توسعه دهندگان و کاربران باید مایل به حفظ سرعت ثابت در طول زمان باشند. " دو سال قبل ، تیم من در Sprint PCS مدام از من می شنیدند که "توسعه نرم افزار بزرگ یک ماراتن است ، نه یک سرعت." اگر اعضای تیم بخواهند هنگام کار روی یک پروژه یک و نیم ساله ، یک سرعت ثابت را حفظ کنند ، نمی توان در عرض یک یا دو ماه سوزاند. این پروژه باید برنامه ریزی ، بودجه بندی ، زمان بندی و ارزیابی می شد تا اعضای تیم زمان معقولی را برای کار روزانه خود بگذرانند و خیلی خسته نشوند. به عنوان یک مدیر ، وظیفه من رسیدن به این هدف بود. و تمام الزامات تجاری را برآورده کنید.

هنگامی که من در اولین سمت مدیریتی خود کار کردم (این در سال 1991 بود ، در یک شرکت تازه تأسیس که کارتهای ضبط ویدئو را برای رایانه های شخصی و کوچکتر ایجاد می کرد) ، مدیر عامل 3
مدیر ارشد اجرایی - مدیر اجرایی (مدیر عامل). تقریباً ویرایش شده

وی گفت که مدیریت "بسیار منفی" نظر من را دارند. من همیشه وقتی توانایی های ما به عنوان توسعه دهنده تمام شده بود و محصولات یا توابع بیشتری از ما می خواستند ، "نه" پاسخ می دادم. تا سال 2002 ، این برای من یک عادت شده بود: من ده سال دیگر را نپذیرفتم که از هوی و هوس صاحبان مشاغل پیروی کنم.

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

در این بین ، کارمندان با حجم کار دیوانه کننده کنار آمده اند و حجم کارهای گزاف به یک امر عادی تبدیل شده است. به نظر می رسد که هیچ کس به این واقعیت فکر نکرده است که مهندسان نرم افزار می توانند زندگی اجتماعی یا خانوادگی نیز داشته باشند. بی ادبی به نظر می رسد اما واقعیت دارد! من نمونه های زیادی را می شناسم که بار کاری بیش از حد روابط خانوادگی را برای همیشه خراب کرده است. همدردی با توسعه دهنده معمولی گیک سخت است. در ایالت واشنگتن محل تولد من ، درآمد یک مهندس نرم افزار تنها درآمد یک دندانپزشک است. مانند روزهای فورد ، یعنی در دهه 1920 ، زمانی که افراد در کارخانه های او پنج برابر بیشتر از درآمد ملی درآمد کسب می کردند ، هیچ کس حتی به یکنواختی کار یا رفاه حال متخصصان فکر نمی کند: حقوق آنها بسیار زیاد است! تصور وجود اتحادیه های کارگری در صنایع هوشمند مانند توسعه نرم افزار دشوار است ، زیرا هیچ کس به طور جدی علل بیماری های جسمی و روانی را که توسط توسعه دهندگان تجربه می شود ، بررسی نخواهد کرد. کارفرمایان مسئولیت پذیرتر ، مثلاً اقداماتی مانند ماساژ یا روان درمانی را ارائه می دهند. یا اینکه آنها به جای تمرکز روی بررسی ریشه های اصلی این مشکل ، روزهای سلامت روان را سپری می کنند. یک بار نویسنده فناوری در یک شرکت معروف نرم افزاری به من گفت: "اگر من از داروهای ضد افسردگی استفاده کنم اشکالی ندارد ، زیرا همه این کار را می کنند!" برنامه نویسان معمولاً با همه شرایط موافقت می کنند ، حقوق مناسبی می گیرند و عواقب آن را متحمل می شوند. من می خواستم این وضعیت را تغییر دهم ، و رویكرد مفیدی را پیدا كنم كه به من اجازه می دهد بله بگویم و همچنان از تیمم محافظت كنم ، اطمینان حاصل شود كه سرعت مطلوب حاصل می شود. من می خواستم اعضای تیم خود را به جامعه و خانواده برگردانم و شرایطی را که باعث ایجاد استرس و مشکلات بهداشتی برای توسعه دهندگان زیر سی سال آنها شده است ، بهبود بخشم. بنابراین تصمیم گرفتم که با این مشکلات کنار بیایم.

در جستجوی مدیریت موفقیت آمیز تغییر

دومین مشکلی که فکر من را به خود مشغول کرد مدیریت تغییر در سازمانهای بزرگ بود. من مدیر توسعه در Sprint PCS و سپس موتورولا بودم. نیاز شدیدی وجود داشت که هر دو شرکت به روشهای کار انعطاف پذیرتری روی آورند. اما در هر دو مورد ، من در اجرای روشهای چابک در بیش از یک یا دو تیم مشکل داشته ام.

هر دو بار اختیار کافی برای سفارش دادن تغییر در کار چندین تیم را نداشتم. من سعی کردم به درخواست مدیریت ارشد تغییر ایجاد کنم ، اما اختیار لازم را نداشتم. از من خواسته شد تا روی همکاران تأثیر بگذارم تا همان تغییراتی را که در تیم خودم ایجاد کردم ، در تیم هایشان اعمال کنم. اما آنها عجله ای برای اتخاذ روشهایی نداشتند که به نظر می رسید به بهترین شکل ممکن خود را در تیم من ثابت کرده اند. این مقاومت احتمالاً چندین دلیل داشت. بیشتر اوقات ، من شنیده ام که هر تیم شرایط خاص خود را دارد و روش های من باید متناسب با نیازهای خاص دیگران باشد. در اواسط سال 2002 ، فهمیدم كه محكمانه انجام هرگونه فرآیند توسعه نرم افزار بی فایده است - این فقط كارساز نیست.

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

سعی کردم این مسئله را در کتاب مدیریت چابک برای مهندسی نرم افزار که در آن زمان می نوشتم ، بیان کنم. من تعجب کردم ، "چرا توسعه چابک نتایج اقتصادی بهتری نسبت به رویکردهای سنتی ایجاد می کند؟" من می خواستم برای این منظور ساختار نظریه محدودیت ها را اعمال کنم 4
گلدرات ، الیاهو م. این چیزی که تئوری محدودیت ها نامیده می شود چیست و چگونه باید اجرا شود؟ Great Barrington، MA: مطبوعات شمال رودخانه ، 1999.

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

شکل: 1.1 چرا روش های توسعه عمومی اشتباه است

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

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

فهمیدم که می توانم این روش را با برخی از تکنیک های ناب ترکیب کنم. با شبیه سازی گردش کار چرخه حیات توسعه نرم افزار به عنوان یک جریان مقدار و ایجاد یک سیستم ردیابی و تجسم برای گرفتن تغییرات در حالت کار در حال ظهور "جریان" از طریق سیستم ، می توانم محدودیت ها را تعریف کنم. توانایی شناسایی محدودیت اولین قدم به سمت مدل اصلی TOC است. گلدرت \u200b\u200bقبلاً کاربردی از این نظریه را برای مشکلات گردش کار ایجاد کرده است ، که به طرز نامناسبی طناب بافر-بافر نامیده می شود. با این حال ، متوجه شدم که نسخه ساده شده این سیستم را می توان در زمینه توسعه نرم افزار پیاده سازی کرد.

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

این فرصت در پاییز سال 2004 در مایکروسافت ظاهر شد که در تحلیل این مثال به تفصیل در این کتاب شرح داده شده است.

از طناب بافر-طناب تا کنبان

محلول طناب بافر-بافر در Microsoft نتیجه داده است. مقاومت ضعیف ، بهره وری بیش از سه برابر ، زمان سرب 90٪ کاهش یافته و پیش بینی 98٪ بهبود یافته است. در پاییز 2005 ، من در مورد نتایج به دست آمده در یک کنفرانس در بارسلونا گزارش دادم 5
اندرسون ، دیوید جی و دراگوس دومیتریو ، "از بدترین به بهترین حالت در 9 ماه: اجرای راه حل طناب بافر-بافر در بخش IT مایکروسافت" ، مجموعه مقالات کنفرانس جهانی TOCICO ، بارسلونا ، نوامبر 2005.

و در زمستان 2006 گزارش دیگری ارائه دادم. کار من توجه دونالد راینرتسن را جلب کرد که مخصوصاً به دفتر من در ردموند آمد. او می خواست مرا متقاعد کند که همه چیز برای انتقال کامل به کنبان آماده است.

Kan-ban -یک کلمه ژاپنی است که به معنای واقعی کلمه به "صفحه سیگنال" ترجمه می شود. در ساخت ، از چنین تخته ای برای تجسم سرعت روزافزون تولید استفاده می شود که امکان تولید بیشتر را فراهم می کند. کارکنان در هر مرحله از فرآیند نمی توانند به مرحله بعدی کار بروند تا زمانی که سیگنال مربوطه از طریق برد kanban داده شود. اگرچه از وجود این سازوکار آگاه بودم ، اما اطمینان نداشتم که این کار برای کارهای فکری ، به ویژه توسعه نرم افزار مفید یا حتی قابل استفاده است. من می دانستم که kanban سرعت مطلوبی را ارائه می دهد ، اما از شهرت خوب آن به عنوان روشی برای پیشرفت روند افزایشی بی اطلاع بودم. من نمی دانستم که Taiichi Ohno ، یکی از بنیانگذاران سیستم تولید تویوتا ، گفت: "دو اصل اساسی سیستم تولید تویوتا اتوماسیون به موقع و به کمک انسان ، یا خودمختاری است. برای مدیریت سیستم از ابزاری استفاده می شود - این Kanban است. " به عبارت دیگر ، کانبان برای فرآیند حیاتی است. کایزن ("بهبود مستمر") مورد استفاده تویوتا. این مکانیزمی است که باعث کارایی سیستم می شود. اکنون ، با پشت سر گذاشتن پنج سال تجربه ، این را به عنوان یک حقیقت مطلق می پذیرم.

خوشبختانه ، دون یک مورد قانع کننده برای حرکت از طناب بافر-بافر به کانبان ساخت. به نظر بسیار باطنی بود: سیستم kanban انتقال آرام تری از حالت بیکار در فضای باریک از طناب بافر-بافر را فراهم می کند. با این حال ، درک چنین ویژگی متمایزی برای خواندن و درک این کتاب لازم نیست.

پس از بررسی دوباره راه حل پیاده سازی شده در مایکروسافت ، متوجه شدم که اگر ما بلافاصله آن را در نتیجه سیستم kanban درک کنیم ، نتیجه همان خواهد بود. برای من جالب بود که دو رویکرد متفاوت منجر به یک نتیجه می شود. بنابراین ، از آنجا که این روند مشابه بود ، من احساس تکلیف نمی کردم که آن را فقط در نتیجه اجرای سیستم طناب بافر-بافر درک کنم.

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

ظهور روش کانبان

در سپتامبر 2006 ، مایکروسافت را ترک کردم و به سمت رئیس توسعه نرم افزار در Corbis ، یک شرکت ذخیره سازی عکس و مالکیت معنوی در مرکز شهر سیاتل ، درآمدم. با الهام از آنچه در مایکروسافت بدست آوردم ، تصمیم گرفتم یک سیستم kanban pull را در Corbis پیاده سازی کنم. در اینجا نیز نتایج بسیار موفقیت آمیز بوده و منجر به توسعه بیشتر مفاهیم ارائه شده در این کتاب شده است. این مجموعه گسترده ای از این مفاهیم است - تجسم گردش کار ، انواع اقلام کار ، مدرک ، کلاس های خدمات ، گزارشگری خاص مدیریت و تجزیه و تحلیل معاملات - که روش Kanban را تعریف می کند.

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

"Kanban" در ژاپنی به معنی "صفحه سیگنال" است. در ساخت ، از چنین تخته ای برای تجسم سرعت در حال افزایش استفاده می شود ، که به شما امکان می دهد محصولات بیشتری را با هزینه کمتری تولید کنید. نمونه بارز رویکرد تویوتا است که به لطف آن اصل "دقیقاً به موقع" برای سالها با حداقل هزینه به طور م minimalثر اجرا می شود.

دیوید اندرسون مجموعه ای گسترده از ایده ها (تجسم روند و قوانین کار ، نمونه برداری از اقلام کار ، کلاس های خدمات ، مدرک ، معیارها و نمودارها برای حسابداری و تجزیه و تحلیل مدیریت) را ارائه می دهد که روش کانبان را تعریف می کند.

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

برای اولین بار به زبان روسی منتشر شد.

دارندگان حق چاپ قطعه ارائه شده از این کتاب با توافق با توزیع کننده محتوای حقوقی LLC "Liters" (بیش از 20٪ از متن اصلی) ارسال شده است. اگر فکر می کنید ارسال مطالب حقوق شما یا شخص دیگری را نقض می کند ، در این مورد به ما اطلاع دهید.

تازه ترین! رسیدهای کتاب امروز

وصیت نامه یوت بلانشت
دمانژ پاتریشیا
نشریات دوره ای

سوزان از روی سنگ بلند شد و قصد داشت به ماشین برگردد که صدایی شنید:

- بیا! بیا پیش من! بیا پیش من! بیا!

و دقیقاً مانند اولین بار ، این واژه های مجزا با یک هق هق گریه نامفهوم دنبال شدند. دختر یخ زد. صدا آنقدر واضح بود که نمی توانست تکان بخورد.

و سپس او دوباره این کلمات را شنید:

- بیا ، بیا ... بیا پیش من! بیا!

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

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

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

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

هر روز بعد از نیمه شب اتفاقی در قلعه می افتد ...

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

- برای کمک! برای کمک! دختر فریاد زد. - کسی! کمک!

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

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

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

در طول بازی با من ، دوستان و دشمنان در کنار هم هستند ، برخی در مواقع دشوار کمک می کنند ، دیگران آماده هستند که از پشت چاقو بزنند ، اما شما باید به خود و شانس اعتماد کنید. هدف تعیین شده است ، بنزین در مخزن ریخته می شود ، یک حرز در اطراف گردن است و پا پدال گاز را به زمین فشار می دهد. پیروزی فرا خواهد رسید و من به هدف خود خواهم رسید! امیدوارم…
ارواح از مه
آسیاب الکساندرا
نشریات دوره ای

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

بسته هفتگی - رهبران برتر برتر هفته!

2. رئیس جمهور نفرین شده
تابستان لنا
رمان های عاشقانه ، رمان های داستانی عاشقانه ، داستان علمی ، داستان کارآگاهی ،

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

گاهی خیانت پایان نیست ، بلکه آغاز است.

گاهی اوقات دری به دنیای دیگری است که جنگ در آستانه آن است. جایی که گرگ ها برای زنان خود با مرگ می جنگند و مردم اسلحه ها را با گلوله های نقره بار می کنند. جایی که یک قاتل مرموز پرسه می زند ، گلوی هرکسی را که شباهت زیادی به شما دارد ، می خزد. جایی که لبخندهای خوش اخلاق فرصتی مطمئن برای گرفتار شدن در دام است و گرگی که پشت سر شما غر می زند فرصتی برای فرار است.

آماده شوید ، اینجا یک آکادمی گرگ ها ، یک دیوانه خارج از درب و یک مرد مرموز است که به دلایلی تصمیم گرفت که شب بتواند به شما مراجعه کند.

و همه به این دلیل است که خیانت پایان نیست ، بلکه فقط آغاز است.
آکادمی Arcturus 2. همسر گرگ
آهک سیلویا
داستان علمی ، سایبرپانک

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