Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

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

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

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

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

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

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

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

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

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

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

Например, вот чего пишет Мартин Фаулер.
www.maxkir.com/...thRUS.html#N885

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

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

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

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

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

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

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

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

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

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

Такие дела, тру стори и я не тролль.

юнит тесты
Ну ладно не надо совсем смешивать. )) Есть конкретные практики чисто технические — увеличивают производительность чисто техническую самих программистов как процесс уже чисто технический без привлечения клиента и даже продукта.
делаются смешанные команды
Скорее всего проблема в том, что скрам для распределенных команд не самая простая штука. И уж точно такой проект для пилотного (в качестве «попробовать» скрам) не годится.
Но в моем случае за около 10ка лет работы я так и не увидел как агиле взлетел бы в чистом виде.
Для начала неплохо было бы разобраться, что такое «agile в чистом виде». Насколько я понимаю, то ваш водопад с итерациями был достаточно agile :)

Я видел вполне работающие по скраму проекты. Это продуктовые компании в основном со стабильными тимами. Вообще, основная проблема внедрения скрама — это преодоление сопротивления людей.

основная проблема внедрения скрама — это преодоление сопротивления людей
#totalfacepalm

Вот мы и подошли к идее «внедрения скрама как карго-культу».

Вот мы и подошли к идее «внедрения скрама как карго-культу».
Дома книжка по Скраму валяется — там половина страница об этом.
Притом такие методы предлагаются, что после прочтения хочется вымыть глаза. Например, манипулируя пассивным большинством, которому пофиг скрам-нескрам, выставить недовольных отщепенцами, спровоцировать на конфликт и задавить. Я думаю по таким книгам вполне б могли учиться секретари всяких комсомольских и партийных организаций.

«Scrum-of-Scrums уровня продукта
...
На самом деле повестка дня Scrum-of-Scrums не так уж и важна — важнее, чтобы эта встреча проводилась регулярно.»
— Хенрик Книберг

Видел другие тру стори с параличом анализа и по пишущеемуся по нескольку лет ядру.
Когда перешли на скрам с выкатыванием несовершенной, но более или менее готовой функциональности — клиент стал довольный.

Так что зло не в скраме, а поваре, который его готовит.

Видел другие тру стори с параличом анализа и по пишущеемуся по нескольку лет ядру.
И такое бывало :)
Так что зло не в скраме, а поваре, который его готовит.
Конечно. Мой пост действительно о том что поваров хороших я не видел :) Хотя дипломы кулинарного училища у них были.

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

Второсортные IT компании это лидеры рынка например и зарабатывают бешеные миллионы бабла :)

чёт давно не придумывали новых карго- культов.

Скрам — великолепный способ избежать ответственности и создать ИБД.

Два эпика этому господину. Методология «чик-чик и в продакшен» — наше все.

Если Скрам такой класный, то почему его нельзя применять везде? В каких случаях Скрам нельзя или неэффективно применять.
1. Плохо применять для больших долгоживущих проектов. В этом случае нежелание писать документацию обернётся большими проблемами, когда:
а). Придёт время поменять «воон тот кусок ядра, который был написан лет 5 назад человеком, который давно свалил». Тогда задача, выполнение которой заняло бы 2..3 дня, займёт 3 недели с полным переписыванием кода + ещё 5..6 недель на багфикс регрессии в самых неожиданных местах, если этот кусок много где используется в downstream системах.
б). Необходимо будет написать большие user guides для конечных пользователей (например, Navision, Axapta). Полное отсутствие адекватной документации приведёт к тому, что НИКТО не будет понимать, как именно конкретная фича работает (зачастую это самое «как» заметно отличается от того, что написано в user stories). Соответственно, техрайтеры будут тратить время программеров на то, чтобы те объяснили, как это работает. В большинстве случаев, объяснение будет находиться с помощью дебага исходного кода.
2. Проекты с высокой ответственностью (медицина, авиация, космонавтика). Там, где баг на продакшене обернётся не баблом, а человеческими жизнями.
3. Там, где роадмап расписан на месяцы (или даже годы) вперёд. В отличие от 1 или 2, применить-то можно, но эффективность по сравнению с waterfall’ом будет заметно ниже.
и до кучи вопрос — будет ли эффект от QA который постоянно вариться в процессах команды? Или же QA должен быть полностью независим от всей возни и смотреть на проект беспристрастно?
Вопрос поставлен некорректно.
Уточняющий вопрос: кто такой этот QA? Какая у него роль? За что он отвечает?
нежелание писать документацию обернётся большими проблемами

