Главная » Хабрахабр » [Перевод] Как оценить длительность IT-проекта, а когда это вообще не стоит делать

[Перевод] Как оценить длительность IT-проекта, а когда это вообще не стоит делать

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

Её менеджер Барри хотел составить квартальный прогноз работы её команды. Селеста чувствовала давление. Каждый из них являлся частью другого проекта. Задача усложнялась тем, что группа Селесты работала не над одним продуктом: Барри хотел получить прогноз сразу по трём.

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

Она назначила встречу на следующий день и собрала данные.
Девушка прибыла в офис Барри ровно в 10 утра. Селеста решила признаться Барри и посмотреть, к чему они придут. Он жестом попросил её войти и поднял один палец, чтобы дать понять: он будет готов через минуту. Когда она постучала в дверь, Барри всё ещё говорил по телефону.

Она села в кресло для посетителей напротив его стола.

Барри повесил трубку и повернулся: «Что ж, обсудим сроки проектов, так?»

Кажется, вот что можно сделать в такой ситуации». Селеста кивнула и сказала: «Да.

Мне нужны конкретные обязательства. Барри нахмурился: «Кажется? Никаких „кажется”!»

Селеста села поудобнее: «Барри, на тебя давят, чтобы выпустить эти три продукта?»

— Барри покачал головой. «Как ты узнала? Не знаю, что им ответить, кроме того, что всё будет». — Если послушать ребят из продаж и маркетинга, то случится катастрофа, если мы сейчас их не выпустим.

— Я думала, продукт А был главным приоритетом». «Но в прошлом месяце вы же обсуждали портфель проектов, — напомнила Селеста.

— И продукты B и C тоже являются главным приоритетом». «Так и есть, — сказал он.

Селеста закатила глаза: «Но ты же знаешь, что может быть только один главный приоритет, не так ли?»

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

«Над каким продуктом нам работать в первую очередь?», — спросила Селеста.

— Он самый окупаемый». «Продукт А, конечно, — сказал он.

— Мы напряжёмся и выпустим А в течение месяца. «Хорошо, вот что мы сделаем, — сказала Селеста. Они должны увидеть, что мы делаем за неделю. Ваша задача — заставить этих милых людей посещать наши презентации каждую неделю. Если они не придут на демо, я отказываюсь давать им какую-либо информацию».

Я понял насчёт демо. Барри откинулся назад: «Погоди. И почему ты не дашь им никакой информации?» А что в остальные два месяца?

Для продукта А мы выпускаем три-четыре истории [код для пользовательских задач] в неделю. Селеста сказала: «Если бы мы работали только над одним продуктом, я могла бы рассчитать оценку на основе нашего цикла разработки. Но мы не знаем реального цикла разработки для продуктов B и C».

Барри кивнул: «Почему нет?»

— Это довольно далеко для маркетинга. «Продукты B и C запланированы через два и три месяца, — сказала Селеста. Мы понятия не имеем, какие функции нужно будет реализовать через два и три месяца. Проблема в том, что чем дальше работа, тем меньше „времени” отдел маркетинга работает с владельцем продукта для уточнения историй. Это нормально, мне нравится заниматься этим со своими ребятами, но нам нужно больше конкретики. Нам пришлось бы делать научно обоснованные предположения на пустом месте (scientific wild-ass guess, SWAG). Которой нет».

«Так почему ты дашь им никакой информации, если они не придут на демонострацию?» — спросил Барри.

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

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

Был бы у вас соблазн сделать всё иначе?

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

Слишком часто требования не полностью определены и, как с командой Селесты, проведение оценки отрывает команду от срочной работы над проектом. Есть как минимум две проблемы оценки квартальной работы.

Если в вашем городе больше одного светофора, то вы знакомы с колебаниями трафика. Проблема в том, что планирование разработки ПО не похоже на планирование дорожной поездки. Чаще всего от 30 до 45 минут. Я живу в пригороде Бостона, откуда поездка в аэропорт может занять и 20, и 90 минут. Это существенная вариация для 13-километровой поездки.

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

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

