Налаштування процесу у великій команді, або як ми прийшли до Scrum. Частина 1

Кожна команда - це унікальна група людей. І я вважаю, що процес, по якому кожна окрема команда буде організовувати
свою роботу, також буде унікальний. У побудові процесів слід відштовхуватись саме від людей, їх характерів і потреб.
І тут я говорю і про замовника, і про команду розробки, адже всі ми в “одному човні”.

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

В цій статті я поділюсь досвідом постановки процесів у великій команді (> 10 людей) і спробую пояснити, чому ми
прийшли до Scrum.

Початок

Уявімо, що ми працюємо у типовій команді, яка складається з 5 людей. У нас є тім лід, який відповідає за комунікацію

із замовником і виконує роль технічного лідера.

Наш процес виглядає наступним чином:

• розробник каже тім ліду(TL) “Який таск мені взяти далі?”
• Тім лід пише замовнику(чи контактній персоні зі сторони замовника) і виясняє яку задачу можна взяти далі в роботу
• Надалі розробник(Dev) виясняє деталі або з тім лідом, або напряму з контактною персоною(CP). Тобто, у випадку(Dev -> TL -> CP) вся робота проходить через Тім ліда:

А у випадку(Dev -> CP) вся робота виконується виключно розробником самостійно:

                                       

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

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

Перші проблеми

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

Що станеться з нашим процесом, коли команда почне рости ?

• підхід Dev -> CP починає ставати неможливим, так як губляться технічні знання про взаємозв’язки функціоналу, крім того Тім ліду стане досить важко контролювати технічну якість через незнання бізнес логіки
• підхід Dev -> TL -> CP стає занадто витратним для Тім ліда, так як вся його робота поступово перетворюється в так званий Relations/Integration management і він починає не встигати виконувати свої прямі обов”язки по розвитку архітектури, виконанні складних технічних задач, консультуванні розробників, проведенні Code Review.

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

Що ж робити далі в такій ситуації?

Подивимось проблемам в очі

1. Не впорядкований беклог. Наш беклог - це просто список завдань і ідей для розробки. А тому розробники не знають, яке наступне завдання можна брати в роботу. Тобто девелопер/тім лід повинен звертатись до CP стосовно кожного наступного завдання. У випадку 15-ти розробників це буде досить обтяжливо для CP.
2. Тім лід може бути єдиною контактною персоною зі сторони команди. У випадку відсутності TL можливі потенційні проблеми з комунікацією.
3. Якщо кожний член команди самостійно обговорює бізнес логіку своїх завдань, то інші розробники не мають жодного розуміння, як воно працює. Таким чином, якщо у якийсь момент часу розробник йде з команди, то команда втрачає знання по певній кількості функціоналу, що обов’язково призведе до проблем в підтримці.
4. Тім лід починає не встигати виконувати свої прямі обов”язки.
5. Як замовник, так і команда не можуть передбачити, як швидко їм вдасться завершити розробку певного функціоналу, дати релізів і т.д.
6. Окремі розробники можуть “простоювати” в очікуванні завдань, у виясненні бізнес логіки.
7. Не всі розробники однаково досвідчені і команди, як правило, досить не однорідні. Замовники, як правило, хочуть зекономити, а тому прагнуть побільше набирати початківців. Початківці завжди потребують великої допомоги. Якщо завдання початківцю дає Тім лід, то збільшується навантаження на нього. Але якщо початківець буде намагатись виясняти бізнес логіку і завдання самостійно, то це може призвести до проблем на проекті, що також призведе до збільшення навантаження на Тім ліда і буде значним стресом для початківця.

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

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