Agile - гэта маніфест распрацоўкі праграмнага забеспячэння, або, прасцей кажучы, ідэя, падыход да стварэння прадуктаў шляхам бесперапыннага хуткага пастаўкі каштоўнага працоўнага функцыяналу.
Agile рэалізуецца метадалогіямі:
- Scrum - кіраўнічы фреймворк;
- XP - інжынерныя практыкі;
- Канбан - арганізацыя Падтрымка.
Таксама ёсць мноства іншых метадалогій, якія не гэтак папулярныя але ўсё яшчэ выкарыстоўваюцца ў пэўных сітуацыях. Можна назваць некалькі з іх: Crystal Clear, Dynamic Systems Development Method (DSDM), Agile Unidied Process, Future-driven development, ICONIX.
Каштоўнасці Agile:
- Людзі і іх узаемадзеянне важней працэсаў і інструментаў;
- Гатовы прадукт важней дакументацыі па ім;
- Супрацоўніцтва з заказчыкам важней жорсткіх кантрактных абмежаванняў;
- Рэакцыя на змены важней прытрымліваньню плана.
прынцыпы Agile
- Наш высокі прыярытэт - гэта задавальненне заказчыка з дапамогай частых і бесперапынных паставак прадукту, каштоўнага для яго.
- Мы прымаем змены да патрабаванняў, нават на позніх этапах рэалізацыі праекта.
- Гнуткія працэсы вітаюць змены, з'яўляецца канкурэнтнай перавагай для заказчыка.
- Пастаўляць цалкам працоўнае праграмнае забеспячэнне кожныя некалькі тыдняў, у крайнім выпадку, кожныя некалькі месяцаў. Чым часцей, тым лепш.
- Прадстаўнікі бізнесу і каманда распрацоўкі павінны працаваць разам над праектам.
- Паспяховыя праекты будуюцца матываванымі людзьмі. Дайце ім адпаведнае навакольнае асяроддзе, забяспечыце усім неабходным і даручыце зрабіць сваю працу.
- Самы эфектыўны метад ўзаемадзеяння і абмену інфармацыяй - гэта асабістая гутарка.
- Працоўнае праграмнае забеспячэнне - галоўная мера прагрэсу праекта.
- Гнуткія працэсы спрыяюць бесперапыннаму развіццю. Усе ўдзельнікі праекту павінны ўмець вытрымліваць такі пастаянны тэмп.
- Пастаянную ўвагу да тэхнічнага дасканаласці і якаснай архітэктуры спрыяюць гнуткасці.
- Прастата неабходная, як мастацтва максімізацыі працы, якую не варта рабіць.
- Лепшая архітэктура, патрабаванні, дызайн ствараецца ў самаарганізуюцца камандах.
- Каманда пастаянна шукае спосабы стаць больш эфектыўнай, шляхам налады і адаптацыі сваіх працэсаў.
Scrum
Арганізуйце працу ў вашай арганізацыі ў невялікіх кроссфункциональних камандах, якія ўтрымліваюць ўсіх неабходных спецыялістаў. Вылучыце чалавека - скрэм-майстры, які будзе адказваць за захаванне працэсаў у камандзе і канструктыўную атмасферу.
Патрабаванні разбіце на невялікія, арыентаваныя на карыстальнікаў, функцыянальныя часткі, якія максімальна незалежныя адзін ад аднаго, у выніку чаго атрымаеце беклог прадукту. Затым ўпарадкаванне элементы беклога па іх важнасці і зрабіце адносную ацэнку аб'ёмаў кожнай гісторыі. Вылучыце асобнага чалавека - уладальніка прадукту (product owner), які будзе адказваць за патрабаванні і іх прыярытэты, замыкаючы на сябе ўсіх зацікаўленых асоб.
Усю працу вядзіце кароткімі (ад 1 да 4 тыдняў) фіксаванымі ітэрацыі - спрынт, пастаўляючы ў канцы кожнага з іх скончаны функцыянал, які можна пры неабходнасці вывесці на рынак - инкремент прадукту. Каманда, згодна з сваёй хуткасці, набірае заданні на нязменную па часе ітэрацыю - спрынт. Кожны дзень праводзіцца скрэм-мітынг, на якім каманда сінхранізуе сваю працу і абмяркоўвае праблемы. У працэсе працы члены каманды прымаюць у працу элементы беклога адпаведнасці з прыярытэтам.
У канцы кожнага спрынту праводзіце агляд спрынту (demo), каб атрымаць зваротную сувязь ад уладальніка прадукту, і рэтраспектыву спрынту (retro), каб аптымізаваць вашы працэсы. Пасля гэтага ўладальнік прадукту можа змяніць патрабаванні і іх прыярытэты і запусціць новы спрынт.
ролі
- У Scrum прынята вылучаць тры асноўных ролі: уладальнік прадукту, скрэм-майстар і каманда.
Уладальнік прадукту (Product owner Менеджэр прадукту) - гэта чалавек, адказны за прыярэтызацыя патрабаванняў і часта за іх стварэнне. - Скрэм-майстар - член каманды, які дадаткова адказвае за працэсы, каардынацыю працы каманды і падтрымання сацыяльнай атмасферы ў камандзе.
- Каманда - 7 ± 2 чалавек, якія рэалізуюць патрабаванні ўладальніка прадукту.
артэфакты
Беклог прадукту (Product Backlog) - приоритезировать спіс патрабаванняў па ацэнцы працавыдаткаў. Звычайна ён складаецца з бізнес-патрабаванняў, якія прыносяць канкрэтную бізнес-каштоўнасць і называюцца элементы беклога (User stories).
Беклог спрынту (Sprint Backlog) - частка беклога прадукту, з высокай важнасцю і сумарнай ацэнцы, не перавышае хуткасць каманды, адабраная для спрынту.
Инкремент прадукту - новая функцыянальнасць прадукту, створаная падчас спрынту.
працэсы
Большасць працэсаў Scrum носяць характар сустрэч, так як дадзеная метадалогія заснавана на якасных камунікацыях.
Скрэм-мітынг
Скрэм-мітынг (Scrum meeting, скрэм, штодзённы скрэм, планёрка) - сход членаў каманды (з магчымасцю запрашэнні ўладальніка прадукту) для сінхранізацыі дзейнасці каманды і інфармаваннем аб праблемах. Кожны член каманды адказвае на тры пытанні:
- Што было зроблена з папярэдняга скрэм-мітынгу?
- Якія праблемы?
- Што будзе зроблена да наступнага скрэм мітынгу?
планаванне спрынту
Для планавання спрынту неабходна мець якасны беклог, што азначае наступнае:
- усе элементы беклога павінны мець унікальную лікавую важнасць;
- найважнейшыя элементы беклога павінны быць удакладнены і зразумелыя ўсёй камандзе і ўладальніку прадукту;
- уладальнік прадукту павінен дакладна ўяўляць, што будзе рэалізавана ў рамках кожнага элемента беклога.
агляд спрынту
Агляд спрынту (таксама часта выкарыстоўваецца тэрмін «дэманстрацыя» або скарочана «дэма») - паказ ўладальніку прадукту (і зацікаўленым асобам) працуе функцыянал прадукту, зробленага паводле спрынт. Асноўная задача правядзення агляду спрынту складаецца ў атрыманні зваротнай сувязі.
рэтраспектыва
У доўгатэрміновым плане рэтраспектывы (або скарочана «рэтра») з'яўляецца найважнейшым практыкай Scrum: бо менавіта яны дазваляюць адаптаваць і кастомизировать Scrum, робячы з яго па-сапраўднаму гнуткі фреймворк для кіравання праектамі.
Таксама, традыцыйным з'яўляецца фармат па зборы дадзеных, які заключаецца ў адказах кожнага ўдзельніка на тры пытанні:
- Што было зроблена добра?
- Што можна палепшыць?
- ���Яки паляпшэння будзем рабіць (Action items)?
канбан
Для таго каб выкарыстоўваць канбан, дастаткова прытрымлівацца за ўсё тром правілах. Такім чынам, канбан з'яўляецца найбольш "Не дырэктыўнай метадалогіі». Гэта можа быць як плюсам, так і мінусам, так ўкараняць і выкарыстоўваць канбан добра пасля Scrum, а яшчэ лепш не адмаўляцца ад карысных практык гэтага гнуткага фреймворка.
Такім чынам, канбан - гэта высока адаптыўны інструмент, які патрабуе ад каманды, якая вырашыла выкарыстоўваць яго, адпаведнага ўзроўню самаарганізацыі і дысцыпліны:
- Візуалізуе вытворчы працэс - для гэтага звычайна выкарыстоўваюць дошку, размечаную па этапах працы над задачай. Вядома, больш прасунутым варыянтам будзе выкарыстоўваць плазму / праектар, і выводзіць туды стан трэкера.
- Абмяжоўвайце колькасць незавершанай працы (WIP, Work In Progress) - у кожнага слупка-стану каманда паказвае максімальную колькасць задач, якія могуць у ім знаходзіцца. Такім чынам, мінімізуецца пераключэння паміж задачамі і звязаныя з гэтым страты пры вытворчасці.
- Аптымізуе працэс - аснова аптымізацыі вытворчасці ў рамках канбан. Неабходна адсочваць сярэдні час задачы і памяншаць яго.
XP (Экстрэмальнае праграмаванне)
Інжынерныя практыкі з'яўляецца правераныя часам рашэнні, звязаныя непасрэдна з рэалізацыяй патрабаванняў заказчыка.
Асноўныя практыкі:
- Бесперапынная інтэграцыя (Continuous Integration) - выкарыстанне спецыяльнага праграмнага забеспячэння, якое атрымлівае свежую версію зыходнага кода праекта, і выконвае пабудова ПА. У выпадку наяўнасць праблем выводзіцца і рассылаецца адпаведнае паведамленне. У зборнік праекта абавязкова ўваходзіць запуск аўтаматычных тэстаў.
- Распрацоўка праз тэставанне (Test Driven Development) - спачатку пішам аўтаматычныя тэсты, а затым функцыянал які забяспечвае праходжанне гэтых тэстаў. Аб TDD я пісаў ужо шмат і можна прачытаць артыкул Unit tests - пачатак. Частка 1.
- Парнае праграмаванне (Pair programming) - код пішацца двума распрацоўшчыкамі за адным кампутарам, прычым адзін з распрацоўшчыкаў мае ролю «пілота», а другі ролю «штурмана». Гэта істотна падымае якасць кода.
- Калектыўнае валоданне кодам (Collective code ownership) - забяспечвае кроссфункциональнисть саміх удзельнікаў каманды і дазваляе рэалізоўваць гэтую важнае ўласцівасць Scrum. Важнай перавагай такога падыходу з'яўляецца хуткае распаўсюджванне ведаў паміж удзельнікамі каманды. Для рэалізацыі гэтай практыкі неабходна выкарыстоўваць стандарты кадавання , Каб код, напісаны рознымі ўдзельнікамі каманды, быў аднолькавы з пункту гледжання афармлення. Праверку на адпаведнасць стандартам лепш ажыццяўляць на этапе пабудовы праекта ў аўтаматычным рэжыме. Таксама працэдура Code review дапамагае дасягнуць гэтай практыкі XP.
- Стандарт кадавання (Coding standard or Coding conventions) - набор правіл напісання кода. Кожны распрацоўшчык у камандзе павінен ім прытрымлівацца.
- 40-гадзінны працоўны тыдзень (Sustainable pace, Forty hour week) - гэта гарантыя для каманды ад перагрузак, аднаго з выгляду страт у эканомным вытворчасці. Трэба вельмі дакладна разумець, што колькасць адпрацаваных гадзін не роўна колькасці зробленага функцыяналу, як і ў любой інтэлектуальнай і інжынернай дзейнасці.
- Рэфактарынг (Design Improvement, Refactor) - гэта змены зыходнага кода без змены функцыянальнасці для паляпшэння ўнутранага якасці (прастата кода, гнуткасць архітэктуры і г.д.). рэкамендую прачытаць Што такое "Чысты код"?
У XP ёсць яшчэ некалькі важных практык якія паўсядзённа выкарыстоўваюцца ў працы па Agile / Scrum: Гульня ў планаванне (Planning game), Заказчык заўсёды побач (Whole team, Onsite customer), Частыя невялікія рэлізы (Small Releases), прастата (Simple design), метафара сістэмы (System metaphor).
У Вікіпедыі апісаных дадзеныя практыкі - экстрэмальнае праграмаванне .
Больш тэорыі Agile можна паглядзець у прэзентацыі Барыса Вольфсанам.
Таксама рэкамендую прачытаць "Гнуткія метадалогіі распрацоўкі" Вольфсон Барыс
Калі вы заўважылі памылку, калі ласка, вылучыце фрагмент тэксту і націсніце Ctrl + Enter.
Якія праблемы?Што будзе зроблена да наступнага скрэм мітынгу?
Што можна палепшыць?
?�Яки паляпшэння будзем рабіць (Action items)?