Про "легкому" процесі замовте слово: процес розробки у відділі інструментарію Larian Studios

Проходячи співбесіду на посаду керівника розробки у деяких компаніях, автору в ході розмови доводилося вислуховувати одну і ту ж історію:

"Є у нас 3 — 4 програміста, які ось уже півроку (або рік — період часу залежав від компанії) «пиляють» один проект. Тим не менш, незважаючи на зусилля, працездатною «демки», яку можна запустити і продемонструвати Замовнику, все ще немає. Ми шукаємо керівника, який зміг би організувати роботу».
Дивність ситуації полягає в тому, що начебто розумні і досвідчені керівники компаній замислюються про організації процесу розробки не на початку роботи над проектом, а лише тільки тоді, коли набрана команда терпить невдачу. Між тим, над процесом слід замислюватися в самому початку.

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

Про компанію
Larian Studios — це невелика компанія з кількістю співробітників трохи більше 100 людина розробляє серію рольових ігор Божественність. Компанія складається з кількох студій, розташованих у різних країнах. Одна із студій знаходиться в Санкт-Петербурзі. Ігри випускаються під різні платформи, серед яких Windows, Linux, Mac OS X, Xbox і PlayStation ONE 4.

технології
Для розробки ігор компанія використовує свій 3D движок і свою інтегровану середу розробки. Незважаючи на те, що движок портований під різні платформи, розробка ведеться на платформі Windows. Це пов'язано з тим, що середовище розробки написана з використанням технологій WinForms і WPF і працює під управлінням середовища .NET Framework.

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

image
Редактор Larian Editor використовується для створення гри Divinity: Original Sin 2
Незважаючи на те, що середовище розробки виглядає переконливо, а безліч UI-елементів забезпечує доступ до великої функціональності, проте, зручність її використання залишає бажати кращого як з-за перевантаженості самого інтерфейсу, так і з-за того, що окремі його частини не узгоджені один з одним. В цьому і полягає основна проблема.

Про вимоги
Основні вимоги до інструментарію можна виразити 3-ма умовами:

  1. Він повинен виглядати професійно, а не як «наколеночный» софт.
  2. Повинен володіти заданою функціональністю і бути зручним у використанні.
  3. Терміни і вартість розробки не повинні перевищувати розумних меж.
image
Редактор All Spark, розроблений відділом інструментарію, що використовується для створення візуальних ефектів
Про замовників
Інструменти розробляються для внутрішніх замовників. До них відносяться всі ті люди, які безпосередньо роблять гру. Це і дизайнери візуальних ефектів і 3D-аніматори, і ігрові дизайнери, і скриптеры і т. д. і т. п.

Про відділ
Відділ розробки інструментарію є невеликим. Його склад:

  • 1 провідний програміст (він же менеджер)
  • 3 програміста
  • 1 інженер з якості
Про
Огляд
Щоб організувати роботу відділу, необхідно поставити процес розробки. Поставлений процес допоможе здавати проекти в строк і з заданою якістю. Оскільки команда невелика, і всі один одного знають, то ми використовуємо не великоваговий і зарегульований всякими правилами, а легкий процес розробки. Багато речей у ньому не формалізовані, а інші — ґрунтуються на усних домовленостях. Однак є й чітко структуровані речі, про яких мені і хочеться розповісти.

Стадії і етапи розробки
Процес розробки у відділі інструментарію можна розділити на 4 етапи:

image

  1. Розробка концепції
    На цьому етапі наші внутрішні Замовники готують концепцію розроблюваної програми і формулюють основні вимоги.

  2. Планування
    На даному етапі ми робимо оцінку проекту і створюємо його план.

  3. Розробка
    На даному етапі проводиться розробка програми.

  4. Супровід
    У програму вносяться поліпшення, виправляються помилки.
