Здравствуйте, Кирилл Лебедев, Вы писали: КЛ>Здравствуйте, 0x7be, Вы писали:
0>>Собственно, центральная идея, вокруг которой эджайл крутится: адаптация как разрабатываемого продукта, так и метода его разработки важнее следования предопределённым планам и регламентам.
КЛ>В этом нет какого-либо открытия. Собственно, методики и процессы разрабатываются именно для того, чтобы проекты укладывались в заданные сроки, в заданный бюджет и содержали запланированную функциональность. Однако из этого не следует, что каждый способен разработать методику. Часто просто не хватает квалификации.
Вы кажется, не поняли что вам пытался сказать 0x7be.
Давайте, я попробую.
Что для вас важнее — уложиться в срок и бюджет, или сделать продукт, который нужен заказчику?
Те процессы и методологии о которых вы говорите относятся к первому варианту. А agile — ко второму.
Здравствуйте, RGB_Dart, Вы писали:
RGB>Если у вас есть описание будущего функционала, бюджет и сроки — то зачем вам agile? Используйте RUP, например.
А если оно есть, но неправильное?
On 08.08.2013 12:49, RGB_Dart wrote:
> Что для вас важнее — уложиться в срок и бюджет, или сделать продукт, > который нужен заказчику? > > Те процессы и методологии о которых вы говорите относятся к первому > варианту. А agile — ко второму.
Поиграю в твою же словесную игру. Ты хочешь сказать, что выбор agile
разумен в том случае, когда срок и бюджет неограничены, главное сделать
продукт, что удовлетворит заказчика?
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, RGB_Dart, Вы писали:
RGB>>Если у вас есть описание будущего функционала, бюджет и сроки — то зачем вам agile? Используйте RUP, например. 0>А если оно есть, но неправильное?
Здравствуйте, RGB_Dart, Вы писали:
RGB>Если у вас есть описание будущего функционала, бюджет и сроки — то зачем вам agile? Используйте RUP, например.
Даже в таких проектах нередко описание функционала появляется не на стадии pre-production, как это должно быть, а в начале или середине production. Ближе, к концу production существующее описание изменяется и — о, Боже! — нужно переделывать всё то, что уже сделано. На стадии post-production описание функциональности меняется снова и, опять-таки, нужно большую часть переделывать.
Так что аджайл тут не при чём. Просто фича может измениться несколько раз на основе фидбэка, полученного от ревьюеров.
RGB>Суть agile — работа в условиях неопределенных требований. Набора хотелок хватает на пару недель — месяц работы максимум. Дальнейшее будущее сильно туманно и зависит от фидбека, который команда получит после внедрения результатов очередной итерации. На основании этого фидбека появятся новые требования (или изменятся старые), сформируется новый пул задач на пару недель — месяц и процесс будет повторяться сколько угодно раз.
Тем не менее, бюджет на итерацию всё равно есть и важно не вылететь за его пределы.
Здравствуйте, Vzhyk, Вы писали:
V>Ты путаешь предсказание будущего (это к гадалкам) с предсказуемостью V>процесса разработки.
Любая "предсказуемость" — это про будущее.
Здравствуйте, Vzhyk, Вы писали:
V>On 08.08.2013 12:49, RGB_Dart wrote:
>> Что для вас важнее — уложиться в срок и бюджет, или сделать продукт, >> который нужен заказчику? >> >> Те процессы и методологии о которых вы говорите относятся к первому >> варианту. А agile — ко второму. V>Поиграю в твою же словесную игру. Ты хочешь сказать, что выбор agile V>разумен в том случае, когда срок и бюджет неограничены, главное сделать V>продукт, что удовлетворит заказчика?
Выбор agile разумен, когда главное — сделать продукт, удовлетворяющий заказчика.
Бюджет и сроки в таком случае становятся проектными ограничениями. Зачем их делать бесконечными я не очень понимаю.
Здравствуйте, 0x7be, Вы писали:
0>Скажи, а какого размера были описанные проекты? 0>В терминах потраченных человекочасов, размеров бюджета, временных рамок.
Приведённые задачи — учебные за исключением одной. Но это не значит, что они нереальные. Как я выбирал эти задачи? Смотрел какую-нибудь книжку по ООП или же популярное обсуждение на форуме, а затем — описывал, как бы я эту задачу решал. Иными словами — описывал свой подход.
Точно такой же подход я применял при решении уже других, реальных задач. Но рассказывать про эти задачи я, к сожалению, не имею права. Потому что в своё время подписывал NDA.
Если говорить о реальных проектах, в которых я принимал участие в роли опытного или ведущего программиста, то могу привести информацию по их срокам и трудозатратам:
1. Игра для Nintendo Wii — 5 программистов, 1 аниматор, 1 моделлер, 1 UI-дизайнер, 2 тестера, 1 продюсер. Срок — 10 месяцев.
2. Игра для Xbox 360/PS3 — порядка 100 человек, из них инженеров — около 50, срок — полтора года.
3. Игра для Xbox 360/PS3 — около 50 человек, инженеров — около 30, срок разработки — 1 год.
4. Навигационная система — 4 инженера, 1 менеджер, 1 продюсер, срок — 2 года.
0> Так вот, переформулирую свой высказывание: я не знаю ни одной методики разработки, которая бы позволяла для инновационных проектов составить план с фиксированными рамками, сроками и бюджетами.
А и не нужен точный срок. Нужна оценка, которая тагетируется при работе над проектом.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Приведённые задачи — учебные за исключением одной. Но это не значит, что они нереальные. Как я выбирал эти задачи? Смотрел какую-нибудь книжку по ООП или же популярное обсуждение на форуме, а затем — описывал, как бы я эту задачу решал. Иными словами — описывал свой подход.
Это несколько снижает ценность приведенных примеров.
КЛ>Если говорить о реальных проектах, в которых я принимал участие в роли опытного или ведущего программиста, то могу привести информацию по их срокам и трудозатратам:
Спасибо за информацию.
КЛ>А и не нужен точный срок. Нужна оценка, которая тагетируется при работе над проектом.
Я думаю, что ты слишком обобщаешь. Некоторым заказчикам ОЧЕНЬ нужен точный срок и/или бюджет, рамки.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, RGB_Dart, Вы писали:
RGB>>Если у вас есть описание будущего функционала, бюджет и сроки — то зачем вам agile? Используйте RUP, например.
КЛ>Даже в таких проектах нередко описание функционала появляется не на стадии pre-production, как это должно быть, а в начале или середине production. Ближе, к концу production существующее описание изменяется и — о, Боже! — нужно переделывать всё то, что уже сделано. На стадии post-production описание функциональности меняется снова и, опять-таки, нужно большую часть переделывать.
КЛ>Так что аджайл тут не при чём. Просто фича может измениться несколько раз на основе фидбэка, полученного от ревьюеров.
Мы с вами подошли к самой сути!
Внимание вопрос — какая группа методологий предполагает более быстрый фидбек от заказчика — Agile или Rup/CMMI/NASA ?
При использовании какой методологии количество переделывемой работы будет минимально (при условии часто меняющихся требований)?
Какая методология явно принуждает использовать инженерные практики облегчающие внесение изменений в уже написанный код?
On 08.08.2013 13:16, RGB_Dart wrote:
> Выбор agile разумен, когда главное — сделать продукт, удовлетворяющий > заказчика. > Бюджет и сроки в таком случае становятся проектными ограничениями. Зачем > их делать бесконечными я не очень понимаю.
Так как ты сделаешь продукт, удовлетворяющий заказчика, если бюджет или
срок тебе этого не позволят?
Posted via RSDN NNTP Server 2.1 beta
Re[8]: Канбан и итерации
От:
Аноним
Дата:
08.08.13 10:42
Оценка:
Здравствуйте, Vzhyk, Вы писали:
V>Поиграю в твою же словесную игру. Ты хочешь сказать, что выбор agile V>разумен в том случае, когда срок и бюджет неограничены, главное сделать V>продукт, что удовлетворит заказчика?
Это в каждой книжке по Agile на первых десяти страницах написано.
Здравствуйте, Vzhyk, Вы писали:
V>On 08.08.2013 13:16, RGB_Dart wrote:
>> Выбор agile разумен, когда главное — сделать продукт, удовлетворяющий >> заказчика. >> Бюджет и сроки в таком случае становятся проектными ограничениями. Зачем >> их делать бесконечными я не очень понимаю. V>Так как ты сделаешь продукт, удовлетворяющий заказчика, если бюджет или V>срок тебе этого не позволят?
Честно говоря, не понял вопроса.
Удовлетворенность заказачика продуктом это не булево значение (true/false), а функция.
Чем больше бюджет и сроки, тем более удовлетворительным получится продукт, если делать его по agile.
Функция "удовлетворенности" — нелинейна. Первоначальные вложения денег и времени могут дать значительное увеличение удовлетворенности клиента (делаются самые важные и нужные фичи), дальнейшие вливания могут не давать такого эффекта (рюшечки / красивости не добавляющие много ценности продукту)
Здравствуйте, 0x7be, Вы писали:
0>Это несколько снижает ценность приведенных примеров.
Почему?
0>Я думаю, что ты слишком обобщаешь. Некоторым заказчикам ОЧЕНЬ нужен точный срок и/или бюджет, рамки.
Ты хочешь сказать, что заказчикам нужно уложиться в срок и бюджет? Так это да. Но стопроцентной гарантии никто не даст. Решения придётся принимать походу проекта.
On 08.08.2013 14:28, RGB_Dart wrote:
> V>Так как ты сделаешь продукт, удовлетворяющий заказчика, если бюджет или > V>срок тебе этого не позволят? > > Честно говоря, не понял вопроса.
Все ты понял (Путин). Просто то что ты описываешь — это классическая
разводка на бабки заказчика, коей пользовались всегда, только раньше
громкого словечка не придумали и рекламы такой не делали.
> Удовлетворенность заказачика продуктом это не булево значение > (true/false), а функция.
Однако... лично я всегда слитал, что можно быть или удовлетворенным или
нет, но вот удовлетворенным наполовину — это как? Хотя, для продвижения
очередной разводки все способы хороши.
> Чем больше бюджет и сроки, тем более удовлетворительным получится > продукт, если делать его по agile.
Ну еще бы, коль вложил уже надцадь ярдов, как-то сложно согласится с
тем, что в никуда вложил.
Здравствуйте, Кирилл Лебедев, Вы писали:
0>>Это несколько снижает ценность приведенных примеров. КЛ>Почему?
Ну, ты же сам написал о решении этих задач в сослагательном наклонении, т.е. не решал их.
Т.е. многие риски, которые возникли бы при решении этих задач в реальных условиях, не могли реализоваться просто по определению.
0>>Я думаю, что ты слишком обобщаешь. Некоторым заказчикам ОЧЕНЬ нужен точный срок и/или бюджет, рамки. КЛ>Ты хочешь сказать, что заказчикам нужно уложиться в срок и бюджет? Так это да. Но стопроцентной гарантии никто не даст. Решения придётся принимать походу проекта.
Не могу удержаться от того, чтобы не напомнить более раннее твоё утверждение о том, что методики, позволяющие
заканчивать проекты в срок с заданной функциональностью и без выхода за пределы отведённого бюджета
существуют. А теперь ты говоришь, что "стопроцентной гарантии никто не даст"
Ну ладно, если серьёзно, то оно понятно, что стопроцентной гарантии никто не даст.
Тогда сразу возникает вопрос: а сколькипроцентную ты готов давать?
На месте клиента, оплачивающего твою работу, мне очень интересно знать ответ на этот вопрос.
On 08.08.2013 15:11, 0x7be wrote:
> заканчивать проекты в срок с заданной функциональностью и без выхода > за пределы отведённого бюджета > > существуют. А теперь ты говоришь, что "стопроцентной гарантии никто не > даст"
А землетрясения и цунами тоже гарантировать надо. А если без них, то
обычный "водопад", если ему следовать уже дает такую гарантию (просто он
требует 60-70% работ проведенных на уровне составления ТЗ).
