Must have артефакти для розробки ПЗ

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

Привіт! Мене звуть Сергій Алексєєв, в ІТ я вже 9-й рік і останнім часом частіше з’являюсь на DOU зі своїми статтями. Це пов’язано з тим, що я хочу передати свої знання спільноті. Цього разу я вирішив написати статтю, в якій буде багато прикладів артефактів, без яких неможливо зробити програмне забезпечення, або через їх відсутність збільшується термін розробки ПЗ. Чи ще гірше  — буде реалізовано зовсім не те, що було заплановано спочатку.

Я хочу, щоб стаття допомогла різним командам підвищити свою ефективність та професіоналізм. Сподіваюся, що цей матеріал прочитають співробітники, які відповідають за ІТ на держслужбі та в інших непрофільних компаніях. Можливо, люди почнуть впроваджувати  у себе кращі практики, що дозволить компаніям стати ефективнішими. Я не хочу нікого ображати, але не секрет, що професійний рівень фахівців у цих структурах є значно нижчими, ніж у провідних ІТ-компаній країни, хоча винятки є завжди. Такими компаніями я б назвав MHP, НП, «Розетка», ДТЕК. Можливо, їх більше. Напишіть у коментарях про ці організації.

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

На малюнку нижче я спеціально виділив місце у процесі «беклог менеджмент», де відбувається декомпозиція вимог та створення більшості артефактів. Особисто я використовую rolling waves підхід  у всіх проектах, щоб збір та опис вимог пройшли спокійніше.

Процес декомпозиції feature

Чим є feature (далі фіча) у світі ПЗ? Фіча — це частина функціональності в програмному забезпеченні, яку необхідно реалізувати у певному обсязі та послідовності. Наприклад, «Find friends» у Facebook, «Stories» у Instagram, «New incognito tab» у Chrome.

Ось так виглядає процес декомпозиції feature на практиці:

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

До теми: Як проводити інтерв’ю із замовником

Етап	Завдання	Коментар
Аналіз	Отримати бачення, обсяг та межі фічі	Оформлюйте це у вигляді найпростіших вимог на зразок: –        Користувач повинен мати можливість робити “Х”. –        Система має надавати можливість робити «У». –        Необхідна реалізація інтеграції із системами «A» та «B». В ідеалі це мало бути зроблено на етапі «Discovery», де аналітик готує документ під назвою «Vision & Scope», в якому є перелік фіч. Якщо фіча має певну логіку розрахунків, обов’язково напишіть про неї. Намагайтеся писати максимально все, що знаєте, але не розписуйте це дуже детально на даному етапі.
Аналіз	Визначити і описати ролі	Ролі також знадобляться у момент опису use cases. Я виділяю два типи ролей (бізнес та системні): –        Бізнес-роль — це посади в організаційній структурі компанії. Для бізнес-ролі буде описано перелік бізнес-операцій без прив’язки до будь-якого програмного забезпечення. –        Системна роль — роль, яка використовуватиметься у додатку для опису доступного функціоналу ПЗ. Приклад колл-центру: є 2 бізнес-ролі (супервайзер і оператор), кожна з цих ролей має свої обов’язки та метрики, за які вони несуть відповідальність. У програмному забезпеченні ви можете створити дві системні ролі і кожному з користувачів буде призначено свою роль. Тим самим ви робите межу між UI & Data за ролями. Але у разі, коли оператору потрібно розширити можливості у ПЗ, йому можуть призначити додаткову роль «Супервайзер» для розширення повноважень у ПЗ, а не в реальному світі (один з можливих варіантів реалізації).
Аналіз	Зрозуміти основні кейси використання фічі	Будь-яка фіча реалізовується для того, щоб підтримувати щонайменше один сценарій взаємодії користувача/системи з ПЗ і давати користь. Вам необхідно якомога раніше і більше виявити сценарії, які стосуються певної фічі. Це дозволить зрозуміти обсяг робіт, рамки реалізації та спланувати розробку. Тут вам допоможуть “use case” діаграми. Приклад колл-центру: основні сценарії для оператора – прийняти дзвінок, зафіксувати звернення, здійснити дзвінок тощо.
Аналіз	Зрозуміти основні сутності фічі	Розуміння основних сутностей та їхніх взаємозв’язків необхідне для правильного проектування ПЗ. Це важливо не лише з точки зору технічної архітектури, але і для проектування інтерфейсів. Приклад колл-центру: клієнт, який телефонує до колл-центру; користувач, який приймає дзвінок; дзвінок, заявка тощо. Цю проблему допоможуть вирішити діаграми ERM.
Дизайн	Визначити основний сценарій	На етапі дизайну я завжди рекомендую показати “happy path”, щоб команда та клієнти розуміли сценарій: як він буде виглядати з самого початку до кінця (end2end). Приклад колл-центру: успішне формування заявки щодо вхідного дзвінка –  інтерфейс картки дзвінка, інтерфейс карт клієнта, інтерфейс заявки.
Дизайн	Створити дизайн	Необхідно показати обраний або кілька сценаріїв на самих мокапах. Бажано зробити інтерактивний мокап.
Дизайн	Створити артефакти	Поки створюються дизайни та з’ясовуються вимоги, ви створюєте артефакти (перелічені нижче в тексті) для всіх учасників процесу розробки ПЗ.
Затвердити	Презентувати клієнту/ співробітникам	Для того, щоб затвердити вимоги та зробити рішення остаточним на цій ітерації, вам потрібно представити його клієнту чи колегам (якщо це продуктова компанія).
Затвердити	Закрити відкриті питання	Зберіть всю необхідну інформацію для закриття/вирішення питань після проведених однієї або кількох зустрічей. Затвердження вимог як окремий процес слід детальніше розглянути пізніше.
Затвердити	Підтвердити дизайн та вимоги	Після презентації у вас буде затверджене рішення або відкриті питання, які потрібно вирішити.