Почему вы считаете, что скрам в обязательном порядке отменяет любую документацию? Это заблуждение. Гибкие методологии делают упор на читабельный, хорошо документированный код с тестами (которые также будут выполнять роль документации). К тому же, никто не запрещает писать отдельную от кода документацию, описывающую какие-то нетривиальные решения в проекте.

задача, выполнение которой заняло бы 2..3 дня, займёт 3 недели с полным переписыванием кода + ещё 5..6 недель на багфикс регрессии в самых неожиданных местах, если этот кусок много где используется в downstream системах.

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

Необходимо будет написать большие user guides

Процесс итеративный, пишите user guides учитывая этот аспект (т.е. после каждой итерации, а не спустя годы). В чем проблема-то?

Проекты с высокой ответственностью

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

Почему вы считаете, что скрам в обязательном порядке отменяет любую документацию? Это заблуждение.
Я в курсе :) Говорю не с точки зрения теории, а с точки зрения практики. Есть несколько моментов.
1. Самый главный. Программисты НЕ ЛЮБЯТ писАть документацию. И при любой возможности съехать этим воспользуются.
2. Приоритезация задач построена обычно так, чтобы документирование (если оно вообще входит в backlog, хехе :) ) стояло на последнем месте. Работающая фича важнее документации — часть agile manifesto. Поэтому, если времени на фичу мало (а его всегда мало :) ) - лишнее время, если фича внезапно делается быстрее графика, тратится на прикручивание новых свистелок, перделок, рефакторинг, тестирование — но не на документирование. Естессно, можно потребовать, чтобы незадокументированная фича не маркировалась сданной — но сколько по скраму не работал, такого не видел.
Гибкие методологии делают упор на читабельный, хорошо документированный код с тестами (которые также будут выполнять роль документации).
Круто. Теперь скажите, плз, как техрайтеру в этом разобраться? Для справок, техрайтер — это обычно девочка, имеющая филологическое образование, в задачи которой входит написать тот самый user guide на хорошем инглише. Не более. То есть, лезть в код она не будет просто потому, что это в её задачи не входит. Зато в её задачи входит взять какой-нить документ типа feature overview, функциональных требований в др., связать их в единое целое, добавить скриншотов и написать это так, чтобы бизнес-пользователь, знающий только «левый клик мыши, правый клик мыши, двойной клик мыши», прочитав этот гайд, понял, что нужно сделать в программе, чтобы получить желаемый результат.
Собссно, имеем то, что я описал выше. Скрам не годится для сложных проектов, требующих большого количества разнообразной документации.
В данном конкретном примере проблема обусловлена плохим кодом, но никак не методологией.
Не обязательно. Код может быть просто прекрасным. Но отсутствие адекватной документации для долгоживущих проектов приводит к утрате знаний о отдельных фичах и их взаимосвязи вследствие миграции людей, эти фичи разрабатывавших. Чтобы понять суть проблемы, предложу некоторую вымышленную ситуацию.
Пусть, скажем, мы разрабатываем 1С (Navision и Axapta, которые я приводил в примере выше, намного сложнее, но не суть). И вот приходит лид и говорит: «у клиента Васи возникла проблема. Значение супер-пупер налога при подсчёте его в 1-ю фазу луны считается неправильно. Да, я в курсе, что эту фичу последний раз модифицировали 5 лет назад, но ему очень надо».
Глубокий дебаг на n-ный день обнаруживает, что виновата некая переменная ядра, которая переполняется из-за выросшего курса рубля к зимбабвийскому доллару. Решение: расширить её, например, из string[50] до string[70]. Теперь внимание, вопрос: имея из документации только user stories, сколько связанных изменений провтыкается в фичах, использующих данную переменную?
Это я ещё привёл сравнительно лёгкий случай. Более интересный вариант, например, изменить что-нить в логике ядра, например, добавить деление на дополнительную переменную при расчёте.
Или, как вариант, такая задачка: оптимизировать производительность компоненты, последний раз изменённой те же 5 лет назад. Причина оптимизации: количество записей за 10 лет эксплуатации системы превысило расчётное и теперь компонента не справляется с их обработкой в заложенное в NFRs время. Я почти уверен, что компонента будет переписана заново.
Программисты НЕ ЛЮБЯТ писАть документацию.
Сделайте требование документирования кода частью DoD. Также введите механизм ревью кода, который выявит несоответствия DoD.
Естессно, можно потребовать, чтобы незадокументированная фича не маркировалась сданной — но сколько по скраму не работал, такого не видел.
Именно так и надо делать.
Теперь скажите, плз, как техрайтеру в этом разобраться? Для справок, техрайтер — это обычно девочка, имеющая филологическое образование
Здесь речь шла о технической документации, она не предназначена для девочки техрайтера. Девочка техрайтер будет писать документацию по каждой фиче исходя из содержимого user story (в которой будут достаточно четкие acceptance criteria).
Код может быть просто прекрасным. Но отсутствие адекватной документации для долгоживущих проектов приводит к утрате знаний о отдельных фичах
Ваш пример это не проблема методологии, а проблема отсутствия документации. Повторюсь — скрам не отменяет документирование. Кто ж вам виноват, что вы не пишете документацию?
хорошо документированный код с тестами (которые также будут выполнять роль документации)
Это бред.
Итеративные процессы подразумевают постоянный рефакторинг и ненакопление архитектурного долга, чтобы потом не было необходимости делать полное переписывание.
За чей счет этот банкет? Полностью переводится в то, о чем я сразу написал: «подразумевают непрерывную продажу заказчику непрерывных часов разработки с видимостью деятельности путем направленности на создание утовлетворенности личной самого заказчика».

