Оцінка витрат часу в застарілій базі коду

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

Спадкова база даних коду дуже брудна ('код спагетті') і часто, мабуть, проста функція (наприклад, названа як "multiplyValueByTen") пізніше виявляється як "тисячі рядків коду перевірки, що включає 10 таблиць у трьох різних схемах".

Тепер мій начальник (справедливо) просить мене оцінити, скільки часу знадобиться для написання функції X в новій архітектурі. Але у мене виникають труднощі з реалістичною оцінкою; часто я дуже недооцінюю завдання через причини, про які я говорив вище, і бентежу себе, бо не можу закінчити вчасно.

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

Як слід підходити до такого сценарію?

Хоча я прекрасно розумію, як працює рефакторинг застарілого коду, моє питання не стосується "як зробити рефактор / переписати?" але про надання реалістичної відповіді на те, "скільки часу знадобиться, щоб рефактор / переписати частину X?"

Прочитайте "Чистий кодер" Боба Мартіна (та "Чистий код", поки ви на ньому). Далі з пам’яті, але я настійно пропоную придбати власну копію.

Що вам потрібно зробити, це середньозважене середнє значення в три бали. Ви робите три оцінки за кожен твір:

• найкращий сценарій - якщо припустити, що все йде правильно (a)
• найгірший випадок - якщо припустити, що все піде не так (б)
• власне здогадка - що, на вашу думку, напевно знадобиться (с)

Ваша оцінка тоді (a + b + 2c) / 4

• Ні, це не буде точним. Існують кращі способи оцінки, але цей метод швидкий, простий для розуміння та пом’якшує оптимізм, змушуючи вас розглядати найгірший випадок.
• Так, вам доведеться пояснити своєму менеджеру, що ви не знайомі з кодом і що для вас занадто непередбачувано робити чіткі, точні оцінки, не витрачаючи тривалий час на дослідження коду, щоб покращити оцінку (пропонуйте зробити це, але скажіть, що вам потрібно п днів, щоб дати чітку оцінку, скільки ще днів знадобиться). Якщо ви "JuniorDev", це має бути прийнятним для розумного менеджера.
• Ви також повинні пояснити своєму менеджеру, що ваші оцінки оцінюються в середньому, виходячи з найкращого, гіршого та ймовірного випадку, і надати їм свої цифри, що також дає їм смуги помилок.
• НЕ ведіть переговори щодо оцінки - якщо ваш менеджер намагається використати найкращий випадок для кожної оцінки (вони дурні - але я зустрічав подібних), а потім знущаєтесь / мотивуєте вас намагатися досягти терміну, ну, вони іноді будеш розчарований. Продовжуйте пояснювати обґрунтування оцінок (найкращий випадок, найгірший випадок та ймовірний випадок) і продовжуйте наближатися до середньозваженої більшості разів, і вам повинно бути все в порядку. Крім того, для власних цілей зберігайте таблицю своїх оцінок та додайте факти, коли закінчите. Це має дати вам краще уявлення про те, як скорегувати свої оцінки.

Редагувати:

Мої припущення, коли я відповів на це:

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

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

Давайте зробимо відпрацьований приклад:

• Найкращий випадок, із досвіду найшвидший, який я зробив по-справжньому, був тиждень від початку до кінця (5 днів)
• Найгірший випадок, з досвіду, в той час, що всюди були посилання, і це закінчило мене 6 тижнів (30 днів)
• Фактична оцінка, можливо, це займе 2 тижні (10 днів)

5 + 30 + 2х10 = 55

55/4 = 13,75 - це те, про що ви говорите своєму прем'єр-міністру. Можливо, ви обійдете до 14 днів. З часом (напр., Десять завдань) воно повинно бути середнім.

Не бійтеся коригувати формулу. Можливо, половина завдань закінчиться кошмарами, і лише десять відсотків - це легко; тому ви зробите оцінку a / 10 + b / 2 + 2c / 5. Навчіться зі свого досвіду.

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

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

• 0 - миттєвий
• 0,5 - швидка виграш
• 1 - проста зміна
• 2 - пара простих змін
• 3 - більш складний
• 5 - зажадає певного роздуму
• 8 - значна кількість роботи
• 13 - великий шматок роботи, який, ймовірно, потрібно розбити
• 20 - масова частина роботи, яку безумовно потрібно розбити

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

