Мистецтво оцінювання

14.12.2017

СТАТТЯ СЕТА БРАУНА (SETH BROWN)

Зображення видалено.Сет Браун, менеджер з розвитку

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

У Сета Брауна – великий бекграунд досвіду роботи в Lullabot. Він почав свою кар’єру написанням різних текстів для журналів випускників коледжу. Це був 1995 рік, і, як представник покоління Х, Сет тоді опікувався створенням веб-сайту коледжу. Він займається побудовою сайтів до сьогодні. Також він був менеджером інтернет-проекту, технічним письменником, редактором - протягом 15 років. До приходу в Lullabot Сет працював у коледжі Колорадо, у коледжі Роллінз, у Асоціації випускників університету Колорадо, Пенн Стейт та Blue Tent Marketing, у компанії з інтернет-маркетингу неподалік від Аспену, штат Колорадо.

У Blue Tent Сет створив веб-відділ з нуля. Коли компанія розширилася з трьох до 30 чоловік, Сет став дизайнером/розробником/менеджером проектів, віце-президентом веб-проектів і партнером Чаі Валлаха (Chai Wallah).У процесі спостереження за проектами Lullabot Сет іще й аналізує бізнес-процеси, збирає вимоги й уносить свій вклад у плани розвитку проектів Lullabot вищого рівня.

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

Сет є головою групи користувачів Друпал Західного Колорадо. Він відомий на drupal.org як sethlbrown.

Зображення видалено.

Дві правди про оцінювання

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

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

Оскільки ми любимо наших клієнтів, а далеко не всі з них живуть у світі необмежених бюджетів й гнучких вимог, оцінювання (естімейти) – це доконечна потреба. Отже, що ж робити з цим пориванням до оцінювання? У цій статті я розповім про те, як Lullabot використовує широкосмуговий метод оцінки Дельфі, який було розроблено в корпорації «РЕНД» у 1940 році, – один із методів технічного оцінювання, що базується на консенсусі. Не хвилюйтеся! Наш підхід не такий химерний, як це звучить.

Декомпозиція проекту

Перш ніж ви зможете оцінювати, ви маєте розкласти проект на частини, що підлягатимуть оцінюванню. Теоретично це доволі просто. Цитата з підручника мого коледжу інформатики й обчислювальної техніки: «Алгоритми для вирішення задачі можуть бути розроблені формулюванням проблеми, а потім – розкладанням проблеми на підзадачі. Кожна підзадача також має бути розділена на менші підзадачі. Цей процес повторюється, доки кожна задача, що залишилася, не стає такою, що легко вирішується». «Чудово, - можете ви подумати. – це звучить просто! У мене є час, аби надолужити втрачене в моїй партії на chessatwork.com». Реально, це завжди складно – придумати структуру декомпозиції робіт (Work Breakdown Structure, W.B.S.) – такий модний термін для довгого й комплексного перелічування маленьких важливих завдань, необхідних для завершення mongongous-проектів.

Існує безліч різних підходів до декомпозиції проекту; ви можете вивчати їх у всіх деталях, що виходять за межі цієї статті, але я коротко поясню декілька найбільш популярних. Якщо вимоги невідомі, їх потрібно виявити, - це такий хитромудрий спосіб сказати, що настав час сісти з вашими замовниками десь на три дні, і поставити силу-силенну запитань. Мені подобається уявляти себе детективом, що розслідує вбивство, не залишаючи й каменю на камені. Звичайно Lullabot робить це тиждень на місці, а потім вертається до себе на базу, щоб написати документи «Бачення й коло застосування», або «Специфікація вимог до програмного забезпечення», у яких проект розкладається на 10-20 базових особливостей із детальним описом вимог (requirements) та припущень (assumptions) щодо кожної. Ці особливості мають бути розкладені на все менші й менші добірки проблем. Ми хочемо описати тут типові рішення цих проблем на Друпал.

Коли ми працюємо з клієнтом, знайомим із Agile/Scrum (гнучка методологія розробки/методологія управління розвитком інформаційних систем), ми, можливо, не маємо потреби в тому, щоб робити оцінку, але ми так само будемо розробляти проектні затримки, представлені як епоси (epics), і потім поділені на частини всередині історій користувача (user stories), і історії користувача стануть елементами, що підлягають оцінюванню, а також – базою для рекомендацій рішень Друпал.

Наш підхід до декомпозицій проекту