Просто идеально сформулировал

Это бред.
Что именно в процитированном тексте вы считаете бредом? То, что код надо документировать или тот факт, что тесты являются своего рода документацией к коду, т.к. описывают различные варианты использования и ожидания к результату?
подразумевают непрерывную продажу заказчику непрерывных часов разработки с видимостью деятельности путем направленности на создание утовлетворенности личной самого заказчика
Это какая-то демагогия, даже комментировать что-то сложно. Но, попробую:

1. Удовлетворенность «заказчика» (взял в кавычки, потому что тут все обычно сложнее, чем просто один человек) важна в любой методолгии.

2. Что такое непрерывная продажа и непрерывные часы я не знаю.

3. Скрам ориентирован на результат, если вы считаете обратное, то вы залуждаетесь.

1. Плохо применять для больших долгоживущих проектов.
В большом проекте есть минипроекты, там — возможно и эффективно, ибо дисциплинирует.

OpenUP видится разумным компромиссом

Скрам это самое мерзкое что могло случиться с аджайлом и все же случилось. Все уже забыли о каких ценностях было написанно в agile manifest, зато расплодилось много бесполезных идиотов под названием скрам мастера и аджайл коучи.
Все забыли о том что, agile это в первую очередь хорошие практики, стремление к самосовершенствованию, постоянная производительность, continuous deployment, а не стори поинты, скрам мастера, митинги, ретроспективы и код фриз в четверг.

Вообще, какой-идиот вообще придумал код-фриз? Продукт должен быть готов к деплою после каждого коммита, это бизнес-решение, а не часть процесса.

В общем, хочу напомнить всем ИТТ, что аджайл придуман программистами для программистов, а не менеджерами, и за ним стоят вполне определенные ценности. И эти ценности гораздо важнее Великого и Ужасного Процесса Который Никто Не Сможет Наладить Без Сертифицированного Скрам Масетра.

