Ошибки разработчика. Кейсы, как делать не надо

Меня зовут Павел, я сооснователь компании Stan’s Assets from KAPPS, и уже более 5 лет я работаю с Unity-проектами. За свою карьеру мы все совершаем много ошибок в своей работе, и часто многие разработчики их повторяют.

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

Неправильная эстимация задач

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

В какой-то момент услышали фразу, что вследствие стала нашим корпоративным мемом: «Я чувствую, что на меня оказывают моральное давление, потому что эстимейт нужно предоставить в часах». Разработчик предложил делать его в уточках, звездочках, либо же сердечках :) Да, история похожа на анекдот. Но она иллюстрирует то, как сложно иногда бывает оценить время работы и результата выполненных тасков. И когда задачи становятся более сложными, то оценки работ становятся куда более нетривиальными.

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

И чем более эти задачи атомарные, разбитые на какие-то неделимые участки, тем точнее вы сможете дать по каждому из них эстимацию. А соответственно общая эстимация будет суммой всех этих эстимаций. Мы описали подход, который называется WBS (work breakdown structure).

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

Преждевременная оптимизация кода

На одном из наших проектов разработчик очень «бережно» относился к написанию кода, например, к тому, как работают циклы. Поэтому у нас часто были разговоры о том, что лучше работает — for или foreach. Этот разработчик все время очень сильно защищал идею того, что все переменные, которые я объявляю внутри тела цикла, нужно вынести за пределы самого цикла.

И представьте себе ситуацию, когда я объявляю 3-5 переменных (bool-флаги, integer-счетчики) очень высоко, потом у меня идет код, потом цикл for. При чтении такого кода потерять из контекста все эти переменные очень легко еще до момента, когда доскролил до самого цикла.

Такая рьяная позиция нашего разработчика была обусловлена тем, что он не совсем понимал, как работает компилятор того же C#. То есть до конца не осознавал, что фактически на устройстве выполняется не совсем тот код, который был написан нами на C#. Это значит, что если мы объявляем переменную внутри цикла for, то это не значит, что компилятор представит ее в том же виде после компиляции в IL (intermediate language) или C++ код (при использовании IL2CPP scripting backend).

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

Почему moonwalk — это плохо

Иногда люди думают, что удаленная работа — это возможность работать на нескольких работах сразу. И они считают, что отлично смогут справиться с восьмичасовыми задачами за 2-4 часа, а все остальное время посвящать другой 8-часовой работе. Это приводит к негативным последствиям на обоих проектах.

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

Если говорить на чистоту, то совмещать несколько full-time работ — это тяжело, и точно нерабочая история на длинной дистанции. Таких разработчиков называют moonwalkers. И помимо последствий для проектов скорее всего они встречаются с внутренним выгоранием и убивают свою же продуктивность на месяцы, может и годы. А всплывает это очень быстро. И хотя в краткосрочной перспективе это кажется заманчивым — получить не одну зарплату, а две — это быстро закончится, а вот последствия как для карьеры, так и для собственного состояния придется разгребать еще долго.

Почему фейлятся билды

Каждый разработчик если не собирал билд сам, то точно готовил его к сборке. И наверное сталкивался с тем, что очень часто в самый неподходящий момент билд может сломаться.

Вспомним проект Ori WotW. Репозиторий проекта находился на SVN, и это накладывало множество ограничений на удобства пользования. Особенно работа в различных ветках. То есть если разработчик работал над какой-то фичей, то ему приходилось коммитить код напрямую в главную ветку develop (в которой одновременно «живет» множество артистов, дизайнеров и других разработчиков), что подвергало опасности рабоспособность текущей ветки и команды в целом. Это замедляло или даже приостанавливало работу команды до момента исправления проблемы.

Поэтому очень часто происходило так, что люди могли сломать билд по той или иной причине. В данном случае мы хотели сделать акцент не на том, как минимизировать поломки и «научить» себя коммитить код, который не сломает ветку, а, скорее, как вовремя диагностировать проблему. Существует множество разных систем для CI/CD: Jenkins, Team City, GitHub Actions и другие. Такие решения помогают автоматизировать и стабилизировать процесс сборки билдов и поступление «новых» изменений в главную ветку разработки. Ревью кода, автоматические билды, автоматические тесты и QA — это как раз те подходы, которые призваны «помешать» разработчикам сломать проект и зафейлить билд. Не забывайте об этом и тогда ваша разработка будет происходить максимально гладко!

