1. 8.1 Код
2. 8.2 Тести
3. 8.3 Користувальницькі історії
4. 8.4 Історії. нарахування балів
5. 8.5 Швидкість
6. 8.6 Визначення "Зроблено"

Анотація: Для підтримки своїх практик agile підходи визначили кілька артефактів, деякі з них конкретні, як "картки історій", інші віртуальні - чисто концептуальної природи. Почнемо з головних віртуальних артефактів: працюючий код, тести, призначені для користувача історії, бали за історію, швидкість, визначення зробленого, беклог продукту. Потім перейдемо до розгляду конкретних артефактів: робочого простору, карток історії, завдань, панелі історій, діаграмі виконаних робіт. І на закінчення розглянемо п'ять артефактів, чотири з яких віртуальні, а один конкретний, що фігурують постійно у всіх обговореннях agile - хоча і негативно, як пастки, яких слід уникати: перешкоди, технічні борги, витрати, залежно, діаграми залежностей.

8.1 Код

Код - це центр agile світу, і головна цінність - це працюючий код, який може бути виконаний як частина розробки системи. Акцент на коді є частиною agile прагнення піти в програмної інженерії від процесів і планів і перейти до конкретних результатів, які тільки і важливі для успіху програмного проекту.

8.2 Тести

Поряд з кодом тести - це головний продукт, рекомендований усіма agile підходами. Екстремальне програмування реабілітувала тести, зараховуючи їх до основної концепції програмної інженерії. Два види артефактів фактично входять в цю концепцію (пізніше один з них став колекцією примірників іншого): юніт тести і набір регресійних тестів.

Юніт тест являє опис деякого часткового тесту і очікуваних результатів його виконання. Процес юніт тестування зазнав істотних змін у зв'язку з появою інструменарія тестування, званого xUnit, як наприклад JUnit для Java. Як зазначалося в попередньому розділі, не випадково, що Бек, одна з найбільш шанованих особистостей в XP, є (разом з такими людьми, як Еріх Гамма) одним з авторів цього інструментарію. Юніт тест в стилі xUnit приймає форму класу і включає:

• програму (метод), що виконує тест;
• програми підготовки умов тестування і відновлення контексту після виконання тесту, наприклад, установка з'єднання з базою даних і відновлення вихідного стану бази після проходження тесту;
• затвердження (відомі також як оракул), що визначають умови успішного проходження тесту. Розглянемо, наприклад, операцію, обробну запит на оренду автомобіля, і, якщо запит виявиться прийнятним, встановлює змінну age - вік водія; тест для цієї операції може включати твердження is_accepted implies (age> = 18 & age <= 75).

Цей стандартний підхід до визначення тестів представляє одне з найважливіших дотіженій в мистецтві програмної інженерії за останні двадцять років. Він застосовується в багатьох проектах, навіть в тих, що не використовують agile методи.

Існує і кращий підхід. Замість того щоб розглядати код і тести як окремі артефакти і пов'язувати затвердження тільки з тестами, можна розглядати затвердження як механізм специфікації та записувати їх як інтегральну частину коду в формі інваріантів класу, передумовою та постусловіем методів класу. Таким підходом є проектування за контрактом, що використовується в мові Eiffel [Meyer 1997], [Meyer 2009]. При цьому підході з'являється можливість автоматично генерувати тести за кодом і твердженнями. Все це, однак, предмет іншого обговорення.

Набір регресійних тестів представляє колекцію юніт тестів. Він включає будь-який тест, який в деякій точці проекту не був успішно виконаний. Один із феноменів розробки ПО полягає в тому, що "старі помилки, вже виправлені, мають тенденцію повертатися на наступних кроках розробки". Причини різні: помилки контролю версій, неповне усунення помилки, найчастіше використання невдалого зразка. Цей феномен називають регресією. Одна з цілей створення регресійного набору тестів полягає в тому, щоб впоратися з проблемою регресії шляхом постійного виконання тестів як частини безперервної інтеграції.

Фактично немає причин включати в цей набір тільки "падаючі" тести. Ми бачили, що один з важливих вкладів agile (перш за все XP) - це правило, відповідно до якого кожному елементу коду відповідає, щонайменше, один тест. XP вимагає, щоб тест будувався і запускався до реалізації відповідного коду, так що тест автоматично стає "падаючим" і включається в регресійний набір тестів. Амблер зазначає, що аджілісти ввели в практику якщо не TDD, то, по крайней мере, регресійні тестування.

