Привет всем!
Теория, необходимая для старта в разработке, весьма обширна. У каких-то специалистов (backend-разработчиков на Java и других языках) ее больше, а других (например, frontend-разработчиков на JavaScript — React Native) — чуть меньше.
Однако и у одних, и у других должен быть большой запас не только технических, но и “организационных” знаний. Эти “организационные” познания — одна из точек пересечения для frontend- и backend-разработчиков.
Сегодня я хочу поговорить об одном из аспектов таких нетехнических, организационных знаний — об оценке задач (estimation).
И так как я работал только в Agile методологии (которая по факту считается самой популярной), в его подчасти, Scrum, рассматривать оценку задач буду в контексте Scrum.
Сразу скажу, что оценка, называемая ещё эстимацией, трудна.
Лично для меня как для разработчика это один из самых трудных / нежелательных аспектов работы.
Необходимо учитывать множество различных факторов, которые могут повлиять на оценку задачи. При этом планы по дальнейшей разработке будут отталкиваться от ваших прогнозов.
А что если не угадать с оценкой?
Если разработчик закладывает на задачу гораздо больше часов, чем в итоге будет потрачено, может сложиться впечатление, что он не самый лучший специалист, ведь оценка была очень неточной. Так сказать, пальцем в небо.
В то же время, если разработчик не вложится в прогнозированное время, он ставит под угрозу планы заказчика по выпуску продукта/новой фичи.
Это бизнес, а бизнес — это деньги, и мало какому заказчику понравится такой прокол.
Собственно поэтому я и недолюбливаю эстимацию, ведь иногда так сложно установить точное время выполнения задачи.
Как проводится оценка времени
Как правило эстимация проводится в часах или стори поинтах. Лично мне гораздо ближе процесс оценки именно в стори поинтах. Если часы — это что-то физическое, то, в чём можно ошибиться, стори поинты — это уже немного о другом, более абстрактном.
Как правило, команды разработчиков ПО дают оценки в формате времени: часы, дни, недели, месяцы. Такие временные оценки основаны в первую очередь на личном опыте, предположении или интуиции. В таком случае разработчики просто смотрят на задачу и озвучивают предположение, сколько она бы заняла у него времени.
В итоге они весьма редко бывают точными, ведь есть слишком много факторов, которые могут повлиять на срок выполнения работы.
Поэтому многие команды, работающие по Agile методологии, используют именно стори поинты. Давайте разбираться.
Что такое Story points
Стори поинт — это единица измерения, выражающая оценку общих усилий, которые необходимы для полной реализации определенного участка работы (функционала). То есть, это такая себе относительная сложность.
Команды присваивают оценку в стори поинтах в зависимости от сложности работы, объема работы, риска или неопределенности.
Как правило эти значения назначаются, чтобы эффективнее разбивать работу на более мелкие части, тем самым устраняя неопределенность.
Со временем это помогает командам понять, чего они могут достичь за определенный период времени, и способствует более точному планированию следующих участков работы.
Вам это может показаться совершенно нелогичным, но на самом деле эта абстракция весьма полезна: она подталкивает команду к принятию более жестких решений относительно сложности работы.
Давайте рассмотрим некоторые причины использовать стори поинты при планировании:
можно избежать неточности оценки во временных интервалах;
в отличие от оценки во времени, можно лучше учесть затраты на накладные расходы: коммуникации между членами команды и заказчиком, различные обсуждения командой и планирования, а также непредвиденные ситуации;
каждая команда будет оценивать работу по разной шкале, что означает, что их скорость (измеренная в баллах) будет разной;
определив шкалу для назначения каждого стори поинта, вы сможете быстро распределять баллы без особых споров.
Как НЕ надо использовать стори поинты
К большому сожалению, стори поинты часто применяют не по назначению.
Стори поинты могут ошибаться, если они используются для оценки людей, определения подробных сроков и ресурсов, а также когда их ошибочно принимают за меру производительности.
Вместо этого командам необходимо их использовать, чтобы понять объем / сложность работы в каждой задаче и для расстановки приоритетов. Возможно, что части, которые оценены как более сложные, стоит делать в первую очередь, чтобы их удалось сделать до до конца спринта, ну а более легкие отодвинуть на позже.
Напомню вам, что такое спринт в контексте Scrum методологии:
Sprint — это повторяемый фиксированный временной интервал, в течение которого создается некоторый запланированный участок функционала.
Насколько долгий этот временной промежуток, определяется в начале разработки по договорённости команды и заказчика. Это может быть промежуток в две недели или месяц, или любой другой срок.
Как правило эстимация задач ведется в начале спринта, чтобы спланировать возможный объём выполненной работы к его концу, когда выполненная работа предоставляется заказчику.
Представление заказчику выполненной за спринт работы называется demo.
Оно помогает видеть ваш прогресс в разработке продукта, получать фидбек от заказчика и скорректировать развитие проекта согласно видению заказчика.
Но все же мы немного отвлеклись: вернёмся к эстимации.
Оценка задач лишь одним разработчиком была бы слишком субъективной. Поэтому как правило это командная работа.
Техник для командной оценки довольно много. Сегодня мы рассмотрим самую используемую из них — Scrum poker.
Для этой техники необходим менеджер, который будет кем-то типа ведущего этого Scrum poker-а. Это может быть человек специализации Scrum Master, ну или же PM.
Что такое Scrum Poker
Scrum poker — или покер планирования — это техника оценки, которая основана на достижении договорённости. В основном используется для оценки сложности предстоящей работы или относительного объёма решаемых задач при разработке ПО.
Сразу отмечу, что Scrum poker — обычная практика при разработке, и вам точно нужно знать, что это за зверь.
Для этого процесса обычно используется некое приложение или сайт, который позволяет нам организовывать командную оценку той или иной задачи.
Как это происходит?
Команда берёт элемент невыполненной работы (новую задачу, функционал), вкратце обсуждает возможные подводные камни и другие нюансы, связанные с ним. После этого каждый участник выбирает карточку с числом, которое отображает его оценку сложности.
Ах, да при оценке используются не обычный ряд, а числа Фибоначчи.
Числа Фибоначчи так популярны в scrum poker-е потому, что между ними со временем увеличивается промежуток (напоминает уровни пирамиды). Существуют задачи, у которых будет огромная сложность, и малым количеством стори поинтов тут не обойтись.
Пояснение для необычных карточек:
неизвестное количество эндпоинтов
бесконечно долгая задача
нужен перерыв
Более редкие способы эстимации:
в размерах футболок —S, M, L, XL
или в собаках — чихуахуа, мопс, такса, бульдог и так далее (как по мне, это самая странная единица оценивания задач =D)
Затем команда сравнивает поставленные оценки одной и той же задаче разными разработчиками, и если они сходятся, отлично!
Если же нет, необходимо обсудить причины различий в оценке (аргументы). После этого можно сообща прийти к единому эстимейту, с которым все плюс-минус будут согласны.
Ну а почему вообще используется покер для планирования серьёзного программного проекта? Ведь это как-то странно.
На самом деле подобная геймификация побуждает членов команды мыслить независимо, предлагая им показать свой результат одновременно со своими тиммейтами.
Это, в свою очередь, позволяет избежать зависимости от взглядов других членов команды.
Ведь иначе менее опытные разработчики будут поглядывать и ориентироваться на оценки более опытных членов команды, что сведёт на нет полезность их собственной оценки.
Но при одновременном вскрытии результатов это по сути невозможно.
В качестве примера приложения для планирования в формате Scrum Poker можно взять приложение от Atlassian.
Пример оценки задачи
Представим, что ваша команда выделила некоторую шкалу для оценивания в стори поинтах:
1. Имеется ли опыт с задачей подобного рода
+1 — делал такую задачу ранее
+2 — не делал такую, но работал с похожей
+3 — не делал такую же и не было опыта ни с чем подобным
2. Объем функционала задачи
+1 — малый объем
+2 — средний объем
+3 — большой объем
3. Сложность реализации данной задачи
+1 — легкая
+2 — средняя
+3 — сложная
4. Сложность тестирования данного функционала
+1 — легкая
+2 — средняя
+3 — сложная
Начинается Scrum Poker по задаче, и вы оцениваете ее так:
вы никогда не работали с имплементацией аналогичного функционала ранее — +3
функционал задачи среднего объема — +2
реализация задачи имеет высокую сложность — +3
высокая сложность написания тестов для данного функционала — +3
По итогу получается 11 стори поинтов, но так как такой карточки нет, вы предлагаете 13.
Другой ваш коллега оценивает задачу:
работал с аналогичной задачей ранее — +1
функционал задачи среднего объема — +2
реализация задачи имеет среднюю сложность — +2
средняя сложность написания тестов для данного функционала — +2
В итоге у него получается 7 стори поинтов, но такого в числах Фибоначчи нет, и он ставит карточку с максимально приближенным числом — 8.
Другие члены команды, соответственно, ставят оценки, отталкиваясь от своих субъективных взглядов.
Далее вы показываете свои результаты и обнаруживаете, что почти все ваши коллеги поставили эстимацию 13, кроме одного разработчика, который поставил 8.
В таком случае ему даётся слово, и он приводит доводы.
А они, к примеру, такие: он работал ранее с такой же задачей, и она не так сложна, как это может показаться, и в итоге он убеждает остальных членов команды сменить своё решение с 13 на 8 стори поинтов, говоря, что он поможет тому, кто займется этой задачей, разобраться с ней. Либо, в конце концов, выполнит её сам.
И во общем-то не важно, прислушаются к его доводам остальные или нет, ведь так или иначе оценка будет присвоена данной задаче, и команда перейдет к ознакомлению со следующей.
Первые разы оценки будут неточные, как и прикидки объема работ, которые вы планируете сделать за следующий отрезок времени (спринт).
Ведь эти прикидки делаются именно по эстимациям.
Спустя какое-то время, примерно месяца через три, команда начнёт более точно оценивать задачи, да и станет виден средний объем работ, который может выполнить команда за спринт.
Но это общее планирование объема работ, это больше про время, а в данном случае может быть много разных факторов, оказывающих влияние.
Например, ушёл в отпуск на две недели один из разработчиков. То есть нужно вычеркнуть определённый объем планируемых работ (планируемого функционала).
Или в команду пришёл новый разработчик, но при этом полноценно на него рассчитывать не надо, т.к. нужно учесть время на адаптацию к проекту, называемое онбордингом. Это может быть недели две, плюс-минус неделя, в зависимости от сложности проекта.
На этом у меня сегодня всё, надеюсь я немного улучшил ваши познания в такой нетехнической части знаний как эстимация задач.
Если же вы хотите углубиться в данную тему, как и в детали Scrum, настоятельно советую прочитать книгу Джеф Сазерленд "SCRUM". За последствия я не ручаюсь, ведь возможно, после неё у вас появится назойливое желание стать Scrum Master-ом =D
В скраме есть спринты, в конце спринта - sprint demo / sprint review (более новое название ревью, раньше и еще массово употребляется - демо), на этом демо, команда демонстрирует реализованные фичи.
Если разработка идет по спринтам, каждый спринт имеет фиксированное количество дней - две недели или три или сколько там решат.
Поэтому бизнес видит, если юзер стори (фича) предполагается к выводу в демо в этом спринте, значит будет фича через две недели, если это фича большая, то как правило тоже видно, ну значит будет в след спринту.
Если это эпик большой, состоящий из многих юзерстори, это могут быть кварталы, там уже на глаз определяется.
В этом одна из главных фишек , почему эджайл стал так популярен в айти, чтобы не делать годами непонятно что, которое будет работать непонятно когда, Большая Задача, делится на поднаправления, они на эпики, эпики на стори, стори на таски, таски на сабтаски, и это уже другой разговор, когда абстрактную задачу Построить Дом, сводят к набору подзадач - к примеру "залить фундамент", "вырыть яму под фундамент", да, могут быть накладки, но в целом это измеримо и понятно сколько может времени занять.
И чем меньше размер задачи, тем меньше возможные накладки.
На большой Задаче Построить Дом, может за 1 год построят, может за 20 если ну все пойдет не так - документы, коммуникации и тд.
На маленькой подзадаче "вырыть яму" нету влияния документов, нету влияния других факторов, только проблемы к примеру - там кабель проморгали на схеме и повредили, там еще что-то, но это уже то, что решаемо тоже за сравнительно небольшой период времени.
И здесь и нужен опыт, когда опытные тимлиды и синиоры, могут мастерски лавировать между потенциальных проблем и уже на этапе уточнения ТЗ, на этапе оценки могут сразу сказать "вот такую фичу будем делать долго, там много подводных камней, конкуренты вас обскачут , она потеряет смысл, а если выбрать эти технологии, и сделать почти тоже, но вот так, и будет быстро и что нужно", поэтому и платят ЗП за опыт.
Это ключевое понятие - опыт, а не знания, можно прекрасно разбираться в технологиях и иметь глубокие технические скиллы, но не имея опыта, как когда-то зафейлилось из-за этого, а там застопорилось из-за другого, это только половина того, что нужно программисты, поэтому именно опыт, а не уровень техзнаний определяет грейд программиста - джун/мидл/синиор/техлид, хотя безусловно, более сильные технические специалисты быстрее по грейдам будут расти.
Как итого, небольшие фичи бизнес видит прозрачно когда будет имплементировано.
Чем более абстрактные и больше размер фичи, тем более неопределенней.
Суть эджайла конечно не столько в понимании времени, сколько быть гибким -
waterfall или kanban, это когда известно заранее , к примеру есть Дом, мы знаем 100% все шаги.
scrum прижился в ИТ из-за того, что это эджайл позволяет очень быстро ориентироваться,
в этом спринте делаем сенсоры птиц. Потом конкурент выпустил и запатентировал этот сенсор, мы хопа, быстро в воздухе переобуваемся, и в следующий спринт закладываем другую фичу - без сенсоров, просто автоматическая система отпугивания - есть птицы или нет, мы меняем, и так постоянно, изменения на ходу, поскольку в ИТ все меняется постоянно кардинально, нужно очень оперативно на это реагировать.
КЛассический waterfall, 10 лет планировать, а потом 10 лет по инструкции строить - здесь не подходит. На строительстве второго этажа жилого дома, вдруг выяснилось что нужно строить ТРЦ...это будет полная перезагрузка всех процессов и с нуля, вернее сначала разрушить, потом с нуля.
А при Скраме, это очень легко - ТРЦ как ТРЦ, второй этаж брсоаем строить, в первом расширяем высоту, Меняем размеры и тд.
То есть скрам отлично подходит если мы не знаем как выглядит конечный результат
Можно почитать:
- epics
- user-stories
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