Оценка затрат времени в устаревшей кодовой базе

Недавно я начал работать над проектом, в котором очень старое монолитное приложение переносится в архитектуру на основе микросервисов.

Устаревшая кодовая база очень грязная («спагетти-код»), и часто, по-видимому, простая функция (например, названная «multiplyValueByTen») позже показывает себя как «тысячи строк кода проверки, включающего 10 таблиц в 3 различных схемах».

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

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

Как мне подходить к такому сценарию?

Хотя я прекрасно понимаю, как работает рефакторинг устаревшего кода, мой вопрос не о том, «как сделать рефакторинг / переписать?» но о том, чтобы дать реалистичный ответ на вопрос "сколько времени потребуется, чтобы реорганизовать / переписать часть X?"

Прочитайте «Чистый кодер» Боба Мартина (и «Чистый код», пока вы на нем). Следующее из памяти, но я настоятельно рекомендую вам купить свою собственную копию.

Что вам нужно сделать, это средневзвешенное значение в три балла. Вы делаете три оценки для каждой части работы:

• лучший сценарий - при условии, что все идет хорошо (а)
• наихудший сценарий - при условии, что все идет не так (б)
• фактическое предположение - что вы думаете, это, вероятно, займет (с)

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

• Нет, это не будет точным. Существуют лучшие способы оценки, но этот метод быстрый, легкий для понимания и снижает оптимизм, заставляя вас рассматривать наихудший случай.
• Да, вам придется объяснить своему менеджеру, что вы не знакомы с кодом, и что вы слишком непредсказуемы, чтобы делать точные, точные оценки, не затрачивая много времени на изучение кода каждый раз, чтобы улучшить оценку (предложите сделать это, но скажем, вам нужно n дней, чтобы точно оценить, сколько еще дней это займет). Если вы «JuniorDev», это должно быть приемлемо для разумного менеджера.
• Вы также должны объяснить своему менеджеру, что ваши оценки усреднены на основе наилучшего, наихудшего и вероятного случаев, и предоставить им свои цифры, которые также дают столбцы ошибок.
• НЕ договаривайтесь об оценке - если ваш менеджер пытается использовать наилучший вариант для каждой оценки (они дураки - но я встречал кое-что подобное), а затем запугивать / мотивировать вас пытаться уложиться в срок, ну, они собираешься быть разочарованным иногда. Продолжайте объяснять обоснование оценок (лучший случай, худший случай и вероятный случай) и продолжайте приближаться к средневзвешенному значению чаще всего, и с вами все будет в порядке. Кроме того, для собственных целей сохраняйте электронную таблицу с вашими оценками и добавляйте фактические данные, когда вы закончите. Это должно дать вам лучшее представление о том, как скорректировать свои оценки.

Редактировать:

Мои предположения, когда я ответил на это:

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

Средневзвешенное значение в три пункта хорошо работает в этом случае. Это быстро, понятно для нетехнических и по нескольким оценкам следует усреднить что-то приближающееся к точности. Особенно, если OP прислушается к моему совету о ведении учета оценок и фактических данных. Когда вы знаете, как выглядят «наихудший случай» и «лучший случай» в реальном мире, вы можете использовать фактические данные в своих будущих оценках и даже скорректировать оценки для своего руководителя проекта, если худший случай хуже, чем вы думали.

Давайте сделаем проработанный пример:

• В лучшем случае, исходя из опыта, самым быстрым, что я сделал, было очень простое - начало недели (5 дней).
• В худшем случае, из опыта, было время, когда везде были ссылки, и в итоге у меня ушло 6 недель (30 дней).
• Фактическая оценка, вероятно, это займет у меня 2 недели (10 дней)

5 + 30 + 2x10 = 55

55/4 = 13,75, что вы и говорите в личку. Может быть, вы округлить до 14 дней. Со временем (например, десять заданий) оно должно усредняться.

Не бойтесь корректировать формулу. Может быть, половина задач заканчиваются кошмарами, и только десять процентов - легкие; Таким образом, вы делаете Estmate A / 10 + B / 2 + 2C / 5. Учитесь на своем опыте.

