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 — тоже игра с определенными правилами.

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

С эджайл методиками такое не прокатит. Все их составные части очень сильно повязаны друг на друга. Одно без другого не работает. Нужно внедрять классическую схему полностью. Именно так, как написано в умных книжках.
Мне вот всегда интересно узнать что скрывается под «у нас не получилось внедрить agile, у нас и без него хорошо». Да что хорошо??? Хорошо без итераций? Хорошо не делать план на итерацию? Хорошо не получать фидбек от разработчиков и заказчика? Хорошо не показывать продукт заказчику в конце итараций, а свалить все в конце и будь что будет? ИМХО есть только 3 альтернативы: 1) полный бардак, 2) agile, 3) команда и заказчики гении, которые умеют все делать с первого раза (в существовании такого подхода на практике я сильно сомневаюсь).

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

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

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

>Руководитель проекта постоянно контролирует план выполнения, совместно с программерами разбирает вопросы по ходу и возможно что-то меняется.
Что меняется?

Видимо ничего, поздравляю, у вас и так agile :)

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