О сроках

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

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

Сжатые сроки. И сжатые сраки. Чтобы успеть к срокам.

У нас есть несколько характеристик проекта, которые мы можем покрутить. Скоуп. Команда. Сроки. Деньги.

Скоуп. Объём работ. Трудоёмкость. Сколько и чего нужно сделать.

Можно измерять в совершенно абстрактных сторипоинтах. Можно в более конкретных человекочасах. Можно в совершенно конкретных нормочасах, но в программирование их пока не завезли.

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

Человекочасы вполне конкретны. Их можно измерить по факту. Именно этим и занимаются эти приложения типа Upwork и TimeDoctor, которые не только считают время, которое конкретный программист нажимает кнопочки и двигает мышкой, занимаясь конкретным проектом или даже задачей, но ещё и делают скриншоты, а также записывают, какие программы запускались, и какие сайты открывались.

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

Нормочасы совершенно конкретны. Но программирование пока ещё считается творческой профессией. И у нас нет типовых задач, с типовыми нормами трудозатрат. Думаю, что никогда и не появятся, ибо такие задачи прекрасно автоматизируются. И мы их автоматизируем.

Команда. Конкретные люди, которые будут делать задачи. Человеческие ресурсы.

Они отличаются навыками и ролью. Есть фронтендеры, есть бэкендеры, есть аналитики, есть тестировщики.

Квалификацией. Сениор крут, и делает всё быстро. Джун медленен и несамостоятелен.

Стоимостью. Зато джун дёшев. А сениор очень дорог. Цена чаще всего определяется рейтом, то есть деньгами за человекочас.

Доступностью. Или занятостью. Никто в здравом уме, трезвой памяти и честно не может постоянно работать по 40 часов в неделю. Тех апворкочасов, что записывают упомянутые программы. 40 часов в неделю можно находиться в офисе, но не полноценно работать. 30 часов в неделю — очень хорошо, это фултайм. 10-20 часов — парттайм.

Берём весь скоуп, оценённый в человекочасах. Делим на человеческие ресурсы, распределяя задачи по соответствующим ролям, учитывая доступность каждого члена команды. Получаем сроки. Календарные сроки. Настолько точные, насколько точной была оценка.

Умножаем либо оценки соответствующих задач, либо доступность в течение срока проекта, на соответствующие рейты. И получаем стоимость. Деньги.

Вполне простая арифметика.

Что делать, если не успеваем?

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

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

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

Деньги. Как сэкономить деньги? Ну, можно нанять менее квалифицированных специалистов (например, не из России, а из Индии). Сроки, может, вырастут несущественно. Тут беда в другом. Резко возрастут затраты на последующее развитие и сопровождение продукта. Покупаете дешёвую машину? Разоритесь на запчастях.

Чтобы точно узнать сроки, нужно точно знать трудоёмкость. Хотите знать сроки всего проекта? Нужна оценка всего проекта.

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

Скрам вообще придумали разработчики, чтобы защитить себя. Вся ответственность ограничивается рамками лишь одного спринта. Мы его оценили. Мы пообещали, что сделаем то-то и то-то за вот эти фиксированные пару недель. Мы сделаем. Хотите что-то ещё? Вон отсюда в следующий спринт.

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

Про Лин ничего не скажу. Он появился на горизонте, когда я уже понял, что не хочу быть менеджером. Мне плевать на всевозможные книжные методологии. Всё равно в реальности в каждом проекте складывается своя методология. И у меня в голове все они всё равно сводятся к написанию кода, мать вашу.

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

Почему-то слишком часто считается, что оценка, пусть в человекочасах, это одно число. Ничего подобного. Мы почти всегда пользуемся оценкой по трём точкам. То, что называется PERT.

Здесь по каждой оцениваемой задаче выдаётся три цифры.

Оптимистичная оценка. Минимальная. За сколько это можно сделать, если всё сложится идеально? Если не вылезет никакой непредвиденной фигни. Если фаза Луны будет подходящей. Если ни одно нейтрино не повредит биты нашей памяти. Может, повезёт настолько, что эту задачу вообще не надо будет делать, потому что вскроются какие-то счастливые обстоятельства и завершатся долгие исследования. Тогда оптимистичная оценка будет нулевой.

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

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

Конечно, сюда можно просто поставить бесконечность. Но не нужно. Если совсем непонятно что делать, сюда нужно поставить время, которое разумно потратить на попытку сделать эту задачу. А когда время вышло — прекратить. Подойти с другой стороны, сделать по-другому (что уже другая задача). Но — прекратить.

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

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

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

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

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

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

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

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