В чем сложность
Вполне обоснованная ситуация, когда заказчик хочет получить точную оценку проекта по срокам и стоимости. Стоимость напрямую зависит от сроков, поэтому давайте определимся почему тяжело оценить сроки в IT проекте:
- Разработка программ — это процесс интеллектуальной деятельности. Есть типовые задачи, которые уже делались раньше, оценить такие не составляет труда. Но есть и нестандартные задачи. У нас таких обычно 20-30% работ по проекту. Эти задачи невозможно оценить, потому что неизвестно сколько они займут времени и какие могут возникнуть проблемы при их разработке. Простой пример: попробуйте ответить на вопрос: «Сколько времени займет путь из Москвы до поселка Заполицы на автобусе? И сколько стоит такая поездка?». Вряд ли вы вообще были там раньше, поэтому для вас эта задача нестандартная, сходу и не скажешь сколько. С примером просто — позвонил на автовокзал, узнал цену и продолжительность поездки. Но даже здесь есть риск застрять в пробке. А заказчик будет звонить вам и трясти результат. И правильно сделает: пообещали — выполняйте.
- Требования заказчика. Практически в любом проекте в ходе реализации меняют первоначальные требования. Заказчик мог что-то забыть или появились новые хотелки уже после старта проекта.
- Еще одна проблема, вытекающая из того, что деятельность интеллектуальная — это квалификация разработчика. Профессионал может выполнить задачу в разы быстрее новичка.
Эти три причины я написал в порядке убывания их проблемности.
Как мы их устраняем
Начну с самой простой — квалификация разработчиков. Решается таким образом: либо в проектную команду идут разработчики средней квалификации, либо мы садим в одну команду новичка и профессионала, чтобы он новичка подтягивал в слабых местах. Таким образом скорость усредняется до скорости среднего разработчика и роль квалификации на сроки существенно падает.
Следующие две проблемы посерьезнее. Начну со второй — меняющиеся требования заказчика.
Мы пользуемся двумя вариантами построения процессов разработки: Scrum и НЕScrum.
С нескрамом проще: с заказчика собираются требования, составляется ТЗ и смета, и начинается работа строго по ТЗ. Такой подход используем при разработке простых проектов: лендинги, корпоративные сайты.
Но все в ТЗ описать невозможно, поэтому в ходе проекта всегда образуются спорные вопросы. Например, это происходит там, где заказчик ожидал чего-то де-факто, а для нас это трудная (или долгая) задача и на нее требуется время. Портить отношения с заказчиком не хочется, поэтому приходится либо тратить время менеджера на обсуждение этой проблемы, либо тратить время программиста для решения задачи, либо тратить время менеджера + время программиста для придумывания альтернативной задачи и ее решения. В этом случае мы обычно выбираем вариант, который принесет наибольшую пользу бизнесу заказчика (ведь «хотелки» часто не имеют под собой серьезного обоснования, и, порой, даже вредят).
В больших проектах такие ситуации возникают неизбежно. И это время закладывается как риск. Да, пусть это вас не шокирует, так делают все студии, они закладывают определенное количество времени под риск, за которое вы переплачиваете. Так вообще делают многие компании, работающие с большой неопределенностью в проектах.
Как делается в скраме?
Для проекта составляется большой список задач — backlog. Он отсортирован по приоритетам, как хочет заказчик. Команда набирает себе задач из этого списка на 2 недели работы. После двух недель, заказчик получает полностью готовую и протестированную часть функционала. Но что самое интересное, если за эти две недели что-то у заказчика меняется, то он может спокойно выкинуть какую-нибудь из задач в проекте. Или поставить новую. Или поменять приоритет. Таким образом, в следующие две недели в работе будет то, что хотел заказчик. В этом и состоит гибкость. Есть одно НО: заказчик не может менять, убирать или добавлять задачи к тем, что уже в работе, т.е. в этих двух неделях.
Работа с заказчиком организована в трелло.
А работа команды организованна в youtrack'е.
Таким образом, можно не закладывать время на изменения в риски и безболезненно вносить новые требования в проект, что выгодно и для нас, и для заказчика.
Последняя проблема — оценка длительности нестандартных задач. К слову, стандартные задачи оцениваем по этой же методике. То, что я буду описывать — это часть скарама, оценка методом покер-планирования. Задачи по очереди берутся из Backlog’а. Оценку проводит вся проектная команда, члены которой, (внимание!) должны прийти к единому решению. Если хотя бы один из них не согласен, то обсуждение задачи будет продолжено. Оценивают в условных единицах, мы их называем story points (s.p.). Эти условные единицы представляют из себя часть последовательности Фибоначчи: 0,1,2,3,5,8,13,21. Задачи, оценка которых выше 21, обязательно разбиваются, чтобы избежать грубой оценки.
Сам процесс оценки проходит так: первым говорит тот, кто непосредственно реализует данную задачу: делали мы такое или нет, как это будет программироваться, где могут возникнуть проблемы, с какой вероятностью они возникнут — все, что может помочь при оценке сложности задачи. Затем высказываются остальные, задаются вопросы. У каждого есть 8 карт с числами Фибоначчи 0,1,2,3,5,8,13,21 (используется специальная колода карт). Когда все готовы голосовать, каждый выкладывает одну карту рубашкой вверх. Когда все карты выложены, они переворачиваются, и все видят оценки.
Таким образом, никто не знает чужого решения. Если все оценки сходятся, то голосование завершается и задаче присваивается соответствующая сложность, но если хотя бы у одного из участников другая оценка, то обсуждение продолжается. Каждый должен отстоять свое мнение.
В итоге мы имеем гибкую команду, способную подстраиваться под меняющиеся требования заказчика и умеющую точно прогнозировать сроки по проектам.
Комментарии (20)
redant
15.04.2015 22:15Я думаю, типичная особенность молодых (не крупных) компаний — стремление удержать клиента. Или это можно прочитать, как боязнь его потерять. Нормальная ситуация — предупредить клиента о наличии рисков и заложенном 30% запасе сроков на нетривиальные задачи и сообщить ему о том, что любая его хотелка и доработка будет эти сроки увеличивать. И всё это не на словах, а в договоре. Но большинство так не делает.
apikhtovnikov Автор
16.04.2015 07:2130% слишком много. Это 1/3. Любой заказчик скажет: «Да вы что, совсем охре… и?! Мне за эти 30% еще и платить надо!? Убирайте эти риски из сроков и цены, или не видать вам проекта»
defuz
16.04.2015 09:26Эти условные единицы представляют из себя часть последовательности Фибоначчи: 0,1,2,3,5,8,13,21. Почему именно эти цифры? Последовательность Фибоначчи отражает типичную неопределенность при обсуждении больших и важных пунктов.
Спасибо, давно хотел узнать, что означают эти цифры.apikhtovnikov Автор
16.04.2015 09:35Взято из википедии
defuz
16.04.2015 11:38Значит это позорное предложение нужно убрать как отсюда, так и из википедии. Последовательность Фибоначчи означает много чего, но только не «неопределенность при обсуждении больших и важных пунктов». Хотите знать, почему на самом деле эта последовательность используется для оценки сложности задач? Вот вам ответ:
1. Эта восходящая последовательность увеличивается не слишком быстро (медленее степеней двоек: 1, 2, 4, 8), но и не слишком медленно (быстрее натуральных чисел: 1, 2, 3, 4), а как раз «нормально» – каждое следующее значение ? в 1.6 раз больше предыдущего.
2. Потому что это прикольно. Людям нравится находить скрытые зависимости там где их нет, и предложение, которое вы скопировали из википедии – отличное тому подверждение.apikhtovnikov Автор
16.04.2015 13:14В принципе, я с вами согласен. Убрал этот момент из статьи. Спасибо за правильную критику
defuz
16.04.2015 13:29Я хотел еще спросить: вы указываете 0 как вариант ответа. Т.е. вы подразумеваете, что разработчик может сказать задачу вообще делать не нужно, или что это значит?
apikhtovnikov Автор
16.04.2015 13:33Это значит, что задача займет очень мало времени. Например, вход/регистрацию мы обычно оцениваем на 0. Т.к. у нас эти модули уже запроганы, нужно их перенести с другого проекта и сверстать формы (это занимает минут 20 максимум).
JetHedgehog
16.04.2015 13:37Хм-хм… При таком подходе 10 подобных задач займут около 3 часов. А за это время можно небольшую user story сделать.
apikhtovnikov Автор
16.04.2015 13:40А зачем так сильно дробить истории?
У нас ни разу не было больше одной нулевой истории в спринте. Обычно, это такие истории, которые важно не упустить, но делаются они очень быстро.JetHedgehog
16.04.2015 13:57> А зачем так сильно дробить истории?
Бывает множество несвязанных друг с другом доработок.
Если таких историй мало, то не нужно. У меня частая ситуация такова, что есть множество мелких доработок. Если они хоть как-то друг с другом связаны, объединяются в одну историю в виде чеклиста и он целиком тогда оценивается.apikhtovnikov Автор
16.04.2015 15:02Доработки это вообще отдельная песня.
Мы оцениваем процентов 10 доработок, не больше. Остальные быстрее сделать, чем оценивать.
JetHedgehog
Не страдаете от дублирования/синхронизации информации между Trello и YouTrack? Конечно, заказчику Trello удобнее. Но почему бы его не пересадить на YouTrack? И наоборот, чего такого с вашей точки зрения есть в YouTrack, от чего вы не можете отказаться и не переходите на Trello полностью?
apikhtovnikov Автор
Сами изначально работали в трелло. Но некоторые вещи в трелло делать нельзя. Например берндаун диаграммы, которые нам очень нужны.
Да, проблема переноса задач есть, но сам по себе перенос решает другую проблему: переносит задачи разработчик. И он не перенесет задачу, в которой что-то не понял. Таким образом в ютреке только те задачи, которые мы точно делаем и которые нам точно ясны.
Клиентов на trello-то долго подсаживать надо. Боже упаси от попыток подсадить их на ютрек)
JetHedgehog
У меня наоборот клиенты очень радуются Trello. Это от специфики аудитории зависит, наверное.
Про перенос — да, в один конец из Trello в YouTrack нормально все пойдет. Я больше переживаю за обратный процесс, когда изменения из YouTrack надо отображать обратно в Trello. Хотя наверное можно в конце спринта подводить некое резюме и делать массовый апдейт данных. Спасибо за то, что делитесь опытом!
apikhtovnikov Автор
Не переживайте) Мы делаем это так: разработчик из терлло переносит истории в ютрек. В трелло же они перетаскиваются в столбец «В работе». А в конце спринта все эти задачки разом переносятся в «Готово». Сложностей нет)
Заказчик знает, что в столбце «В работе» менять уже ничего нельзя.
JetHedgehog
Ну если у заказчика не шаловливые ручки, тогда все ОК, спасибо еще раз)