Обратите внимание, я не делаю никаких предположений о качестве PM. Плохой премьер-министр даст краткую оценку совету проекта, чтобы получить одобрение, а затем запугивает команду проекта, чтобы попытаться достичь нереального срока, который они взяли на себя. Единственная защита - вести учет, чтобы вы могли видеть свои оценки и приблизиться к ним.

Это может быть хорошим моментом для введения квази-гибкого подхода. Если вместо оценки в часах / днях вы назначили шкалу типа Фибоначчи и дали каждой задаче значение, основанное на ее размере:

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

Затем, как только вы оценили кучу таких задач, вы работаете над ними. В гибкой среде вы развиваете «скорость», которая является мерой того, сколько очков вы наберете, скажем, за неделю. После нескольких недель тестирования и обучения (вы можете продать это своему менеджеру как часть процесса - «Мне понадобится несколько недель тестирования и научиться понимать процесс оценки»), вы будете больше уверенности в том, сколько баллов вы можете продвигать каждую неделю, и, следовательно, вы можете с большей готовностью переводить свою оценку во время.

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

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

Это не по-настоящему проворно, так как в нем не участвуют церемонии, но я понял из ОП, что он сам по себе. Надеюсь, что этот подход может дать более уверенные оценки.

Первое, что вы делаете, это начинаете собирать данные о том, сколько времени вам нужно, чтобы что-то сделать прямо сейчас. Чем больше у вас данных о производительности вашей команды, тем лучше. Это будет повсеместно, но не беспокойтесь об этом прямо сейчас. Это правда, и вам нужно показать реальность своему боссу.

Тогда вы собираетесь купить несколько книг.

1. Оценка программного обеспечения: демистификация черного искусства Стивом Макконнеллом
2. Эффективная работа с устаревшим кодом от Michael Feathers

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

Объясните: если точные оценки важны для компании, вам нужно начать применять то, что вы изучаете из книги Фезера. Если вы хотите работать быстро, гладко и предсказуемо, вам нужно начать рефакторинг кода и поместить его в тестовый комплект. Я был там, где ты. Время разработки совершенно непредсказуемо, потому что вы понятия не имеете, что вы могли бы сломать, верно? ... Да. Получите это в испытательный комплект. Сервер CI для выполнения этих тестов также не может повредить.

Наконец, объясните своему боссу, что все еще некоторое время будет немного непредсказуемо. Вероятно, через несколько лет, но эта разработка будет становиться легче с каждым днем, а оценки будут более точными, когда у вас будет больше данных и улучшится код. Это долгосрочные инвестиции для компании. Я прошел через это недавно, потребовалось почти 2 года, чтобы стать в основном предсказуемым.

Я знаю, что больше говорил об улучшении кода, чем об оценке, но сложная правда в том, что ваши оценки будут паршивыми, пока вы не сможете приручить унаследованную базу кода. В то же время, используйте историческую производительность, чтобы оценить, сколько времени это займет. Со временем вы захотите принять во внимание то, что вы уже получили код, чтобы он соответствовал вашим оценкам.

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

Возможно, вы думаете, в поле для представления одной оценки. Я должен работать в устаревшем коде, и когда я делаю более формальную оценку, я обычно делаю два или три :

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

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

После того, как эти оценки будут опубликованы, я буду держать своего менеджера в курсе того, с чем, по-видимому, мы имеем дело. Если окажется, что мы смотрим на абиссальную особенность, то, возможно, нам придется пожертвовать ею - это случилось. Если ваш босс не может смириться с тем, что для данного куска унаследованного кода есть какие-то абиссальные особенности, тогда я желаю им удачи, потому что у них будет очень трудная и расстраивающая жизнь.

Когда я сталкивался с такой проблемой, я полагался на диапазоны своих оценок. Мне не мешало говорить своим боссам: «Трудно делать хорошие нерегулярные оценки на этой базе кода. Если вы попросите одну, это будет очень широкая оценка». Я дал "3 дня до 3 лет" в качестве оценки один раз. Излишне говорить, что это не была популярная оценка, но это то, что я дал.