Набір регресійних тестів представляє один з визначальних agile артефактів, точно так же, як безперервна інтеграція - одна з визначальних agile практик, навіть для команд, які не сприймають більш екстремальні ідеї, такі як TDD.

Регресійний набір - ключова цінність будь-якого добре керованого програмного проекту. Частково його привабливість в тому, що він представляє істинно зростаючий продукт. Ми бачили, що "зростання", що пропагується в agile підходах, не завжди добре працює при застосуванні до розробки. Але набір тестів має властивість "зростання" за своєю природою. Він може починатися з зовсім невеликого безлічі, і, якщо кожен дотримується дисципліни "ні п'яді коду без тесту", зростає швидко і стає одним з основних ресурсів проекту.

8.3 Користувальницькі історії

Призначені для користувача історії становлять базовий набір вимог в agile методах.

Призначена для користувача історія представляє опис дрібнозернистої функціональності, як її бачать користувачі. Більш загальним поняттям є "випадок використання" або "варіант використання", детально пророблений в добре відомій книзі Якобсона [Jacobson 1992]. Варіант використання може бути великим (грубозернистим): він описує сценарій повного взаємодії, наприклад, процес замовлення елемента на комерційному сайті. Призначена для користувача історія багато менше.

Стандартний стиль agile - опис користувальницьких історій. У цьому стилі призначена для користувача історія задається трійкою: <роль, мета, переваги>. наприклад:

"Як співробітник Я хочу скасовувати замовлення, так щоб розумні запити на виключення полісів можна було узгоджувати".

Хоча деякі проекти приймають такий фіксований стиль, можливі різні варіанти опису.

Визначальне властивість користувальницьких історій як засобу для опису функціональності системи в тому, що кожна історія описує одиницю функціональності з точки зору користувача, точніше з позицій ролі користувача, оскільки є поняття ролі, але немає поняття просто "користувач". "Змінити реляційну базу даних на НЕ-SQL рішення" - це не призначена для користувача історія. Для інтеграції такого ахітектурного рішення необхідно визначити його як завдання для користувальницької історії, яка описує переваги, видимі користувачеві. наприклад:

"Як менеджер з маркетингу Я хочу створити нові пропозиції споживачам без відповідності існуючим схемам, так щоб була можливість більш швидко відповідати потребам ринку".

Переваги, пов'язані з одними історіями як основою розробки, в тому, що команда орієнтується на переваги, що доставляються системою користувачеві, а не зациклюється на внутрішніх потребах самої системи. Але в цьому величезному перевазі одночасно криється і дефектність такого підходу. Розмір призначеної для користувача історії, як випливає з визначення, залишає мало простору для припущень. Розглянемо два приклади, кожен з яких додає функцію в систему купівлі квитків на літак.

1. "Як клієнт компанії я хочу вводити код, що дає право на знижку, в кінці резервування, а не на початку, щоб уникнути повторення всієї процедури з самого початку, якщо я не подумав про це заздалегідь.
2. Як клієнт компанії я хочу використовувати один і той же інтерфейс як при оплаті польоту, так і при покупці, оплачуваної за рахунок накопичених миль, щоб уникнути повторення всієї процедури з самого початку, якщо я не подумав про це заздалегідь.

Історія 2 інспірована ситуацією, розказаної Поппендік, в якій компанія порушила Lean принцип "цілісності", надавши дві різні системи для покупки квитка і покупки, оплачуваної за рахунок накопичених миль.

Ці дві історії зовні схожі, але істотно розрізняються по складності. Реалізація історії 1 представляє рутинну задачу, на яку потрібно максимум один день роботи. Припускаючи, що дві системи продажу квитків (за готівку і за рахунок компенсації за накопичені милі) розрізняються, як в ситуації, розказаної Поппендік, реалізація історії 2 зажадає злиття двох систем. Реалізація злиття двох систем вимагає значних зусиль. Це звичайна ситуація - різні історії вимагають різних зусиль для їх реалізації, що призводить до необхідності вводити оцінку складності історій, що вимірюється в балах. Тема складності буде обговорюватися в наступному розділі. Зараз же поговоримо про зусилля різного типу. Одні зусилля носять характер зростаючого вдосконалення, інші - хірургічного втручання. Специфікування двох різних за характером завдань в одній і тій же формі призначених для користувача історій приховує їх принципово різну природу. Історію 2 краще явно специфікувати як зміна архітектурного рішення, навіть якщо не буде вказано, які переваги принесе це рішення конкретного користувача.

