Agile команда и контракты с фиксированной ценой

[yshilyaev]

Букв много, но про проблему работы по скраму с фиксированной ценой — практически ничего.
Классически клиент по договору Fix price желает зафиксировать все 3 параметра: стоимость, объем работ, сроки. Т.е. там тоже есть люди, которые читали PMBoK. Рассказами про стори-поинты и числа Фибонначи людей от бизнеса можно вгнать в ступор, но убедить так работать — невозможно. По крайней мере у нас.
Челов от бизнеса надо убеждать по-другому. :)

[steel_ne]

Челам от бизнеса говорится — это стоит 480 косарей. А вот откуда это число…

[yshilyaev]

Сказал ты челам, что это стоит полмульта. И дальше? На релизах они тебе выкатили еще 10ть фич. Искусство в работе по фикс-прайсу заключается не в оценках как таковых, а в составлении контрактов. Как составить контакт так, чтобы либо scope не был зафиксирован, либо цена. Еще лучше, когда зафискирована ставка, а scope и бюджет нет. Тогда это уже не фикс-прайс, а time&material. :) Каковыми и являются большинство agile контактов.

[steel_ne]

А без договора и любой agile превращается в рабство. «Вы копайте, считайте часы, а если мне не понравится, не заплачу. И еще должны будете».

Если все зафиксировать (и хотелки тоже) и правильно все оценить, то вполне можно работать по любой технологии. Какая разница заказчику, в какую песочницу играются программеры?

[Jay_Di_Human]

Стратегически мыслящему заказчику важно, в какую песочницу играются программеры. Особенно, если он настроен на долгосрочное сотрудничество.
И да, такие заказчики бывают. К сожалению, в основном зарубежные.

[yshilyaev]

С одной оговоркой — Если это профессиональный заказчик.
Наши (да и не только наши) заказчики от бизнеса ничего в программировании не понимают, поэтому красоты процесса оценить не могут. ;(

[Jay_Di_Human]

Мне повезло однажды работать с таким заказчиком. Но лишь однажды. Заказчик из США, Бостон. Возможно, это потому, что они сами технари и сами представляли бизнес.

[yshilyaev]

Ну таки я всегда так и объясняю, что заказчику до одного места по какой схеме работают разработчики. Главное, чтобы эта схема была близка к классической схеме: Товар — Деньги — Товар.
Если же процесс основан на схеме: «Деньги — Может быть товар — Ой мы тут не все сделали — Как это вы не это хотели? — Дайте денег, суки!» То, пардон, хоть какие названия говори.
Но по скраму процесс товар-деньги-товар… мне получалось организовывать. Заказчик не знал, что это Скрам. ;)

[steel_ne]

Та все правильно написано. При фиксировании цены главное не провтыкать с оценками. Это боль любой проектной технологии. Вот и разжевывается метод оценки с ключевой, на мой взгляд, фразой:

Это те деньги, которые мы согласны потерять.

[acerv]

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

[yshilyaev]

Владелец продукта (Product Owner) — это роль заказчика, вообще-то. ;)
Если мы PO подменяем своим, то это скорее Proxy PO.

[cyber_art]

Product Owner — это человек ответственный за продукт. В идеальном случае — это Заказчик, но обычно он не готов им быть: занят другими делами, не хочет вникать в процесс, и т.п. Поэтому обычно PO становиться кто-либо из команды (аналитик, ПМ).

[yshilyaev]

Я об этом и говорил. :)
Такого называют Proxy Product Owner.

[case]

Спасибо, поправим.

[JuliaTem]

Вот объясните мне, человеку работавшему и по аджайл и без.
Если одно из основных достоинств аджайл — это то, что заказчику не надо заранее составлять чёткое тз, и он может изменять требования в процессе разработки. То о каком фиксированном наборе обязательств может идти речь?
Как только мы зафиксируем обём работ, это перестанет быть аджайлом :)

[exaide]

Красной нитью через статью проходит мысль:
«Аджайл с фиксированными обязательствами подобен аджайлу без фиксированных обязательств, только с фиксированными обязательствами» :)

[case]

Этот вопрос часто задается на конференциях и в кулуарах. Потому и выбрал именно эту статью.

[yshilyaev]

Ага. На одной конференции вышел один мой знакомый и рассказывал как они работают по фикс-прайсу по аджайлу. Очень убедительно рассказаывал. А потом когда началась сессия вопросов в него полетели: «А как вы боретесь с ростом требований?» «А как вам их оплачивают?»… На что докладчик только и отвечал: «У нас с ними выстроены доверительные отношения».
Через 5ть минут подвох вскрылся: у компании Заказчика и компании Разработчика одни и те же владельцы. Это две аффилированные компании. В такой ситуации можно доверять. ;)

[case]

Шикарно! :)

[Popik]

Я завидую вашему окладу в час

[Hellbot]

Не оклад, а стоимость. Слегка разные цифири.

[dammer]

Всё равно завидую)

[karevn]

Сдаётся мне, серьезное преимущество scrum — это чёткая сформулированность user story на момент когда она попадает в цепкие лапки разработчика. Потому что эту story уже на десять раз посмотрели во время покеров и плэннигов и еще раз пересмотрели непосредственно перед запуском итерации — это повышает вероятность вылавливания проблем постановки задач и резко повышает продуктивность за счет того, что программист садится и просто реализует, а не бегает к PO/PM каждые десять минут. А ТЗ неизбежно устаревает, в голове же всё не удержишь.

[maxim_ge]

На мой взгляд, самая большая проблема тут — Прогнозируемая производительность команды

Чтобы ее получить, необходимо выполнить несколько итераций. Хенрик Книберг в Scrum и XP: заметки с передовой рекомендует в качестве продолжительности спринта 3 недели. Т.е. пилотный проект, получается, будет длиться несколько месяцев. Хорошо, когда это лишь малая часть от общего бюджета, т.е. проект — весьма крупный.

С трудом представляю, как можно оценить производительность за одну итерацию — народ только-только начнет «въезжать» в проект.

Ну т.е. самая крупная проблема проектов с фиксированой ценой по сути осталась за рамками статьи. Ну что ж, зато еще раз прочитали изложение методологии SCRUM :)