На самом деле три: Для разумной оценки у нас несколько вариантов.

  • Можно оценить порядок величины. Считаю, что это полезно для всего проекта. «Мы предполагаем от пяти до девяти месяцев работы. Узнаем лучше, когда ответим на эти вопросы и закончим эту часть сложной работы». SWAG хорошо подходит для таких оценок.
  • Можно собрать достаточно информации о требованиях и предоставить разумную оценку. Команде может понадобиться поработать с пользовательскими историями, чтобы сделать прогноз с достаточно малым разбросом по времени.
  • Есть вариант оценить работу на короткий отрезок, например, на неделю-две. Может оказаться, что итоговый прогноз не совсем правильный. Но обычно он достаточно близок к результату, чтобы не разочаровать людей, которые попросили сделать его.

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

В оценке восемь месяцев мы уверены на 80%. «Мы считаем, что этот проект займёт пять месяцев с 50% уверенностью в точности этого прогноза. Десять месяцев — это 90% уверенности».

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

Не знаем, когда именно в первом квартале, но думаем, что справимся». Можете использовать метод спирали: «Мы ориентируемся на первый квартал следующего года. Узнав ещё больше, говорите: «Где-то в феврале, если не случится метели». По мере продвижения проекта уточняете: «Обновляем оценку на срок где-то между серединой января и серединой марта». Потом в январе можете сказать: «Третья неделя февраля».

Самая реалистичная — конец февраля. Я бы ещё рекомендовала диапазон из трёх дат: «Оптимистичная дата — январь. Самая пессимистичная — конец апреля».

Это искушает Святого Мерфи (из закона Мерфи) заняться вашим проектом и наделать гадостей. В любом случае никогда не давайте однозначной оценки.

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

Я вообще не люблю прогнозы по сроку выполнения программных проектов или других IT-проектов, особенно Agile. Вместо этого предпочитаю, чтобы команда выпускала очень маленькие истории или оценивала работу по времени цикла.

Если вы не знакомы с терминологий:

  • Пользовательские истории описывают, как клиент или пользователь использует продукт с одной функциональной целью («Хочу забронировать место» или «Нужно опубликовать данные умного города для удовлетворения требований прозрачности»). Истории отличаются от взгляда разработчика, который смотрит на продукт с точки зрения баз данных и API.
  • Время цикла относится к общему времени, которое требуется команде для выпуска работы над одной историей. Это включает в себя и активное время разработки, и время простоя, когда работа чего-то ожидает.

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

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

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

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

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

Я иду по тому же маршруту каждый день, отслеживая свою относительную скорость. Например, я каждый день хожу пешком, чтобы поддерживать себя в форме. В дождливый или жаркий и влажный день скорость падает до 4 км/ч. В хороший солнечный день я прохожу около 5,6 км в час. В снег или гололёд могу вообще не выйти на улицу, в этом случае моя скорость равна 0.

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

Но слишком часто менеджеры пытаются дать оценку для проектов с очень большими историями. Если истории достаточно малы, скорость соответствует времени цикла. Какую одну или две истории вы хотите выбрать?» Подсчёт будет проще: «Мы можем закончить одну или две истории за цикл.

Когда Барри обсудил вопросы с коллегами, один из них заявил: «Отказаться от оценки сроков — это жульничество!»

Вы же хотите, чтобы мы выпустили продукт, верно?» Барри ответил: «Неправда.

И B, и C». Ответ был «Конечно.

— Если вам так нужен продукт А, какой смысл делать прогноз по остальным? «Проблема в том, что их нужно делать по очереди, — ответил Барри. Когда мы сделаем достаточно, то повторим процедуру для B и C. Мы можем приступить к работе и показать наш прогресс. К тому же, у вас будет время уточнить требования для B и С, чтобы подготовить нам истории».

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

Преподнесите её так, как ему нужно. Знайте, какая оценка нужна вашему менеджеру. И если у вас мало времени, приступайте к работе.

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

Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Завтра пройдет первый матч между OpenAI и профессионалами Dota 2. Разбираемся, как работает бот

Информация о матчах появилась на официальном сайте Dota 2 в разделе с расписанием игр плей-офф The International. Завтра вечером, перед началом очередного дня плей-офф The International, в рамках шоу-активностей пройдет первый показательный матч между профессиональными игроками и ботом OpenAI Five. ...

[Перевод] Обзор техник реализации игрового ИИ

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