Етап 1. Розробка концепції
Робота над новим інструментом починається з розробки концепції. Цим займаються наші внутрішні Замовники такі, як дизайнери візуальних ефектів, 3D-аніматори, ігрові скриптеры і т. д.

Процес створення концепції складається з декількох стадій:

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

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

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

    3. Ергономічні
      Наявними інструментом незручно користуватися, що істотно позначається на продуктивності праці і, як наслідок, швидкості розробки гри.
  2. Формулювання вимог
    На цій стадії зацікавлені особи формулюють вимоги до нового інструмента. Ці вимоги включають як функціональну частину (що інструмент повинен робити), так і ергономічну складову (наскільки інструментом повинно бути зручно користуватися).

  3. Пошук рішень-аналогів
    Пошук рішень проблем, сформульованих на попередньому кроці, слід почати з вивчення програм-аналогів. В нашому випадку такими аналогами є Unreal Editor, Unity 3D, FxStudio Designer та інші програми. Глибоке знання подібних інструментів дозволяє підглянути вдалі рішення і використовувати їх у власній програмі.

  4. Малювання макетів
    Макети дозволяють розробникам створити візуальне уявлення про те, як розробляється інструмент буде виглядати. Спочатку досить намалювати кілька ключових екранів таких, як головне вікно програми, вікно редагування основних даних, панелі інструментів. По мірі розробки можна додавати макети і для інших вікон.

  5. Підготовка документа
    Фінальний документ формується шляхом об'єднання мокапов з вимогами. Документ розбивається на розділи на поэкранной основі: кожен екран — окрема глава. На початку розділу наводиться макет відповідного екрану, а під ним — відповідні вимоги в текстовому вигляді.
Етап 2. Планування
Під час планування команді важливо виконати три речі:

  1. Домовитися про результаті з зацікавленими особами.
  2. Скласти план проекту.
  3. Скласти план комунікацій.
Крок 2.1. Домовитися про результат
На цьому етапі важливо зрозуміти, що буде собою представляти альфа-версія продукту. В нашому випадку, альфа-версія — це версія програми, яка виходить по закінченню третього етапу — розробка, про яку докладніше ми будемо говорити нижче. Альфа-версія може включати в себе далеко не всі вимоги, які Замовники сформулювали в концепції, а лише деяка підмножина. Чому?

Справа в тому, що концепція включає в себе багато побажання Замовників. Деякі з них не перевірені практикою, і можуть у реальності не знадобитися. І, навпаки, може знадобитися реалізувати щось інше, про що Замовники не подумали, коли писали концепцію.

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

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

Мінімальна робоча версія і є альфа-версією. На її випуску закінчується етап розробки.

image
Редактор Genome, розроблений відділом інструментарію, дозволяє 3D-аніматорів візуально програмувати персонажа
Після того, як наші Замовники починають використовувати нашу програму, виявляються баги і різні шорсткості. Крім того, з'являється і досвід використання спочатку в тестових, а потім — і в «бойових» умовах. Цей досвід дозволяє оцінити інші вимоги: які з них важливі, а які — несуттєві.

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

Крок 2.2. Скласти план проекту
Щоб скласти план проекту, потрібно:

  1. Зробити оцінку проекту
  2. Оцінити наявні ресурси
  3. Запланувати майлстоуны

Крок 2.2.1. Зробити оцінку проекту

На мою думку, існують два види оцінки проекту:

  1. Попередня оцінка
  2. Детальна оцінка
Попередня оцінка є досить грубою. Вона використовує спрощену декомпозицію, але з цієї причини не вимагає занадто багато часу.

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

Щоб заощадити час, що ми робимо грубу оцінку проекту. Однак і при використанні «грубих моделей» можна отримати точний результат. Як ми цього досягаємо? Для оцінки проекту замість однієї моделі ми використовуємо три:

  1. Функціональну модель
  2. Компонентну модель
  3. Процесну модель
Функціональна модель являє розроблювану програму у вигляді набору корисних функцій. Вона відображає точку зору користувача.

