English Version

Fixed Price: Как НЕ нужно эстимировать

Автор: Александр Якима (www.enter-agile.com)

Fixed-Price контракт - неидеальная среда для agile-разработки. Говоря более точно: просто для разработки. Мы не всегда можем более-менее точно оценить, сколько времени у нас уйдет на приготовление завтрака или на поход на работу, хотя делаем эту рутину регулярно. Что уж говорить о разработке ПО, где элемент уникальности - наиболее характерная черта...

Тем не менее, Fixed-price - это реальность в мире разработки, в частвности в аутсорсинге. И так или иначе, FP-проекты приходится оценивать и давать коммитмент. В этом посте мы абстрагируемся от практически всего и кратко постараемся рассмотреть ключевой вопрос:

Как эстимировать Fixed-Price проект?

Как обычно проходит эстимирование? Ответить можно "наоборот", рассмотрев, что обычно приводится в качестве эстимейта в пропоузале или каком-то другом подобном документе. Картина обычно следующая:

Таблица 1. Традиционная разбивка при оценивании Fixed-price проекта.

Более или менее детализировано, но идея одна и та же - декомпонируем по задачам. Грубо говоря, вот вам время на разработку, вот на работу с требованиями и т д. При большей детализации выяснится, что мы рассчитываем столько-то времени на разработку схемы базы данных, столько на написание хранимых процедур и триггеров, столько на ORM-уровень, бизнес-логику мы напишем за столько, а вот столько-то у нас займет UI. Конечно, при этом (в частвности при самом процессе эстимирования) особой уверенности нам добавляет часто то, что мы комбинируем "лэйерную" декомпозицию с разбивкой "модульной", получается что-то вроде матрицы. Ну как тут можно ошибиться???

Особенно иронично то, что так часто выглядят эстимейты проектов, которые команды-аутсорсеры клянутся сделать в рамках методологии "agile" (кавычки обязательны). В любом случае, вот моя принципиальная рекоммендация:

Не делать декомпозицию по задачам / модулям / лэйерам!

А как же делать? Отвечу вопросом: а как вы собираетесь имплементировать этот agile-проект? Ясно ведь как: закоммитимся на определенный объем пользовательских историй в первой итерации, потом так же во второй и т. д. Прекрасно, значит так нужно и эстимировать. Отсюда правило:

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

Оценка тогда выглядит совершенно сходно с бэклогом релиза (в данном случае предполагая, что результат работы над текущим FP-проектом как раз и является этим релизом), а процесс разбиения и эстимирования очень близко должен напоминать типичную процедуру планирования Agile-релиза.

Таблица 2. Agile-оценка.


Таким образом достигается несколько принципиально важных целей:

1. При разбиении по пользовательским историям или фичам "анализ требований" получается более полным и адекватным, так как служит критической цели - оченке проекта. В случае №1 это не так, четкой внутренней необходимости для команды в адекватном анализе требований нет.

2. Заказчик и команда получают дполнительную степень свободы в планировании и выполнении: теперь заказчику понятно, что он может отложить на будущее, а что важно делать в первую очередь. Когда перед тобой список задач (напр., разработка, тестирование...) то как увидеть, чем можно пожертвовать? Тестированием модуля А или разработкой модуля Б?

3. Вероятность "вписаться" в рамки обещаний значительно выше, так как планироание иммитирует ход разработки, а не является иным по природе. Более того, если оценку дает команда уже работвашая совместно и если (при некоторых допущениях) можно говорить, что проект "типичен" или хотя бы не экзотичен, то априори команда уже имеет полезную для этого случая способность оченивать пользовательские истории ( напр., в стори-поинтах). Стори-поинт - это ни что иное, как единица измерения трудозатрат команды по разработке полностью всей истории, всех 100% - от анализа требований до разработки и тестирования. Этот факт обуслалвливает большую надежность оценки.

Точных оценок вам!

КАНБАН: пример естественного применения

Автор: Александр Якима (www.enter-agile.com)


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

Итак, описание кейса:

- Стадии (фазы, этапы) работы объективно существуют как часть формализованного процесса - диктуются заказчиком.

- Процесс почти строго последовательный

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

- Эстимирование объективно осложнено: система очень большая, каждый второй work item несет в себе много нового и неизвестного

