Поработав некоторое время с руководством, которое было приверженцем канбана, я написал такую заметку. Вот она:
У меня складывается впечатление, что модные словечки типа "аджайл", "скрам", "канбан", "гибкие методологии" постепенно становятся ругательными в профессиональной среде. У такого положения вещей есть несколько объективных причин:
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-ый вариант ранее реализованного продукта, а делаем что-то, чего раньше не делали) неизбежно несет в себе высокую степень риска и точно прогнозировать их в треугольнике "рамки-сроки-деньги" бесполезно. КЛ>В этом утверждении и заключается распространённая ошибка. Почему-то считается, что планы и оценки создаются для того, чтобы потом точно (тютелька в тютельку) в них вписаться. Это приводит к тому, что если какой-либо из планов не был выполнен или время выполнения какой-либо задачи не совпало с первоначальном эстимейтом, то план — сорван, а прогноз — в корне неверный. Планы и оценки делаются совсем для другой цели — для того, чтобы не потерять контроль над проектом. Конечно, самый оптимальный вариант — когда сроки и планы совпадают с реальными.
Понимаешь, бизнес-контекст проектов бывает очень разный. Где-то надо строго держать бюджет, но можно жертвовать рамками, где-то наоборот, а где-то фиксированы все показатели. Где-то допустимым считаются кратные отклонения от предыдущих оценок, где-то — проценты. Это твоё "почему-то считается" вытекает ровно из бизнес-контекста проекта. Так вот, переформулирую свой высказывание: я не знаю ни одной методики разработки, которая бы позволяла для инновационных проектов составить план с фиксированными рамками, сроками и бюджетами.