Дизайн архитектуры проекта

Очень сложно в долгосрочной перспективе заниматься проектом, если не следить за его чистотой и не задумываться об архитектуре на самых разных уровнях: будь то на низком уровне, среднем или высоком. Вы спросите — почему, можно же очень быстро собирать приложение, делать прототипы, фиксить, и с этим приходить к заказчику.

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

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

Чем это хорошо и зачем это все нужно?

Представьте, что сегодня вы делаете один проект, а завтра вы делаете пять проектов, и они между собой чем-то схожи. Вместо того, чтобы переносить из одного проекта, который вы делали ранее, буквально копируя какие-то папки или скрипты — вы просто можете импортировать себе в новый проект безболезненно тот же core-функционал, который вам был нужен.

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

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

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

Делитесь этими знаниями, дабы не терять время на исправление ошибок, а создавать новые и классные проекты, о которых вы мечтаете.

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному4
LinkedIn

Найкращі коментарі пропустити

Самая правильная оценка задач — вообще не оценивать. Займет, сколько займет. Если спонсора это не устраивает, мы ищем такие проекты, задачи и таких спонсоров, где будет так. Самые лучшие инженерные команды, где довелось поработать, именно так и подходили к вопросу. (само собой, у них run-rate и бюджет были довольно резиновые). Иногда, конечно, мог быть какой-нибудь crunch, но это не основная часть R&D процесса.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Про преждевременную оптимизацию, и вынесение переменных за тело цикла. Удивительно что люди все ещё мыслят компиляторами из 80 х годов. Даже Borland C для MS DOS уже оптимизировал, распределял регистры вместо стека и т.д. Откуда у современных разработчиков этот аттавизм ? Им же не 50 лет. Причем есть статические анализаторы которые на код в стиле Кернигана и Ричи ругается сообщениями типа Brain overload и т.п. Однако стоит отметить что лично я никогда не видел у молодых такого кода, в отличие от классики которую пишут новички с ещё не сформированным мышлением. Тоесть классика «кода с душком». Сверхсложные функции на 200-300 операторов и елочками из операторов выбора в на 2-3 уровня в глубину, велосипеды, не знание регулярных выражений, неумение пользоваться стандартными библиотеками, работа с бинарными данными через строковый тип, сверх-мудреный дизайн модулей, хардкодинг, магические числа, глобальные переменные и т.д.

В общем, банальные вещи, но про них, конечно, лучше не забывать.

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

Бувають звичайно генії програмування, але писати одразу ідеальний код, у вас так виходить?
Іноді доводиться і шліфувати, і рефакторити код по кілька разів, та й коли у тебе постійно дедлайни, про ідеальний код зазвичай не йдеться....

У меня — нет, достаточно часто приходится повторно над ним работать. Мне показалось что в статье я как раз «призываю» разработчиков думать и проектировать свой код, вместо бездумного его наращивания.

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

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

Что касается проблемы дизайна проекта:

если не следить за его чистотой и не задумываться об архитектуре на самых разных уровнях

Знание о том что «что-то» сломалось вовсе не отвечает на вопрос как можно рационально продолжить масштабирование приложения, не ломая его.

Почему фейлятся билды

Каждый разработчик если не собирал билд сам, то точно готовил его к сборке. И наверное сталкивался с тем, что очень часто в самый неподходящий момент билд может сломаться.

Чесно кажучи, так і не зрозумів з опису, чому білд може зламатися. Я — розробник, зібрав чи смерджив мою робочу гілку локально, потім зробив push на GitHub/GitLab, що там ламатиметься?

В статье описан пример работы с SVN на конкретном проекте, поэтому я не совсем понял к чему вопрос.

Пф) та є мільйон і один спосіб зламати білд після мержа фічі в девелоп бранч xD

Таких разработчиков называют moonwalkers.

А чому розробників? Це можуть бути і менеджери, QA і адміни. Для адмінів та менеджерів це навіть більш імовірно, тому що вони звикли до переробок чи роботи на кілька проектів усередині компанії.

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

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

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

Категорически согласен с вами (как и в жизни, всё имеет смысл), но Вы наверняка согласитесь что 99% кода который мы пишем каждый день — вовсе не требует «глубинного» осмысления его микро- или макро-оптимизаций.

