— Отже, я хочу розповісти тобі про Agile та Scrum.
На початку 21 століття уявлення про програмування перекинулося.
Т. до. всі переконалися, що довгострокове планування не працює, було вирішено взагалі від нього відмовитись.
— Це як же?
— А ось так.
Було придумано максимально гнучкий підхід до управління роботою.
Основні концепції гнучкої розробки:< /span>
- люди та взаємодія важливіші за процеси та інструменти;
- працюючий продукт важливіший за вичерпну документацію;
- співпраця із замовником важливіша за узгодження умов контракту;
- готовність до змін важливіша за дотримання початкового плану.
Принципи швидкої розробки:< /p>
- задоволення клієнта за рахунок раннього та безперебійного постачання цінного програмного забезпечення;
- привітання змін вимог навіть наприкінці розробки (це може підвищити конкурентоспроможність отриманого продукту);
- часте постачання робочого програмного забезпечення (кожний місяць чи тиждень або ще частіше);
- тісне, щоденне спілкування замовника з розробниками протягом усього проекту;
- працююче програмне забезпечення — найкращий вимірник прогресу;
- спонсори, розробники та користувачі повинні мати можливість підтримувати постійний темп на невизначений термін;
- постійна увага до покращення технічної майстерності і зручному дизайну;
- простота - мистецтво не робити зайвої роботи;
- найкращі технічні вимоги, дизайн та архітектура виходять у самоорганізованої команди;
- постійна адаптація до обставин, що змінюються.
Основною проблемою розробки програми було визнано те, що ніхто з учасників на жодному етапі не має всієї повноти інформації про те, що робити.
Замовник може розповісти, як він бачить програму, але щось він упускає, щось вважає самим собою зрозумілим.
Менеджер взагалі повинен перекладати вимоги з мови програмістів на мову замовника та назад.
Занадто багато невизначеності.
Часто вимоги замовника виглядають так: зробите якось, потім покажіть мені, якщо мені не сподобається – переробіть.
— М-так. Як усе запущено.
— Згідно з новим баченням, програмісти більше не випускають продукт або програму, вони реалізують потрібну замовнику функціональність. — А в чому різниця?
— Ну, дивись, припустимо, раніше на розробку програми йшов рік. І лише за перші півроку було вже на що подивитися. Це як будувати великий будинок: спочатку котлован, потім фундамент, стіни, дах, оздоблення тощо. А тепер програмісти намагаються якомога раніше випустити потрібний замовнику функціонал. Це ніби будівельники спочатку збудували курінь, потім часник, потім невеликий будиночок, потім уже почали робити великий будинок і той - частинами.
Якщо врахувати, що замовник швидше за все сам точно не знає, чого хоче, то це дуже розумний підхід.
Припустимо, хоче замовник великий мисливський будиночок.
Збудували йому маленький, він у ньому пожив. зиму і вирішив, що будинок із дерева йому не подобається. Робитимемо з цегли у 4 шари.
Пожив поряд із озером влітку, а його комарі заїли. Він десь чув, що озеро - це круто, от і хотів. А тепер йому озеро не потрібне. Так і будинок будувати легше: немає озера – немає загрози паводків, от і можна будувати будинок не на палях, а на землі, а це на 25% швидше.
— Цікава аналогія. Невже замовник так часто змінює свої вимоги? -max-width="614" alt="Agile, Scrum, waterfall - 1" src="https://cdn.javarush.com/images/article/263d7ac5-e75d-459a-9640-05f5fe59c189/original.png" >
— Та річ тут не в замовнику.
По-перше, дуже складно уявити наперед, що вийде. І менеджери, і тестувальники, і програмісти теж бувають у такій ролі. І теж змінюють свою думку залежно від того, що вийшло.
А по-друге, хіба вимоги замовника – не головне? Адже сенс усієї цієї роботи – це зробити саме те, що замовнику потрібно, а не те, що він сказав на початку робити.
Адже раніше як було: бізнес-аналітики складуть список усіх вимог, цей список включають до договору, підписують і працюють тільки по ньому.
< p>Якщо в ньому немає чогось, що дуже потрібно замовнику, але про що забули, ніхто цього щось робити не буде.— Зрозуміло. Працювати за планом легше, але не все можна зробити за планом!
— Саме.
Тому були придумані методики гнучкої розробки.
І про найпопулярніше з них – Scrum — я тобі сьогодні розповім.
Основна фішка скраму - це розбиття розробки проекту на невеликі ітерації - зазвичай 2-4 тижні. Така ітерація називається «спринт».
Спочатку спринту проводиться «планування спринту» — нарада години на 3-4.
Наприкінці проводиться «демо» — демонстрація всіх повністю завершених завдань.
Ось як завжди все відбувається:
Перед першим спринтом, замовник (або його представник), формує список вимог – набір того, що має вміти програма. Такі вимоги зазвичай називають «user story», а замовника – «product owner».
Product owner перекладається як власник товару, т.к. продукт пишеться для нього і він і тільки він визначає список вимог - що треба, коли і в якому порядку. Крім того, product owner зазвичай ще призначає завданням пріоритет. Спочатку реалізовуватимуться завдання з найвищим пріоритетом. Увесь список вимог ще називають «product backlog» або «резерв продукту».
Коли починається спринт, всі збираються на нараду. Веде його зазвичай scrum-master: зазвичай це хтось із команди. Мета наради – відібрати завдання (user story) на поточний спринт (ітерацію розробки).
Спочатку кожному завданню дається колективна приблизна оцінка в « абстрактних людино-днях», їх ще називають «story point». Потім команда вирішує, скільки завдань вона встигне зробити за цей спринт.
При цьому команда сама вирішує, скільки завдань вона встигне зробити за спринт.
Припустимо, product owner очікував, що команда відбере 7 перших завдань, а вона відібрала всього 5, то завдання 6 та 7 переносяться на наступний спринт. Якщо product owner це не влаштовує, він може підвищити пріоритет 6 та 7 завдання, щоб їх точно відібрали, але тоді зі спринту випадуть якісь інші завдання.
Також scrum master може запропонувати розбити частину завдань на дрібніші і розставити їм різні пріоритети, щоб product owner виявився максимально задоволеним.
У цьому є сенс наради – завдання можна міняти та розбивати, можна міняти їм пріоритети і т.д. Це саме та робота, яку не було видно на самому початку, але яка приносить дуже багато користі.
— Зрозумів, це як кермувати машиною. Навіть якщо на початку здається, що треба їхати тільки прямо, то на ділі треба постійно об'їжджати ями і керувати то вправо, то вліво, обганяти і поступатися дорогою.
— Так, якось так.
Список завдань, відібраних для спринту, називають sprint backlog або резерв спринту.
Программісти розподіляють, хто і що робитиме, а тільки потім приступають до роботи. Для підвищення ефективності, скрам пропонує, щоб щодня проводилися наради по 5-15 хвилин, де всі б розповідали один одному, хто що зробив за минулий день і чим займатиметься сьогодні.
— Командна робота. Поважаю!
— Для кращої наочності зазвичай пропонують відображати поточний стан спринту на спеціальній дошці:
Зверни увагу на три колонки зліва.
На стікерах пишуться короткі назви завдань. А стікери переклеюються в іншу колонку залежно від статусу (У планах, У процесі, Готово)
Дело ти бачиш діаграму згоряння. Там щодня відображається список незроблених завдань. В ідеалі за час спринту кількість неготових завдань падає до нуля.
Коли спринт завершується, scrum-master проводить demo, де демонструється список всього, що повністю зроблено.
Потім проводиться «розбір польотів» — нарада теж на кілька годин. На ньому зазвичай намагаються з'ясувати, що було зроблено добре, а що (і як) можна було зробити краще.
Зазвичай за 2-3 спринти можна виявити основні проблеми, які заважають команді працювати ефективніше, та усунути їх. Це призводить до більшої продуктивності, не збільшуючи навантаження на команду. Таке було неможливим до ери гнучких методологій.
У середині спринту, іноді ще проводять «чісування» — Нарада присвячена плануванню наступного спринту. На ньому зазвичай уточнюють пріоритети завдань, а також можна розбити деякі завдання на частини та/або додати нові завдання до product backlog – резерв продукту.
В принципі у мене все – це оглядова лекція, і на пальцях її не пояснити, але тут ти можеш почитати пару хороших статей на цю тему:
http://scrum.org.ua/wp-content/uploads/2008/12 /scrum_xp-from-the-trenches-rus-final.pdf
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