Поработав некоторое время с руководством, которое было приверженцем канбана, я написал такую заметку. Вот она:
У меня складывается впечатление, что модные словечки типа "аджайл", "скрам", "канбан", "гибкие методологии" постепенно становятся ругательными в профессиональной среде. У такого положения вещей есть несколько объективных причин:
1. Отсутствие конкретных пошаговых методик ведения ИТ-проектов, которые позволяли бы заканчивать проекты в срок с заданной функциональностью и без выхода за пределы отведённого бюджета.
Вместо методик часто можно услышать и прочитать банальные советы в стиле: "сокращайте потери", "принимайте решения, как можно позже" и т.п. Некоторые из этих советов очевидны, некоторые – спорны. Но те и другие сформулированы настолько общё и настолько банальны, что под них можно подвести всё, что угодно (любую ситуацию, любой пример). И самое главное – они не дают инструмента для решения реальных проблем, которые встречаются на проекте.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, zfima, Вы писали:
Z>>В чем подвох?
КЛ>Поработав некоторое время с руководством, которое было приверженцем канбана, я написал такую заметку. Вот она:
КЛ>У меня складывается впечатление, что модные словечки типа "аджайл", "скрам", "канбан", "гибкие методологии" постепенно становятся ругательными в профессиональной среде. У такого положения вещей есть несколько объективных причин:
Может вы что-то не правильно делали просто? Чем испортили себе впечатление
КЛ>1. Отсутствие конкретных пошаговых методик ведения ИТ-проектов, которые позволяли бы заканчивать проекты в срок с заданной функциональностью и без выхода за пределы отведённого бюджета.
Ну, наверное, это можно только составить для какой-то работы, которая постоянно повторяется. Например, делать одинаковые сайты — картинки меняй и всё. Тут и сроки известны, и бюджет и соответствования целям. Ну, или траншею рыть — тоже всё известно.
КЛ>Вместо методик часто можно услышать и прочитать банальные советы в стиле: "сокращайте потери", "принимайте решения, как можно позже" и т.п. Некоторые из этих советов очевидны, некоторые – спорны. Но те и другие сформулированы настолько общё и настолько банальны, что под них можно подвести всё, что угодно (любую ситуацию, любой пример). И самое главное – они не дают инструмента для решения реальных проблем, которые встречаются на проекте.
Ну, думаю тут (в канбане), ещё есть и немало философии... Может ты и прав.
КЛ>Продолжение
Здравствуйте, zfima, Вы писали:
Z>В Канбане не обязательны итерации. Z>Т.е. — Канбан не итеративный? (Не Agile?) Z>В чем подвох?
Подвох в том, что agile != итерации.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>У меня складывается впечатление, что модные словечки типа "аджайл", "скрам", "канбан", "гибкие методологии" постепенно становятся ругательными в профессиональной среде. У такого положения вещей есть несколько объективных причин:
ПМСМ, это здоровая реакция на попытку сделать из эджайла новую религию, как в своё время делали религию из ООП.
Но это не отменяет того, что мемплекс эджайла содержит полезные идеи.
КЛ>1. Отсутствие конкретных пошаговых методик ведения ИТ-проектов, которые позволяли бы заканчивать проекты в срок с заданной функциональностью и без выхода за пределы отведённого бюджета.
А они есть такие методики?
И если есть, то какова область их применимости?
Здравствуйте, zfima, Вы писали:
Z>Здравствуйте
Z>Знаю, что Канбан является гибким процессом с небольшим кол-вом ограничений.
Z>В Канбане не обязательны итерации.
Z>Т.е. — Канбан не итеративный? (Не Agile?)
Канбан — конвейерный (рассчитан на конвейер)
Вот пытался понять как этот самый канбан применим к разработке проектов и как он может помочь.
С таким же успехом можно применить абстрактный "вау эффект", который можно наполнить любым смыслом,
которым только пожелаешь.
Даже чрезвычайно упрощающий реальность скрам и то дает больше полезных советов.
А с канбанов похоже работает культ карго.
Типа японцы делают качественные авто. Они пользуют канбан.
В IT есть явные проблемы с качеством. Давайте тогда делать как японцы. Наверняка поможет.
Но если кто внятно разъяснит и еще лучше расскажет про личный опыт,
то буду только благодарен.
Здравствуйте, zfima, Вы писали:
Z>Может вы что-то не правильно делали просто? Чем испортили себе впечатление
Предположим, команда из 6 разработчиков + 1 аниматор + 1 UI-дизайнер + 2 3D-моделлера + 2 2D-артиста делают игру. Как Вы думаете, сколько нужно поставить deliverables к ближайшему майлстоуну? Промежуток между майлстоунами месяц — полтора. В нашем случае — 45.
Каждый deliverable — это feature, которая включает в себя несколько технических и артовых задач. Сколько было таких задач? Порядка 300 технических + артовые, которые я не считал, т.к. ими занимался ведущий артист.
Каждая техническая задача имеет свой estimate (который, согласно отраслевым стандартам варьируется от 4 до 24 часов) и текущий прогресс по нему. Некоторые задачи закрываются с опережением срока. Некоторые — с задержкой, которая связана с обнаружением непредвиденных обстоятельств. Происходит переоценка задач и, как результат, перепланирование работы и перераспределение задач между разработчиками. Нередко случается, что задача одного разработчика переходит к другому из-за того, что первый разработчик погряз в предыдущей своей задаче, а другой — справился со своей быстрее, чем ожидалось.
Ряд задач откладывается из-за того, что арт у художников ещё не готов или продюсеры (о, чудо!) решают полностью переделать дизайн фичи.
Как всем этим управлять при помощи карточек? При таком объёме задач бумажные карточки осыпятся под собственной тяжестью, а электронные канбан-доски будут полностью захламлены.
Представьте теперь, что произойдёт, когда над проектом работают не 10, а 100 человек. А ведь именно так и происходит при разработке больших игр.
Z>Ну, наверное, это можно только составить для какой-то работы, которая постоянно повторяется. Например, делать одинаковые сайты — картинки меняй и всё. Тут и сроки известны, и бюджет и соответствования целям. Ну, или траншею рыть — тоже всё известно.
Вы ошибаетесь. Есть вполне устоявшиеся и апробированные процессы в крупных корпорациях. Они не так известны и популярны, как модные аджайл и канбан, однако предсказуемы и приводят к запланированному результату. Да что там корпорации! Даже американские стартапы используют процессы. И без дизайн-документации и планирования никто и строчки кода не напишет.
Просто это не так весело, как играть в геймификацию и тасовать карточки. Зато — надёжно и практично.
Разумеется, для PR-целей корпорации утверждают, что они следуют тренду и используют аджайл. Просто надо научится отделять зёрна от плевел. Реальные процессы не светят.
Здравствуйте, bkat, Вы писали:
B>Типа японцы делают качественные авто. Они пользуют канбан.
Речь, по всей видимости, идёт о Тойоте. На счёт канбана — это очередное заблуждение. Тойота использует не канбан, а Toyota Production System. Канбан — это обычная бумажная карточка (своего рода накладная). Понятно, что производственная система Тойоты не сводится к одним лишь карточкам.
Здравствуйте, 0x7be, Вы писали:
0>Но это не отменяет того, что мемплекс эджайла содержит полезные идеи.
Какие?
КЛ>>1. Отсутствие конкретных пошаговых методик ведения ИТ-проектов, которые позволяли бы заканчивать проекты в срок с заданной функциональностью и без выхода за пределы отведённого бюджета. 0>А они есть такие методики?
Да.
0>И если есть, то какова область их применимости?
Коммерческая разработка ПО. Например, видеоигр.
Здравствуйте, bkat, Вы писали:
B>Но если кто внятно разъяснит и еще лучше расскажет про личный опыт, B>то буду только благодарен.
Есть небольшой личный опыт работы по канбану.
Опыт крайне негативный, команда перешла на скрам.
Впрочем, по одному кейсу нельзя судить в чем причина неудачи
Здравствуйте, Кирилл Лебедев, Вы писали:
0>>Но это не отменяет того, что мемплекс эджайла содержит полезные идеи. КЛ>Какие?
Собственно, центральная идея, вокруг которой эджайл крутится: адаптация как разрабатываемого продукта, так и метода его разработки важнее следования предопределённым планам и регламентам.
0>>А они есть такие методики? КЛ>Да.
Поделись сакральным знанием
0>>И если есть, то какова область их применимости? КЛ>Коммерческая разработка ПО. Например, видеоигр.
Я о другом.
Мой опыт говорит о том, что любая разработка с высокой степенью инновационности (т.е. когда не клепаем/внедряем n+1-ый вариант ранее реализованного продукта, а делаем что-то, чего раньше не делали) неизбежно несет в себе высокую степень риска и точно прогнозировать их в треугольнике "рамки-сроки-деньги" бесполезно.
И, наоборот, тиражирование уже имеющегося опыта при правильном подходе может быть вполне предсказуемым делом.
Этот аспект ортогонален предметной области.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, bkat, Вы писали:
B>>Типа японцы делают качественные авто. Они пользуют канбан. КЛ>Речь, по всей видимости, идёт о Тойоте. На счёт канбана — это очередное заблуждение. Тойота использует не канбан, а Toyota Production System. Канбан — это обычная бумажная карточка (своего рода накладная). Понятно, что производственная система Тойоты не сводится к одним лишь карточкам.
Но ведь кто-то свел к карточкам, в надежде, что это поможет IT проектам
если закончили раньше срока — хорошо, если не закончили в срок — перепланировали — это разве предсказуемый процесс разработки? если вы не про тот процесс, что описали в соседнем посте?
если про тот, то это то же самое что сказать что фондовый рынок предсказуемый — он пойдет либо вверх либо вниз
з.ы. я не фанат эджайла, но считаю что процесс разработки по природе своей непредсказуем, это такая данность, с которой нужно жить, и эджайл в этом не помогает а наоборот
Здравствуйте, 0x7be, Вы писали:
0>Собственно, центральная идея, вокруг которой эджайл крутится: адаптация как разрабатываемого продукта, так и метода его разработки важнее следования предопределённым планам и регламентам.
В этом нет какого-либо открытия. Собственно, методики и процессы разрабатываются именно для того, чтобы проекты укладывались в заданные сроки, в заданный бюджет и содержали запланированную функциональность. Однако из этого не следует, что каждый способен разработать методику. Часто просто не хватает квалификации.
0>Поделись сакральным знанием
Собственно говоря, делюсь уже давно . Например, здесь на панели справа разобраны 5 кейсов, затрагивающих техническое проектирование, продуктовое проектирование и немного управление проектами.
Здесь и здесь находятся списки литературы по проектированию и управлению проектами.
0>Мой опыт говорит о том, что любая разработка с высокой степенью инновационности (т.е. когда не клепаем/внедряем n+1-ый вариант ранее реализованного продукта, а делаем что-то, чего раньше не делали) неизбежно несет в себе высокую степень риска и точно прогнозировать их в треугольнике "рамки-сроки-деньги" бесполезно.
В этом утверждении и заключается распространённая ошибка. Почему-то считается, что планы и оценки создаются для того, чтобы потом точно (тютелька в тютельку) в них вписаться. Это приводит к тому, что если какой-либо из планов не был выполнен или время выполнения какой-либо задачи не совпало с первоначальном эстимейтом, то план — сорван, а прогноз — в корне неверный. Планы и оценки делаются совсем для другой цели — для того, чтобы не потерять контроль над проектом. Конечно, самый оптимальный вариант — когда сроки и планы совпадают с реальными. Однако если что-то пошло не так, это вовсе не означает, что проект сорван. Срыв сроков по какой-либо задаче — это основание для принятия инженерного, управленческого или продюсерского решения, а именно:
1. Ведущий программист может помочь менее опытному коллеге найти другое, более дешёвое технические решение.
2. Менеджер проекта может передать задачу другому разработчику или подключить дополнительные силы.
3. Продюсер может переформулировать фичу таким образом, что её реализация в обновлённом варианте займёт гораздо меньшее время, или же сделать фича-кат.
On 08.08.2013 11:34, evgeny.e wrote:
> если закончили раньше срока — хорошо, если не закончили в срок — > перепланировали — это разве предсказуемый процесс разработки? если вы не > про тот процесс, что описали в соседнем посте?
Ты путаешь предсказание будущего (это к гадалкам) с предсказуемостью
процесса разработки.
Вот этой фразой описали ситуацию, когда применять agile не следует: 1. Отсутствие конкретных пошаговых методик ведения ИТ-проектов, которые позволяли бы заканчивать проекты в срок с заданной функциональностью и без выхода за пределы отведённого бюджета.
Если у вас есть описание будущего функционала, бюджет и сроки — то зачем вам agile? Используйте RUP, например.
Суть agile — работа в условиях неопределенных требований. Набора хотелок хватает на пару недель — месяц работы максимум. Дальнейшее будущее сильно туманно и зависит от фидбека, который команда получит после внедрения результатов очередной итерации. На основании этого фидбека появятся новые требования (или изменятся старые), сформируется новый пул задач на пару недель — месяц и процесс будет повторяться сколько угодно раз.
Чтобы все это имело хоть какой-то смысл — каждая итерация добавляет что-то ценное продукту. Когда продукт становится достаточно хорош с точки зрения заказчика — разработку можно и остановить.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>В этом нет какого-либо открытия. Собственно, методики и процессы разрабатываются именно для того, чтобы проекты укладывались в заданные сроки, в заданный бюджет и содержали запланированную функциональность. Однако из этого не следует, что каждый способен разработать методику. Часто просто не хватает квалификации.
А я и не говорил, что эджайл предлагает исключительно оригинальные идеи Если вдуматься, то принципы успешного управления проектами известны задолго до явного оформления этой дисциплины и уж точно задолго до появления IT.
0>>Поделись сакральным знанием КЛ>Собственно говоря, делюсь уже давно . Например, здесь на панели справа разобраны 5 кейсов, затрагивающих техническое проектирование, продуктовое проектирование и немного управление проектами.
Прочитал.
Скажи, а какого размера были описанные проекты?
В терминах потраченных человекочасов, размеров бюджета, временных рамок.
0>>Мой опыт говорит о том, что любая разработка с высокой степенью инновационности (т.е. когда не клепаем/внедряем n+1-ый вариант ранее реализованного продукта, а делаем что-то, чего раньше не делали) неизбежно несет в себе высокую степень риска и точно прогнозировать их в треугольнике "рамки-сроки-деньги" бесполезно. КЛ>В этом утверждении и заключается распространённая ошибка. Почему-то считается, что планы и оценки создаются для того, чтобы потом точно (тютелька в тютельку) в них вписаться. Это приводит к тому, что если какой-либо из планов не был выполнен или время выполнения какой-либо задачи не совпало с первоначальном эстимейтом, то план — сорван, а прогноз — в корне неверный. Планы и оценки делаются совсем для другой цели — для того, чтобы не потерять контроль над проектом. Конечно, самый оптимальный вариант — когда сроки и планы совпадают с реальными.
Понимаешь, бизнес-контекст проектов бывает очень разный. Где-то надо строго держать бюджет, но можно жертвовать рамками, где-то наоборот, а где-то фиксированы все показатели. Где-то допустимым считаются кратные отклонения от предыдущих оценок, где-то — проценты. Это твоё "почему-то считается" вытекает ровно из бизнес-контекста проекта. Так вот, переформулирую свой высказывание: я не знаю ни одной методики разработки, которая бы позволяла для инновационных проектов составить план с фиксированными рамками, сроками и бюджетами.
Здравствуйте, Кирилл Лебедев, Вы писали: КЛ>Здравствуйте, 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% работ проведенных на уровне составления ТЗ).
Здравствуйте, 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 и по бюджету во много раз)) Хотя делал "прототип" — прокопал там на два штыка сначала вдоль траншеи. Казалось все просто)))
Здравствуйте, mangaman, Вы писали:
m> Z> Ну, или траншею рыть — тоже всё известно.
m> Хахаха)) Вы траншей мало рыли)))) Вот бишь недавно у себя у дома — рою траншею под дренаж. Рыл-рыл -- бах, кирпичи закопаны Полдня выковыривал камни. Рою дальше — бах, твердущий слой неясно чего, типа известняка. День ломом ломал. Дальше ударил лопатой куда-то, сломал лопату. Поехал за лопатой — черенков нет. Купил через день. Прошли дожди — верхняя кромка начала оползать. Купил доски, укрепил стенки траншеи, чтобы не сползали. m> Даже у экскаваторщиков частенько проблемы
m> Итого, превышение по срокам раз в 10 и по бюджету во много раз)) Хотя делал "прототип" — прокопал там на два штыка сначала вдоль траншеи. Казалось все просто)))
Бесстрашный ты: кирпичами часто обкладывают опасные места типа силового кабеля или газовой трубы
Здравствуйте, Dziman, Вы писали:
D>Бесстрашный ты: кирпичами часто обкладывают опасные места типа силового кабеля или газовой трубы
Ха ха) Да не, там они колотые были и вразброс. И камни разные. На этом месте была какая-то старая хозпостройка раньше.
RGB>Вопрос — в какой момент этой диаграммы заказчик получит работающий продукт? Ответ: на этапе transition.
А почему весь продукт делается за одну такую итерацию? Product Delivery можно точно также разбить на циклы. Данный цикл (с выкидыванием всего ненужного) легко применим к фиче.
Здравствуйте, zfima, Вы писали:
Z>Знаю, что Канбан является гибким процессом с небольшим кол-вом ограничений.
Z>В Канбане не обязательны итерации.
Z>Т.е. — Канбан не итеративный? (Не Agile?)
Z>В чем подвох?
Канбан микроитеративный. При "работе по канбану" предполагется техническая возможность делать билд под конкретное изменение, по готовности. Современные билд-сервера и средства развертывания это умеют. Они мониторят изменения, и билдят непрерывно. Микроитерации — это последнее время модно, см. например http://en.wikipedia.org/wiki/DevOps
При этом, в некоторых платформах, например PHP, или с серверной логикой на Transact-SQL, все еще проще, так как билд отсутствует как технологическая процедура. Поэтому, понятие "итерации" по сути существует только в воображении, и делать деплоймент по готовности тупо проще. Собственно, наоборот — нет особых причин его не делать по готовности.
Полдня выковыривал камни. Рою дальше — бах, твердущий слой неясно чего, типа известняка. 