Утім, буває, що відкриття бюджету немає, ви не можете продати Agile, чи ви працюєте з RFP (замовленням на продукт). У таких сценаріях я би порадив розібрати проект на частини за тими рішеннями Друпал, що вже існують. Які типи контенту, перегляди, значення таксономії, меню, блоки й т. ін..? Чи будете ви потребувати Panels або Context модулів для допомоги з блоками або макетом? Знання інструменту заздалегідь – це величезна перевага, коли справа доходить до здійснення оцінки (естімейту). Якщо ви вже користувалися такими рішеннями як Panels, Services, SOLR або Migrate, або компонентами розв’язання проблем у минулому, то невідомого менше, і ви зможете оцінювати з минулого досвіду. Lullabot має таблиці, які нам подобається використовувати як допомогу в обмірковуванні великих, багаторівневих сайтів із точки зору їх компонування будівними блоками Друпал. Цей шаблон, Номери таблиць, також допомагає нам запам’ятовувати роздуми про нефункціональні вимоги й речі, які зазвичай не бачать користувачі, але які є також важливими: розгортання процесів, вимоги до хостингу тощо.

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

Стандартна структура декомпозиції робіт

Ось таблиця, що демонструє, як ми зазвичай формуємо нашу структуру декомпозиції робіт:

Зображення видалено.

Зверніть увагу, які у вас колонки для R&D (Research & Development), «Розвиток», «Темізація» і «Контроль якості» для кожного елементу. Робочий час, витрачений на управління проектом, ми розраховуємо окремо, як накладні видатки по проекту в цілому. Наш досвід підказує, що, у залежності від виду проекту, внутрішніх управлінських ресурсів та навичок клієнта, видатки по управлінню проектом, у загальному випадку, складають від 20 до 35% від усього бюджету. Найбільші за часом видатки зарезервовані за клієнтами, які раніше не були задіяні в підприємство із розгортання CMS.

Також іноді корисно організовувати W.B.S. у спрінти: періоди роботи тривалістю не більше місяця. Користь від такої вправи в тому, що це допомагає вам розпочати, аби отримати відмітки в графіку, і спонукає до того, щоб ви подумали про пріоритети й послідовність задач. Зробіть кожний п’ятий етап стикувальним, без певних цілей та завдань, крім того, зауважте й неминучі затримки проекту, архівацію згубних помилок минулих етапів і різноманітних завдань. Більшість процесів управління змінами в контрактах дозволяють, теоретично, можливість змін у замовленнях, що виникають, але майже ніколи не залишають часу в розкладі, аби розібратися з цими змінами.

Скільки коштує цей поганий хлопець?

І ось, насамкінець, ми добралися до модної справи - оцінювання. Перший крок – визначення одиниць оцінювання. На Lullabot ми користуємося ідеально запрограмованими годинами, що визначають, скільки часу буде використано, якщо програміст лишився сам, вільний від відволікань, насичений, як горною свіжістю, блаженством від відтворювання коду, і пише тести з Selenium або теми завдань. Ми виявляємо гнучкість із прирощенням, у тому сенсі, що ми робимо наші найкращі приблизні оцінки. Утім, правда полягає в тому, що чим вища оцінка, тим вища й вірогідність похибки. З цієї причини часто буває корисно обмежити прирощення припущень, щось на кшталт: 15 хвилин, 1, 2, 3, 4, 8, 12, 16, 24, 32, або 40 годин. Зайве – сперечатися щодо того, чи піде на задачу 30 або 32 години, тому як… добре, складно сказати, не знаю. У моєму уявленні, такі задачі, які, вірогідно, візьмуть понад один тиждень на розробку, мають бути поділені на суб-задачі, і переглядатися. Якщо ви виконали вашу роботу з W.B.S., щодо переважної частини задач із нижнього рівня діапазону ви матимете більшу точність.

Далі оберіть двох або більше інженерів із вашої команди, включно з тими, які були задіяні в процесі декомпозиції проекту на задачі. Розповсюдьте вільну від оцінок копію таблиці W.B.S. серед усіх, хто оцінює, і попросіть їх скористатися нею й дати оцінки кожному елементу, одночасно документуючи свої припущення в колонці «Коментарі» у таблиці. Документування припущень є відповідальною річчю для консенсусу, і необхідне для добрих контрактів. Якщо ці припущення задокументовані й потім враховані в договорі, то це просто, і в контракті передбачається те, що, за домовленості з клієнтом, попередня оцінка може бути відхилена, а попередня вартість – переглянута.