Трохи поверховий виклад, хотілося б глибшого розбору

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

А ось і ні. Цей підхід може 1000 разів не спрацювати, бо:
1) За під-завданнями немає чітких вимог і дати точну оцінку неможливо
2) Розробник буде працювати з кодом або технологіями чи API, які раніше не бачив і може наступити на купу граблів, які затягнуть виконання

Ви справді IT консультант і з вашими клієнтами розмовляєте у такому стилі?

А почему собственно он должен предлагать что-то взамен.
Вроде приведены валидные ситуации, в которых метод оценки работать не будет.
Вывод: метод как минимум не серебрянная пуля.

Ох вас и триггернуло ) понедельник он такой, да.

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

Спасибо за рекомендации, оценка по трём точкам согласен, важно чтобы привычкой была. Не всегда её использую к сожалению. Возможно потому, что часто как-то неосознанно не рассматриваю негативный сценарий, а выбираю скорее между «наиболее вероятным» и «позитивным».

Прям конкретно в цифрах не считал к сожалению. Из 20 задач не попал в оценку навскидку задачах в 11-12, больше половины в общем. Из них 5-6 задач процентов на 30, что по идее не сильно критично, но были задачи где и на 50 и больше, до 100. Проблема ещё и в том, что точность оценки зависит от сложности и объёма задачи, чем сложнее задача, тем больше разброс в оценке и тем чаще ошибаюсь с эстимейтами. То есть выходит что на более важных (сложных и больших) задачах я как раз чаще ошибаюсь.
Решением вижу не давать оценок «навскидку», а брать дополнительное время для оценки времени и не экономить на нём: вникать во все детали задачи, разбивать задачу на небольшие части и оценивать уже их (собственно, как в данной статье и предлагается). Сюда же по поводу «заморачиваться» — насколько я могу судить, я не сильно заморачиваюсь, возможно даже нужно наоборот ответственнее подходить к оценке и не давать быстрых оценок, как этого возможно ждут от меня.
На счёт смены менеджмента: не уверен, что это решение. Проблемы с оценкой задач у меня наблюдалась на нескольких местах работы, то есть или мне подряд не везло с менеджментом или всё-таки проблема во мне :)

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

— поправить строчку в коде, найти строчку, исправить, коммит, пуш, пулл-реквескт это минут 6 мин.(0.1ч)

Так не бывает. Ну или по крайней мере не должно быть в случае non-critical-production-bug.
Как минимум
+локал билд (30сек -> XX мин), пусть будет 5 минут по среднеоптимистической оценке, зависит конечно от проекта
+локал тест (1 мин -> YY мин), пусть будет 5 минут по среднеоптимистической оценке, реально очень часто больше
< push / PR are here >
+code review (30 сек -> Z мин)

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

Классический пример микроменеджмента, не дай бог работать на таком проекте.

переделка это новая задача с типом «коррекция». При таком подходе качество процессов у вас взлетит в разы.

Угу. Только веслать некому будет...

Возражу вам по поводу локального билда, зачем весь солюшен собирать, гоните тест сразу.

Ошибаются все, даже в самых очевиднейших вещах. В лучшем случае (синтаксическая ошибка) код просто не соберется на билд сервере — тем не менее даже это потеря времени ( конкретно у меня на проекте, в некоторых случаях локальный билд около 10 минут, на билд серверах до 45 минут). В худшем же (например, надо было исправить 1000 -> 10000, исправилось 1000 -> 100000 ) - это может обнаружиться только после деплоймента, и весь цикл надо перезапускать заново — еще большая потеря времени.

Если же

задачи собираются в пакеты работ, так «дешевле» по расписанию.

то тут еще хуже

Например, добавить новый или набор новых сущностей готовой спеке на 10-20 полей, и создать юнит тесты на гетер-сетер.

Задачи такого плана крайне редко имеют самостоятельную ценность — обычно это часть задачи вида (первое что пришло в голову) — «extend API to provide XXX». И для подобных задач разделение вида «extend persistence layer» , «extend business logic layer», «extend web/api layer» вполне достаточно в 80% случаев. Ну, подразумевая что команда не полные идиоты и не находятся в состоянии итальянской забастовки

создать юнит тесты на гетер-сетер.