p.s. Если команде нужно время на «стабилизацию кода», в не-легаси проекте, то ее техлид просто некомпетентный идиот.

Продукт должен быть готов к деплою после каждого коммита, это бизнес-решение, а не часть процесса.
воу-воу. запускать регрессионное тестирование на каждый пук? или автотесты со 100% покрытием — обязательно для agile’a? кодфриз касается мерджа в какую-то «основную ветку», а не произвольных коммитов в ответвления.
в не-легаси проекте
BTW в какой момент проект становится «легаси». два года норм возраст? или надо подождать до 2.5? just asking
запускать регрессионное тестирование на каждый пук?
Если у проекта хорошая архитектура, то можно будет вносить изменения не боясь что в другой части проекта что-то упадет. Соотвественно scope тестирования очень сильно сужается.
BTW в какой момент проект становится «легаси». два года норм возраст? или надо подождать до 2.5? just asking
Когда сложность проекта начинает рости не линейно, а экспоненциально, тогда уже можно считать легаси. По личному опыту знаю проекты которые становятся «легаси» уже через полгода.
Вообще, какой-идиот вообще придумал код-фриз? Продукт должен быть готов к деплою после каждого коммита, это бизнес-решение, а не часть процесса.
Расскажите это разработчикам ПО в аэрокосмической индустрии (например).

Рарзработчики ПО в NASA вообще не знают что такое SCRUM, а работают по ватерфолу, с спецификациями и design by contract.

Кто здесь вообще говорил про NASA? Индустрия на NASA не заканчивается, в мире есть великое множество мелких и средних фирм, занятых в аэрокосмической индустрии. Все они waterflow используют? Нет конечно.

Вообще, какой-идиот вообще придумал код-фриз? Продукт должен быть готов к деплою после каждого коммита, это бизнес-решение, а не часть процесса.
Какой идиот придумал код-фриз? А какой идиот решил, что продукт должен быть готов к деплою после каждого коммита?

Только идиот запускает в космос продукт который не готов после каждого коммита.

Да, это действительно весомый аргумент.

А какой идиот решил, что продукт должен быть готов к деплою после каждого коммита?
Кент Бек.
Кент Бек.
Argumentum ad verecundiam.

а зачем вообще коммитить в такой стратегии? Держите «это» при себе.

Но хардкорным Agile тем, не менее не обделены.
ru.wikipedia.org/....BD.D0.B8.D0.B5

какойто странный вброс.

Продукт должен быть готов к деплою после каждого коммита, это бизнес-решение, а не часть процесса.

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

Так что нужны и другие виды тестирования.
Стремиться, конечно, надо к тому, чтобы хорошо всё было после каждого комита, но и помнить надо, что это невозможно.

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

Также скрам мало подходит для проектов, где поток идет только поток мелких задач (например от customer service) — в этом случае правильнее делать kanban.

Ну а в целом, скрам подходит тем, кто готов его пробовать и работать над ошибками.

или крупный проект
Скрам не масштабируется. Предел — пару десятков человек единой команды.

Пару десятков для команды в скраме — это очень много. Канонический предел 7 ± 2. Скрам масштабируется через scrum of scrums (дробление на команды), что возможно практически в любом крупном проекте.

Конечно. В теории. Scrum of Scrums of Scrums of ...

Ирония понятна, но хотелось бы уточнить, вы сейчас пишете о своем опыте или ОБС?

А зачем? Зачем — мне?

Видел я Scrum of Scrums как с позиции рядового синьера, так и с позиции тим.лида (это было в разных компаниях). Так вот более бесполезного способа про***ть время, придумать сложно.

Так вот более бесполезного способа про***ть время, придумать сложно.

Вынесло мозг. Конечно, понял, что хотели сказать.

Вот со всем согласен в вашем посте, кроме этого:
«Иначе — водопад»

