Канбан (разработка на софтуер)

Канбан (на японски: かんばん) е метод за управление на интелектуалната дейност, който набляга на доставката точно на време, без същевременно членовете на екипа да са пренатоварени. При този подход процесът – от дефинирането на задачата до доставянето на продукта, е изложен на показ за участниците в него, а същевременно разработчиците на софтуера взимат работни задачи от така наречената „опашка“.

Канбан може да бъде разделен на две части:

Канбан – Система за визуално управление на процеси, която указва какво да се произведе, кога да се произведе и какво количество да бъде произведено.
Методът Канбан – Подход за постепенно, еволюционно подобряване на процесите в една организация.

Методът Канбан

Името „Канбан“ произлиза от японски език и буквално преведено означава „сигнална карта“. Методът, както е формулиран от Дейвид Андерсън^[1] ^[2], е подход на постепенна, еволюционна промяна на процесите и системите в организацията.

Използва система, при която се ограничава количеството на текуща работа във всеки един момент от работния процес, а допълнителни задачи могат да се поемат едва тогава, когато е възможно да има работен прогрес върху тях. Този подход е основен механизъм за разкриване на системни операционни проблеми и стимулиране на взаимопомощта, с цел продължително подобряване на системата. Методът Канбан е кръстен на едноименната система за ограничени задачи в процес на работа.

Канбан методологията е свързана с четири базови принципа:

Започни с това, което правиш сега: Канбан не определя специфичен набор от роли и стъпки. Методът започва с ролите и процесите, които са на разположение и стимулира продължителни, нарастващи и еволюционни промени в системата.
Съгласявай се да преследваш постепенни еволюционни промени: Организацията (или екипът) трябва да се съгласи, че продължителните, нарастващи и еволюционни промени са начинът да се правят подобрения в системата. Внезапните промени може да изглеждат по-ефективни, но имат по-висок шанс за провал, поради съпротива и страх в самата организация. Канбан методът окуражава продължителните, малки и постепенни промени в текущата система.
Уважавай текущите процеси, роли, отговорности и титли.: Възможно е към момента организацията да има някои елементи, които работят приемливо и заслужават да бъдат запазени. Но трябва да търсим разсейване на страха, за да се установяват и бъдещи промени. Съгласявайки се да се уважават текущите роли, отговорности и работни титли, се елиминират началните страхове. Това би ни позволило да придобием по-широка подкрепа за нашата Канбан инициатива.
Лидерство на всички нива: Лидерски действия трябва да се окуражават на всички нива в организацията от индивидуални участници до старши мениджъри.

Шест основни практики

Андерсън идентифицира и пет ключови свойства, които са наблюдавани във всяко успешно имплементиране на метода Канбан. По-късно тези пет са преименувани на практики и са увеличени с допълнителна шеста.

Визуализирай
Работният процес при интелектуалната дейност е присъщо невидим. Визуализирането на потока на работа е ключов за разбирането на това как върви работата. Без разбиране на работния процес, направата на правилните промени е по-трудна. Познат метод за визуализиране на работния процес е използването на стена с колони и карти. Колоните представляват различните състояния или стъпки на работния процес.
Ограничавай задачите, които са „в процес на работа'
Ограничаването на задачите, които са „в процес на работа“ гласи, че трябва да се имплементира система за поемане („теглене“) на задачи, касаещи части от работния процес или целия работен процес. Тази система ще действа като един от основните стимули за продължителни, постепенни промени в системата. Системата може да се имплементира като канбан система, CONWIP система, DBR система или друга разновидност. Критичните елементи са, че текущата работа във всеки един етап от работния процес е лимитирана и нови задачи се „изтеглят“, когато има наличен капацитет в ресурса до достигане на лимита за все още незавършена работа.
Управлявай потока на работа
Процесът на работа през всеки етап трябва да бъде следен, измерван и докладван. Чрез активно управление на процеса може да бъде оценено дали продължителни, постепенни промени в системата ще имат положителни или отрицателни ефекти.
Уточнявай изискванията
Докато механизмът на даден процес не е стриктно разяснен, често може да е невъзможно да се обсъжда подобрението му. Без точно разбиране на това как нещата работят и как работата трябва да бъде свършена, всяка дискусия може да бъде емоционална и субективна. Когато налице е коректно и точно разбиране, е възможно да се премине към по-рационално, емпирично и обективно дискутиране на проблемите. Това прави установяването на консенсус около предложенията за подобрение по-вероятен.
Използвай обратна връзка
Организациите, които не са въвели второ ниво на обратна връзка, оценяване на операциите, като цяло не са засвидетелствали подобрения отвъд локалното отборно ниво.
Усъвършенствай съвместно, еволюирай експериментално (използвайки модели и научни методи)
Методът Канбан окуражава малки, продължителни и еволюционни промени, които остават. Когато екипите споделят еднакво разбиране на работните теории, работния процес и рисковете, е по-вероятно за тях да изградят споделени разбирания за даден проблем и да предложат действия за подобрение, с които да се съгласят. Методът предлага използването на научен подход за въвеждането на продължителни, постепенни и еволюционни промени. Методът не определя специфичен научен подход, който да се използва.

Основни използвани модели са:

Теорията на ограниченията (Theory of constraints) (изучаване на така наречените bottlenecks или пречки)
Lean моделът (базиран на концепцията за „прахосване“)

Вижте също

Източници

↑ Anderson, David. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Prentice Hall, September 2003. ISBN 0-13-142460-2.
↑ Anderson, David. Kanban – Successful Evolutionary Change for your Technology Business. Blue Hole Press, April 2010. ISBN 0-9845214-0-2.

Външни препратки

Aspects of Kanban by Karl Scotland, Посетен на 17 февруари 2011
De-mystifying Kanban Архив на оригинала от 2013-09-21 в Wayback Machine. by Al Shalloway of Net Objectives Архив на оригинала от 2013-08-29 в Wayback Machine.
Kanban Applied to Software Development: from Agile to Lean
What is Best, Scrum or Kanban? Архив на оригинала от 2013-08-26 в Wayback Machine.

Тази страница частично или изцяло представлява превод на страницата Kanban_(development) в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите.

ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.

[1] Anderson, David. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Prentice Hall, September 2003. ISBN 0-13-142460-2.

[Anderson1-2] Anderson, David. Kanban – Successful Evolutionary Change for your Technology Business. Blue Hole Press, April 2010. ISBN 0-9845214-0-2.

[1]

[2]