Компонентна модель являє додаток у вигляді набору модулів. Вона відображає погляд інженера.

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

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

Можливо, більш детально дана тема буде розкрита в окремій статті.

Крок 2.2.2. Оцінити наявні ресурси

Щоб правильно врахувати наявні ресурси, потрібно зрозуміти, що жоден працівник не витрачає 100% свого часу на виконання завдань. Обов'язково, якусь частину свого часу програміст буде витрачати на спілкування з колегами і невеликий відпочинок.

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

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

При оцінці наявних ресурсів ми використовуємо таку таблицю продуктивності праці:
Працівник Продуктивність
Провідний інженер 50%
Інженер 85%
Новачок 50%
Недосвідчений новачок 25%
Провідний інженер, крім програмування, витрачає частину свого часу на планування, розподіл завдань, спілкування з Замовниками, введення в курс справи новеньких, якщо такі є, і на навчання недосвідчених. Тому ми вважаємо, що він може витрачати на програмування лише половину свого часу.

Звичайний інженер повинен працювати з 85-ю процентної продуктивністю. Решта 15% свого часу витрачає на комунікацію з іншими членами команди, спілкування з Замовниками та написання звітів.

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

Недосвідчений новачок спочатку змушений витрачати на навчання більше часу, ніж просто новачок. Тому продуктивність 25% в самому початку не повинна виглядати чимось страшним. Проте з часом вона теж повинна зростати.

Використовуючи ці цифри, можна оцінити реальну продуктивність праці всієї команди.

Припустимо, команда складається з 4-х людина:

  • провідний інженер;
  • інженер;
  • новачок;
  • недосвідчений новачок
Тоді продуктивність всієї команди буде дорівнює:

1 * 50% + 1 * 85% + 1 * 50% + 1 * 25% = 210% = 2,1 людино-дні

Це в два рази менше, ніж при простому підході, коли вважається, що кожна людина працює зі 100-відсотковою продуктивністю.

Крок 2.2.3. Запланувати майлстоуны

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

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

Для розподілу робіт за майлстоунам ми використовуємо кілька критеріїв:

  1. Тема
    Кожен майлстоун повинен бути присвячений певній темі. Це дозволяє команді сконцентруватися на чомусь певному та уникнути розкидів і метань.
    Приклади тем: модель даних, панелі інструментів, вікно редагування графа і т. п.

  2. Залежність
    Необхідно враховувати залежності між роботами. Необхідно розподілити роботи таким чином, щоб залежні роботи розташовувалися б пізніше тих робіт, від результатів виконання яких вони залежать.

  3. Тривалість
    Необхідно витримати приблизно однакову тривалість всіх майлстоунов. Ми намагаємося домогтися того, щоб тривалість кожного майлстоун становила 5-6 тижнів.


Крок 2.3. Скласти план комунікацій
Щоб робота над проектом просувалася успішно, необхідно подумати про те, як буде будуватися спілкування всередині команди між окремими розробниками, а також між командою і Замовниками.

Ми у себе в компанії використовуємо кілька практик, які опинилися — в нашому випадку! — досить успішними.

Простір проекту в «хмарі»

При старті нового проекту ми створюємо простір проекту в «хмарі». Як хмарного сховища ми використовуємо Google Drive. Але можна використовувати і інші сервіси: Яндекс Диск, Mail.Ru One Drive від компанії Microsoft та інші.

Якщо вимоги конфіденційності чи просто особисті уподобання не дозволяють використовувати хмарний сервіс, то можна встановити Sharepoint на локальному сервері, або використовувати систему контролю версій типу svn, git або perforce, або завести папку проекту на звичайному файловому сервері. Варіантів — від простих до екзотичних — маса.

Єдиний простір проекту дозволяє сконцентрувати всі документи, пов'язані з проектом, в одному місці. А використання «хмари» дозволяє відкрити доступ до них всім членам команди: кожному — зі свого робочого місця.

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