Основою для декомпозиції будь-якої фічі є принцип ітеративності. Він дозволяє вам щоразу розуміти клієнта все краще і чіткіше. Тож не бійтеся практикуватися і робити помилки.

Практика

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

Epic: Account management

Features: log in / log out / password recovery

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

До цього переліку входять:

• Meeting Notes;
• Use cases;
• Flows;
• ERM;
• State Machine;
• Design;
• User Stories;
• Mock Data.

По кожному з артефактів я відповідатиму на такі питання: навіщо, як, коли, особиста думка.

Meeting Notes

 Навіщо. Після зустрічі гарним тоном вважається зафіксувати домовленості та план подальших дій. Я рекомендую використовувати цей артефакт лише як інструмент самоконтролю, а не документ суворої звітності. Структура документа досить проста. Це має бути все, про що домовилися, затвердили та які подальші кроки запланували. Це необхідно не лише для перестрахування себе, але і для того, щоб бути на одній хвилі з замовником. Набагато простіше координувати вимоги в письмовій формі, ніж усно. Meeting notes мені потрібні на короткий проміжок часу, щоб зафіксувати інформацію, потім агрегувати, помістити в юзер сторі, дописати вимоги, переробити Моку, проводити зустрічі — і це, мабуть, все. Основну роль цей документ виконав.

Як. Якщо зустріч не була запланованою і швидкою, тоді ручка та папір — мої найкращі друзі. Якщо я контролюю ситуацію, то, звісно, OneNote. Не має значення, як я зафіксував інформацію, я завжди її оцифровую. Далі в електронній формі я можу її розшарити будь-кому і коли завгодно. Якщо у вашому проекті є багато людей, яким важливі ваші домовленості з замовником, то можете використовувати, наприклад, Confluence.

Коли. Я пишу нотатки під час зустрічі та після. Для кожної зустрічі я обов’язково готую тему та список питань, на котрі мені потрібно отримати відповіді, щоб робота над проектом просувалася відповідно до плану. Звісно, я повідомляю клієнту про свої наміри, щоб ми не витрачали час. Після кожної зустрічі у мене є низка нових вимог, змін, уточнень. Всю цю інформацію я напряму транслюю в в юзер сторі (створюється нова або редагується стара).

 Особиста думка. Деякі проєктні менеджери/ліди, сподіваючись перестрахувати себе та  врятувати проект від змін, намагаються змусити аналітиків офіційно проводити цю документацію як сувору звітність. Особисто я вважаю, що це дохлий номер. Необхідно не займатся дурницями, а вирішувати проблеми змін скоупу іншими методами. Хто не знає якими — приходьте до мене, розповім.