Відсутність такої перспективи може привести до нестабільних проектам і марною роботі. Кожен може уявити існування користувальницьких історій, які говорять про необхідність замовлення квитків за рахунок компенсації накопичених миль. Реалізація цих історій може призводити до створення окремої системи. Можуть з'являтися нові історії, і в якийсь момент виявиться, що ця система стає настільки ж складною, як і звичайна система покупки квитків. Природно виникне питання про злиття систем. Правильний підхід, що дозволяє уникнути дублювання і марних витрат, міг би бути заснований на архітектурному передбаченні і усвідомленні на ранніх етапах, що авіакомпанія повинна мати модель предметної області, що покриває всі концепції резервування квитків. Обидві розглянуті системи покупки в цьому випадку мали б в підставі одну і ту ж модель. Такий підхід вимагає абстрагування від індивідуальних користувальницьких історій, вимагає деякого системного бачення ситуації, концентрації на фундаментальних властивостях системи. Все це призводить до необхідності спочатку розробляти архітектуру, перш за все модель предметної області. Ця модель буде підтримувати різні призначені для користувача історії, передбачені спочатку, і ті, що з'являться пізніше.

До речі, все сказане цілком поєднується з одним із принципів agile підходу Lean - "Бачити Ціле". Але Поппендік не показує, як цей принцип може поєднуватися з розробкою, повністю заснованої на призначених для користувача історіях. Він не поєднується.

Винесення користувальницьких історій на передній план є важливим внеском agile. Вони грають важливу роль, але не ту, що їм відводить agile. В якості основи розробки вони призводять до системи, зшиваємо з шматочків, до системи, де одна функція додається за одною без належної уваги до інфраструктури в цілому. Правда, роботи зі створення інфраструктури не приносять слави, в agile підходах їх намагаються відсунути в сторону, оскільки вони не приносять користувачеві негайних видимих ​​переваг. Заміна реляційної бази даних на НЕ-SQL рішення не додає функціональності, але може бути критичною з позицій розширюваності і масштабування системи. Заміна структури даних, заснованої на деревах, структурою, заснованою на хеш-таблицях, річ загадкова для споживачів, що змушує їх гадати, "а чим це займаються розробники вже другий тиждень"? Тут немає ніяких користувальницьких історій, і все ж це може бути ключовим рішенням для проекту в цілому.

Точно так же, як тест, навіть мільйони тестів, не можуть замінити специфікацію, призначені для користувача історії (і варіанти використання) не можуть замінити вимоги і проектування архітектури. Унікальна роль історій, аналогічна ролі тестів для специфікацій, полягає в тому, що вони забезпечують механізм перевірки правильності вимог і проектування. Вимоги високого рівня мають переваги абстракції і спільності, але несуть ризик непрактичність, пропуску випадків, важливих для користувача. Складання списку призначених для користувача історій не повинно замінювати написання загальних вимог, але це важливий крок в розумінні того, що ніщо важливе не забуте. Вони дозволяють проводити наскрізний контроль, недостатній для повного опису системи, але необхідний для її успішної роботи.