Наприклад, у нашому випадку папка проекту зазвичай містить в собі 4 такі підпапки:

  1. Концепція
    Містить документи, що описують вимоги Замовників і дизайн розроблювального додатка.

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

  3. Управління проектом
    Ця папка містить все те, що відноситься до питань управління проектом: оцінку проекту, складу команди, графік проекту, графік відпусток і т. д.

  4. Оцінка якості
    Сюди містяться описи тест-кейсів, звіти за результатами майлстоун, правила щодо оформлення багів, перелік проблемних місць у програмі, методики пошуку багів.

Список контактів

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

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

Список контактів краще всього оформляти у вигляді приблизно такої таблиці:
Ф. В. О. Посада Моб. Тел. E Skype
Іванов П. І. Провідний програміст +7 (XXX) XXX-XX-XX pivanov@company.com pivanov
Петров В. С. Програміст +7 (XXX) YYY-YYYY ipetrov@company.com ipetrov

Щоденні наради (стендапи)

Кожен день наша невелика команда (4 програміста і 1 QA-інженер) збирається на коротку нараду, щоб обговорити поточний хід роботи над проектом. Зазвичай така нарада займає 10 — 15 хвилин і дозволяє всім членам команди бути в курсі справ.

Формат наради протягом тривалого часу залишається незмінною і складається з трьох частин:

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

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

  1. Що я робив вчора?
  2. Що я збираюся робити сьогодні?
  3. чи Є у мене якісь перешкоди, які заважають мені виконувати поточні завдання?
Такий формат звіту дозволяє менеджеру проекту (або провідному інженерові, виконує частину менеджерських функцій) бути в курсі того, як рухається проект і якого прогресу досягла команда. А оскільки кожен член команди повинен розповісти про завдання, над якою працює на даний момент і назвати наявні проблеми, то це допомагає іншим членам команди вчасно дізнаватися про залежності між своїм завданням і завданням свого колеги і, при необхідності, ці залежності розрулити, скорегувавши свої дії.

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

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

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

«Обговорення» в програмі-комунікаторі

Перед початком роботи за проектом ми також створюємо «обговорення» в програмі-комунікаторі. Наша компанія використовує для цієї мети slack. Але можна використовувати і інші програми, такі, як HipChat, skype і т. п.

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

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

Етап 3. Розробка
Огляд
Процес розробки складається з послідовності майлстоунов. Кожен майлстоун закінчується випуском версії програми, яка підтримує заплановану функціональність. Останній майлстоун етапи розробки закінчується випуском альфа-версії.

image

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

Майлстоун
Протягом кожного майлстоун виконуються такі роботи:

  1. Планування роботи
    1. займає від 2-х людино-днів до 1-ої людино-тижня
    2. виконується провідним програмістом

    3. іноді вимагає інтенсивного обговорення із Замовником окремих вимог
  2. Розробка (займає 4 — 5 тижнів)
  3. Виправлення багів (займає 1 тиждень)
Завдання
Під час планування майлстоун робота, яку треба зробити до закінчення майлстоун, розбивається на завдання. Виконується оцінка завдань, а самі завдання вносяться в систему контролю завдань. В якості такої системи ми використовуємо JIRA, але це не має істотного значення. Замість неї можна використовувати будь-яку іншу систему контролю завдань: від безкоштовного Redmine до дорогого DevTrack.

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

  1. Користувальницькі завдання
  2. Технічні завдання

Користувальницькі завдання

Користувальницькі завдання визначаються за кінцевим результатом, який необхідно досягти. Цей результат добре видно кінцевому користувачу, і тому користувальницькі завдання легко верифікуються QA-інженером: результат або є, або його немає.

Приклади таких завдань:

  • Створити випадає панель для вибору текстури
  • Додати форму для вибору кольору