Зверніть увагу: Запис вебінару “User Story Mapping – кейс з реального життя”

Use Cases

 Навіщо. Використання Use Cases дозволяє усвідомити та показати максимальну картину того, що буде включено до розроблюваної функції або цілого продукту. Використовуючи цю техніку, ви можете легко відобразити та простежити залежності взаємодії між користувачем та системою. Межі функціональності або продукту чітко видно. Use Сase-діаграма також дуже зручна при декомпозиції вимог. Почитати детально.

 Як. Ця діаграма створюється ітеративно, у міру того, як надходить нова інформація. Більшість змін в діаграмі припадає на початок з’ясування вимог. Саме на початку ви намагаєтесь зрозуміти, які будуть кейси використання ПЗ.

 Коли. Оскільки інформація про кейси змінюється досить рідко, я малюю її на самому початку аналізу продукту/функції. Це не забирає багато часу — 2-3 годин максимум.

 Особиста думка. Використання Use Cases дуже допомагає у структуруванні інформації. Я майже завжди використовую цей тип діаграм у проектах, де є багато ролей та сценаріїв.

Буде цікаво: Юзер сторі чи Юз кейси…ось в чому питання! (Requirements 101: User Stories vs. Use Cases)

Process flow diagram

 

Навіщо. Щоб спростити узгодження бізнес-логіки між усіма учасниками процесу розробки ПЗ. Я використовую «Activity Diagrams» або «Cross functional flow charts» для вирішення 99% завдань. Мені не потрібні складні та комплексні нотації на зразок BPMN/IDF0 тощо. Безперечно, деякі клієнти, особливо на пострадянському просторі, люблять ці нотації, але здебільшого мені не доводилося їх задіювати і робота йшла успішно. Почитати детально.

Як. Насамперед вам необхідно зрозуміти, як працюють процеси в даний момент, якщо це вже існуючий бізнес. Якщо це щось нове, тоді вам потрібно подумати, як виглядатиме той чи інший процес. Використовуючи патерн AS IS/TO BE, я завжди роблю замальовки процесів AS IS на папері у вигляді схем/слів/кракозябликів, а ось процеси TO BE я вже малюю в програмному комплексі, використовуючи певну нотацію та тип діаграми.

Коли. Ітеративно, у міру надходження нової інформації. Процеси можуть залежати один від одного.

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

Entity Relationship Model

Навіщо? ERM дозволяє показати взаємовідносини між бізнес-сутностями. Якщо ви зможете це зробити на початку розробки свого продукту, тоді це спростить технічним фахівцям розуміння того, як правильно будувати архітектуру самого додатка та бази даних. Використовуючи такі діаграми в процесі розробки ПЗ, ви знижуєте ризик того, що потрібно буде переробляти програму.

P.S. Навіть якщо розробники кажуть: «Ми використовуємо NoSQL бази даних і ми можемо змінюватися на ходу», – не вірте їм 🙂 Цей трюк працює тільки спочатку, поки продукт молодий і зелений, і немає ані навантажень, ані складної бізнес-логіки. Так що нехай не лінуються і думають про архітектуру.

Як. Щоб зрозуміти, як використовувати ці діаграми, я рекомендую почитати про реляційні бази даних. На яких принципах вони побудовані, які є зв’язки і навіщо це необхідно.

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

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

Зверніть увагу: Як писати хороші User Stories

State Machine

Навіщо? Щоб зрозуміти, які існують стани/статуси та які тригери на це впливають. Кожна сутність має свій life cycle. У деяких із них він досить короткий і складається із 2-3 статусів. Але бувають і складні сутності, де безліч різних станів і факторів, які впливають на їх зміну. Хороший приклад сутності зі складною структурою — це заявка до служби підтримки, де є кілька рівнів служб, і заявці іноді доводиться пройти 3-4 рівні з розглядом і переадресацією цієї заявки до інших служб. Про те, як визначати статуси та стани сутностей, ви можете подивитися у моєму відео. Такі діаграми допомагають backend-розробникам у реалізації бізнес-логіки.

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