https://pm.stackexchange.com/questions/4251/why-would-teams-use-the-fibach-sequence-for-story-points

https://stackoverflow.com/questions/9362286/why-is-the-fibach-series-used-in-agile-planning-poker

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

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

Тоді ти збираєшся купувати кілька книжок.

1. Оцінка програмного забезпечення: Демістифікація чорного мистецтва Стіва МакКоннелла
2. Ефективна робота зі спадковим кодексом Майкла Пір'я

Книга МакКоннелла підкаже вам почати збирати дані, а потім пояснити, як їх використовувати для отримання більш точних оцінок. Завжди дайте оцінку 3 бали! Завжди. Обов’язково виділіть частини книги, в яких йдеться про те, як низька якість коду підірве ваші оцінки. Покажіть їх своєму начальнику.

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

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

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

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

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

1. Первинна оцінка - якщо припустити, що мені доведеться витратити деякий час на копання, але архітектура дозволяє зміни, які ми хочемо
2. Ангельська оцінка - передбачає, що все прозоро / легко знайти, і мені потрібно лише внести незначні зміни (це те, що я іноді залишаю поза увагою ... особливо якщо я знаю, що в певній базі коду є лише чорти)
3. Abyssal Estimate - передбачає, що основна структура застарілого коду несумісна із запитуваною функцією, і мені доведеться зробити великий рефакторинг, щоб зробити роботу

Всі три оцінки враховують, наскільки сильна функція сама по собі, будь-який досвід роботи з цією базовою базою коду, і моє відчуття кишки щодо змін (які я виявив може бути досить точним)

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

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

Ключовим моментом є угода про те, що я поновлю свої оцінки в міру просування роботи. Тож якщо мені скажуть "Впровадити XYZ, скільки часу це займе?" моя відповідь може бути "десь між днем ​​і 4 місяцями. Однак, якщо ви дозволите мені реально подивитися на код протягом декількох годин, я можу зменшити невизначеність у цьому вікні". Потім я переходжу до коду і повертаюсь з "2 - 4 тижні". Це все ще не ідеальне вікно, але принаймні це щось, чим можна керувати.

Для цього є кілька ключів:

• Переконайте бос , що ці оцінки краще лікувати як розмова , тому що ви будете дізнатися більше про те, що завдання виглядає як під час роботи його. Це можливість для вашого начальника мати інформацію, якої вони не мали б, якби вони просто попросили провести одну оцінку.
• Запропонуйте варіанти, як рухатися вперед, яка швидкість розробки торгового коду порівняно з покращенням оцінок. Дайте їм додаткову ручку, яку вони можуть повернути. Іноді начальство знає, що завдання потрібно просто виконати, і їм потрібна лише бальна оцінка. В іншому випадку вони виконують плюси і мінуси завдання, а можливість уточнення оцінок є цінним.
• Якщо можливо, я також запропоную синергійні бонуси. Часто є архітектурні вдосконалення, які могли б принести користь багатьом завданням. Якщо у мене є 10 завдань, кожне з яких займає "1-2 місяці зараз, але оновлення триватиме 2 тижні", то простіше продати 20 тижнів, які можуть знадобитися для оновлення X.

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

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

і

Закон Гофстадтера: "Це завжди триває більше часу, ніж ви очікували, навіть якщо ви враховуєте закон Хофстадтера".

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

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

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

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

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

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

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

Ми використовували евристику для оцінки особливостей проекту «коричневого поля»: Ми підрахували, як довго було б впровадити цю функцію в проект «зеленого поля», без нічого вже реалізованого. Потім ми помножили цю оцінку на 2, щоб розібратися з очищенням сміття, яке вже існувало.

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

Я думаю, вам слід сісти з вашим начальником, подивитися йому прямо в очі і сказати:

«Слухай боса! Ми просто реконструюємо тут. Немає нових функцій для доставки, і немає клієнтів, які очікують на цю функціональність; тому не повинно бути термінів. Це займе стільки часу, скільки потрібно, вам потрібно вирішити, чи потрібно це робити чи ні ".

Скористайтеся твердими напористими жестикуляціями, такими як вказівка, і сідайте вперед на своєму кріслі.

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