В чем сложность

Вполне обоснованная ситуация, когда заказчик хочет получить точную оценку проекта по срокам и стоимости. Стоимость напрямую зависит от сроков, поэтому давайте определимся почему тяжело оценить сроки в 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 (используется специальная колода карт). Когда все готовы голосовать, каждый выкладывает одну карту рубашкой вверх. Когда все карты выложены, они переворачиваются, и все видят оценки.

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

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

Автор: apikhtovnikov

Источник