Правила

Команда

Команда має складатися з 3-5 студентів. У команді повинні бути люди з такими ролями: розробники серверної й клієнтської частини, QA фахівець, UІ\UX фахівець і лідер команди. Команда крос-функціональна, що означає, що один студент може суміщати більш ніж одну роль одночасно й команда є повністю укомплектованою для виконання завдання. Наприклад, лідер команди може бути одночасно розробником або розробник серверної частини, може бути також QA фахівцем. Також одна роль може бути розділена між кількома студентами. Команда самостійно вирішує, які люди відповідають за який напрямок залежно від своїх навичок і вимог продукту.

Ролі

Розробник серверної частини - відповідає за розробку сервера й бази даних. Стек технологій: ASP.NET, node.js, python (django) або інші.

QA фахівець - відповідає за якість і надійність системи й відсутність у ній критичних помилок. Перевіряє різні сценарії використання системи.

UІ\UX фахівець - відповідає за дизайн і зручність користувацького інтерфейсу.

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

Система керування проектом

У якості системи для керування проектом рекомендується використовувати безкоштовний сервіс Trello, у якому необхідно створити дошку з наступними колонками: Backlog, Planned, Іn progress і Done, де розміщаються завдання команди. Над одним завданням може працювати тільки одна людина й не більш 3 днів.

Backlog - стовпчик незапланованих на спринт завдань (див. методологія);

Planned - стовпчик запланованих незавершених й не початих на спринт завдань;

Іn progress- стовпчик завдань, над якими зараз ведеться робота;

Done - стовпчик завдань, що виконані.

Вимоги до ПЗ

• Заборонено використовувати будь-які CMS (Content Management System) системи. Наприклад WordPress, Joomla!, Drupal, Magnolia, Wix, Weebly.

• Дозволяється використовувати фреймворки, готові набори компонентів та бібліотеки. Наприклад DevExpress, KendoUI, AngularMaterial та інші.

• При побудові програмного забезпечення слід враховувати вимоги принципів SOLID, YAGNI, DRY, KISS.

Вимоги до процесу розробки ПЗ

1) Команда має встановити критерії готовності для початку роботи над "історією" (Definition of Ready). Бажана відповідність INVEST моделі.

• Independent – незалежна

• Negotiable – не контракт с замовником.

• Valuable – ( a vertical slice). Має цінність для продукту.

• Estimable – можлива оцінка з достатньою точністю (принцип «good enouth»).

• Small – можливо виконати за спринт.

• Testable – може бути протестована, навіть якщо тести ще не написано.

Definition of Ready для історії:

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

• Критерії прийомки повинні бути зрозумілими для команди.

• Команда повинна оцінити історію.

• Команда повинна розуміти як провести демо для історії.

Definition of Ready для спринту:

• Пріоритезований беклог.

• Дефекти, історії та інша робота яку команда зобов’язалася виконати додана до спринт беклогу.

• Всі члени команди порахували свою доступність. (Кількість годин, що вони можуть витратити на проект по кожному робочому дню окремо).

• Всі історії в спринт беклозі, виконують вимоги Defenition of Ready для історії.

2) Команда має встановити критерії прийому/здачі "історії" (Definition of Done).

• Програмний код написано.

• Юніт тести написані і всі успішно виконані (процент покриття має визначити команда)

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

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

• Документація оновлена ( є документ в якому описані всі вимоги до продукту, які було вже досягнуто. Документ не має включати елементи що неготові або тільки плануються).

Звітність

1) По кожному спринту окремо:

a. Product Backlog – вигрузка беклогу продукту на початок спринту

b. Sprint Backlog – беклог спринту на початок та на кінець спринту

c. Sprint Goal – ціль спринту.

d. Sprint Burndown Chart. – графік що демонструє яким чином робота, що була запланована виконувалась на протязі спринту. Він повинен відображати, скільки роботи команда зобов’язалась виконати, скільки вона насправді мала часу, коли закривались історії та задачі, продемонструвати згорання спринт беклогу.

Відео-звіт має містити таку таку інформацію:

1. Sprint planning

2. Sprint demo

3. Sprint retro

У звітуванні за п.1,3 бере участь вся команда.

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

3) Є інструкція, що визначає як саме слід налаштувати оточення, щоб скомпілювати програмне забезпечення з вихідного коду.

4) Є інструкція, що визначає що саме слід зробити та за яких умов, щоб розгорнути додаток. Перелік дій повинен бути вичерпний та легко відтворюваний. Вірогідність помилки людини має бути мінімізовано.

5) Звіт про якість програмного забезпечення після виконання кожної "історії" на підставі статичного аналізу коду.

6) Всі версії документу з вимогами до програмного забезпечення.

7) Дозволяється використовувати платформи типу JiraRedmine, qTest, Zephyr, Testpad, Confluence з метою полегшення управління процесом розробки, будь-якого типу розгортання, за умови наявності доступу у журі. Звіти п.1, п.2, п.5, п. 6 якщо вони побудовані за допомогою цих інструментів та відповідають іншим вимогам є допустимим.

8) Формат звітів MicrosoftWord, Pdf.

Методика оцінювання команд

1) Оцінюються тільки ті історії які виконали всі вимоги Defention Of Ready та вимоги щодо звітності п.1 - 4

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

Наприклад: Веб сайт базовий функціонал.

Веб сайт створений.

Є сторінка авторизації.

Є головна сторінка.

Є сторінка профілю користувача.

Є можливість змінити пароль та налаштувати профіль.

Є домашня сторінка (доступна після авторизації).

Після визначення яка частина епіку виконана, команді отримає бали за епік.

100% балів за епік це всі функціональні вимоги виконані, виконані вимоги звітності 1- 8, виконані вимоги Defenition of Done та Defenition of Ready.

Всі епіки мають однакову вагу і складають загалом 79% фінальної оцінки.

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

a. Покриття юніт тестами.

b. Кількість помилок (технічного боргу) виявленого статичним аналізом коду.

c. Дотримання вимог YAGNI, KISS, DRY, SOLID.

По кожному пункту буде складено рейтинговий список. Команда що посіла перше місце отримає 7% фінального балу. Оцінка всіх інших команд буде знижена за допомогою ряду Фібоначчі. (2 та 3 місце «-1%», 4 місце «-2%». І тд.).

Отправить отзыв

Реєстрація