Pull to refresh

Comments 27

вы будет четко следовать процессу выпечки, отмеряя каждую минуты и на выходе получите отличный пирог
Не факт, ох, не факт… :)

Кроме теории, как известно, ещё есть и практика, без которой с первого раза мало что получается хорошо как бы точно и подробно вы не следовали инструкциям
Согласен. Точно следовать всем инструкциям часто невозможно и даже вредно:
— не всегда есть под рукой именно те продукты, которые указаны в рецепте (типа укроп, собранный прошлым летом в южных районах Прованса);
— вы знаете, что ваша печка работает не так хорошо, как эталонная, потому время выпечки нужно увеличить;
— ваша жена/мама/дочь ненавидит соленое, потому соли нужно ложить существенно меньше
и т.д. и т.п.

Таких тонкостей полно как при выпечке, так и при разработке ПО :)
Я так и не понял, почему провалилось внедрие agile
Потому что многие «нарушают рецепт», иначе говоря начинают менять его с самого начала.
Agile — набор принципов. Корочка дложна быть хрустящей, внутреность должна быть сочной итп. Я вообще с трудом представляю ситуацию, когда agile удается зафейлить.
фейлят конкретные фреймворки типа скрама, нарушая его правила. что же касается agile — принципы нарушаются так же с легкостью, особенно про людей и про документацию.
В agile обязательно следовать всем принципам? Если следовать всем принципам нет необходимости, например, в случае начальник-программист в единственном числе?
Если scrum подписал agile, то это не означает, что scrum это agile. Это означает только то, что scrum поддерживает agile.
Agile, как мне кажется, в первую очередь, в голове. Я использовал agile до того, как и любая разумная философская мудрость, он был сформулирован. Если человек не способен к гибкости прпоцессов и мышления, то никакие частные рецепты ему не помогут, независимо от того, нарушены они или нет.
Так, мне видится, что описанная вами проблема не в рецептах, а в патологической неспособности конкретных человеков готовить. Agile — религия, невозможно следовать религии в корыстных целях без духовного совершенства.

Осталось привести правила Agile/Scrum/Kanban которые не нужно нарушать :)
Agile — это методология (даже философия, если угодно) и чтобы быть «agile» достаточно следовать манифесту и основным принципам.
Scrum и Canban — это методики с набором правил и артефактов, из которых желательно ничего не выбрасывать, особенно на этапе внедрения процесса (то самое «Shu»).

Все основные моменты по Scrum можно найти в чеклисте от ребят из ScrumTrek. Это и есть правила, которые нельзя нарушать.

С Kanban еще проще, правил всего 3:
— визуализировать процесс;
— ограничивать количество задач, находящихся в работе;
— измерять время цикла задачи и оптимизировать его.
Вот это чётко, ясно и по делу! Спасибо!
Все правильно.
Agile — набор ценностей из манифеста. Отследить их нарушение просто.
Scrum — каркас с известной классической схемой — отследить его нарушение еще проще.
Kanban — тоже игра с определенными правилами.

По факту при внедрении тех или иных инструментов мы привыкли внедрять их понемногу. Поробовали какую то часть — оценили результат — не понравилось — стали искать что то еще.

С эджайл методиками такое не прокатит. Все их составные части очень сильно повязаны друг на друга. Одно без другого не работает. Нужно внедрять классическую схему полностью. Именно так, как написано в умных книжках.
UFO just landed and posted this here
Хорошо бывает и без agile — нет же цели внедрять agile в каждый дом. Да и на самом деле альтернатив больше 3, так как есть определенные ситуации когда agile нужен, а есть — когда нет.
Что же касается «у нас не получилось внедрить agile, у нас и без него хорошо» — скорее всего так внедряли.
UFO just landed and posted this here
написание программы обработки энцефаллограмм — алгоритм известен, ui известен, пользователи известны. используем так называемые good practice и успешно выполняем проект.
UFO just landed and posted this here
Опять же, проекты для АЭС и прочие, где безопасность человека на 1 месте.
agile = fail fast. не очень хочется летать на таком самолете =)
«Fail Fast» — термин, который, если не ошибаюсь, уходит корнями как раз-таки в программирование.
Да, в управлении проектами тоже есть такое понятие, но ни в той, ни в другой области оно ни в коем случае не означает, что нужно создавать заведомо нерабочее решение.
И уж тем-более, на мой взгляд, нельзя ставить знак равенства между методологией и одним из подходов или концепций. Да и здравый смысл еще никто не отменял).
Это миф, или ошибочный вывод. Bdd, tdd не отменяются agile-ом. Agile не отменяет проектирование.
UFO just landed and posted this here
Понапридумывали мутоту разную. Agile, Scrum и пр.
Делали проекты всегда без этого. Собирали требования, писали ТЗ, общались, корректировали, тестировали. И все получалось замечательно.
Я понимаю, при проектировании АЭС, это может понадобиться. Но для интернет-прокетов нахрена они нужны? Разве что работодателю мозг пудрить и ЗП за знание методик выше требовать?
UFO just landed and posted this here
Допустим, у меня 2 программиста и дизайнер-верстальщик. Допустим, они делают проект по ТЗ за 6 месяцев. Проект получается не Г, а такой, что все хотят такой же.
Руководитель проекта постоянно контролирует план выполнения, совместно с программерами разбирает вопросы по ходу и возможно что-то меняется.
Что меняется? Либо в процессе придумывается более эффективная и интересная фича, либо программеры пытаются предложить вариант, с которым им будет меньше париться в ущерб первоначальной задумке.

Дорабатывать и совершенствовать проект в борьбе с конкурентами надо постоянно.

В чем экономия, если будет agile? Нужно будет потратить время и деньги на обучение всех участников проекта. Что получим в итоге? Ту же самую работу над проектом, но под модным названием agile?

UFO just landed and posted this here
Есть такая штука как Cynefin Framework
image
(http://en.wikipedia.org/wiki/Cynefin), он описывает взаимодействие в разных типах систем, и говорит о том как с ними взаимодействовать. Ну так вот, ваш тип это либо complicated ordered переходящий к simple ordered система в них не требуются подход, который используется в Agile. Там достаточно хорошо проанализировать и сделать, или откатегоризировать и сделать.
Так что вы полностью правы, в том что в этом случае (когда хотят похожее и 100 раз на дню — Agile не поможет).
Agile работает в зоне Complex систем, где причинно-следственные связи не очевидны пока вы не апробируете систему.
Sign up to leave a comment.