Однак, поряд з перевагами користувальницькі завдання володіють і недоліками: їх складно оцінити, вони можуть володіти циклічними залежностями (наприклад, для виконання завдання Б необхідно спочатку виконати завдання А, а для виконання завдання А, в свою чергу, необхідно виконати завдання Б).

Користувальницькі завдання можна розділити на дві категорії:

  1. Завдання, які характеризують деяку спостережувану частину програми, наприклад, окреме вікно, складний елемент керування або якусь сервісну функцію (наприклад, експорт документа в певний формат).
  2. Завдання, які задають критерії виконання завдань з першої категорії.
Завдання-критерії — це свого роду пункти чек-листа. QA-інженер може пройтися по ньому, умовно поставити галочки (якщо пункти виконуються) і закрити батьківську задачу, якщо всі «галочки» проставлені.

Примітка: Слід зазначити, що завдання-критерії оформляються у вигляді підзадач для завдань першої категорії.

Існують 3 види критеріїв:

  1. Критерії, які описують склад компонента (окремої форми, окремого контрола)
    При формулюванні таких критеріїв слід задавати собі питання:

    • З чого складається компонент?
    • Які елементи включає?
  2. Критерії, які характеризують ключові візуальні характеристики компонента
    При формулюванні таких критеріїв слід задавати питання:

    • Якого кольору фон компонента?
    • текст Якого кольору?
    • Який шрифт використовується?
    Примітка: Не слід перераховувати всі візуальні характеристики до найдрібніших подробиць. Це дуже трудомістко та й не потрібно. Увагу потрібно приділяти тільки ключовим характеристикам або тільки тими характеристиками, які відрізняються від стандартних.

    Мета формулювання критеріїв — не створити детальний опис компонента в найдрібніших подробицях, а звернути увагу QA-інженера на те, щоб він не забув перевірити ті чи інші характеристики перед тим, як «закриє» завдання.

    ПРИКЛАД. Якщо колір фону, колір і шрифт тексту вікна не відрізняється від стандартних, то всі ці перевірки можна сформулювати у вигляді одного завдання:

    Перевірити, що колір фону, колір тексту, шрифт і розмір шрифту збігаються з керівництвом.

  3. Критерії, які описують поведінку
    При формулюванні таких критеріїв слід задаватися питаннями:

    • елемент робить?
    • Як він відреагує на визначену дію користувача?
    • Що повинен зробити користувач, щоб елемент повів себе певним чином?
    • Залежить поведінка елемента від часу?
    • Може користувач те чи інше дію скасувати?
    ПРИКЛАДИ:

    • Як користувач, я можу керувати відображенням решітки за допомогою натискання на кнопку Grid
    • Переконайтеся в тому, що список можна розгорнути або згорнути, натискаючи стрілку з лівої сторони заголовка

Технічні завдання

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

ПРИКЛАДИ технічних завдань:

  • Розробити клас, який робить… або відповідає за...
  • Написати функцію, яка...
  • Поліпшити алгоритм пошуку...
Технічні завдання легше оцінити, а отримана оцінка — більш точна. Також з них можна сформувати потік робіт, і легше врахувати і розрулити залежності між ними.

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

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

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

Мітки
При занесенні завдання в JIRA ми маркируем її мітками. Мітки дозволяють налаштовувати різні фільтри, а також — збирати та аналізувати статистику.

В якості міток ми використовуємо:

  • Ідентифікатор майлстоун
    Він дозволяє легко знайти усі завдання, що відносяться до того чи іншого майлстоуну.

  • Тип завдання
    Це завдання-особливість (по-англійськи — feature), або критерій.

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

