У мене досить великий стаж розробки, але починаючи з 2001 року я перейшов на керівні позиції. В основному на посадах тімліда і проджект менеджера, але останні роки в якості керівника компанії. Тому методології розробки – це те, з чим я близько стикаюся. Крім того, я витратив дуже багато часу і сил, щоб виробити власне уявлення про те, як треба будувати процес розробки. Я спікер великої кількості конференцій по проджект менеджменту і, крім усього іншого, ще й сертифікований Scrum Master.
По хорошому, по кожній з методологій SCRUM, Kanban варто читати цілий тренінг, тема дуже обширна. Але навіть якщо ви пройдете такі тренінги, ясніше вам не стане. Чому?
Зараз ми маємо велике кількості теорій з управління командами, які в руках одних людей працюють, а у інших – не працюють. Вся справа в людському факторі. Є природжені керівники, які на інтуїтивному рівні знають, як керувати людьми, а отримані додаткові знання і методології їм допомагають. Але є ті, хто не схильний керувати людьми: людина занадто не впевнений в собі або, навпаки, занадто авторитарний і хоче продавити всіх під себе. В руках у таких керівників навіть найкращі методології можуть не працювати.
З чого все починалося?
На початку не було ніяких особливих методологій, просто було завдання, програмісти сідали і робили. Першими замовниками були військові, а як працюють військові? Все робилося строго за регламентом, поетапно. Така методологія отримала назву «Водоспад». Подібна модель розробки добре підходить саме для військових проектів, коли є одне ТЗ, немає змін і робиться завдання до переможного кінця.
У комерційній розробці все працює інакше. З кожного етапу може знадобитися повернутися на попередній, коригувати ТЗ, змінювати правила, переписувати код, змінювати структуру та ін. Так, це незручно, але і відійти від цього не вийде, бо бізнес змінюється дуже швидко.
Гнучкі методології розробки: Agile
Ринок диктує умови бізнесу, бізнес змінюється і це відбивається на умовах розробки. Таким чином з’явилася велика кількість гнучких методик розробки під загальною назвою Agile. SCRUM, Kanban також відносяться до Agile розробки. Дані методології можуть використовуватися не тільки в програмуванні, але і в інших сферах. Наприклад, Kanban був винайдений в корпорації Toyota і відмінно адаптований саме до промислового виробництва.
Методології не є взаємовиключними. Ви можете одночасно використовувати більшу частину з них разом. Наприклад, SCRUM, Lean і Kanban прекрасно поєднуються і не заважають один одному.
Людьми керувати складно, їх неможливо загнати в одну модель і змусити функціонувати однаково. У кожного члена команди є своє уявлення, в який час краще працювати, в колективі є відносини один з одним, що також впливає на ефективність роботи. PM повинен враховувати цей аспект, а ось жодна методологія вам цього не врахує.
Що ж дають методології? Фактично, кожна з них дає вам опорні точки. Дає можливість розуміти, який з варіантів прийнятих вами рішень, кращий і за якими параметрами. Сьогодні є величезна кількість теорій з управління персоналом. Написані мільйони книг і вони не суперечать один одному, а доповнюють.
Методологія Lean
Це методологія виходу на ринок. Вона каже, що для того щоб вийти на ринок, не обов’язково мати повністю закінчений продукт. Тому що ви будете робити його три роки, потім винесіть на ринок, а він не зайде. Ви даремно витратили час і гроші. Опитувати заздалегідь цільову аудиторію теж немає сенсу. Тільки те, за що користувач платить, то і буде найкращим варіантом, а на опитуваннях можна багато різного сказати. Lean каже, що ви повинні зробити мінімальну версію продукту і дивитися, як він зайде. Але Lean взагалі нічого не говорить про управління персоналом.
Методологія Kanban
Суть Канбана – розподіляти завдання, які ставляться усередині команди, по етапах розробки і переміщати їх за цими етапами. Канбан дошки можуть ділитися на будь-яку кількість етапів, саме примітивний розподіл: 1) Те що в планах 2) Те, над чим працюємо 3) Готово.
SCRUM
Методологія SCRUM каже, що завдання потрібно робити не потоком, а ітераціями. Тобто відбирати якусь кількість завдань, які в фіналі створять якийсь інкремент – доповнення функціоналу до вашого продукту. І ось такими ітераціями ви рухаєтеся до мети. Це відмінна методологія для ІТ сфери – замовник бачить, що у вас постійне нарощування функціоналу, він стабільний і постійно працює. Таким чином ви не втратите занадто багато часу, якщо ринок різко зміниться.
Ще є методологія Extreme Programming, але вона досить важка, тому в чистому вигляді не використовується. Всі запропоновані рішення ефективні, але викручені на максимум. Наприклад, всі знають, що найбільш ефективно програмісти працюють парами, за методологією Extreme Programming передбачається, що весь код пишеться в парі. Код, покритий тестами, працює краще і надійніше, по Extreme Programming код повинен бути покритий тестами на 100%. І так далі. У реальному світі це не зустрічається.
Природно, кожну методологію я дуже сильно спрощую, показую тільки основну суть системи.