- План работы может меняться произвольно - новые важные work items могут появляться в любое время

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

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

А как это лучше всего сделать? Точно! Ограничить работу в прогрессе и аккуратно следить за "проседанием" задач на индивидуальном уровне.

Поток ценности выглядит приблизительно так:


Соответственно, вот пример Канбан-доски для этого процесса:

И стало действительно лучше жить. Разработчик не берет больше одного айтема в разработку (за исключением, когда предыдущий ушел в приемочное тестирование, которое делается удаленной командой) - тоесть формулировка WIP Limit для этого случая звучит немножко нетривиально: "Не более одной задачи в строке таблицы, за исключением 2-х задач, одна из которых на этапе приемочного тестирования". Стало реально трэкать, что и как происходит. При этом, когда новый work item приходит под высочайшим приоритетом с легким движением руки Продакт-оунера, команда убирает одну из текущих задач в "отстойник" и высвобождает слот в пользу новой задачи. Естественно, лечге трэкать потери при постоянном изменении плана и Продакт-оунер принимает более осмысленные решения.

Патчи идут на продакшн-среду каждую неделю и каждую же неделю проводиться то, что команда называет "Kanban status meeting" - что-то похожее на демо + план новых задач (которые можно планировать) вместе с Продкат-оунером. Ежедневный утренний стэнд-ап для определения внутреннего статуса работы команды тоже никуда не исчез. Только проводит его теперь Kanban-мастер.

Наконец, очень важно отметить, что модель хорошо сработала именно потому, что процесс "сторго поэтапный" - данность в связи со спецификой и стилем работы заказчика. Однако, значительно эффективнее (даже в этом самом случае) было бы применять модель D-B-T (Define-Build-Test), в которой нет строгих фаз и "водопадоподобности", а наоборот - микроциклы D-B-T много раз прокручиваются, пока не получается то, что нужно. Но об этом в последующих постах...

Продакт-оунер в аутсорсинге

Автор: Александр Якима (www.enter-agile.com)


Несмотря на поверхностное сходство, Agile-разработка в продуктовой компании и аутсорсинговой - две существенно отличающиеся вещи. Мы поговорим об одной весьма весомой отличительной черте и о том, как минимизировать ее побочный эффект:


В аутсорсинге отношение "Команда - Продакт-оунер" накладываются на отношение "Поставщик - Заказчик" и эти форматы отношений во многом сущесвенно влияют друг на друга.

В некоторых случаях отношение (2) может только вредить совместному бизнесу, именно совместному, так как часто проблемы как раз возникают, когда Поставщик и/или Заказчик преследует любые интересы кроме главного - демонтировать стену между командой и продакт-оунером, и сделать таким образом аутсорсинг разработку максимально схожей на среду продуктовой компании.

Здесь сразу хочу упредить душевное расстройство всех аутсорсинг-менеджеров и в особенности сейлов: мы не говорим здесь о модели staff extension (или как ее еще называют - staff augmentation). Эта модель лишена смысла с точки зрения Agile. Речь не идет о том, чтобы возвращаться к ненавистному "бади-шопу", от которого только-вот придумали как уйти с помощью новомодных (хотя и весьма порочных) парадигм, нет... Успешный Agile-аутсорсинг может работать только если agile-команды будут целостны и самодостаточны на стороне вендора, за исключением П-О. Вот это "маленькое исключение" как раз и определяет характер сервиса.

Посмотрим более детально, что же мешает аутсорсинговой модели реализовать Agile так, как будто это была продуктовая компания со своей собственной командой:

1. Доверия априори нет, заслужить всегда сложно. Именно потому, что Agile не может жить без доверия между Продакт-оунером и Командой этот пункт мы выносим на первое место. При этом часто и заказчик и вендор делают все против правил, удаляясь от желаемого результата. В основном либо потому, что заказчик пытается предохраняться где нужно и где нет - фиксировать скоуп, требовать четких коммитментов, там где это не представляется возможным, обложиться метриками и SLA-соглашениями, полагая, наверное, что юридически весомые документы умеют сами анализировать требования, писать и тестировать код... С другой стороны вендоры - вместо того, чтобы убирать барьеры, очень часто их создают под сладким соусом самоуправляемости, независимости и соблазнительной идеи маркетировать себя как поставщика black-box сервиса, где заказчику неочем беспокоиться на ежедневном уровне, а только перебросить через кирпичную стенку требования, а оттуда со временем назад вылетит "потенциально доставляемый инкремент" (сложно, наверное, подыскать более ироничное применение акронима PSI)...

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

