О бессилии Скрама, скрам-тулах и прочих штуках

Учитывая большой интересе участников прошедшего Скрам-клуба к вопросам, когда же стоит применять Scrum и когда нет, какие тулзы удобно применять в Скраме и другие предлагаю прорезюмировать дискуссии тут.

Были приведены примеры из банковской области, сферы Embeded разработки и еще ряд. Думаю вопросы и ответы будут интересны и тем участникам ДОУ, кто пропустил Фиесту в Леви9.

Итак, ваши мнения по вопросам: Если Скрам такой класный, то почему его нельзя применять везде? В каких случаях Скрам нельзя или неэффективно применять. Какие инструменты удобно использовать для удаленной команды разработки?и до кучи вопрос — будет ли эффект от QA который постоянно вариться в процессах команды? Или же QA должен быть полностью независим от всей возни и смотреть на проект беспристрастно?

До обраного В обраному 0

дополнительный вброс к холивару — возможен ли аджайл в нашем гос. образовании? или вотерфол давности так и будет литься на лекциях.

в нашем гос образовании и без того полно аджайла))) . что касается скрума, то применить его можно везде, в зависимости от того как вы идентифицируете процессы, как распределяете инструменты и время. Очень важно понимать глоссарий проекта и факторы определющие давление на Ваши команды. Есть масса аналитических приёмов позволяющих выявить, визуализировать и подать на блюдце все аспекты (ударение именно на слово аспекты) ваших проектов. Проблема внедрения Скрум заключается в попытке навязывания часто дополнительных стандартов (а ещё чаще выдумывние и поиск закономерностей) к изменениям проекта, от сюда болеют все, проджекты, разработчики, кушечки и т.п. Вопросы конечно актуальны, но в Ваших вопросах кроется та самая проблема.

дело не в скраме а в людях.если вы мдак — у вас что RUP что SCRAM что Canban будет у вас через жопу это касается как разработчиков так и клиентов и менеджеров

Скрам — это только фреймворк, и его успех зависит от выбранной реализации (например extreme programming). Многие упускают из вида необходимость детализации процесса. При формальном применении скрам может не только не решить проблемы процесса разработки, но и значительно увеличичить трудоемкость проекта.

ИМХО проще и эффективнее применять составляющие разных процессов (ежедневные митинги, детальная документация требований, итерации, дизайн архитектуры, автоматическое тестирование, . ) исходя из специфики проекта и четкого понимания целесообразности каждого метода. В первую очередь нужно учитывать наличие четких требований, их изменчивость и необходимость как можно скорее получить работающий продукт.

Для того чтобы внедрить scrum в чистом виде, нужно как минимум знать как это делать. У нас пока это выглядит так — прочел книгу 16 страниц www.facebook.com/. pdf&h=GAQHpfa6m и знают про Scrum все. А когда приглашаешь этого знатока в компанию, чтобы он что-то сделал. Щеки раздует как индую, и начинает чушь молоть. Я чтобы найти классного Scrum Master не одно собеседование провел. Ну вот нашел, доволен результатами.

Даешь скрамосрач!) Разные методологии хороши на разных проектах, если серьезно (ваш кэп), о чем уже было сказано много раз.

Откуда такая любовь у многих манагеров к скраму — хз. Может потому, что заказчики это любят — им показывают красивые картинки, графики, говорят страшные умные слова вроде «скрам, митинг, дейли митинг, итерация, аджайл», устраивают презентации и со стороны заказчика это выглядит убедительно — процесс идет! Хотя на самом деле вся эта движуха может тормозить процесс.

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

скрам и прочие аджайлы — просто модная фишка. Когда то модным был RUP и рисование проекта в UML. Завтра вместо скрамов придумают что то еще. Поэтому не стоит парится — качество ПО никак от этого не зависит. Качество ПО 15 лет назад ничем не лучше и не хуже нынешнего скрамовского.

Энти самые евангелисты втирают про мамочек с бульдозерами и пасуют, когда спрашиваешь, а «зачем это все?».

Долго пытался понять, просветление возникло только после изложения нормальным лектором теории en.wikipedia.org/wiki/Cynefin

и алгоритма:Obvious => WaterfallComplicated => RUP Complex => Agile

Я вам так скажу. По опыту работы. Крупный энтерпрайз. Проекты 1+ год (как правило 2+ на самом деле), команды большие 100+ человек.Есть несколько типов проектов в моей истории, если очень грубо обобщить.1. Мы делаем всю техническую часть полностью сами, объясняя клиенту как ему надо строить процессы и корректируя общую картину мира под его требования. 2. Клиент хочет лезть в техническую и организационную часть, делаются смешанные команды, работаем на благо общества по гибким методологиям.

Так вот, первый тип проектов делается по водопаду с некими итерациями, т.е. собираем требования, потом немного думаем, подписываем доки и начинаем вкалывать. Если меняются требования — тащим это через Change Management или еще как, в результате проект героическими усилиями делается, выходит в прод, клиент счастлив.

Второй тип проектов делается с привлечением внешних консультантов со стороны заказчика, аджайл, юнит тесты, ретроспективы, стандарты индустрии, все дела. Так вот это продолжается от года до нескольких лет (без выходов в продакшн), с постоянным перепиливанием солюшена, сдвигом сроков, изменениями концепций, невероятными человеко-годами закопанными в 80% покрытие кода и поддержку «красивой» статистики в статических анализаторах кода и так далее.

Пока ребята строгают проект за проектом выходя в продакшн (со слезами и мучениями, но тем не менее выходя) и потом быстро доводя солюшн до идеального, апологеты аджайла все продолжают делать истории в джире и смотреть на барнаут чарты. В результате клиенту это надоедает, он переходит на фикс прайс, увольняет дорогих консультантов и мы идем по первому пути.

Не буду спорить что вероятно тут и заказчик не тот, и консультанты плохие да и программисты с менеджерами не те — все может быть и я не спорю что агиле наверное хорош для кучки хипстерков ежедневно читающих HN и другие вещи и находящихся в струе. Но в моем случае за около 10ка лет работы я так и не увидел как агиле взлетел бы в чистом виде. Взлетает вджобывание от забора и до обеда и команда нацеленная на результат.