Общались с CIO одной компании о внедрении Agile. CIO говорит:
- Мне нужны будут метрики, которые покажут, что Agile эффективнее нашего текущего процесса.
Такие вопросы задают постоянно и ответ на них готов. Мы спрашиваем:
- А как вы сейчас измеряете эффективность разработки?
Тут обычно выясняется, что никак не мерят и сравнить не с чем. Однако этот CIO оказался не так прост. Он сказал, что они тоже не мерят, но метрики все равно нужны и мы должны их придумать.
Мы стали думать. Проблема с этими сравнениями в том, что сравнивать не с чем. Даже если вы ведете статистику по проектам. Проекты слишком разные, чтобы можно было провести какое-то усреднение. В Люксофте мы вели очень подробную статистику. Там типичное среднеквадратичное отклонение метрики превышало само значение раза в два. То есть если даже все показатели выше среднего - это ничего не означает, в портфолио легко можно найти проект еще круче. Но в общем, это чистая теория, поскольку, как я уже сказал, все равно никто ничего не измеряет.
Так что сравнить можно проект только с ним самим. Но ведь вы не сделаете один и тот же проект два раза? Что мы в итоге придумали - это сравнивать проект с его моделью. Идею подсказал Сергей, менеджер разработки.
Нарезали Техническое Задание на Баклог (пользовательские истории), оценили их в стори-пойнтах и начали разработку. В конце проекта подвели итоги.
Оказалось, что из первоначального скоупа 70% было сделано и 30% отменилось - оказалось ненужным. По ходу проекта добавилось примерно на 40% новых пользовательских историй (на начало проекта их не было).
Весь проект занял 9 итераций (18 недель) - на одну больше, чем планировалось. Это в Agile.
Теперь давайте представим, как прошел бы водопадный проект. Мы бы сделали 100% первоначального скоупа. Потом показали бы результат заказчикам, и сделали бы Запросов на изменение еще на 40%.
То есть общая длительность проекта в водопаде больше на 30% по сравнению в Agile проектом.
В общем, довольно убедительная картинка. Разумеется, это модель, и она предполагает следующие вещи:
- Производительность команды (грубо говоря, количество стори-пойнтов в единицу времени) не отличается в Agile и в Waterfall
- В водопаде мы не показываем результат заказчику по ходу работ.
- Удаление ненужной функциональности в водопаде бесплатно
- Сбор требований не занимает времени
Вполне убедительно.
ОтветитьУдалитьВы всё ещё сомневаетесь? Тогда мы идём к вам! :)
ОтветитьУдалитьМодель сильно упрощена. В реальности все не так однозначно. Agile привносит достаточно много "лишней" работы, которой не было бы в водопаде. Например, мой опыт показывает, что Agile привносит следующие затраты: митинги с заказчиками, ДЕМО, Планнинги, покеры, выпуск рабочей версии продукта каждый спринт. Всех этих активностей в водопаде либо нет совсем, либо они занимают зачительно намного меньше времени. Вот если бы знать этот оverhead, и прибавить его к тем 100% Agile, то мы бы получили эффективность Agile. Я не думаю, что это было бы больше 40%. Но с другой стороны 40% нового контента тоже не в каждом проекте бывает.
ОтветитьУдалитьДа, модель может быть очень сложной. Как раз этого и хотелось избежать. Оверхеда на планирование в любом случае не больше 10% по опыту. С другой стороны - планирование в waterfall тоже осуществляется, просто оно не вырезано в отдельные митинги. Не уверен даже, что его намного меньше получится. По идее взаимодействие в agile (на которое тратится время) позволяет сделать меньше ошибок, а значит в итоге экономит время. Получается, точную модель надо делать реально сложной.
ОтветитьУдалитьМожно Вашему CIO показать такой отчет:
ОтветитьУдалитьhttp://www.versionone.com/state_of_agile_development_survey/10/page5.asp, там много всего интересного, кстати самое интересное для меня там то что в категории Benefits Obtained from
Implementing Agile последнее место занимает пункт Reduce cost. То есть вроде как во всем Agile хорош а денег экномить не сильно меньше стали
Отчеты вроде как всем известны. Обычно задают вопрос "докажите, что у нас получилось". Тут абстрактные отчеты не помогут.
ОтветитьУдалитьНасчет экономии - единственный способ сэкономить в разработке ПО - это кого-нибудь уволить. Так что мне немного жаль те компании, где результатом внедрения стало сокращение затрат ;-)