Никогда не понимал value от такого (если это именно банальный геттер-сеттер без логики внутри, которые еще и почти всегда autogenerated)

Да ладно, и как можно жить с билдом 7 часов вообще?) Тут 15 минут долго и оптимизируем блин...

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

В этом случае все так

Мне советы не нужны, поверьте :)
Речь шла что практика

Возражу вам по поводу локального билда, зачем весь солюшен собирать, гоните тест сразу.

часто бывает порочной

локально\СI больше, чем в 2 раза. Ссобирай локально, запускай тесты, профит. Пушай в СI !

Именно, это был основной посыл

А может за этим классом ещё что то есть, сериализация например кастомная,

Специально написал:

если это именно банальный геттер-сеттер без логики внутри,

Если же необходимо протестировать

сериализация например кастомная,

То это и будут юнит-тесты сериализации

Это в современных синтакисах

Ну так я предполагал что мы про современность а не про седые времена

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

Идея-то понятна, но очень напоминает попытку взять 9 женщин и родить ребенка за месяц :). И выглядит сильно error-prone

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

Ух ты, а можно отсыпать чудо-травы чтобы попасть в такой мир :)))

Мне проще посадить трех разработчиков, один добавит классы. Второй свойства в эти классы. Третий конструкторы будет в них писать.

А между рядов будет ходить строгая училка и диктовать что писать, ага. Я думал большей ... эээ... «экзотики» чем «отдельные задачи типа „коррекция“ на комменты в пул реквесте» я в этом треде уже не встречу но нет, отечественный менеджмент не так прост... :)

Мне проще посадить трех разработчиков, один добавит классы. Второй свойства в эти классы. Третий конструкторы будет в них писать.

Для «внести в проект 50 классов задать проперти и конструкторы без участия мозга» человечество придумало автогенерацию кода. Ну в крайнем случае один профессиональный стенографист-наборщик «500+ знаков в минуту» заткнёт за пояс ваших трёх "разработчиков"(извините что в кавычках но по-другому не знаю как назвать людей которые наперегонки педалаят пустые гетеры-сеттеры потому что дальше на конвейере к ним прикручивают такие же пустые юнит-тесты)

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

Тут всего один вопрос — кто и как у вас контролирует код джунов? или не джунов, а просто новых людей-не-в-теме ( new hire, перевели с другого модуля / проекта ) ?

Вы мне может возразить, мол, если после код ревью нужна переделка.

Зачем возражать на ожидаемые вещи?

отвечаю, переделка это новая задача с типом «коррекция».

Зачем изобретать велосипед? Это называется technical debt и стандартные процедуры работы с ним

Пул реквест виден кому надо, в чем ваш вопрос я не понимаю?Что-то «плохо» пишется, коментарии вопросы, исправления. Что бывает по-другом?

Это и есть классический код ревью, или вы понимаете под ним только когда несколько седобородых лидов на построянной основе вдумчиво исследуют все что написано , от и до ? Такое тоже бывает, но очень редко, и естественно требует отдельного планирования

Долг технический, к чему он? Исчадие скрама. Откуда ему вдруг взятся.

Технический долг к сраму, да и к любой методологии разработки отношения не имеет — это общее понятие, описывающее необходимые изменения, не связанные напрямую с бизнес-требованиями.

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

Ну да, «х#ли тут думать, копать надо». Речь не об навыках как таковых, речь идет об вещах специфичных для проекта — naming conventions, принятая архитекура модулей, приложений и тестов, принятый набор библиотек и т.п.

человек не справляется, буквально «андерстимейтит» (то есть недооценивает сложность задачи и затягивает сроки)

Як на мене, то «андерестімейт» — це зазвичай проблема в переоцінці власних здібностей і завищених вимог до себе (перфекціонізм).
Класно, що ідея з естімейтами в качках спрацювала.

Дякую за статтю.

Добрый день! Да, уже не первый год работаем над open-source тулкитом github.com/StansAssets

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

Так а в чем анекдот — не понял. Много кто эстимейтит не в часах. Числа фибоначчи же норм. Вопрос же в единицах сложности. Называй их хоть утками, булками или палками

Проблема в том, что бизнесу интересны часы. Точнее, когда будет готово. Поэтому потом эти уточки кто-то должен все равно преобразовать в календарные даты.

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

Очень интересные комментарии, спасибо. Я положительно отношусь к конструктивным «взглядам» на любые вещи.