Одного з моїх колег якось попросили проконсультувати архітектуру забавного нового комп'ютера, повну нових концепцій, об'єктно-орієнтовану і так далі. Після прослуховування з ентузіазмом представленої презентації його першою реакцією було: "Дуже вражаюче, спасибі, але як я можу долучати і зберігати дані?" Йому не вистачало типових користувальницьких історій. Як тести пропонованої системи вони не значимі. Як спосіб побудови системи (хто буде конструювати архітектуру комп'ютера на основі завантаження і зберігання?) Вони недостатні. Проте, вони важливі.

Надаючи призначеним для користувача історіям занадто велике значення, ми зменшуємо роль завдань, критичних для всіх застосувань, для того роду діяльності, яка є предметом критики з боку agile, - побудова моделі предметної області. Ця модель (в припущенні об'єктно-орієнтованої розробки) представляє безліч класів, що покривають фундаментальні концепції створюваної системи: польоти і накопичені милі, службовці та квитанції, клієнти і кредитні карти, абзаци і шрифти, телефонні виклики і текстові повідомлення. Ці та інші концепції проектуються з асоційованими операціями, відносинами між класами - спадкуванням, клієнт-постачальник. При проектуванні предметної області увага приділяється в першу чергу бізнес-аспектів системи, а не тільки аспектам, що носять чисто програмний характер, - доступу до баз даних і призначеним для користувача інтерфейсів. Побудована в результаті модель предметної області не задає функціональність, що поставляється користувачеві. І все ж ця модель являє міцний скелет, що дозволяє успішно розвивати систему.

Можна перестаратися і мати "дуже багато хороших речей". Існує ризик проектування системи "на всі часи", нехтуючи тим, що користувачам потрібна видима функціональність. І це в той момент, коли повинні з'явитися призначені для користувача історії, які здійснюють перевірку на реальність. Техніка дуального програмування, обговорювана в "Практики agile: технічні" , Грає тут важливу роль, дозволяючи організувати потрібну суміш двох підходів двома різними способами:

• послідовно: віддаючи перевагу побудови моделі предметної області в початковій фазі проекту, що дозволить створити міцну основу; потім фокус зміщується на поставку функціональності, видимої користувачеві завдяки призначеним для користувача історіям;
• паралельно: працювати одночасно над обома аспектами, постійно інформуючи один одного.

Грунтуватися виключно на призначених для користувача історіях як на джерелі вимог недостатньо для побудови міцного базису системи. Такий вузький погляд є одним з головних обмежень agile методів.

8.4 Історії. нарахування балів

Успішний контроль проекту вимагає як оцінки витрат на розробку до початку ітерації, так і вимірювання прогресу в період виконання і в кінці ітерації.

Ми розглядали прийоми оцінювання під час обговорення гри в планування і покер планування ( "Практики agile: виробничі процеси" і "Практики agile: виробничі процеси" ). Точно так само важливо проводити вимір того, що зроблено в процесі розвитку проекту.

При проведенні як оцінок, так і вимірювань необхідно вибрати одиницю вимірювання. Артефакти в цьому і наступному розділах представляють відповідь agile на це питання.

Традиційно в програмної інженерії такою одиницею є людино-місяць або людино-день. Цей захід хороша для бухгалтерів, які розраховують зарплату і визначають витрати ІТ, але як метрика ефективності проекту вона не настільки корисна. Крім знання того, скільки часу було витрачено, ми хочемо знати, що ж досягнуто при цих тимчасових витратах. (Кожен, хто коли-небудь мав справу з батьками студента, що розповідають "як багато і наполегливо працював студент і чому ж у нього погана оцінка", розуміє, в чому різниця.)

В якості запобіжного все ще широко вікорістовується підрахунок числа рядків заключний коду. Число рядків неважко підрахуваті, но, здається, це єдиний аргумент на Користь такого заходу. Навіть якщо припустити, що це хороший показник функціональності (спірне твердження), важко уявити, як можна заздалегідь підрахувати цей показник для майбутньої системи. Показник незручний і для вимірювання прогресу розробки. (Спасибі, що ви мені сказали, що вже зробили 85 000 строк, але чи означає це, що робота виконана на 90%, 50% або зроблено тільки 10% роботи.)

Зазвичай, кращою мірою є число функцій, розроблених при створенні системи. Але це число важко оцінити заздалегідь, і воно не завжди підходить при застосуванні сучасної об'єктно-орієнтованої технології розробки, де абстракція даних так само важлива, як і методи обробки даних.

У світі agile основою для вимірювання прогресу розробки природним чином став прийнятий спосіб вимірювання функціональності - призначені для користувача історії. Зрозуміло, що не слід просто підраховувати число історій: історія історії ворожнечу. Тому виникло поняття оцінки історії - число балів, яка нараховується історії, що характеризує її складність.

Одиницею може служити день роботи, але можуть бути й інші критерії. Наприклад, за одиницю можна прийняти найпростішу історію, тоді всі інші будуть оцінюватися щодо цієї базисної історії. За словами Кона [Cohn 2006]:

Краса в тому, що оцінювання історій в балах повністю відокремлює оцінювання трудомісткості розробки від оцінювання її тривалості. Звичайно, трудомісткість і розклад корельовані між собою, але їх поділ дозволяє оцінити кожен показник незалежно. Фактично ви паче не оцінюєте тривалість проекту: вона автоматично виводиться з числа ітерацій, що витрачаються на реалізацію прийнятих історій.

Кон говорить про апріорно оцінюванні проекту, але сказане можна застосувати і до апостеріорного вимірам.

Бали історії мають такі важливі властивості.

• Як випливає з зробленого вище зауваження, бали є відносним індикатором і не задають тимчасові оцінки. Ви можете взяти оцінки історій, зроблені апріорно, і вимірювання в ході розробки, все помножити на 5, і це ніяк не вплине на загальну оцінку трудомісткості проекту. Усередині проекту оцінки, звичайно, повинні бути узгоджені, щоб була можливість визначення і передбачення швидкості розробки, що буде обговорюватися в наступному розділі.
• При вимірі вже досягнутих результатів бали повинні вважатися тільки для реалізованих історій, історії, в повному обсязі реалізовані, враховуватися не повинні. Це правило відповідає agile розуміння "витрат" - категорії, що включає будь-який код, який фактично не поставлений користувачеві.

Більш загальний погляд: будь непоставляемий артефакт не враховується при оцінці прогресу проекту. Приклади можуть включати документацію, плани, вимоги - все, що з точки зору agile представляє "витрати", хоча такі артефакти можуть враховуватися, якщо вони явно входять у визначення "зроблено", що буде обговорюватися далі. Зауважте, тести, які за визначенням не є "витратами", не враховуються в балах історії.

Бали історії є відносно недавнім додаванням в колекцію agile артефактів. Екстремальне програмування спочатку використовувало абсолютний вимір часу - ідеальний час програмування, тобто число днів, необхідних для реалізації історії за умови повного робочого дня і відсутності перешкод. Крім цього, вводився "коефіцієнт стійкості", що дозволяє оцінити реальний час шляхом множення ідеального часу на коефіцієнт, який типово приймався від 2 до 4 (Бек). Критики говорили, що введення коефіцієнта стійкості на практиці означає деяку фальсифікацію оцінок, але насправді це очевидне прагнення розширити рамки оцінок. У 2002 році XP перейшов до "чистим програмістських тижнях". Це тренд, який вказує на прагнення піти від точних часових одиниць до цифр, які не носять абсолютний характер. Щоб підкреслити це властивість, іноді застосовується термін "гумовий ведмедик" як синонім "бали історії".

Усередині проекту бали історії мають сенс, оскільки дозволяють порівнювати прогрес від однієї ітерації до наступної в узгоджених одиницях. І знову Кон [Cohn 2006]:

Тут немає формул, що встановлюють розмір історії. Оцінка історії в балах відображає трудомісткість розробки функціоналу, складність розробки, ризик, властивий історії.

Покер планування (як і більш ранній варіант - гра в планування) - один з прийнятих в agile прийомів для отримання таких оцінок. Ви пам'ятаєте, що в покері використовується набір значень, взятий з деякою послідовності чисел, наприклад з послідовності чисел Фібоначчі: 0, 1, 2, 3, 5, 8 ... За такої практики 1 означає історію мінімальної вартості, і всі інші значення порівнюються з нею . Ви можете вважати, що ця мінімальна історія вимагає двох годин або половини дня роботи, хоча, як пояснює Кон, точний вибір для цієї відповідності для оцінки процесу не критичний.

8.5 Швидкість

Відразу ж, як для користувача історіям дані індивідуальні оцінки та ітерація почалася, ті ж самі заходи можуть служити для оцінки прогресу розробки. Тут стає корисним поняття "швидкість".

Це поняття, критично важливе і, на подив, часто игнорируемое в період до agile, дає чітку, вимірну, безперервну оцінку швидкості розвитку проекту.

Серед програмістів ходить багато жартів про проекти, готових через кілька тижнів після їх початку на 90% і залишаються в цьому стані протягом тривалого часу. Але питання "як далеко ви просунулися" цілком доречний для менеджерів та інших співучасники проекту.

Швидкість є синонімом швидкості, тобто як швидко виконується робота. Для рухомих об'єктів швидкість задається відношенням , де - пройдений шлях, а - час його проходження. Ця інтерпретація застосовна і до швидкості розробки проекту. Чисельник вимірюється в балах історій, знаменник явно не з'являється, оскільки він приймається рівним одиниці - однієї ітерації (спринт в Scrum). Так що під швидкістю в agile світі розуміється число балів тих історій, які виконані під час ітерації.

Так, певна швидкість дає міру виконаних робіт. Ця концепція підтверджує справедливість вибору відносних оцінок, а не абсолютних. На початку робіт над проектом досить важко сказати, скільки часу піде на реалізацію завдання - дві чи цілий день. Оцінювання в балах дозволяє уникнути завдання точних часових оцінок і зосередитися на оцінці відносної складності завдань, порівнюючи їх один з одним. Якщо застосовувати цю методику узгоджено протягом всього проекту, то відносні передбачення (бали історії) будуть все більше наближатися до абсолютним значенням (тривалості виконання історії).

Саме припустимо, що у нас є дві оцінки:

• перший спринт покриває історії на 30 балів;
• один бал відповідає одному дню роботи команди.

За нашими очікуваннями, другий з цих припущень може бути далі від істини, ніж перше. Тепер припустимо, що протягом 30-денного спринту вдалося виконати історій на 20 балів. Припустимо, що подібна ситуація мала місце і протягом наступних кількох спринтів (згадайте "коефіцієнт стійкості" в ранніх версіях XP), так що можна вважати, що знаменник, який визначає час при підрахунку швидкості, дорівнює не 1, а 1,5. Якщо з плином часу цей зразок залишається стабільним і команда працює все краще, як і повинно бути, то оцінки стають все більш точними. Це та "краса", яку мав на увазі Кон в наведеній вище цитаті.

Мал.8.1.

Оцінка трудомісткості розробки. конус невизначеності

Такі прийоми, які використовують безперервно уточнюється вимірювання для поліпшення початкових грубих оцінок, є прикладом більш загальної концепції програмної інженерії, спочатку введеної боєм [Boehm 1981] і отримала назву "конус невизначеності". Конус визначає межі (в кінцевому рахунку - вимірюване значення) деякого властивості проекту. В ході роботи над проектом ми маємо все більше інформації про властивості проекту, і кордони звужуються.

Як зазначалося, швидкість зазвичай вимірюється по відношенню до повної ітерації. Іноді може бути корисний дрібніший рівень гранулярності. Хоча навряд чи має сенс порівнювати вчорашню і сьогоднішню швидкість, але побудова безперервного графіка швидкості може служити хорошим індикатором розвитку проекту.

Швидкість - одна з найбільш цікавих концепцій, популяризуються agile методами. До метриці, заснованої на балах історій, як єдиної міру трудомісткості проекту, можна пред'являти претензії. Вони були висловлені на початку цієї глави. Проте, твердження, що проект повинен стежити і візуалізувати швидкість розвитку, є корисним і вражаючим.

8.6 Визначення "Зроблено"

Акцент agile на поставку актуальною функціональності, уникаючи витрат, відбивається в строгому визначенні прогресу як числа балів поставлених історій, але це вимагає строгих і узгоджених критеріїв, які визначають, що завдання дійсно зроблена. У Scrum дається визначення поняття "зроблено", що пояснює, що ми маємо на увазі, коли говоримо - це "зроблено".

Узгодженість вкрай важлива у визначенні "зроблено". Ми можемо вимагати або не вимагати, щоб повнота користувальницької історії включала повноту відповідних даних, що вводяться користувачем вручну, але прийняття такого рішення має бути єдиним для всіх призначених для користувача історій. В іншому випадку ми не зможемо правильно оцінювати міру прогресу розробки.

Сазерленд [Sutherland 2013] наводить такі визначення "зроблено":

• готовий до публікації (найпростіший варіант);
• минулий етапи юніт-тестування та інтеграційного тестування; готовий до приймально-сдаточному тестування; розгорнутий на сервері;
• минулий приймальне тестування, є письмові пояснення до релізу, готовий до публікації, які не збільшує "технічний борг".

Технічний борг - поняття, що означає недосконалість коду або вади в архітектурі, які в майбутньому, можливо, зажадають невиправданої роботи.