Здравствуйте, RGB_Dart, Вы писали:
RGB>Здравствуйте, Кирилл Лебедев, Вы писали: КЛ>>Здравствуйте, 0x7be, Вы писали:
0>>>Собственно, центральная идея, вокруг которой эджайл крутится: адаптация как разрабатываемого продукта, так и метода его разработки важнее следования предопределённым планам и регламентам.
КЛ>>В этом нет какого-либо открытия. Собственно, методики и процессы разрабатываются именно для того, чтобы проекты укладывались в заданные сроки, в заданный бюджет и содержали запланированную функциональность. Однако из этого не следует, что каждый способен разработать методику. Часто просто не хватает квалификации.
RGB>Вы кажется, не поняли что вам пытался сказать 0x7be. RGB>Давайте, я попробую.
RGB>Что для вас важнее — уложиться в срок и бюджет, или сделать продукт, который нужен заказчику?
A в чем разница? Помоему, одно и тоже.
при разработке ПО надо:
уложиться в срок
в смету
в требования
Если что-то отсутствует — проект, наверное, можно посчитать провалом
RGB>Те процессы и методологии о которых вы говорите относятся к первому варианту. А agile — ко второму.
Здравствуйте, RGB_Dart, Вы писали:
RGB>Если у вас есть описание будущего функционала, бюджет и сроки — то зачем вам agile? Используйте RUP, например. RGB>Суть agile — работа в условиях неопределенных требований.
Странное у вас представление о RUP и Agile.
Открою страшную тайну в RUP есть итерации о_0 Причем RUP ожидает изменение требований на протяжении всего проекта (и очень существенно во время первых итераций). RUP не менее адаптивный, чем эджайловские методологии. RUP это в первую очередь шаблон процесса, из которого можно выкинуть все то что нужно конкретно вам.
Хорошо, что хоть не водопад в пример привели. Хотя в реальности никто водопад в чистом не использовал, а был он выдуман как оппозиция к "нормальным" методологиям. Эдакий "обычный порошок" из рекламы.
Любая методология или процесс разработки должен учитывать "условия неопределенных требований", это не особенность Agile, это особенности индустрии.
С другой стороны, Agile это не (только) про "неопределенные требования".
Если посмотреть на http://agilemanifesto.org/ то кроме изменения требований, там есть еще про людей (а не винтики в процессах), про работающее ПО (а не про документы), про работу вместе С заказчиком (а не НА него) и только в конце "быть готовыим к изменениям" (а это, ИХМО, намного серьезнее, чем "учитывать неопределенные требования").
По поводу "функционала, бюджета и сроков".
В любом серьезном проекте все это есть. Сначала пишется видение, по нему бизнесс план, по нему выделяется бюджет и оговариваются сроки.
Даже в стартапах. Инвесторы хотят видеть описание проета (лучше всего в виде бизнесс плана), выделяют бюджет и оговаривают сроки.
СУВ, Aikin
ПС
Вот как выглядит итерационная модель RUP. Довольно занятный график.
On 08.08.2013 15:22, zfima wrote:
> Если что-то отсутствует — проект, наверное, можно посчитать провалом
Насколько я понял, подразумевается ситуация, когда требовании нет вообще
и они меняются по несколько раз на неделю, а смета и срок в общем-то
неограничены (ограничены желанием заказчика, когда ему надоест или
сделают что-то, что удовлетворит заказчика).
Здравствуйте, Vzhyk, Вы писали:
V>А землетрясения и цунами тоже гарантировать надо. А если без них, то V>обычный "водопад", если ему следовать уже дает такую гарантию (просто он V>требует 60-70% работ проведенных на уровне составления ТЗ).
Истинность этого утверждение не очевидна
Здравствуйте, 0x7be, Вы писали:
I>>Очевидно — нет. 0>А что такое "предсказуемый процесс"?
"предсказывать будущее в отношении себя"
Предсказуемость процесса это всего лишь предсказуемость некоторых аспектов, и есть некоторые сомнения, что создатели методологий внесли в эти аспекты тебя и твое будущее
Например итерации дают предсказуемость получения промежуточных результатов — конец спринта. Отсутствие ожидаемых результатов на этот момент означает наличие некоторых проблем, что фактически есть результат, хотя и не ожидаемый.
Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, RGB_Dart, Вы писали:
RGB>>Если у вас есть описание будущего функционала, бюджет и сроки — то зачем вам agile? Используйте RUP, например. RGB>>Суть agile — работа в условиях неопределенных требований. A>Странное у вас представление о RUP и Agile. A>Открою страшную тайну в RUP есть итерации о_0 Причем RUP ожидает изменение требований на протяжении всего проекта (и очень существенно во время первых итераций). RUP не менее адаптивный, чем эджайловские методологии. RUP это в первую очередь шаблон процесса, из которого можно выкинуть все то что нужно конкретно вам.
Спасибо за развернутый комментарий. Однако, я кое с чем не согласен.
Вы превели прекрасную диаграмму. A>Вот как выглядит итерационная модель RUP. Довольно занятный график.
Вопрос — в какой момент этой диаграммы заказчик получит работающий продукт? Ответ: на этапе transition.
Есть принципиальная разница между понятием "итерация" в RUP и в том же Scrum'e.
В RUP явно выделены фазы жизненного цикла проекта (Inception-Elaboration-Construction-Trasition). Работа в рамках одной фазы делится на итерации.
Чтобы перейти к следующей фазе надо достичь критериев завершенности у предыдущей.
Например, чтобы перейти к Construction, в конце фазы Elaboration должно выполняться следующее условие:
A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed. The use-case model should be 80% complete.
(см. http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process)
Если оно не выполнилось — делаем еще одну итерацию Elaboration.
Грубо говоря (на рисунке) у нас 1 итерация "придумывания" границ системы, 2 итерации формирования требований, 4 итерации реализации требований и 2 итерации внедрения продукта.
В Scrum каждая итерация (спринт) похожа на другие. В каждой итерации есть и работа с требованиями, и проектирование / кодирование, и тестирование, и развертывание. Весь жизненный цикл продукта сжат в одну 2-хнедельную итерацию.
Именно поэтому Scrum, например, более устойчив к изменениям требований в конце проекта, нежели RUP.
RUP — менее адаптивный.
Здравствуйте, Aikin, Вы писали:
A>По поводу "функционала, бюджета и сроков". A>В любом серьезном проекте все это есть. Сначала пишется видение, по нему бизнесс план, по нему выделяется бюджет и оговариваются сроки. A>Даже в стартапах. Инвесторы хотят видеть описание проета (лучше всего в виде бизнесс плана), выделяют бюджет и оговаривают сроки.
Отвечу отдельно, чтобы не смешивать дискусии.
Вы сейчас говорите про Fixed Price.
Мое мнение — Agile в Fixed Price проектах лучше не применять.
Проекты бывают разные. Есть внутренняя автоматизация, time and material и т.д. Разным проектам разные методологии.
Мне кажется, точку в дискуссии может поставить вот эта цитата из википедии.
Methods exist on a continuum from adaptive to predictive.Agile methods lie on the adaptive side of this continuum. Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team cannot report exactly what tasks they will do next week, but only which features they plan for next month. When asked about a release six months from now, an adaptive team might be able to report only the mission statement for the release, or a statement of expected value vs. cost.
Predictive methods, in contrast, focus on analysing and planning the future in detail and cater for known risks. In the extremes, a predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive methods rely on effective early phase analysis and if this goes very wrong, the project may have difficulty changing direction. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.
Здравствуйте, Vzhyk, Вы писали:
>> Истинность этого утверждение не очевидна V>Много чего не очевидно, но познается с опытом.
Конечно
Правда, бывает и обратное: "очевидные" сначала вещи перестают быть таковыми.
On 08.08.2013 16:16, 0x7be wrote:
> Правда, бывает и обратное: "очевидные" сначала вещи перестают быть таковыми.
Это не обратное, опыта в начале еще нет.
Здравствуйте, Vzhyk, Вы писали:
>> Правда, бывает и обратное: "очевидные" сначала вещи перестают быть таковыми. V>Это не обратное, опыта в начале еще нет.
В другом смысле обратное
I>Предсказуемость процесса это всего лишь предсказуемость некоторых аспектов, и есть некоторые сомнения, что создатели методологий внесли в эти аспекты тебя и твое будущее
I>Например итерации дают предсказуемость получения промежуточных результатов — конец спринта. Отсутствие ожидаемых результатов на этот момент означает наличие некоторых проблем, что фактически есть результат, хотя и не ожидаемый.
из этого я вынес 3 мысли:
1. предсказуемость процесса это предсказуемость не событий в будущем, а аспектов процесса (например получение промежуточных результатов при итерациях) (допустим эта фраза имеет смысл с точки зрения банальной логики)
2. наличие промежуточных результатов можно предсказать, но они появляются не в будущем (а где??)
3. не смотря на то, что их предсказали, они все равно могут отсутствовать (что означает проблемы, но по-прежнему позволяет процессу называться предсказуемым)
Здравствуйте, 0x7be, Вы писали:
0>Ну, ты же сам написал о решении этих задач в сослагательном наклонении, т.е. не решал их.
Я такого не писал. Задачи были решены, но не закодированы. Но этого и ненужно, т.к. рассматривался процесс получения архитектуры из требований.
0>Т.е. многие риски, которые возникли бы при решении этих задач в реальных условиях, не могли реализоваться просто по определению.
Это крайне неконкретно. При рассмотрении конкретных решений нужно приводить конкретные возражения, например: При использовании промежуточной базы данных для хранения временной информации от датчиков может возникнуть такой-то негативный эффект (указать) и вероятность срабатывания риска (указать) увеличится.
0>Не могу удержаться от того, чтобы не напомнить более раннее твоё утверждение о том, что методики, позволяющие 0>
0>заканчивать проекты в срок с заданной функциональностью и без выхода за пределы отведённого бюджета
0>существуют. А теперь ты говоришь, что "стопроцентной гарантии никто не даст"
Не надо заниматься казуистикой. В качестве примера приведу две компании. Одна — российская. Практикует канбан и гибкие методологии. Занимается выпуском хидден обжектов. За всё время своего существования выпустила пару игр. Одну — более-менее удачно для себя и неудачно для заказчика. Вторую — с убытками для себя. Остальные 4 или 5 проектов не завершила. Заказчики постоянно отваливались либо входе продакшена, либо на звершающих стадиях. Майлстоуны постоянно срывались. Программисты постоянно овертаймили. И другая компания, западная. Каждый год выпускает игры. Некоторые — новая версия каждый год. Над разработкой одной игры работают от 50 до 200 человек. Никакого канбана не используется. Есть свой чётко формализованный процесс. Игры выпускаются практически всегда в срок. Фейлы конечно тоже есть. Но их немного.
Так чей процесс лучше?
0>На месте клиента, оплачивающего твою работу, мне очень интересно знать ответ на этот вопрос.
Ты пока не мой клиент. Да и финансовой информацией о проектах, которые приводил в качестве примеров, я не обладаю. А обладал бы — не сказал бы, тк коммерческая тайна. Тем не менее, качественную оценку я тебе привел.
Здравствуйте, Кирилл Лебедев, Вы писали:
0>>Ну, ты же сам написал о решении этих задач в сослагательном наклонении, т.е. не решал их. КЛ>Я такого не писал. Задачи были решены, но не закодированы. Но этого и ненужно, т.к. рассматривался процесс получения архитектуры из требований.
Правильность архитектуры окончательно проверяется только её реализацией и поддержкой в течение некоторого времени.
КЛ>Это крайне неконкретно. При рассмотрении конкретных решений нужно приводить конкретные возражения, например: При использовании промежуточной базы данных для хранения временной информации от датчиков может возникнуть такой-то негативный эффект (указать) и вероятность срабатывания риска (указать) увеличится.
Почему не корректно? Только реализации может вскрыть все проблемы теоретически проработанного решения.
КЛ>Не надо заниматься казуистикой. В качестве примера приведу две компании. Одна — российская. Практикует канбан и гибкие методологии. Занимается выпуском хидден обжектов. За всё время своего существования выпустила пару игр. Одну — более-менее удачно для себя и неудачно для заказчика. Вторую — с убытками для себя. Остальные 4 или 5 проектов не завершила. Заказчики постоянно отваливались либо входе продакшена, либо на звершающих стадиях. Майлстоуны постоянно срывались. Программисты постоянно овертаймили. И другая компания, западная. Каждый год выпускает игры. Некоторые — новая версия каждый год. Над разработкой одной игры работают от 50 до 200 человек. Никакого канбана не используется. Есть свой чётко формализованный процесс. Игры выпускаются практически всегда в срок. Фейлы конечно тоже есть. Но их немного. КЛ>Так чей процесс лучше?
Не сильно понимаю, к чему ты привёл эти примеры. Чтобы дать ответ на твой вопрос данных, вообщем-то, недостаточно.
Например, я видел один достаточно крупный проект, где программисты тоже овертаймили и сроки постоянно срывались просто потому что:
1. Проект был продан заказчику с явно заниженными сроками и бюджетами, чтобы выиграть тендер.
2. Менеджмент проекта слишком сильно "лёг под клиента", позволив тому бесконтрольно расширять рамки.
Там можно было бы построить идеальный процесс, но проект всё равно провальный просто потому, что вытянуть налаживанием процесса проваленный по бизнесу проект нельзя.
0>>На месте клиента, оплачивающего твою работу, мне очень интересно знать ответ на этот вопрос. КЛ>Ты пока не мой клиент. Да и финансовой информацией о проектах, которые приводил в качестве примеров, я не обладаю. А обладал бы — не сказал бы, тк коммерческая тайна. Тем не менее, качественную оценку я тебе привел.
Блин, не надо так резко реагировать Понятное дело, что я не просил у тебя конкретных цифр по конкретным проектам. Меня интересует твой подход к решению этой проблемы.
Здравствуйте, evgeny.e, Вы писали:
I>>Например итерации дают предсказуемость получения промежуточных результатов — конец спринта. Отсутствие ожидаемых результатов на этот момент означает наличие некоторых проблем, что фактически есть результат, хотя и не ожидаемый.
EE>из этого я вынес 3 мысли: EE>1. предсказуемость процесса это предсказуемость не событий в будущем, а аспектов процесса (например получение промежуточных результатов при итерациях) (допустим эта фраза имеет смысл с точки зрения банальной логики) EE>2. наличие промежуточных результатов можно предсказать, но они появляются не в будущем (а где??)
"предсказуемость получения промежуточных результатов — конец спринта". Вопрос, если сейчас начало спринта, то конец спринта это будущее или "а где??" ?
EE>3. не смотря на то, что их предсказали, они все равно могут отсутствовать (что означает проблемы, но по-прежнему позволяет процессу называться предсказуемым)
"Отсутствие ожидаемых результатов на этот момент означает наличие некоторых проблем, что фактически есть результат, хотя и не ожидаемый"
Тебе понятно, что ожидаемый результат это всего лишь подмножество всех возможных результатов ?
EE>одно форматное слово у меня — ппц
Если пробовать читать, то будет гораздо понятнее.
Никто тебе не даст предсказание на тему, будет ли готова фича через две недели. Готовность фичи это ожидаемый результат. Через две недели у тебя есть точка контроля и это гарантирует процесс.
Фича готова — это результат, при чем ожидаемый.
Фича не готова — это тоже результат. Но если фича не готова, стало быть есть тому причины, проблемы и это так же результат. В следующем спринте ты это учитываешь, и получаешь тем самым другие гарантии, которые так же обеспечивают предсказуемость некоторого аспекта.
КЛ>1. Отсутствие конкретных пошаговых методик ведения ИТ-проектов, которые позволяли бы заканчивать проекты в срок с заданной функциональностью и без выхода за пределы отведённого бюджета.
Выделенное — лишнее.
Серебряной пули нет ни в IT, ни где бы то ни было вообще. Что уж там, даже при постройке однотипных домов по одному и тому же проекту одной и той же командой сроки могут быть разными, и качество постройки тоже, не говоря уже о бюджете. А всё потому, что где-то грунтовые воды подгадят, где-то муницепалитет...
A>Хорошо, что хоть не водопад в пример привели. Хотя в реальности никто водопад в чистом не использовал, а был он выдуман как оппозиция к "нормальным" методологиям. Эдакий "обычный порошок" из рекламы.
/offtop:
Ничего себе "выдуман". Да это единственный процесс, который принят в строительстве, добыче полезных ископаемых и других подобных отраслях. Попробуйте BHP Billiton уговорить вести разработку месторождений Agile-методом... или даже RUP
КЛ>Одна — российская. Практикует канбан и гибкие методологии. <...> И другая компания, западная. Каждый год выпускает игры. Некоторые — новая версия каждый год. <...> КЛ>Так чей процесс лучше?
Вы всерьез считаете, что финансовый успех компании определяется принятым в ней процессом? Влияние, несомненно, есть, но не следует его преувеличивать. Любой, даже самый лучший процесс, можно с лёгкостью перечеркнуть сейлзами нетрадиционной анатомии.
КЛ>Поработав некоторое время с руководством, которое было приверженцем канбана, я написал такую заметку. Вот она:
КЛ>У меня складывается впечатление, что модные словечки типа "аджайл", "скрам", "канбан", "гибкие методологии" постепенно становятся ругательными в профессиональной среде. У такого положения вещей есть несколько объективных причин:
КЛ>1. Отсутствие конкретных пошаговых методик ведения ИТ-проектов, которые позволяли бы заканчивать проекты в срок с заданной функциональностью и без выхода за пределы отведённого бюджета.
КЛ>Вместо методик часто можно услышать и прочитать банальные советы в стиле: "сокращайте потери", "принимайте решения, как можно позже" и т.п. Некоторые из этих советов очевидны, некоторые – спорны. Но те и другие сформулированы настолько общё и настолько банальны, что под них можно подвести всё, что угодно (любую ситуацию, любой пример). И самое главное – они не дают инструмента для решения реальных проблем, которые встречаются на проекте.
В Agile разработка заканчивается в момент исчерпания бюджета.
Так что у вас неправильный Agile
Здравствуйте, zfima, Вы писали:
Z> Ну, или траншею рыть — тоже всё известно.
Хахаха)) Вы траншей мало рыли)))) Вот бишь недавно у себя у дома — рою траншею под дренаж. Рыл-рыл -- бах, кирпичи закопаны Полдня выковыривал камни. Рою дальше — бах, твердущий слой неясно чего, типа известняка. День ломом ломал. Дальше ударил лопатой куда-то, сломал лопату. Поехал за лопатой — черенков нет. Купил через день. Прошли дожди — верхняя кромка начала оползать. Купил доски, укрепил стенки траншеи, чтобы не сползали.
Даже у экскаваторщиков частенько проблемы
Итого, превышение по срокам раз в 10 и по бюджету во много раз)) Хотя делал "прототип" — прокопал там на два штыка сначала вдоль траншеи. Казалось все просто)))
Полдня выковыривал камни. Рою дальше — бах, твердущий слой неясно чего, типа известняка. 