Зараз неоціненна гра в оцінювання розпочинається по-справжньому. По-перше, корисно мати безстороннього проектного менеджера або модератора гри. В ідеалі, ця людина не повинна мати частки в задачах, що підлягають оцінюванню, і, виходячи з цього, має бути неупередженою. Модератори збираються в Skype, на конференц-лінії, у реальній кімнаті, чи демонструють вільні від оцінок копії як таблиці Google Doc. Тепер настав час розкрити їхні оцінки для всіх, а також припущення щодо цих оцінок. Для багатьох задач оцінювання має бути дійсно закритим, а необхідність робити припущення – незначна. У таких випадках менеджеру з проектів або модератору краще зробити простий постінг середніх значень у спеціальну таблицю. Утім, якщо оцінки розбіжні дико, - це означає, що потрібно обговорити припущення. Один розробник міг би запропонувати декілька команд у командній стрічці drush (drupal shell), котрих буде достатньо, аби управляти модулем користувача там, де інший розробник буде повинний запустити повнофункціональний UX (User experience). Кожного разу, коли всі досягають згоди в припущеннях, і менеджер проектів задокументовує це, наступає час інженерів для здійснення переоцінки. Сподіваюся, що результати будуть уже точнішими. Іноді ті, хто визначає час, після обміну припущеннями змінюють позиції з вищої на нижчу або навпаки. Різниця з початковою оцінкою “естіматора” ставиться в “Дельфі”, за методом широкосмужної оцінки (Wideband Delphi estimation).

Ключовий момент тут – пересвідчитися, що тон бесіди є вільним і товариським, і тоді продовжувати цикл «оцінювання – дискусія – оцінювання – дискусія». Мета – консенсус щодо найліпше обміркованої оцінки, і забезпечення того, аби групові припущення були задокументовані. Якщо ви після трьох ітерацій оцінки ще не досягли консенсусу, це, вірогідно, тому, що в душі ви не згодні з припущеннями. Це неминуче і внаслідок надто багатьох невідомих, або це – програмістська гордість («Це не займе 12 годин, тут же лише хук змінити!»). У такій ситуації корисніше те, що просуває вперед: виділіть суперечливі колонки жовтим, і призначте когось, хто розпочне ліквідацію неясних моментів. Якщо, через графіки, у вас є лише один раунд для здійснення кінцевої оцінки, розглядайте можливість показати клієнтові діапазон, разом із припущеннями, які стосуються цього діапазону так чи інакше. Це можуть бути пункти, які ви не хочете оцінювати. Спробуйте додати час і матеріали в умови контракту, щоби покрити ризики у неоцінюваній частині роботи, яка не підлягає прогнозуванню (див. міграції, дата (migration, data.)).

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

Додатковий кредит

Аби представити ще більше функцій у процесі та пересвідчитися в оцінках, що проводяться наосліп, спробуйте використовувати http://www.planningpoker.com, велику віртуальну гру з оцінювання, яка має додаткові переваги, у тому числі двохвилинний таймер для кожного раунду дискусій.

Бездоганний розтин

Шукайте шляхи реєстрації часу (ми спокійно користуємось http://www.letsfreckle.com) у проектах, і розглядайте питання реєстрації часу, принаймні, на рівнях деталізації, таким чином, щоб ви могли повернутися й виконати бездоганний розтин ваших оцінок. Якщо щось пішло не так, то виникає питання: чому Спрінт 6: Міграція даних зайняв у 47 разів більше часу, ніж очікувалося. Занотуйте типи етапів, які, здається, повторювали ще раз і ще, як винні в перевитраті, і відрегулюйте ваші наступні оцінки відповідним чином. Якщо ви насправді скрупульозні, роздивіться вхідні вашої W.B.S., як задачі, прямо в системі управління проектом. Ми використовуємо Unfuddle, із віхами, що являють собою етапи та завдання для пунктів W.B.S. Unfuddle, як і багато інших програм для менеджменту проектів, дозволяє реєструвати час на заданих рівнях. Після того як проект став завершеним, поверніться й зробіть огляд наявного продукту біля оцінок, і подивіться, що сталося. Ви дізнаєтеся багато чого, і ця історична дата спрямовуватиме вас на шляху майбутніх естимейтів.

У висновку

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