3. Ревенью важнее методологии. Так считает практически любая компания-поставщик, это диктуется ее основными бизнес-инстинктами. Это тот случай, когда инстинктами должен управлять разум. Очень часто аутсорсинг-вендор и знает что нужно бы в процессе поменять, но видя малейшее противление со стороны заказчика, сворачивает все "излишне нервирующие" темы и просто продолжает работать как есть. Опять, же - проще сказать, чем сделать... это правда. Все три приведенных примера исходят из самой сущности аутсорсинг-разработки и поэтому очень сложно устранимы. Но пункт 3 наиболее сложен, так как еще и противоречит общепринятому "заказчик всегда прав..."

Теперь несколько фраз о способах решения этих сложностей.

Что касается №1, то тут вопрос скорее отношения к собственному бизнесу, чем объективная проблематика. Иными словами, аутсорсинг-компаниям, конечно необходимо как-то обосновывать высокие рейты (по сравнению с другими), однако делать это можно по-разному. По крайней мере без резких противоречий с ключевыми принципами и ценностями Agile. Это становится особенно четко видно, когда "продается" услуга заманчиво называемая "Agile Fixed Price" или "Agile Managed Delivery" или как-то еще с одним и тем же подтекстом - Agile с минимальной тратой времени Продакт-оунера - но это нонсенс. Наоборот, разумный аутсорсинг-вендор увидит тут конкуррентное преимущетво по сравнению с "недоучками", предлагая то, что на самом деле будет работать и послужит хорошим бизнес-кейсом, подспорьем для приобретения новых клиентов в будущем - модель которая максимально сближает П-О и Команду, не ставит лишних барьеров. Это отдельная большая тема, в текущем посте же только скажу, что в какие бы юридические и маркетинговые обертки не был облачен проект, если П-О не будет "знать всех своих разработчиков в лицо" в полном смысле фразы, то надо помнить, что тогда не только Agile невозможен, но и отказаться от такого "черного ящика" П-О будет всегда очень легко. Подумайте на секунду, слышали ли вы много случаев противоположных, чтобы в продуктовой компании П-О уволил всю (!) свою команду? В аутсорсинге это случается сравнительно часто. Повод для раздумий, не так ли?..

№2 решается всегда непросто. Если удастся (и если есть кому), то нужно такого П-О постепенно "обучать". Не нужно сильно комплексовать из-за того, что это заказчик. Если делать все аккуратно, никто не заметит, что это по сути образовательный процесс. Хуже, если П-О страдает существенной упертостью, бывает и такое. Придется тогда тратить больше времени на "логирование проблем и сбор фактажа", которые время от времени в ходе ретроспектив необходимо будет своему П-О в очень корректной форме предоставлять. Вода камень точит...

№3 - исходит полностью из культуры компании, поэтому тут совет двоякий. Во-первых, тем, кто на эту культуру сильно влияет исходя из своего заоблачного служебного положения - помнить всегда о том, что именно мега-успешные Agile проекты приносят дивиденды в виде лояльных заказчиков, творчески заряженных сотрудников, и много buzz'а вокруг компании о том, как здесь умеют делать software. Тем же от кого зависит хотя бы ситуация на проекте и кто хочет эту проблему разрешить - наберитесь терпения и все-таки постепенно добивайтесь процессных изменений. Каждый успешный шажок - аргумент для вашего менеджмента, что вы поступаете правильно. Ваша мотивация - шанс стать проводником изменений во всей компании по уже известному вам паттерну, когда наступит время. Поверьте, у вас в этом почти не будет конкуррентов...

OSDN.org.ua - My Conference Speech

Last Saturday I had a speech at pretty interesting conference of developers and users of free open source software - OSDN. I was speaking about FOSS tools for Agile teams. Here're few pics:




...and the presentation:

Agile foss tools
View more presentations from alexyakima.
Newer Posts Older Posts Home
Powered by Blogger