Коли. Оновлюйте щоразу, коли ви отримуєте нову інформацію або розуміння того, які сутності/умови/тригери з’явилися.

Особиста думка. Використовуйте цей артефакт у разі, коли ви розумієте, що певна сутність має багато умов, статусів. І без візуалізації команді буде важко зрозуміти, що і коли має статися.

Design

Навіщо? Якщо ви робите програмне забезпечення, призначене для використання людиною через візуальні інтерфейси, тоді вам не обійтися без дизайну вашого ПЗ. Додаткове пояснення, навіщо потрібен дизайн на проекті, вважаю зайвим.

Як. Розгорнуту відповідь про те, як може бути побудована комунікація з дизайнером, ви можете переглянути в цьому відео.

Коли. Оновлюйте щоразу, коли вам надходить нова інформація або розуміння того, як користувач взаємодіятиме з системою. Намагайтеся тримати мокапи оновленими.

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

Буде корисно: Вебінар “Артефакти бізнес аналітика: темплейти та приклади”

User Story

Навіщо? Для того, щоб створювати програмне забезпечення шматочок за шматочком. Це як збирати пазл. Спочатку є лише ідея у головах замовників, цю ідею необхідно описати, надати їй фарб, потім розбити на невеликі шматочки і зібрати в єдине ціле силами команди.

Дуже важливий момент: user story не є todo-листом. Не пишіть туди, що має зробити розробник (створити сервіс, отримати щось за допомогою webhook, залити дані тощо).

Як. Працюючи бізнес-аналітиком, основну частину часу я витрачав на опис user stories. Я не лише описував поведінку, а й робив перегрупування вимог, простежував залежності та виставляв пріоритети. Це те, чим має займатись аналітик на проектах у поточних реаліях бізнесу.

Ітеративна робота над user stories – це must have навичка аналітика! Обговорили вимоги з клієнтом => написали user story => обговорили з командою => внесли зміни => обговорили з клієнтом => змінили user story => обговорили з командою => внесли зміни. І так доти, поки клієнт не буде задоволений вимогами, а команда не зможе дати оцінку цієї історії користувача.

Коли. Після зустрічі з клієнтом/командою.

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

Mock Data (тестові дані)

Навіщо. Це ретельно підготовлені дані, які повинні використовуватися розробниками під час проектування/розробки системи. QA-фахівці повинні використовувати їх як еталонні дані при тестуванні.

Як. Я надаю команді дані в Excel-файлі. Якщо розробка user story включає використання кількох залежних сутностей (наприклад, товарів, складу, виробника тощо), я додаю кілька вкладок у файл, на якому є інформація по кожній сутності. У таких завданнях дуже допомагає функція (ВПР або VLOOKUP) — рекомендую почитати кейси її використання.

Коли. Дані про певну user story повинні бути надані команді перед розробкою цієї user story. Інакше є ризик затримки розробки та тестування.

Якщо ваша система залежить від іншої, подбайте, щоб ваша команда зрозуміла, яка структура та тип даних буде в майбутньому.

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

Висновки

Деякі з вас одразу скажуть, що підхід до роботи над вашими проектами зовсім інший: замовник хоче побачити щось інше або звик до ТЗ  (технічного завдання) на 100500 сторінок у форматі *.docx. Моя відповідь проста: якщо ви хочете змінюватись і зростати, вам доведеться знайти способи змінити підходи до роботи з клієнтами та дати їм чітке розуміння плюсів і мінусів різних підходів. Вам доведеться побудувати прозорі та довірливі відносини, якщо ви хочете зростати разом зі своїм клієнтом. Вам потрібно пам’ятати, що це ви фахівці з розробки ПЗ, а не ваш клієнт! Ви повинні його вчити і допомогати, а не він вам! Ви голова в цьому контексті, а клієнт має бути лише щасливим споживачем ваших послуг!

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

Взято з DOU