Agile Experts супраць Agile Manifesto

Як вы лічыце, ваш "мясцовы спрытны эксперт" чытаў Agile Manifesto? У вас ёсць? Ну, гэта не праблема ... калі вы не выкарыстоўваеце слова "Agile" штодня! Але калі вы робіце (ці ваш мясцовы эксперт)… ну - гэта нешта накшталт людзей, якія занадта шмат гавораць пра рэлігію, але не адкрылі Біблію (апавяшчэнне аб палітычнай карэктнасці) альбо святую кнігу па свайму выбару, бо іх урокі літаратуры 10 гадоў таму ... Мы іх не любім. Нездарма.

Добра, давайце не каментаваць іншых людзей і іх меркаванне. Давайце замест гэтага прайдзіцеся крок за крокам "Спрытную Біблію".

Цытаты з Agile Manifesto будуць дадзены ў

тэкставы блок такога кшталту

і нашы каментарыі будуць давацца ў звычайным адступе, як гэта. Пойдзем!

Маніфест, адзіны!

Наш галоўны прыярытэт - задаволіць кліента
шляхам ранняй і пастаяннай дастаўкі
каштоўнага праграмнага забеспячэння.

Гэта такая выдатная ідэя! На той момант гэта было рэвалюцыйна! Але выкананне гэтай ідэі - нешта цяжэйшае, чым можна было ўспрымаць гэтыя некалькі радкоў.

Галоўная праблема: Кожны, хто меў непасрэдны кантакт з кліентам, ведае, што кропка гэтага Маніфеста як мінімум хітрая.

На жаль, кліент не заўсёды ўпэўнены ў тым, што ён хоча, альбо ён хоча занадта шмат рэчаў адначасова, і не можа іх расставіць перад імі належным чынам! Больш за тое, можа здарыцца, што некаторыя з тых рэчаў, якія кліент думаў (а), што хацеў, пазней не захацеў ...

Калі адкласці гэта - кропка Маніфеста сапраўды даказвае яго каштоўнасць для поспеху прадукту! Але гэтымі выключэннямі не варта грэбаваць, бо яны могуць быць фатальнымі!

Наступны пункт ахоплівае нешта падобнае, давайце працягнем гэтую тэму там.

Прывітанне змяняецца патрабаванням, нават у канцы
развіццё. Спрытны працэс змены джгута
канкурэнтная перавага кліента.

Гэта выдатна. Але пастаяннае кручэнне і ціск на каманду распрацоўшчыкаў робіць прадукт кволым. Кадаванне хутка з вялікай колькасцю перанакіраванняў праекта робіць якасць кода прадукту нізкім, і змены становяцца ўсё цяжэй. Больш рацыянальнае і спакойнае развіццё павышае эфектыўнасць унясення змяненняў на позніх этапах распрацоўкі прадукту. Мы згодныя, што змены трэба вітаць, але іншыя дагаворы / дамовы таксама павінны быць зменены прапарцыйна! Часта чакаецца, што прадукт будзе разгорнуты ў той жа час, што і ў выпадку адсутнасці дадатковых змен. Не крута.

Спрытнасць заключаецца ў тым, каб быць гатовымі да чаканых змен, а не аб змене ўсяго і заўсёды. Тыя, хто мае акрэдытацыю для зносін з патэнцыйным кліентам / кліентам, павінны дамагчыся рэалістычнага пагаднення з самага пачатку. Часта 10 хвілін з пяром і паперай у патрэбны час (пачатак праекта) эканоміць дні, тыдні і нават месяцы развіцця (перанакіраванне, павароты, змены) на позніх этапах! Такое млявасць у запуску прадуктаў трэба лічыць непрафесійным, таму што гэта вельмі шмат! Мэнталітэт "давайце проста займем кліента, пазней мы прыдумаем нешта, каб скончыць працу". Этычнасць неэтычная, і занадта часта даводзіцца распрацоўшчыкам "эканоміць дзень" (праца звышурочна, праца ў выхадныя, праца дома, праца ў стрэсавае асяроддзе) ... Не крута. І сапраўды - нават не спрытны.

Даставіць рабочае праграмнае забеспячэнне
часта, з а
пару тыдняў да пары месяцаў, з сабой
перавагу больш кароткім тэрмінам.

У мяне толькі добры досвед працы з гэтым. Гэта дае магчымасці для ранняй цягі-выпрабавання-навучання, паляпшэння зваротнай сувязі. Выдатны матэрыял, калі канцэпцыя Agile дастасавальная пры распрацоўцы праграмнага забеспячэння патрэбнага тыпу прадукцыі. (Не заўсёды так, верыце ці не.)

Дзелавыя людзі і распрацоўшчыкі павінны працаваць
разам штодня на працягу ўсяго праекта.

Ок, можа і не штодня, але таксама - вялікія пальцы! Нам (людзям) гэтага не ўдалося знішчыць за апошнія 15 гадоў ... Дайце нам часу.

Стварайце праекты вакол матываваных асоб.
Дайце ім навакольнае асяроддзе і падтрымку, якую яны маюць патрэбу,
і давярайце ім, каб зрабіць працу.

Менавіта тут большасць так званых агілістаў не выконваюць дзеянняў Agile Manifesto. Яны часта не маюць павагі да асоб, якія, калі не эксперты, усё ж лепш прафесіяналаў, якія лічаць іх вобласць ведаў, чым "спрытны" кіраўнік праекта. Гэта прымушае мэнэджара занадта шмат уцягваць у працу іншых людзей, што адна за адной парушае важныя "механізмы". Паніжае спрытнасць і "надзейнасць" для змен. Які процілеглы.

Самы эфектыўны і эфектыўны метад
перадача інфармацыі ў і ў межах распрацоўкі
каманда вядзе размову ў твар.

Ну, мы нічога не можам сказаць супраць гэтага. Наадварот, ура за гэта!

Працоўнае праграмнае забеспячэнне - галоўная мера прагрэсу.

Так. Праблема ў тым, што многія так званыя агілісты таксама не выконваюць гэты пункт.

Спрытныя працэсы спрыяюць устойліваму развіццю.
Спонсары, распрацоўшчыкі і карыстальнікі павінны мець магчымасць
падтрымліваць пастаянны тэмп бясконца.

Цяжка дасягнуць, але, вядома, - выдатны арыенцір.

Пастаянная ўвага да тэхнічнай дасканаласці
і добры дызайн павышае спрыт.

Зноў жа, на жаль, так званыя спрытныя кіраўнікі праектаў часта забываюць пра гэта, тым самым робячы сур'ёзныя, калі не фатальныя, наступствы.

Прастата - мастацтва максімальнага павелічэння колькасці
Праца не зроблена - важна.

Радуйся, прастата!

Лепшыя архітэктуры, патрабаванні і праекты
выйсці з самаарганізаваных каманд.

Ave!

З рэгулярнымі інтэрваламі каманда разважае над тым, як
каб стаць больш эфектыўным, то настройвае і настройвае
адпаведна яго паводзінам.

Амін!