Данашњи софтверски тимови су, барем у својим процесима, агилнији! Они су вољни да размишљају изван постављених параметара да би пратили шта им смета. Они су жељни учења и усвајања нових техника управљања пројектима и пројектним процесима.
Метода управљања пројектима названа Канбан већ годинама је кружила у софтверској индустрији, а валута је стекла у последњих пет година. Заједно са Агиле методологијама, усвајање Канбан методе омогућило је компанијама пуно да се прославе.
Али ту је и критика да Канбан није ништа друго него прослављени списак обавеза. Па шта је то? Хајде да сазнамо.
Шта је Канбан?
Ако је ваша компанија спремна прећи традиционални приступ управљању софтверским пројектима, данас нема техника управљања пројектима.
За један постоји систем Агиле Пројецт Манагемент који се фокусира на нелинеарне, итеративне методе развоја софтвера. Употреба Агиле метода евидентна је у компанији Сцрум, која се фокусира на флексибилнији приступ управљању пројектима.
Агиле такође има везе са другим оквирима за управљање пројектима као што су Канбан и Ектреме Программинг. Од њих је Канбан достигао велику популарност. На крају крајева, ко не жели да се развијају Јапанци?
Канбан је концепт који се развио у Тојотиној фабрици за производњу како би постигао праводобну производњу (ЈИТ), која смањује трошкове и омогућава мање употребе ресурса. У њеном срцу следи принцип „потезања“ рада, што значи да задатке или производе треба „повлачити“ захтевима и потражњом, а не „гурати“ одоздо на доле. Развијен је да обезбеди боље складиштење аутомобилских компоненти у Тоиотама, заснован на потражњи. То је значило да ће се са порастом потражње попуњавати захтеви.
Концепт је прилагођен софтверској индустрији са неколико измена Давид Андерсон, у својој књизи из 2010. године, Канбан . Од тада се користи са разним пројектима са великим успехом. Може бити од огромне помоћи у сложеним пројектима који могу претрпети преоптерећење с једне стране развојног циклуса.
У основи, Канбан процес процеса софтверског третирања третира као цјевовод. Рецимо да софтверски процес има три врсте задатака: анализу, развој, тестирање и на крају, употребу. Рецимо да има двадесет задатака које је потребно испунити.
У случају традиционалног система управљања пројектима, на примјер,
- Укупно има 25 прича
- Аналитичари су у стању да обраде пет прича недељно
- Програмери могу да обраде пет прича недељно
- Тестери су ограничени на три приче недељно
У овој ситуацији, рад се једноставно гомила на крају тестера. На крају 1. недеље, ситуација ће бити следећа:
- Само три приче су прешле на имплементацију.
- Програмери и аналитичари раде на три приче, јер тестери нису у могућности да узму излазност програмера и тестирају је исто.
- Посао се нагомилава, остављајући програмере и аналитичаре и менаџера пројеката, у исправном стању.
Аналитичари и програмери сада могу једноставно превртити палчеве! Или њихов менаџер може схватити да ради без посла и преместити их у други пројекат, где се може створити слична ситуација. Дакле, постоје два пројекта која су сада заглављена у фази тестирања!
Проблеме у таквој ситуацији није тешко уочити. Каква је сврха развијања десет прича (или делова софтвера) када их ускоро неће ни тестирати?
Сада, на методу Канбан.
Канбан метода је крајње једноставан концепт. Слиједи једноставна логика употребе „методе повлачења“ за прво уклањање уских грла и ограничавања „Радови у току“ (ВИП) за боље радне процесе.
У свом најједноставнијем облику, Канбан, буквално, „визуелна табла“ помаже тако што „повлачи“ предмете са списка обавеза, уместо да ради са роковима. Канбан метода помаже у препознавању уских грла како би се проток процеса боље управљао.
Основни Канбан одбор има списак задатака које је потребно обавити, задатке у току и испуњене задатке.
У софтверу за управљање, међутим, задаци могу бити мало сложенији. Већина Агиле пројеката такође има сличан одбор. На Канбан плочи, фазе размештања су јасно обележене, заједно са бројем за сваку колону. Овај број представља максимални број задатака или прича које одређени корак може да поднесе.
Наш пример на Канбановој табли изгледао би овако некако почетком друге недеље. То значи да програмери и аналитичари неће радити на оптималном броју прича током те недеље. Било би очигледно да се посао гомила на крају тестера. Организације могу да осигурају да тимови раде заједно како би тестирање завршило. Алтернативно, они могу да погледају друге моделе протока процеса да се то не догоди.
Када се пројекти рјешавају кроз систем Канбан, мање је простора за гомилање посла. Приче се узимају у складу са максималном доступном ширином опсега.
У уобичајеном Канбан постављеном раду, посао ће се одвијати према расположивој ширини опсега, а посао ће привући тимови, тако да су увек у максималном капацитету. Систем такође омогућава брзи запис за хитне задатке, тако да се кроз плочу крећу уз минимални напор.
Погледајте ову Канбан таблу.
Јасно је да сви кораци раде максимално ефикасно. А задатак који је на „брзој стази“ такође се узима у обзир.
Канбан никако није једина метода која се користи за повећање ефикасности ограничавањем ВИП-а. Постоје и други системи који постижу исти резултат - на пример, ЦОНВИП (стални радови у току) и ДБР (бубањ-пуфер-коноп), који су првенствено намењени производној индустрији.
Међутим, Канбан је систем који је најбоље модификован да одговара софтверској индустрији.
По чему се Канбан разликује од агилне методологије?
У свом срцу, Канбан је методологија која користи неке елементе агилног управљања пројектима. Многи пројекти у оквиру Агиле коријена имају коријене у Леан приступима. Разлика између Канбанове методологије и агилног управљања пројектима није тако црна и бела као што би веровали заговорници две методе. Имају више заједничког него разлике.
Окретни оквир није апсолутни. Питање није да ли су тимови агилни или не. Тимови често имају агилност у различитом степену. Једна од метода за већу флексибилност у вашем процесу развоја софтвера је коришћење Канбана.
Постоји неколико разлика између Канбан и Агиле методологија. Неке од карактеристика Канбановог развоја које су мало другачије од Агиле-а су:
- Временске линије нису значајан фактор . Ово је тежак концепт да омотамо главу, јер изгледа врло неинтуитивно. „Како радите без рокова?“ Људи се често питају. Али ако се сваки члан тима ангажује на својој максималној ефикасности, тада време престаје да буде фактор.
- Приче (задаци) су веће него у типичним Агиле системима. Трајање и сложеност прича обично су дуже него код типичног Сцрум пројекта. Како фокус није на процени времена, већ на једноставно кретању процеса, Канбан може да приушти да ради на већим причама.
- Нема значајних промена у постојећим процесима. Принципи Канбана за развој софтвера, који је на свом блогу артикулирао његов оснивач, Давид Андерсон, укључује следеће основне принципе:
-
- Почните с оним што сада радите
- Пристаните да предузмете инкременталне, еволутивне промене
- Поштујте тренутни процес, улоге, одговорности и наслове
- Свака прича се мери у времену циклуса . Пројекат се не вреднује по традиционалном агилном рачунању брзине (броја прича завршених током одређеног времена), већ по времену циклуса. То значи да Канбан ставља нагласак на то колико је времена требало да се испуни задатак. На многим Канбановим таблама често можете видети ознаку која помиње колико дана треба тиму да заврши причу. Ова процена се ставља у следећи циклус.
Канбан: Одбор, али шта друго?
Дакле, Канбан је плоча која нам показује како су приче сређене - да ли је и тако велика ствар, многи питају. У ствари, постоји велика дискусија о томе шта Канбан може и може.
Да ли је Канбан само метода за управљање током рада? Или је то нешто што се може користити заједно са Агиле методологијама за максималну ефикасност? Или, може ли то бити потпуно нов начин управљања током рада?
Сваки тим користи Канбан за своје посебне ситуације. Без обзира на то, Канбан има потенцијал да делује као начин живота за развој софтвера, уколико се навикне на његов оптималан ниво.
Било да се користи за управљање током рада или као нова парадигма у развоју софтвера, не може се порећи да помаже у управљању ВИП-овима.
Да би Канбан најбоље функционисао, важно је размишљати не само о управљању ВИП-овима, већ као оквиру за управљање пројектима. Одређене основне смернице ће помоћи овом процесу.
- Оптимизирајте тимове тако да ниједан тим не покрене нешто што не може завршити. Ово помаже процесу.
- Не одолевајте променама оригиналног Канбан система. Ако се ваш пројекат добро сналази са роковима и временским роковима, укључите га исто као и ви. То омогућава здравије и снажније развојно окружење.
- Не избегавајте тимски рад. Канбан можда изгледа, али није модел заснован на појединцима који раде у изолацији. Тимски рад мора бити саставни део развоја Канбан софтвера.
- Размишљају ван оквира. Размислите о променама у току рада. Многи тимови се сада одлучују за Тест-Дривен Девелопмент, са Аццептанце Тест-Дривен Девелопмент-ом, где се тестови прихватања прво спроводе са случајевима коришћења, а затим покрећу потребне карактеристике и природу развоја.
Хибриди
Како све више компанија користи алате за управљање пројектима који су најприкладнији за њихову конкретну ситуацију, није изненађујуће да су две најбоље методологије управљања пројектима: Сцрум и Канбан, интегрисане у велики успех.
Хибрид, назван Сцрумбан, улази у бројне пројекте.
Ако организација већ користи Сцрум, али му је тешко држати пројекат заједно, било да спринтери не раде добро, да тестирање не буде непропусно за ваздух, можда је време да размотри Сцрумбан.
Да бих то једноставно објаснио, Сцрумбан је укључивао повећало на спринте. Не ради се само о спринтовима као делу пројекта, већ о ономе што се дешава унутар спринтова. Сцрумбан вам помаже да сагледате како се прича обрађује у спринту и да би то могло имати значаја.
Сцрумбан, или било која од његових варијанти, минимална је промена од постојећих пракси. Лепота употребе Канбана је у томе што се може користити са скоро свим врстама модела управљања пројектима: водопад, Агиле или било шта између тога.
Почетак рада са Канбаном
Лако је започети са Канбан системом. Такође је могуће да се Канбан имплементира на минималан начин као суђење за одређени део пројекта.
- Мапирање процеса развоја софтвера. Направите јасну мапу целокупног процеса. Како пројекат функционише - од почетног дизајна, развоја, тестирања, промене карактеристика доиста?
- Листајте кораке у којима ће се користити Канбан. Користите кораке који су у потпуности под вашом контролом. То обично обухвата фазе анализе, развоја, прегледа и испитивања.
- Радите на важним тачкама као што су:
- Ограничава се у току у току за сваки корак.
- Процеси за убрзани / блокирани рад
- Процјене повратне коверте с обзиром на вријеме циклуса
- Учесталост прегледа плоче / процеса / процене Канбана
- Купите таблу и гомилу Пост-Ит белешки.
- Почети
- Прегледајте по потреби.
- Понављање
Дакле, само напред и крените на Канбан!
Не плашите се ако се не деси онако како сте првобитно намеравали. Цела идеја иза Агиле методологије је да се прилагоди променама у људима и процесима! Обавестите нас о вашим искуствима са методом Канбан.
Препоручени чланци
- 6 најбољих корисних уреда за управљање пројектима (ПМО)
- 8 корисних корака за прављење софистицираних мапа прича за ваш пројекат
- 5 важних вредности екстремног програмирања (моћног)