Найбільш поширеними помилками, які перебувають під час процедури рев'ю коду, є такі:

  1. Помилки через неохайність
    Найбільш яскравий приклад — це ініціалізація складовою змінної. У неакуратно написаному коді ініціалізація такої змінної (або частин такої змінної) може бути розкидана по всьому файлу. Правильно код ініціалізації все ж згрупувати. Помилки із-за необережності допустимі у новачків. Але вони повинні швидко викорінюватися. Бажано, щоб новачок після пари-трійки рев'ю більше таких помилок не допускав.

  2. Помилки через неуважність
    Найбільш поширена помилка — це забування додати тільки що створений файл в change list. Такі помилки допускаються, але повинні зустрічатися вкрай рідко.

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

  4. Помилки в розподілі функцій по модулів і класів
    Найбільш характерний прояв такої помилки — це коли невелика зміна зачіпає відразу безліч файлів. Новачки навчаються довго не робити подібних помилок. Тут потрібна копітка і терпляча робота з боку досвідчених розробників і провідного програміста.

Виправлення багів
Тестування програми відбувається паралельно з розробкою. Для цього у відділі є QA-інженер, який займається лише тестуванням розробляються інструментів.

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

По мірі виконання завдань QA-інженер дивиться, як вони виконані. Якщо він знаходить якийсь баг, то відразу ж заводить його в системі контролю багів. Наше правило — проводити всі знайдені баги через баг-трекер. Навіть якщо баг виявляє програміст, то не кидається його виправляти відразу, а просить QA-інженера його повторити і, якщо він відтворюється, то завести його в системі контролю багів. Чому це важливо?

По-перше, тому що в особі QA-інженера з'являється незалежна сторона, яка зможе проконтролювати, що виправлений баг.

По-друге, тому що зареєстрований у баг-трекері баг потрапляє в статистику, яку згодом можна аналізувати на предмет найбільш поширених помилок або найбільш «бажных» підсистем.

При реєстрації бага в системі контролю багів рекомендується використовувати мітки. Найбільш важливі з них:

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

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

image

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

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

Майлстоун
Тривалість майлстоун на етапі супроводу зазвичай становить 3-4 тижні. Це менше, ніж середня тривалість майлстоун під час етапу розробки. Пояснюється це зменшенням кількості завдань, які необхідно реалізувати. Це зрозуміло, оскільки основна функціональність була реалізована під час розробки.

Завдання, які виконуються в ході етапу супроводу, умовно можна віднести до одного з двох видів:

  1. Усунення бар'єрів
  2. Розширення функціональності
Усунення бар'єрів
Одна з важливих цілей, яку ми переслідуємо на етапі супроводу — це зробити інструмент надзвичайно зручним у використанні. Щоб досягти цієї мети, ми намагаємося усунути всі перешкоди, які заважають нормальному використанню.

Як ми виявляємо такі перешкоди? Просто даємо версію програми замовникам і просимо попрацювати з нею в польових умовах. За результатами роботи запитуємо:

  • Що заважає?
  • Що дратує?
  • Чого не вистачає?
Отримані відповіді аналізуємо і розробляємо варіанти рішень, які усувають проблеми.

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

Досвід реального використання програми дозволяє сформулювати нові вимоги і переоцінити вже існуючі.

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

За вказаний час відділ розробив серйозних 2 додатка: одне — для дизайнерів візуальних ефектів, а інше — для 3D-аніматорів. Перше додаток вже активно використовується в розробці гри і здобули схвальні відгуки з боку користувачів. Воно також дозволило відмовитися від використовуваного раніше додатки третьої сторони і, таким чином, заощадити гроші на оплату ліцензії. Другий додаток було випущено недавно і зараз активно впроваджується в розробку гри.

За два роки відділ виріс в 2 рази: від двох програмістів і 1-го інженера по якості, який працював на проекті лише час від часу, до 4-х програмістів і 1-го інженера по якості на повну ставку. При поточному процесі у відділу є потенціал зростання до 6 — 7 програмістів. При подальшому зростанні понад цю кількість розробників, ймовірно, будуть потрібні зміни в процесі, пов'язані з більшою формалізацією.

Автор дякує своїх друзів і колег за допомогу при підготовці статті.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.