Ключом к этому является соглашение о том, что я буду обновлять свои оценки в ходе работы. Так что, если мне скажут "Внедрить XYZ, сколько времени это займет?" мой ответ может быть «где-то между днем ​​и 4 месяцами. Однако, если вы позволите мне на самом деле посмотреть код на несколько часов, я могу уменьшить неопределенность в этом окне». Затем я смотрю на код и возвращаюсь со словами «от 2 до 4 недель». Это все еще не идеальное окно, но, по крайней мере, этим можно управлять.

Есть несколько ключей к этому:

• Убедите босс , что эти оценки лучше лечить как разговор , потому что вы будете узнать больше о том, что задача выглядит как во время работы его. Это возможность для вашего босса иметь информацию, которой у него не было бы, если бы он просто запросил единую оценку.
• Предложите варианты того, как двигаться дальше, какая скорость разработки торгового кода будет улучшаться по сравнению с оценками. Дайте им дополнительную ручку, которую они могут повернуть. Иногда боссы знают, что задача должна быть выполнена, и им нужна только приблизительная оценка. В других случаях они используют плюсы и минусы задачи, и возможность уточнить оценки является ценной.
• Если возможно, я также предложу синергетические бонусы. Часто есть архитектурные улучшения, которые будут полезны для многих задач. Если у меня есть 10 заданий, все из которых занимают «1-2 месяца сейчас, но потребуют 2 недели с обновлением X», проще продать те 20 недель, которые могут потребоваться для обновления X.

Если у меня есть начальник, которому неудобно получать диапазон, который обновляется на ходу, я дам ему один номер и мою методологию. Моя методология представляет собой комбинацию эмпирического правила, которое мне сказали как молодой разработчик, и закона Хофстадера .

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

а также

Закон Хофштадтера: «Это всегда занимает больше времени, чем вы ожидаете, даже если вы принимаете во внимание закон Хофштадтера».

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

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

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

В такой ситуации я не верю, что можно дать хорошие оценки. Основная проблема заключается в том, что зачастую большая часть работы заключается в том, чтобы точно выяснить, что нужно делать.

Я рассматриваю подобные случаи, давая оценку, основанную на том, что это влечет за собой, но с учетом того, что сюрпризы вероятны. Хотя мне не приходилось сталкиваться с большим количеством устаревшего кода, у меня были некоторые очень неприятные сюрпризы, связанные с вводом - я видел, как несколько часов превращаются в пару недель, а однажды в это невозможно (после Я понял, что у меня не было достаточно данных в определенном случае, обратно к чертежной доске.) К счастью, мой начальник понимает, когда я даю такие оценки.

Ну, оценка - это навык, который некоторые люди никогда не учат хорошо. Это не делает вас бесполезным разработчиком, даже если вы не можете придумать хорошие оценки. Возможно, товарищи по команде или руководство восполнят пробелы. Я ужасен в этом, все же большинство команд любили работать со мной. Сохраняйте спокойствие, объединяйтесь и продолжайте рефакторинг.

Технический долг ставит перед вами небольшие проблемы, но помните, что компания / команда, которая в конечном итоге создала долг, будет продолжать производить долг, если не произойдут изменения в командном духе или руководстве. Кодекс просто отражает социальные проблемы, поэтому сосредоточьтесь на реальных проблемах.

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

Этот фактор зависит от степени связывания и общего размера кода, но если вы сделаете некоторые функции таким образом, вы можете интерполировать этот фактор на основе фактических данных.

Я думаю, что вы должны сесть со своим боссом, посмотреть ему прямо в глаза и сказать:

«Слушай босс! Мы просто рефакторинг здесь. Нет новой функциональности для доставки, и нет клиентов, ожидающих этой функциональности; поэтому не должно быть никаких сроков. Это займет столько времени, сколько нужно, вам нужно решить, должны ли мы сделать это или нет ».

Используйте твердое жёсткое жестикулирование, например, указывание и сядьте вперед на стуле.

В качестве альтернативы вы могли бы сделать несколько цифр, чтобы сделать его счастливым. Но давайте посмотрим правде в глаза, пока вы не пройдете половину работы, ваши оценки будут довольно неточными.