Привіт. Мене звати Гліб Тупчій, я Delivery Manager в компанії MEV. Моя стаття адресована всім новачкам IT-сфери. Ще вчора ви старанно вивчали теорію, слухали лекції та робили домашки. Та ось перед вами свіженький сертифікат чи диплом, ви готові увійти у дивовижний світ IT та сповнені ентузіазму так само старанно виконувати завдання, які тепер вам даватиме тех-лід. Та ось в чому проблема: більше вам ніхто не буде говорити, що і коли робити, тепер — це ваша зона відповідальності. Нумо розбиратись, як з цим дати раду.
Welcome to Agile
З першим працевлаштуванням ви, скоріш за все, увійдете не тільки у дивовиже IT, але й у світ Agile. І якщо про те, як писати код, з різною успішністю розповідають на всіх спеціалізованих курсах, то от про середовище, в якому цей код потрібно буде писати, можуть і забути.
Тому для початку звернемось до азів. Agile — збірник гнучких практик і методологій розробки проєктів. Наведу нижче основні принципи з Agile Manifesto:
- Люди та співпраця важливіші за процеси та інструменти.
- Продукт, що працює, важливіший за вичерпну документацію.
- Співпраця із замовником важливіша за обговорення умов контракту.
- Готовність до змін важливіша за дотримання плану.
Сам Agile ми будемо розбирати на основі методології Scrum, яка відштовхується від того, що люди можуть бути самостійними та автономними. І цей принцип, і принципи Agile-маніфесту звучать досить логічно, чи не так?
Але тут ми стикаємось з першою проблемою: працюючи за Agile та Scrum всі, в тому числі новачки, мають самостійно приймати рішення і брати за них відповідальність.
Це НЕ значить, що побачивши задачу на кшталт «Як користувач, я хочу відкривати сайт і щоб було красіво» швидко накодити пару строк, які покладуть продакшн, бо ти вирішив все запушить в прод, бо хай його грець.
Це значить, зустрівшись з проблемою:
- сісти та подумати над нею;
- сформувати собі технічний план;
- проговорити його зі своїм ментором;
- оцінити фіналізований результат плану і почати із ним роботу.
Так-так, роботи чекає чимало. Але є й хороша новина: новачку з таким підходом точно дадуть плюсик в карму, а згодом будуть готові доручати цікавіші завдання або завдання «із викликом», що сприятимуть персональному та професійному росту.
І цей підхід починається з того, щоб будь-яку задачу довести до готовності брати її в роботу (Definition of Ready). Це означає, що потрібно розуміти:
- Про що в задачі йдеться — що необхідно зробити?
- Як цю задачу робити — чи є в задачі технічний план реалізації чи потрібно зробити цей опис?
- Скільки задача займає часу — чи є в задачі оцінка і чи правильна вона?
- Як задачу тестувати? — чи є розуміння, як цю задачу перевірити, коли вона буде готова
- Як задачу деплоїти? — чи є розуміння, як цю задачу залити під кінець розробки після тестування
- Чи варто цю задачу робити одразу — чи є в задачі виставлений пріоритет до запуску в роботу.
Очевидно, що перший і шостий пункт не може бути продуктом уяви — тут залучається або людина з команди, або зі сторони клієнта, яка надасть вимоги до роботи (що саме має бути виконано і в якому пріоритеті). Але імплементація (як задача буде виконана і її оцінка — це твоя відповідальність)
Крок 1. Описуємо задачу
Почнемо з план імплементації або опису задачу. Опис — це не художній твір з елементами фантастики на тему, як виконати задачу, а радше розгорнута відповідь на наступні питання:
- Як я буду це робити? — покроковий план робіт, який дозволяє побудувати чіткий і зрозумілий алгоритм роботи
- Як я буду це тестувати? — якщо в задачі мають бути дописані юніт-тести (зазвичай воно так і є) — то як вони будуть написані, як ти, як розробник, перевіриш якість коду.
- Як я буду це деплоїти? — коли задача буде дороблена і перевірена, які наступні дії я, як розробник, матиму виконати
Крок 2. Оцінюємо задачу
Зрозумівши, що і як потрібно робити, потрібно ще й визначитись, скільки часу нам на все це буде потрібно. Пам’ятаєте, як на початку ми говорили про те, що більше вам ніхто не буде ставити завдання і говорити на коли потрібно здати домашку їх виконати. Отож. Тепер ви самі їх оцінюєте.
На початковому рівні — визначаєте estimate, тобто скільки часу, вам потрібно на власні маленькі та деталізовані технічні задачі. Але пам’ятаємо, що в сучасних agile методологіях вирізняють декілька видів надання оцінок. Наприклад:
Технічний рівень — тут задача потребує максимальної деталізації та чіткого алгоритму виконання. А якщо є чіткий алгоритм, то й оцінка надається в ідеальних годинах, без урахування перерви на каву.
Наприклад, уявімо, що ви задумали ремонт ванної. За технічним планом, потрібно спочатку винести речі (5 одиниць по 1 хвилині на кожну річ), а потім приступати безпосередньо до ремонту. Тобто ми доходимо висновку, що винести 5 речей займе у нас 5 хвилин.
Рівень Story — в задачах такого масштабу рівень невизначеності більший, а отже, і оцінка менш точна. На цьому рівні загальна практика пропонує використання Story (або Scrum) points, що відповідає суб’єктивній оцінці розробника рівня комплексності задачі. Чим більш важко усвідомити всю роботу і чим більше там потенційних ризиків, тим більша оцінка.
Тепер ремонт у ванній робить ваш друг і просить вашої допомоги. Оскільки ви це вже робили, то можете сказати, що умовно завдання можна поділити на два етапи: винести з ванної речі та зробити сам ремонт. Винести речі з ванної, на вашу думку, задача легка і все в ній відомо, це ви оцінєюте в 1-2 сторіпоінти, а от зробити ремонт може виявитись комплексною задачею, в якій мало що відомо досі, та і саму ванну ви ще не бачили, тому поставите оцінку у 8 сторіпоінтів. Згодом, приступаючи до самого ремонту, ви переоціните цю задачу, розкладете її на менші та отримаєте 2-3 прості для виконання задачі по 1-3 сторіпоінти кожна.
Рівень Epic — для великих категорій задач використовується методика оцінки T-shirt sizing. До уваги, це релятивна методика, коли оцінка для задачі надається у відношенні її «розміру» до розміру інших задач рівня Epic.
Під час ремонту у вашого друга виявилось, що потрібно винести з ванної зубні щітки та пральну машинку. Використовуючи методику T-shirt sizing ми оцінюємо «винести зубні щітки» розміром XS, а винести пральну машинку розміром XXL.
Підкреслюю — важливо, щоб саме ви надаєте оцінку своїм задачам, а після того аналізуєте її. Це важливо тому, що оцінювати в робочій атмосфері доведеться багато, часто швидко і бажано якомога точніше. Тому чим раніше ви займетесь цим самотужки, тим швидше будете рости, як інженер. І не того, що навчитесь ставити циферки в задачах, а тому, що зрозумієте темп своєї роботи.
Бонусний крок — коли трапляється щось несподіване
Опанувавши базові навички опису та оцінки задач, ви можете досить впевнено себе почувати …допоки у рівняння не додасться нове непередбачуване невідоме.
Уявімо розробницю Валентину, яка закінчила всі ремонти у ванній, і пару місяців тому влаштувалась на свою першу роботу в IT-компанію. Отримавши задачу, написавши технічний план та поставивши оцінку, вона почала працювати. Та під час роботи, передивляючись код, вона знайшла коментарі попередніх розробників і зрозуміла, що ці коментарі були поставлені не по гайдлайнам.
Ось ці коментарі і є те невідоме, про яке ми говорили на початку. Що з ним робити? Проігнорувати та удати, що цих коментарів не було? Кинути все та почати фіксити?
Наша Валентина, як відповідальна людина, не могла не повиправляти всі помилки в коментарях, які знаходила. Вона самостійно вирішила, що це більш пріоритетна задача. І от прийшов дедлайн, а початкова задача, яка була так класно і так точно описана — не виконана.
І наче Валентина все зробила правильно, виправивши помилки, але от тільки її ніхто про це просив. Зайва самодіяльність призвела до того, що задача не була виконана, робота не пророблена, проблеми бізнесу не закриті.
А тепер уявімо альтернативний розвиток цієї історії. Знайшовши коментарі, Валентина поставила собі запитання «Чи треба це робити?», не розуміючи загального контексту проєкту. «Не знаю» — подумала вона і створила тікет в беклозі, щоб завтра підняти це питання на дейлі. В результаті робота Валентини виконана, бо вона не відволікалась, менеджер дізнався про проблему і зміг запланувати розв’язання проблеми. Проєкт тим часом завдяки бездоганній роботі Валентини мав успіх на ринку.
Проблема Валентини в першій історії не в тому, що вона виправила помилки попередніх розробників, а в тому, що вона на той момент не розуміла, що зараз пріоритетніше для проєкту — задача, яку їй дали, чи виправлення помилок в коментарях і не уточнила це, коли це мало найбільшу вагу — в момент виявлення помилки.
Тобто наша задача не кидатись у вир із головою, а підійти до питання прагматично — з точки зору доцільності та вигоди. А для цього потрібно завжди задавати собі питання «А навіщо я це роблю?» і «Чи треба це робити?». Роблячи це, можна зробити перший крок в сторону прагматичності. А ця компетенція швидко буде підіймати вас з Trainee до Junior, від Junior до Middle і т. д.
Висновки. І що робити далі?
Перше, що треба зробити в IT, це зрозуміти: свідомий підхід до роботи — це найсмачніша шоколадка в очах людини, що буде вас наймати.
Друге — це почати розбиратись в тій задачі, що вам зараз дають. Чого її треба виконати? Чи можливо виконати задачу легше і швидше?
Описати задачу — це один з перших кроків до її вирішення, і, пишучи технічний план реалізації, набагато легше згодом цю задачу виконати.
Оцінювати задачу — це також відповідальність людини, що виконує роботу. Вміння оцінювати час, який має бути витрачений на роботу, підвищує ваш рівень компетенції, як інженера і як людини. Згодом ви зможете сказати, що на ремонт у ванній вам потрібно 3 дні та чітко вкладетесь у ці строки.
Прагматичність — це дуже важлива складова інженерного способу мислення. Вміння раціональніше витрачати свій час і час інших дозволяє більш ефективно використовувати свої здібності. Прагматичність, як вміння зрозуміти, що зараз дійсно важливо, і робити саме те, що зараз найважливіше, має входити в ваш Mindset. А над його розвитком можна працювати все життя.