Есть же масса других итеративно-инкрементальных методологий, которые подходят проектам с более стабильными требованиями. Но водопад, который рекомендовал НЕ применять еще в 1970х годах Уокер Ройс...

Если углублятся в тонкости, то конечно же выбор методологии для проекта не настолько прост, поэтому я согласен с замечанием.

Но я не случайно указал здесь именно водопад. Он неитеративен, а все его усовершенствования как раз строятся вокруг появления итераций. Цель итераций — уменьшение рисков планирования и ошибок архитектуры. И здесь — пересечение со скрамом, а я не хотел «смазать» сравнение.

еще раз повторю, OpenUP видится разумным компромиссом

Да, или Disciplined Agile Delivery, который, собственно, очень многое унаследовал из OpenUP

ОК, принимается в качестве своеобразного литературного приема :)

Собственно, своим комментарием я больше преследовал цель донести до остальных читателей, что кроме Скрама и водопада существует еще множество опций. По личным наблюдениям, немало вполне грамотных менеджеров проектов, к сожалению, обладают именно таким «черно-белым» видением :(

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

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

Не бывает лекарства от всех болезней. Скрам не панацея, а метод

Если молоток такой хороший инструмент, почему я не могу менять им лампочки?

хорошая аналогия. осталось выяснить где в айти-проектах встречаются лампочки и донести до скрам-гуру что аджайл — это молоток

Реально опытные ребята как раз и не тулят его везде. Видимо, с окружением/менеджментом не повезло

Есть разные задачи. Задача скрама — продавать клиенту его удовлетворение. Всё.

а waterfall предполагает злого клиента, связанного контрактом, давно устаревшие требования и уже полгода как нерабочий продукт(бо наполовину написан)?
а если серьезно, какая методология предлагает забить на потребности бизнеса и их изменения?
agile ставит гибкость во главе списка, но и остальные методологии «продают клиенту удовлетворение», пускай, и в других позах

а если серьезно, какая методология предлагает забить на потребности бизнеса и их изменения?
Неправильный подход. Не «забить», а «определить и зафиксировать их на фазе планирования». Есть определённые бизнесы, у которых цикл производства весьма мало зависит от изменений рынка. Например, авиация, медицина, космонавтика, ядерные программы, военная промышленность. К примеру, цикл производства новой модели «Боинга» занимает 10..15 лет. Соответственно, мы знаем, что мы хотим получить на выходе заранее и спокойно его разрабатываем. И отвлекаться на новую рюшечку, скорее всего, никто не будет: риск падения самолёта стоимостью несколько сотен лямов + гибели сотен людей несоизмерим с возможной прибылью от продажи запиленной в последний момент новой рюшечки.
Есть определённые бизнесы, у которых цикл производства весьма мало зависит от изменений рынка.
на этом этапе я подумал, что речь идет об автоматизации производства.
Соответственно, мы знаем, что мы хотим получить на выходе заранее и спокойно его разрабатываем.
а тут уже понял, что о другом речь.
касательно приведенных примеров не буду спорить, так как согласен.
можете обобщить признаки для указанной ниши? чтоб определить область неприменимость СКРАМа?

Попробую.
1. Изменения в первоначальный проект вносятся нечасто -> скрам неэффективен.
2. Проект требует большого количества разнообразной документации на всех уровнях -> скрам неэффективен.
3. Проект требует мега-тщательного тестирования (когда время на тестирование = 3X от времени разработки) -> скрам неэффективен и с трудом применим.
4. Проект с высоким уровнем ответственности -> скрам неприменим.

1. Изменения в первоначальный проект вносятся нечасто -> скрам неэффективен.
Если проект не совсем в области текущей компетенции команды, то изменения дизайне будут возникать и без изменения исходных требований.
предлагает забить на потребности бизнеса и их изменения?
Что вы знаете о потребностях бизнеса и об их изменениях?

это, типа, вопрос с подвохом?
в общем случае — ни хрена.
в некоторых случаях, в зависимости от доменной области, поболее «владельца бизнеса».
шо дальше?

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

Підписатись на коментарі