Работать по agile, отталкиваясь от высокоуровневых KPI — удобно, практично и эффективно.
И если вам такой подход не дают применять ваши забюрократизированные структуры руководства, то, согласитесь, это вина этих структур, а не подхода.
Значит надо пытаться донести выгоду и преимущества работы по agile до руководства и менять культуру организации (кстати инструментов для этого в Agile тоже предостаточно)
«Проект бюджета» — это всё-таки не «проект внедрения») хоть слова и похожи.
Agile это всё-таки инструмент организации взаимодействия людей. Но если вы хотите организовать обширное согласование «проекта бюджета», то эту деятельность можно построить в духе Agile. Работа короткими итерациями никак не станет причиной «попилим бюджет».
Концептуально в рамках контекста — это одно и тоже, если в финальном варианте продукт подразумевается как набор сложных функций, но его построение можно строить на базе MVP.
Нет, ну ROI можно посчитать без детального графика проекта с таким же уровнем точности, как и без оного. И в том и в том случае точность будет не идеальна, но в случае если ROI расчитан на базе графика проекта, то тот становится практически отлитым в граните и потом начинается подгонялово проектных решений под график а не наоборот.
Комментарий пользователя dralexnone к публикации «График проекта vs Бэклог: битва без шансов» ожидает вашего одобрения:
Очередная утопия. Agile очень хорош для доработок в рамках уже работающего решения. Попробуйте построить Новый дом без плана-проекта-графика или корабль. У Agile есть множество недостатков и два принципиальных:1) c помощью мелких итераций и короткого планирования невозможно избежать архитектурных и концептуальных ошибок 2) невозможно приемлемо оценить бюджет проекта из-за плохой оценки рисков и наполнения бэклога.
Поэтому стартовый грамотный концепт — обязателен, учет архитектурных рисков — также. Классический пример: не учли целевой объем данных и прекрасный по «фичам» проект «не взлетел» из-за бесконечных задержек и блокировок… Переписывать придется с нуля. И таких примеров десятки — любой сложный проект с «нуля» попадает в эту категорию.
И опять таки не будем путать проект как организацию и проект как дизайн. Дизайн концепт сложной технологической системы должен быть разработан с учётом всех рисков, но опять же любой сложный концепт — это набор фич или функций, так что вопрос в грамотной декомпозиции и всё.
Как говорится, Agile — это инструмент, требующий правильного и разумного применения. И будучи примененным с умом, он становится универсальным
Это классно, когда работаешь с обязательными и организованными людьми. Проблема в том, что характер некоторых проектов такой, что условия и требования к продукту проекта могут постоянно изменяться в ходе проекта, а в такой среде обстоятельность финнов и прибалтов может стать тем фактором, что всё погубит.
К сожалению надвигающаяся цифровизация делает режим электровеника всё более актуальным для всех отраслей и типов проектов
Если менеджер не поддерживает вашу тягу к улучшениям, то внедрять улцчшения становится максимально тяжело. Хотя и не невозможно, так что вопрос сложный
Стены, как пример)
Если стены пофиг, то нафиг стены! Можно их тупо снести, мы так делали на некоторых проектах — реально брали в руки молотки и крушили) ит воз фан)
Главное чтобы команда наконец захотела что-нибудь улучшить и начала улучшать. Смысл в том, что если трудно сразу определить, что нужно улучшить в работе, можно попрактиковаться на простых бытовых вещах.
1) если команда не хочет ничего менять, внедрять Agile невозможно. Нужно либо сворачивать попытки, либо поставить команду в ситуацию, когда перемены неотвратимы — речь о более challenging KPIs
2) можно же и в этом "вечном" проекте улучшать свой перформанс постоянно — пилить фичи быстрее, пилить фичи надежнее и более оттестированные, креативить или, например, добавить "ВАУ-фактор".
Весь смысл чтобы команда увидела себя как отдельный стартап — пусть предложат что они могут делать для клиента лучше и что они хотят получить за это от менеджмента, сформулировать и вперёд — добиваться с помощью Agile.
Пока нет реальной потребности улучшаться, Agile не нужен
Это отличная возможность для скрам-мастера и продукт оунера начать "eliminate impediments" — устранять внешние препятствтя.
Тут может быть куча инструментов задействлвано, один из них — совместная ретроспектива
Если за спринт ничего не меняется, значит работа выстроена неправильно. Если вы правильно определили цели саморазвития для каждого члена команды, то у него стояли задачи на эту неделю по улучшению. Если команда просто каждый спринт делает одно и то же, а именно рутинную работу, тем способом, которым они делалт её всегда то смысла в ретроспективах нет не то что в еженедельных, а вообще.
Ретроспектива уместна только там где у команды есть чёткие цели по непрерывному улучшению.
Если их нет то надо начать со стратегической ретро (необязательно называть её "ретроспективой"), определить, хочет ли команда развиваться, если да, то куда и как.
Если команда развиваться не хочет, значит надо сворачивать Agile и увольнять скрам-мастера, потому что тогда он не нужен
Серые кардиналы на то и серые, что никто не знает, что они кардиналы, и если цели манипулируемой команды и талантливого манипулятора совпадают, то выигрывают все)
Если нет глупых вопросов и ответов — это серьёзно. А если это серьёзно, то это не уже игра.
Я имел в виду, что можно задавать глупые вопросы — хороший фасилитатор найдёт способ превратить их в умные.
Перед командой стоит цель закончить этот грёбаный проект. Но эта цель не стоит перед скрам-мастером и он не хочет о ней слышать. Он хочет тратить время команды на то, чтобы рисовать цветочки на доске и включать музыку из порно-роликов.
Если цель «закончить грёбаный проект» не стоит перед скрам-мастерм — это плохой скрам-мастер. Именно поэтому появляются плохие скучные ретро, когда скрам-мастер делает Agile ради аджайла. Целью скрам мастера должно быть: а) Помочь команде быстрее доделать «этот гребаный проект». б) Сделать это так, чтобы в процессе команда научилась доделывать эти гребаные проекты быстрее и качественне, чем раньше.
Если с ноутбуком приходить — это не ретро)
Я понимаю вашу реакцию. Если не видно пользы — то действительно возникает ощущение, что «лезут в душу» и не дают работать. Именно поэтому скрам-мастер должен знать ЧТО делает, а главное ЗАЧЕМ.
Не нужно говорить «мы внедряем Agile» — можно всё это делать под любым другим соусом — «эффективность, развитие и т.д.». Главное, чтобы вы понимали, чего вы хотите достичь и куда планируете двигаться. К сожалению, неправильным Agile-ом отбить вкус к нему можно очень сильно. Я бы рекомендовал сконцентрироваться на коротких быстрых улучшениях и развивать внедрение на волне энтузиазма от успехов
И если вам такой подход не дают применять ваши забюрократизированные структуры руководства, то, согласитесь, это вина этих структур, а не подхода.
Значит надо пытаться донести выгоду и преимущества работы по agile до руководства и менять культуру организации (кстати инструментов для этого в Agile тоже предостаточно)
Agile это всё-таки инструмент организации взаимодействия людей. Но если вы хотите организовать обширное согласование «проекта бюджета», то эту деятельность можно построить в духе Agile. Работа короткими итерациями никак не станет причиной «попилим бюджет».
НУ или вы как-то неправильно понимаете Agile
Аминь!
Концептуально в рамках контекста — это одно и тоже, если в финальном варианте продукт подразумевается как набор сложных функций, но его построение можно строить на базе MVP.
Но вообще это разные понятия, согласен.
И опять таки не будем путать проект как организацию и проект как дизайн. Дизайн концепт сложной технологической системы должен быть разработан с учётом всех рисков, но опять же любой сложный концепт — это набор фич или функций, так что вопрос в грамотной декомпозиции и всё.
Как говорится, Agile — это инструмент, требующий правильного и разумного применения. И будучи примененным с умом, он становится универсальным
К сожалению надвигающаяся цифровизация делает режим электровеника всё более актуальным для всех отраслей и типов проектов
Хотелось добавить образности
Если менеджер не поддерживает вашу тягу к улучшениям, то внедрять улцчшения становится максимально тяжело. Хотя и не невозможно, так что вопрос сложный
Стены, как пример)
Если стены пофиг, то нафиг стены! Можно их тупо снести, мы так делали на некоторых проектах — реально брали в руки молотки и крушили) ит воз фан)
Главное чтобы команда наконец захотела что-нибудь улучшить и начала улучшать. Смысл в том, что если трудно сразу определить, что нужно улучшить в работе, можно попрактиковаться на простых бытовых вещах.
1) если команда не хочет ничего менять, внедрять Agile невозможно. Нужно либо сворачивать попытки, либо поставить команду в ситуацию, когда перемены неотвратимы — речь о более challenging KPIs
2) можно же и в этом "вечном" проекте улучшать свой перформанс постоянно — пилить фичи быстрее, пилить фичи надежнее и более оттестированные, креативить или, например, добавить "ВАУ-фактор".
Весь смысл чтобы команда увидела себя как отдельный стартап — пусть предложат что они могут делать для клиента лучше и что они хотят получить за это от менеджмента, сформулировать и вперёд — добиваться с помощью Agile.
Пока нет реальной потребности улучшаться, Agile не нужен
Это отличная возможность для скрам-мастера и продукт оунера начать "eliminate impediments" — устранять внешние препятствтя.
Тут может быть куча инструментов задействлвано, один из них — совместная ретроспектива
Если за спринт ничего не меняется, значит работа выстроена неправильно. Если вы правильно определили цели саморазвития для каждого члена команды, то у него стояли задачи на эту неделю по улучшению. Если команда просто каждый спринт делает одно и то же, а именно рутинную работу, тем способом, которым они делалт её всегда то смысла в ретроспективах нет не то что в еженедельных, а вообще.
Ретроспектива уместна только там где у команды есть чёткие цели по непрерывному улучшению.
Если их нет то надо начать со стратегической ретро (необязательно называть её "ретроспективой"), определить, хочет ли команда развиваться, если да, то куда и как.
Если команда развиваться не хочет, значит надо сворачивать Agile и увольнять скрам-мастера, потому что тогда он не нужен
Именно про это статья :)
Я имел в виду, что можно задавать глупые вопросы — хороший фасилитатор найдёт способ превратить их в умные.
Если цель «закончить грёбаный проект» не стоит перед скрам-мастерм — это плохой скрам-мастер. Именно поэтому появляются плохие скучные ретро, когда скрам-мастер делает Agile ради аджайла. Целью скрам мастера должно быть: а) Помочь команде быстрее доделать «этот гребаный проект». б) Сделать это так, чтобы в процессе команда научилась доделывать эти гребаные проекты быстрее и качественне, чем раньше.
Иначе всё зря
Я понимаю вашу реакцию. Если не видно пользы — то действительно возникает ощущение, что «лезут в душу» и не дают работать. Именно поэтому скрам-мастер должен знать ЧТО делает, а главное ЗАЧЕМ.