а зачем бизнесу твои естимейты в утках? какой ему от этого толк? может тебе тоже зарплату в утках платить? а будет это 1к или 10к то такое.

Поэтому потом эти уточки кто-то должен все равно преобразовать в календарные даты.

Это однозначно говорит о том, что с управлением проекта большая проблема. Если вы используете скрам (по описанию похоже что да, если фигурирует сайзинг), так это ошибка из ТОП-3 — прямой маппинг эстимейта на время. Тут уже или крестик снять или штаны надеть.

P.S. Скрам, сам по себе, считают одной из самых неудачных методологий разработки, поинт в том, что если уж он выбран на проекте в силу каких-либо причин, то хотя бы не надо усугублять

Статья хорошая, но вопрос по эстимейту неоднозначный, так как описанный подход может занять достаточно много времени. Хотя для более точной оценки этот подход самый правильный.
Есть ещё один интересный способ установки эстимейтов — это определить коэффициент погрешности в своей оценке и начать применять его. То есть сравниваем установленный эстимейт с реальным временем выполнения и получаем нужный нам коэффициент.

Очень круто что затронули момент «авторства» оценки задач. Внутри компании у нас чёткое правило: автор = исполнитель. Конечно бывают ситуации когда задачи назначаются другим разработчикам, в этом случае следует сделать переоценку с новым исполнителем задачи.
Если исполнитель синьор с которым команда уже работает определённое время — его квалификации более чем достаточно чтобы сделать оценку самостоятельно, если мидл — верификация лида, если джуниор — живое обсуждение и обучение разработчика делать такие оценки (позволить человеку проанализировать и выставить эстимейты самостоятельно, но проконтролировать их «адекватность»).

P.s. огромное спасибо за множество потраченного времени на ответы в комментариях под статьёй (надеюсь что не зря и читатели захотят вникнуть в суть, а не сделать поверхностное оценивание проблем).

Самая правильная оценка задач — вообще не оценивать. Займет, сколько займет. Если спонсора это не устраивает, мы ищем такие проекты, задачи и таких спонсоров, где будет так. Самые лучшие инженерные команды, где довелось поработать, именно так и подходили к вопросу. (само собой, у них run-rate и бюджет были довольно резиновые). Иногда, конечно, мог быть какой-нибудь crunch, но это не основная часть R&D процесса.

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

Я знаю несколько команд в Гугле, которые на уровне VP выбили себе правило «никаких дедлайнов», соответсвенно и эстимейтить нечего.

Я в одной из таких команд был TPM-ом, и за пару недель понял, что там с вопросами по оценке буду послан еще дальше, чем с дедлайнами. Далек мир R&D от стандартной проектной работы, но именно там делаются технологии, на которых потом делают проекты :)

Да, не все обратили внимание что речь идет про R&D ;-) А так да, среднестатистический бизнес такие вещи, мягко говоря, не поймет.

Самая правильная оценка задач — вообще не оценивать. Займет, сколько займет. Если спонсора это не устраивает, мы ищем такие проекты, задачи и таких спонсоров, где будет так.

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

Годится для решений, которые вообще на старте не понятно, возможны ли. И их решение — это вопрос количества попыток/итераций со стороны экспертов в области. На которые денег не жалко. Согласен, что это редко, но это лучший вариант для разработчика, к которому нужно стремиться.

UPD: не все проекты коммерческие

Дедлайн по проекту, и естимейт таски в часах это немного не одно и тоже.

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

Выше я на это ответил — даже исследовательские проекты нуждаются в планировании. И при подходе «займет сколько займет» очень легко в конечном итоге просто остаться без финансирования.

конечно там все есть, но статья-то была об ошибках разработчика

У каждого проекта по определению есть границы(сроки его исполнения), если их нет — это не проект.

Ок, тогда можно сказать, что лучше работать на «не проекте», а деньги брать в тумбочке :) Серьезно, какой был бюджет и границы у ядра линукса? Или у биткоина?

Оце дуже не звично. Зараз працюю в такому проекті. З одного боку розхолоджує, з іншого — постійно тримає в тонусі й легкому стрессі: чи не задовго робится ця задача? Поки неоднозначні відчуття.

Заканчивается это тем, что девелоперы просто нихера не делают.

Таку діяльність досить складно затрекати в JIRA

Підписатись на коментарі