Скрам (англ. scrum — штовханина; сутичка навколо м'яча (у регбі)) — підхід управління проєктами для гнучкої розробки програмного забезпечення. Скрам чітко робить акцент на якісному контролі процесу розробки.
Історія
Підхід вперше описали Гіротака Такеучі та Ікуджіро Нонака в статті The New New Product Development Game (Гарвардський Діловий Огляд, січ-лют 1986). Вони відзначили, що проєкти, над якими працюють невеликі, крос-функціональні команди, зазвичай систематично продукують кращі результати, і пояснили це, як «підхід регбі». У 1991 році ДеҐрейс та Шталь у книжці Злі проблеми, справедливі рішення послалися на цей підхід, як на Scrum (штовханина; сутичка навколо м'яча (у регбі)), спортивний термін, згаданий в статті Такеучі і Нонака. Кен Швабер на початку 1990-х використовував підхід, який привів Scrum в його компанію. Вперше метод Scrum було представлено на загальний огляд задокументованим, чітко сформульованим та описаним спільно Сазерлендом та Швабером на OOPSLA'96 в Остіні. Швабер та Сазерленд протягом наступних років працювали разом щоб обробити та описати весь їхній досвід та найкращі практичні зразки для індустрії в одне ціле, в ту методологію, що відома сьогодні як Scrum. Швабер об'єднав зусилля з Майком Бідлом в 2001, щоб детально описати метод в книжці Agile Software Development with SCRUM. Незважаючи на те, що для Scrum нарекли долю управління проєктами з розробки ПЗ, він може також використовуватися в роботі команд обслуговувань програмного забезпечення (software maintenance teams), або як підхід управління розробкою і супроводом програм: Scrum of Scrums.
Визначення
Scrum — це кістяк процесу, який включає набір методів і попередньо визначених ролей. Головні дійові особи — ScrumMaster, той хто опікується процесами, веде їх і працює як керівник проєкту, Власник Продукту, людина, що представляє інтереси кінцевих користувачів та інших зацікавлених в продукті сторін, та Команду, яка включає розробників.
Протягом кожного спринту, 15-30 денного періоду (тривалість визначається командою), працівники створюють функціональний ріст програмного забезпечення.
Набір можливостей, які імплементуються кожного спринту, приходять з етапу, що має назву product backlog (документація запитів на виконання робіт), який має найвищу пріоритетність за рівнем вимог до роботи, що повинна бути виконана. Запити на виконання робіт (backlog items), що визначені протягом наради з планування спринту (sprint planning meeting), переміщуються в етап спринту. Протягом цієї наради Власник Продукту інформує про завдання, які він хоче, аби були виконані. Тоді Команда визначає, скільки з бажаного вони можуть зробити, щоб завершити необхідні частини протягом наступного спринту. Протягом спринту команда виконує визначений фіксований список завдань (т.з. backlog items). Впродовж цього періоду ніхто не має права змінювати перелік запитів на виконання робіт, що слід розуміти, як заморожування вимог (requirements) протягом спринту.
Ролі (дійові особи)
За методикою Scrum у виробничому процесі є визначені ролі, що розбиті на дві групи — «свиней» та «курей». Ці назви використані через жарт про свиню та курку.
Свиня та курка йшли собі дорогою. Курка подивилася на свиню, й каже «А відкриймо ресторан!» Свиня подивилася на курку, й відповідає «Добра думка, а що ми будемо подавати на стіл?» Курка подумала, й каже: «Чому б не подавати яєчню зі шкварками?». «Я не згодна», відповідає свиня, «тоді я буду повністю віддана цій справі (досл. повністю приготована, англ. committed), а ти — лише залучена до неї (англ. involved).»
Отже, свині використовуються для побудови продукту регулярно і часто (повністю задіяні), тоді як будь-які інші — кури, ті, що зацікавлені (і задіяні) в проєкті, але не мають прямого стосунку до приготування страви. Потреби, бажання, ідеї та вплив курей беруться до уваги, але їм не завжди дозволяють прямо впливати, видозмінювати або включатися в хід Scrum проєкту.
«Свині»
Свині повністю задіяні в проєкті, у скрам-процесі, так би мовити вони єдині з «власним беконом» на виробничій лінії.
- Власник Продукту (Product Owner)
Власник Продукту представляє зацікавлені сторони та є голосом клієнта. Він є відповідальним за забезпечення того що команда додає цінність до бізнесу.
- Керівник (ScrumMaster)
Методологія Scrum застосовується за сприяння Scrum-керівника, який є відповідальним за спроможність команди виконати поставлені цілі і вирішення складнощів, які виникають.
- Команда розробників (Scrum Team)
Команда розробників є відповідальною за доставку потенційно готових частин продукту в кінці кожного спринту (the sprint goal). Команда складається з 3-9 людей що виконують роботу (аналізують, виконують дизайн, пишуть код, тестують, готують документацію і таке інше). У Scrum, команда є самокерованою.
«Кури»
- Користувачі (Users)
- Клієнти, Продавці (Stakeholders)
- Експерти-консультанти (Consulting Experts)
Артефакти
Product backlog (беклог)
Product backlog — це документ, який має список вимог до функціональності, які упорядковані згідно зі ступенем важливості. Product backlog представляє список того, що повинно бути реалізовано. Елементи цього списку називаються «історіями» (user story) або елементами backlog-у (backlog items). Product backlog відкритий для редагування усім учасникам Scrum-процесу.
- Обов'язкові поля
- ID — унікальний ідентифікатор, порядковий номер, який використовується для ідентифікації історій у разі їх перейменування.
- Назва (Name) — стислий опис історії. Він повинен бути однозначним, щоб і розробники і product owner могли зрозуміти, про що йдеться і відрізнити одну історію від іншої.
- Важливість (Importance) — ступінь важливості даної історії на погляд product owner ’a. Зазвичай являє собою натуральне число, іноді для цієї цілі використовуються числа Фібоначчі. Чим більше значення, тим вищий пріоритет.
- Попередня оцінка (initial estimate) — початкова оцінка об'єму робіт, необхідних для реалізації історії порівняно з іншими історіями. Вимірюється у story point'ах. Приблизно відповідає числу «ідеальних людино-днів».
- Як продемонструвати (how to demo) — стисле пояснення того, як завершена задача буде продемонстрована у кінці спринта. Дане поле може являти собою код автоматизованого приймального тесту.
- Додаткові поля
- Іноді, також, використовуються додаткові поля у product backlog, в основному для того, щоб допомогти product owner'у визначитися з його пріоритетами.
- Категорія (track). Наприклад, «панель управління» чи «оптимізація». За допомогою цього поля product owner може легко вибрати усі пункти категорії «оптимізація» і задати їм низький пріоритет.
- Компоненти (components) — указує, які компоненти (наприклад, база даних, сервер, клієнт) будуть зачеплені при реалізації історії. Дане поле складається з групи checkbox'ів, які відмічаються, якщо відповідні компоненти потребують змін.
- Ініціатор запиту (requestor). Product owner може захотіти зберігати інформацію про усіх замовників, зацікавлених у даній задачі. Це потрібно для того, щоб тримати їх у курсі діла про хід виконання робіт.
- ID у системі обліку помилок (bug tracking ID) — якщо ви використовуєте окрему систему обліку помилок, тоді у описі історії корисно зберігати посилання на всі дефекти, які до неї відносяться.
Sprint backlog
Sprint backlog — містить функціональність, обрану Product Owner із Product Backlog. Всі функції розбиті по задачах, кожна з яких оцінюється командою. Кожен день команда оцінює об'єм роботи, який необхідно провести для завершення задачі.
Burndown chart
Burndown chart — показує, скільки вже виконано і скільки ще залишається зробити.
Розширення
Критерії готовності (Definition of ready, DoR) — критерії готовності задачі до того, щоб взяти її у роботу.
Критерії повної готовності (Definition of Done, DoD) — критерії повної готовності задачі.
Критерії прийнятності (Acceptance Criteria, AC) — критерії того, що задача не тільки повністю готова, але й в результаті працює як потрібно.
Церемонії (зустрічі)
Планування спринта (Sprint Planning Meeting)
Проходить на початку нової ітерації Спринта.
- Із Product Backlog обираються задачі, зобов'язання по виконанню яких за спринт бере на себе команда;
- На основі обраних задач створюється Sprint Backlog. Кожна задача оцінюється у ідеальних людино-годинах;
- Розв'язання задачі не повинне займати більше 12 годин або одного дня. За необхідності задачу розбивають на підзадачі;
- Обговорюється та визначається, яким чином буде реалізовано цей об'єм робіт;
- Тривалість наради обмежена зверху 4-8 годинами в залежності від тривалості ітерації, досвіду команди тощо;
- (перша частина наради) Беруть участь Product Owner + Команда: обирають задачі із Product Backlog;
- (друга частина наради) Бере участь лише команда: обговорюють технічні деталі реалізації, наповнюють Sprint Backlog.
Щоденна нарада (Daily Scrum Meeting)
Відбувається кожен день протягом спринта. Є «пульсом» ходу спринта. Нараді властиві наступні обмеження:
- починається точно вчасно;
- всі можуть спостерігати, але говорять тільки «свині»;
- триває не більш ніж 15 хвилин;
- проводиться в одному і тому ж місці протягом одного спринта.
Протягом наради кожен член команди відповідає на 3 запитання:
- Що зроблено з моменту попередньої щоденної наради?
- Що буде зроблено з моменту поточної наради до наступної?
- Які проблеми заважають досягненню цілей спринта? (Над рішенням цих проблем працює ScrumMaster. Зазвичай це рішення проходить за рамками щоденної наради і у складі осіб, що безпосередньо займаються даною перешкодою.)
Демонстрація (Sprint Review Meeting)
- Проходить у кінці ітерації (спринта).
- Команда демонструє внесок функціональності до продукту всім зацікавленим особам.
- Залучається максимальна кількість глядачів.
- Усі члени команди беруть участь у демонстрації (одна людина на демонстрацію або кожен показує, що зробив за спринт).
- Обмежена 4-ма годинами в залежності від тривалості ітерації і змін у продукті.
Ретроспектива (Sprint Retrospective)
- Члени команди висловлюють свою думку про минулий спринт.
- Відповідають на два основних запитання:
- Що було зроблено добре у минулому спринті?
- Що потрібно покращити в наступному?
- Виконують покращення процесу розробки (вирішують питання та фіксують вдалі рішення).
- Обмежена 1-3ма годинами.
Засоби управління проєктами, що підтримують скрам
- Banana Scrum [ 25 червня 2013 у Wayback Machine.]
- CollabNet ScrumWorks Pro [ 18 червня 2013 у Wayback Machine.]
- Hansoft [ 16 лютого 2013 у Wayback Machine.]
- Ice Scrum [ 31 березня 2015 у Wayback Machine.]
- Kunagi [ 7 травня 2021 у Wayback Machine.]
- JetBrains YouTrack [ 20 травня 2013 у Wayback Machine.]
- JIRA з використанням плагіну Green Hopper
- , ThoughtWorks Studios
- OneDesk [ 30 травня 2013 у Wayback Machine.]
- PangoScrum [ 19 червня 2013 у Wayback Machine.]
- Pivotal Tracker [ 13 червня 2013 у Wayback Machine.]
- Rally Software [ 13 червня 2013 у Wayback Machine.]
- Redmine та з використанням плагінів
- ScrumDo [ 30 травня 2013 у Wayback Machine.]
- Scrumwise [ 21 червня 2013 у Wayback Machine.]
- Scrumy [ 8 березня 2022 у Wayback Machine.]
- Sprintometer [ 11 лютого 2021 у Wayback Machine.]
- TargetProcess [ 1 жовтня 2021 у Wayback Machine.]
- Tinypm [ 30 травня 2013 у Wayback Machine.]
- VersionOne [ 2 квітня 2018 у Wayback Machine.]
- Visual Studio, Microsoft Team Foundation Server
- Yodiz [ 3 червня 2013 у Wayback Machine.]
Див. також
Примітки
- Hirotaka Takeuchi, Ikujiro Nonaka
- Harvard Business Review
- Peter DeGrace, Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms Yourdon Press Computing Series, 1990 (перше видання)
- Mike Beedle
- Sprint — ривок; кидок; біг на коротку дистанцію; спринт
- Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004, 163pp,
Посилання
- Scrum Guides на багатьох мовах [ 25 липня 2017 у Wayback Machine.] — українською [ 28 жовтня 2015 у Wayback Machine.]
- Опис скрам-процесу [ 3 лютого 2018 у Wayback Machine.]
- Книги зі скраму [ 3 лютого 2018 у Wayback Machine.]
- Корисні матеріали по скраму [ 3 лютого 2018 у Wayback Machine.]
Це незавершена стаття на тему: менеджмент. Ви можете проєкту, виправивши або дописавши її. |
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
Skram angl scrum shtovhanina sutichka navkolo m yacha u regbi pidhid upravlinnya proyektami dlya gnuchkoyi rozrobki programnogo zabezpechennya Skram chitko robit akcent na yakisnomu kontroli procesu rozrobki IstoriyaSutichka Scrum u regbi mizh Newport ta London Welsh 1904 Pidhid vpershe opisali Girotaka Takeuchi ta Ikudzhiro Nonaka v statti The New New Product Development Game Garvardskij Dilovij Oglyad sich lyut 1986 Voni vidznachili sho proyekti nad yakimi pracyuyut neveliki kros funkcionalni komandi zazvichaj sistematichno produkuyut krashi rezultati i poyasnili ce yak pidhid regbi U 1991 roci DeGrejs ta Shtal u knizhci Zli problemi spravedlivi rishennya poslalisya na cej pidhid yak na Scrum shtovhanina sutichka navkolo m yacha u regbi sportivnij termin zgadanij v statti Takeuchi i Nonaka Ken Shvaber na pochatku 1990 h vikoristovuvav pidhid yakij priviv Scrum v jogo kompaniyu Vpershe metod Scrum bulo predstavleno na zagalnij oglyad zadokumentovanim chitko sformulovanim ta opisanim spilno Sazerlendom ta Shvaberom na OOPSLA 96 v Ostini Shvaber ta Sazerlend protyagom nastupnih rokiv pracyuvali razom shob obrobiti ta opisati ves yihnij dosvid ta najkrashi praktichni zrazki dlya industriyi v odne cile v tu metodologiyu sho vidoma sogodni yak Scrum Shvaber ob yednav zusillya z Majkom Bidlom v 2001 shob detalno opisati metod v knizhci Agile Software Development with SCRUM Nezvazhayuchi na te sho dlya Scrum narekli dolyu upravlinnya proyektami z rozrobki PZ vin mozhe takozh vikoristovuvatisya v roboti komand obslugovuvan programnogo zabezpechennya software maintenance teams abo yak pidhid upravlinnya rozrobkoyu i suprovodom program Scrum of Scrums ViznachennyaSkram procesi Scrum ce kistyak procesu yakij vklyuchaye nabir metodiv i poperedno viznachenih rolej Golovni dijovi osobi ScrumMaster toj hto opikuyetsya procesami vede yih i pracyuye yak kerivnik proyektu Vlasnik Produktu lyudina sho predstavlyaye interesi kincevih koristuvachiv ta inshih zacikavlenih v produkti storin ta Komandu yaka vklyuchaye rozrobnikiv Protyagom kozhnogo sprintu 15 30 dennogo periodu trivalist viznachayetsya komandoyu pracivniki stvoryuyut funkcionalnij rist programnogo zabezpechennya Nabir mozhlivostej yaki implementuyutsya kozhnogo sprintu prihodyat z etapu sho maye nazvu product backlog dokumentaciya zapitiv na vikonannya robit yakij maye najvishu prioritetnist za rivnem vimog do roboti sho povinna buti vikonana Zapiti na vikonannya robit backlog items sho viznacheni protyagom naradi z planuvannya sprintu sprint planning meeting peremishuyutsya v etap sprintu Protyagom ciyeyi naradi Vlasnik Produktu informuye pro zavdannya yaki vin hoche abi buli vikonani Todi Komanda viznachaye skilki z bazhanogo voni mozhut zrobiti shob zavershiti neobhidni chastini protyagom nastupnogo sprintu Protyagom sprintu komanda vikonuye viznachenij fiksovanij spisok zavdan t z backlog items Vprodovzh cogo periodu nihto ne maye prava zminyuvati perelik zapitiv na vikonannya robit sho slid rozumiti yak zamorozhuvannya vimog requirements protyagom sprintu Roli dijovi osobi Za metodikoyu Scrum u virobnichomu procesi ye viznacheni roli sho rozbiti na dvi grupi svinej ta kurej Ci nazvi vikoristani cherez zhart pro svinyu ta kurku Svinya ta kurka jshli sobi dorogoyu Kurka podivilasya na svinyu j kazhe A vidkrijmo restoran Svinya podivilasya na kurku j vidpovidaye Dobra dumka a sho mi budemo podavati na stil Kurka podumala j kazhe Chomu b ne podavati yayechnyu zi shkvarkami Ya ne zgodna vidpovidaye svinya todi ya budu povnistyu viddana cij spravi dosl povnistyu prigotovana angl committed a ti lishe zaluchena do neyi angl involved Otzhe svini vikoristovuyutsya dlya pobudovi produktu regulyarno i chasto povnistyu zadiyani todi yak bud yaki inshi kuri ti sho zacikavleni i zadiyani v proyekti ale ne mayut pryamogo stosunku do prigotuvannya stravi Potrebi bazhannya ideyi ta vpliv kurej berutsya do uvagi ale yim ne zavzhdi dozvolyayut pryamo vplivati vidozminyuvati abo vklyuchatisya v hid Scrum proyektu Svini Svini povnistyu zadiyani v proyekti u skram procesi tak bi moviti voni yedini z vlasnim bekonom na virobnichij liniyi Vlasnik Produktu Product Owner Vlasnik Produktu predstavlyaye zacikavleni storoni ta ye golosom kliyenta Vin ye vidpovidalnim za zabezpechennya togo sho komanda dodaye cinnist do biznesu Kerivnik ScrumMaster Metodologiya Scrum zastosovuyetsya za spriyannya Scrum kerivnika yakij ye vidpovidalnim za spromozhnist komandi vikonati postavleni cili i virishennya skladnoshiv yaki vinikayut Komanda rozrobnikiv Scrum Team Komanda rozrobnikiv ye vidpovidalnoyu za dostavku potencijno gotovih chastin produktu v kinci kozhnogo sprintu the sprint goal Komanda skladayetsya z 3 9 lyudej sho vikonuyut robotu analizuyut vikonuyut dizajn pishut kod testuyut gotuyut dokumentaciyu i take inshe U Scrum komanda ye samokerovanoyu Kuri Koristuvachi Users Kliyenti Prodavci Stakeholders Eksperti konsultanti Consulting Experts ArtefaktiProduct backlog beklog Product backlog ce dokument yakij maye spisok vimog do funkcionalnosti yaki uporyadkovani zgidno zi stupenem vazhlivosti Product backlog predstavlyaye spisok togo sho povinno buti realizovano Elementi cogo spisku nazivayutsya istoriyami user story abo elementami backlog u backlog items Product backlog vidkritij dlya redaguvannya usim uchasnikam Scrum procesu Obov yazkovi polya ID unikalnij identifikator poryadkovij nomer yakij vikoristovuyetsya dlya identifikaciyi istorij u razi yih perejmenuvannya Nazva Name stislij opis istoriyi Vin povinen buti odnoznachnim shob i rozrobniki i product owner mogli zrozumiti pro sho jdetsya i vidrizniti odnu istoriyu vid inshoyi Vazhlivist Importance stupin vazhlivosti danoyi istoriyi na poglyad product owner a Zazvichaj yavlyaye soboyu naturalne chislo inodi dlya ciyeyi cili vikoristovuyutsya chisla Fibonachchi Chim bilshe znachennya tim vishij prioritet Poperednya ocinka initial estimate pochatkova ocinka ob yemu robit neobhidnih dlya realizaciyi istoriyi porivnyano z inshimi istoriyami Vimiryuyetsya u story point ah Priblizno vidpovidaye chislu idealnih lyudino dniv Yak prodemonstruvati how to demo stisle poyasnennya togo yak zavershena zadacha bude prodemonstrovana u kinci sprinta Dane pole mozhe yavlyati soboyu kod avtomatizovanogo prijmalnogo testu Dodatkovi polya Inodi takozh vikoristovuyutsya dodatkovi polya u product backlog v osnovnomu dlya togo shob dopomogti product owner u viznachitisya z jogo prioritetami Kategoriya track Napriklad panel upravlinnya chi optimizaciya Za dopomogoyu cogo polya product owner mozhe legko vibrati usi punkti kategoriyi optimizaciya i zadati yim nizkij prioritet Komponenti components ukazuye yaki komponenti napriklad baza danih server kliyent budut zachepleni pri realizaciyi istoriyi Dane pole skladayetsya z grupi checkbox iv yaki vidmichayutsya yaksho vidpovidni komponenti potrebuyut zmin Iniciator zapitu requestor Product owner mozhe zahotiti zberigati informaciyu pro usih zamovnikiv zacikavlenih u danij zadachi Ce potribno dlya togo shob trimati yih u kursi dila pro hid vikonannya robit ID u sistemi obliku pomilok bug tracking ID yaksho vi vikoristovuyete okremu sistemu obliku pomilok todi u opisi istoriyi korisno zberigati posilannya na vsi defekti yaki do neyi vidnosyatsya Sprint backlog Sprint backlog mistit funkcionalnist obranu Product Owner iz Product Backlog Vsi funkciyi rozbiti po zadachah kozhna z yakih ocinyuyetsya komandoyu Kozhen den komanda ocinyuye ob yem roboti yakij neobhidno provesti dlya zavershennya zadachi Burndown chart Burndown chart pokazuye skilki vzhe vikonano i skilki she zalishayetsya zrobiti RozshirennyaKriteriyi gotovnosti Definition of ready DoR kriteriyi gotovnosti zadachi do togo shob vzyati yiyi u robotu Kriteriyi povnoyi gotovnosti Definition of Done DoD kriteriyi povnoyi gotovnosti zadachi Kriteriyi prijnyatnosti Acceptance Criteria AC kriteriyi togo sho zadacha ne tilki povnistyu gotova ale j v rezultati pracyuye yak potribno Ceremoniyi zustrichi Planuvannya sprinta Sprint Planning Meeting Prohodit na pochatku novoyi iteraciyi Sprinta Iz Product Backlog obirayutsya zadachi zobov yazannya po vikonannyu yakih za sprint bere na sebe komanda Na osnovi obranih zadach stvoryuyetsya Sprint Backlog Kozhna zadacha ocinyuyetsya u idealnih lyudino godinah Rozv yazannya zadachi ne povinne zajmati bilshe 12 godin abo odnogo dnya Za neobhidnosti zadachu rozbivayut na pidzadachi Obgovoryuyetsya ta viznachayetsya yakim chinom bude realizovano cej ob yem robit Trivalist naradi obmezhena zverhu 4 8 godinami v zalezhnosti vid trivalosti iteraciyi dosvidu komandi tosho persha chastina naradi Berut uchast Product Owner Komanda obirayut zadachi iz Product Backlog druga chastina naradi Bere uchast lishe komanda obgovoryuyut tehnichni detali realizaciyi napovnyuyut Sprint Backlog Shodenna narada Daily Scrum Meeting Vidbuvayetsya kozhen den protyagom sprinta Ye pulsom hodu sprinta Naradi vlastivi nastupni obmezhennya pochinayetsya tochno vchasno vsi mozhut sposterigati ale govoryat tilki svini trivaye ne bilsh nizh 15 hvilin provoditsya v odnomu i tomu zh misci protyagom odnogo sprinta Protyagom naradi kozhen chlen komandi vidpovidaye na 3 zapitannya Sho zrobleno z momentu poperednoyi shodennoyi naradi Sho bude zrobleno z momentu potochnoyi naradi do nastupnoyi Yaki problemi zavazhayut dosyagnennyu cilej sprinta Nad rishennyam cih problem pracyuye ScrumMaster Zazvichaj ce rishennya prohodit za ramkami shodennoyi naradi i u skladi osib sho bezposeredno zajmayutsya danoyu pereshkodoyu Demonstraciya Sprint Review Meeting Prohodit u kinci iteraciyi sprinta Komanda demonstruye vnesok funkcionalnosti do produktu vsim zacikavlenim osobam Zaluchayetsya maksimalna kilkist glyadachiv Usi chleni komandi berut uchast u demonstraciyi odna lyudina na demonstraciyu abo kozhen pokazuye sho zrobiv za sprint Obmezhena 4 ma godinami v zalezhnosti vid trivalosti iteraciyi i zmin u produkti Retrospektiva Sprint Retrospective Chleni komandi vislovlyuyut svoyu dumku pro minulij sprint Vidpovidayut na dva osnovnih zapitannya Sho bulo zrobleno dobre u minulomu sprinti Sho potribno pokrashiti v nastupnomu Vikonuyut pokrashennya procesu rozrobki virishuyut pitannya ta fiksuyut vdali rishennya Obmezhena 1 3ma godinami Zasobi upravlinnya proyektami sho pidtrimuyut skramBanana Scrum 25 chervnya 2013 u Wayback Machine CollabNet ScrumWorks Pro 18 chervnya 2013 u Wayback Machine Hansoft 16 lyutogo 2013 u Wayback Machine Ice Scrum 31 bereznya 2015 u Wayback Machine Kunagi 7 travnya 2021 u Wayback Machine JetBrains YouTrack 20 travnya 2013 u Wayback Machine JIRA z vikoristannyam plaginu Green Hopper ThoughtWorks Studios OneDesk 30 travnya 2013 u Wayback Machine PangoScrum 19 chervnya 2013 u Wayback Machine Pivotal Tracker 13 chervnya 2013 u Wayback Machine Rally Software 13 chervnya 2013 u Wayback Machine Redmine ta z vikoristannyam plaginiv ScrumDo 30 travnya 2013 u Wayback Machine Scrumwise 21 chervnya 2013 u Wayback Machine Scrumy 8 bereznya 2022 u Wayback Machine Sprintometer 11 lyutogo 2021 u Wayback Machine TargetProcess 1 zhovtnya 2021 u Wayback Machine Tinypm 30 travnya 2013 u Wayback Machine VersionOne 2 kvitnya 2018 u Wayback Machine Visual Studio Microsoft Team Foundation Server Yodiz 3 chervnya 2013 u Wayback Machine Div takozhBerezhliva rozrobka programnogo zabezpechennya Upravlinnya proyektami Masshtabovana gnuchka rozrobkaPrimitkiHirotaka Takeuchi Ikujiro Nonaka Harvard Business Review Peter DeGrace Leslie Hulet Stahl Wicked Problems Righteous Solutions A Catalog of Modern Engineering Paradigms Yourdon Press Computing Series 1990 pershe vidannya ISBN 0 13 590126 X Mike Beedle Sprint rivok kidok big na korotku distanciyu sprint Agile Project Management with Scrum Ken Schwaber Microsoft Press January 2004 163pp ISBN 0 7356 1993 XPosilannyaScrum Guides na bagatoh movah 25 lipnya 2017 u Wayback Machine ukrayinskoyu 28 zhovtnya 2015 u Wayback Machine Opis skram procesu 3 lyutogo 2018 u Wayback Machine Knigi zi skramu 3 lyutogo 2018 u Wayback Machine Korisni materiali po skramu 3 lyutogo 2018 u Wayback Machine Ce nezavershena stattya na temu menedzhment Vi mozhete dopomogti proyektu vipravivshi abo dopisavshi yiyi