Розробка · 23 січня 2015, 13:55 4303

Виталий Годзевич, fullstack developer в UECTech

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

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

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

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

Теми: Agile, Scrum

👍ПодобаєтьсяСподобалось0

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

Facebook

Twitter

LinkedIn

Ctrl + Enter

Ctrl + Enter

Виталий Годзевич 01.03.2015 01:40

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

Відповісти

Підтримати

Vitaliy Dzyuba Project Manager, Business System Developer 07.03.2015 01:57

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

Відповісти

Підтримати

Виталий Годзевич

Нестор Иванович 26.01.2015 21:58

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

Відповісти

Підтримати

Andriy Kurhanevych Працює в GIS Art 26.01.2015 13:56

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

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

Відповісти

Підтримати

Мыкола Гайка 26.01.2015 13:29

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

Відповісти

Підтримати

Анастасия Л 26.01.2015 12:07

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

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

Відповісти

Підтримати

Sergii Surskykh Software Engineer 26.01.2015 10:52

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

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

Відповісти

Підтримати

Леонид Украинский 25.01.2015 23:07

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

Відповісти

Підтримати

Artem Korn бозон Хиггса в ЦЕРН 26.01.2015 02:57

скрам и прочие аджайлы — просто модная фишка

Эх, все бы было нормально, если бы не было упоротых евангелистов скрама.

Відповісти

Підтримати

Леонид Украинский

Sergii Surskykh Software Engineer 26.01.2015 11:10

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

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

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

Відповісти

Підтримати

Włodzimierz Rożkow інфлюенсер в t.me/full_of_hatred 25.01.2015 03:07

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

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

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

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

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

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

Відповісти

Підтримати

Alex Fogol Software Developer, C/C++ Expert 25.01.2015 11:05

юнит тесты

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

Відповісти

Підтримати

Włodzimierz Rożkow

Eugen Kochuev Head of the web-development department в Forma-Pro, engineering manager 25.01.2015 14:09

делаются смешанные команды

Скорее всего проблема в том, что скрам для распределенных команд не самая простая штука. И уж точно такой проект для пилотного (в качестве «попробовать» скрам) не годится.

Но в моем случае за около 10ка лет работы я так и не увидел как агиле взлетел бы в чистом виде.

Для начала неплохо было бы разобраться, что такое «agile в чистом виде». Насколько я понимаю, то ваш водопад с итерациями был достаточно agile :)

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

Відповісти

Підтримати

Włodzimierz Rożkow

Alex Fogol Software Developer, C/C++ Expert 25.01.2015 16:49

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

#totalfacepalm

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

Відповісти

Підтримати

Artem Komisarenko C++ Software Developer в Zultys 25.01.2015 21:10

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

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

Відповісти

Підтримати

Alex Fogol Software Developer, C/C++ Expert 25.01.2015 21:53

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

Відповісти

Підтримати

Artem Komisarenko

Sergii Surskykh Software Engineer 26.01.2015 10:41

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

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

Відповісти

Підтримати

Włodzimierz Rożkow

Włodzimierz Rożkow інфлюенсер в t.me/full_of_hatred 26.01.2015 12:42

Видел другие тру стори с параличом анализа и по пишущеемуся по нескольку лет ядру.

И такое бывало :)

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

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

Відповісти

Підтримати

Sergii Surskykh

Мыкола Гайка 26.01.2015 13:16

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

Відповісти

Підтримати

Włodzimierz Rożkow

Włodzimierz Rożkow інфлюенсер в t.me/full_of_hatred 26.01.2015 13:53

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

Відповісти

Підтримати

Мыкола Гайка

Gremlin 25.01.2015 00:55

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

Відповісти

Підтримати

Oleg Kariakin Senior Java Developer 24.01.2015 23:06

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

Відповісти

Підтримати

Włodzimierz Rożkow інфлюенсер в t.me/full_of_hatred 25.01.2015 03:10

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

Відповісти

Підтримати

Дмитрий Мирошник Lead QA Automation Engineer 24.01.2015 22:27

Если Скрам такой класный, то почему его нельзя применять везде? В каких случаях Скрам нельзя или неэффективно применять.

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

и до кучи вопрос — будет ли эффект от QA который постоянно вариться в процессах команды? Или же QA должен быть полностью независим от всей возни и смотреть на проект беспристрастно?

Вопрос поставлен некорректно.
Уточняющий вопрос: кто такой этот QA? Какая у него роль? За что он отвечает?

Відповісти

Підтримати

Eugen Kochuev Head of the web-development department в Forma-Pro, engineering manager 24.01.2015 22:58

нежелание писать документацию обернётся большими проблемами

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

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

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

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

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

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

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

Відповісти

Підтримати

Дмитрий Мирошник

Дмитрий Мирошник Lead QA Automation Engineer 25.01.2015 02:52

Почему вы считаете, что скрам в обязательном порядке отменяет любую документацию? Это заблуждение.

Я в курсе :) Говорю не с точки зрения теории, а с точки зрения практики. Есть несколько моментов.
1. Самый главный. Программисты НЕ ЛЮБЯТ писАть документацию. И при любой возможности съехать этим воспользуются.
2. Приоритезация задач построена обычно так, чтобы документирование (если оно вообще входит в backlog, хехе :) ) стояло на последнем месте. Работающая фича важнее документации — часть agile manifesto. Поэтому, если времени на фичу мало (а его всегда мало :) ) - лишнее время, если фича внезапно делается быстрее графика, тратится на прикручивание новых свистелок, перделок, рефакторинг, тестирование — но не на документирование. Естессно, можно потребовать, чтобы незадокументированная фича не маркировалась сданной — но сколько по скраму не работал, такого не видел.

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

Круто. Теперь скажите, плз, как техрайтеру в этом разобраться? Для справок, техрайтер — это обычно девочка, имеющая филологическое образование, в задачи которой входит написать тот самый user guide на хорошем инглише. Не более. То есть, лезть в код она не будет просто потому, что это в её задачи не входит. Зато в её задачи входит взять какой-нить документ типа feature overview, функциональных требований в др., связать их в единое целое, добавить скриншотов и написать это так, чтобы бизнес-пользователь, знающий только «левый клик мыши, правый клик мыши, двойной клик мыши», прочитав этот гайд, понял, что нужно сделать в программе, чтобы получить желаемый результат.
Собссно, имеем то, что я описал выше. Скрам не годится для сложных проектов, требующих большого количества разнообразной документации.

В данном конкретном примере проблема обусловлена плохим кодом, но никак не методологией.

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

Відповісти

Підтримати

Eugen Kochuev Head of the web-development department в Forma-Pro, engineering manager 25.01.2015 12:25

Программисты НЕ ЛЮБЯТ писАть документацию.

Сделайте требование документирования кода частью DoD. Также введите механизм ревью кода, который выявит несоответствия DoD.

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

Именно так и надо делать.

Теперь скажите, плз, как техрайтеру в этом разобраться? Для справок, техрайтер — это обычно девочка, имеющая филологическое образование

Здесь речь шла о технической документации, она не предназначена для девочки техрайтера. Девочка техрайтер будет писать документацию по каждой фиче исходя из содержимого user story (в которой будут достаточно четкие acceptance criteria).

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

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

Відповісти

Підтримати

Дмитрий Мирошник

Alex Fogol Software Developer, C/C++ Expert 25.01.2015 11:08

хорошо документированный код с тестами (которые также будут выполнять роль документации)

Это бред.

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

За чей счет этот банкет? Полностью переводится в то, о чем я сразу написал: «подразумевают непрерывную продажу заказчику непрерывных часов разработки с видимостью деятельности путем направленности на создание утовлетворенности личной самого заказчика».

Відповісти

Підтримати

Viktoria Muzychko Senior Software Engineer 25.01.2015 12:00

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

Відповісти

Підтримати

Eugen Kochuev Head of the web-development department в Forma-Pro, engineering manager 25.01.2015 13:59

Это бред.

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

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

Это какая-то демагогия, даже комментировать что-то сложно. Но, попробую:

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

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

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

Відповісти

Підтримати

Sergii Surskykh Software Engineer 26.01.2015 10:28

1. Плохо применять для больших долгоживущих проектов.

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

Відповісти

Підтримати

Дмитрий Мирошник

Костянтин 24.01.2015 22:13

RUP anybody ?

Відповісти

Підтримати

anonymous 25.01.2015 00:07

RUP это долго, дорого, охуенно.

Відповісти

Підтримати

Костянтин

Andrii Stesin Product Manager в здесь я частное лицо 25.01.2015 01:47

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

Відповісти

Підтримати

anonymous 24.01.2015 17:14

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

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

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

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

Відповісти

Підтримати

Євген Козлов Front-end developer в SoftServe 24.01.2015 23:13

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

воу-воу. запускать регрессионное тестирование на каждый пук? или автотесты со 100% покрытием — обязательно для agile’a? кодфриз касается мерджа в какую-то «основную ветку», а не произвольных коммитов в ответвления.

в не-легаси проекте

BTW в какой момент проект становится «легаси». два года норм возраст? или надо подождать до 2.5? just asking

Відповісти

Підтримати

anonymous 25.01.2015 13:36

запускать регрессионное тестирование на каждый пук?

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

BTW в какой момент проект становится «легаси». два года норм возраст? или надо подождать до 2.5? just asking

Когда сложность проекта начинает рости не линейно, а экспоненциально, тогда уже можно считать легаси. По личному опыту знаю проекты которые становятся «легаси» уже через полгода.

Відповісти

Підтримати

Євген Козлов

Artem Korn бозон Хиггса в ЦЕРН 25.01.2015 12:58

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

Расскажите это разработчикам ПО в аэрокосмической индустрии (например).

Відповісти

Підтримати

anonymous 25.01.2015 13:37

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

Відповісти

Підтримати

Artem Korn бозон Хиггса в ЦЕРН 25.01.2015 15:28

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

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

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

Відповісти

Підтримати

Vitaly Chernooky C, Embedded and Linux в Self-Emplyed 25.01.2015 16:01

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

Відповісти

Підтримати

Artem Korn бозон Хиггса в ЦЕРН 25.01.2015 16:11

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

Відповісти

Підтримати

Vitaly Chernooky

anonymous 25.01.2015 16:35

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

Кент Бек.

Відповісти

Підтримати

Artem Korn бозон Хиггса в ЦЕРН 25.01.2015 17:17

Кент Бек.

Argumentum ad verecundiam.

Відповісти

Підтримати

anonymous 25.01.2015 17:31

Ты спросил, я ответил.

Відповісти

Підтримати

Alexandr Semeshchenko 25.01.2015 17:05

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

Відповісти

Підтримати

Sergii Surskykh Software Engineer 26.01.2015 10:56

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

Відповісти

Підтримати

Vitaly Chernooky C, Embedded and Linux в Self-Emplyed 25.01.2015 15:58

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

Відповісти

Підтримати

Yurii Shulima programmer в Free 25.01.2015 13:42

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

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

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

Відповісти

Підтримати

Eugen Kochuev Head of the web-development department в Forma-Pro, engineering manager 24.01.2015 12:36

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

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

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

Відповісти

Підтримати

Alex Fogol Software Developer, C/C++ Expert 24.01.2015 14:06

или крупный проект

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

Відповісти

Підтримати

Eugen Kochuev Head of the web-development department в Forma-Pro, engineering manager 24.01.2015 16:18

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

Відповісти

Підтримати

Alex Fogol Software Developer, C/C++ Expert 24.01.2015 17:32

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

Відповісти

Підтримати

Eugen Kochuev Head of the web-development department в Forma-Pro, engineering manager 24.01.2015 17:42

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

Відповісти

Підтримати

Alex Fogol Software Developer, C/C++ Expert 25.01.2015 10:52

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

Відповісти

Підтримати

Artem Korn бозон Хиггса в ЦЕРН 25.01.2015 13:04

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

Відповісти

Підтримати

Yurii Shulima programmer в Free 25.01.2015 13:29

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

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

Відповісти

Підтримати

Dmytro Lapshyn Solution Architect 24.01.2015 21:36

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

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

Відповісти

Підтримати

Eugen Kochuev Head of the web-development department в Forma-Pro, engineering manager 24.01.2015 22:07

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

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

Відповісти

Підтримати

Andrii Stesin Product Manager в здесь я частное лицо 25.01.2015 01:48

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

Відповісти

Підтримати

Dmytro Lapshyn Solution Architect 26.01.2015 15:40

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

Відповісти

Підтримати

Dmytro Lapshyn Solution Architect 26.01.2015 15:38

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

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

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

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

Відповісти

Підтримати

Nastya Nikolaeva Lead Localization Manager в G5 Entertainment 23.01.2015 15:29

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

Відповісти

Підтримати

Mikhail Boiko SE в NVIDIA 23.01.2015 13:59

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

Відповісти

Підтримати

Виталий Годзевич 23.01.2015 15:06

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

Відповісти

Підтримати

Mykhailo Vezovyk Product Manager 24.01.2015 12:43

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

Відповісти

Підтримати

Виталий Годзевич

Alex Fogol Software Developer, C/C++ Expert 24.01.2015 14:08

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

Відповісти

Підтримати

Mykhailo Vezovyk

Євген Козлов Front-end developer в SoftServe 24.01.2015 23:17

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

Відповісти

Підтримати

Дмитрий Мирошник Lead QA Automation Engineer 25.01.2015 03:02

а если серьезно, какая методология предлагает забить на потребности бизнеса и их изменения?

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 25.01.2015 19:26

Есть определённые бизнесы, у которых цикл производства весьма мало зависит от изменений рынка.

на этом этапе я подумал, что речь идет об автоматизации производства.

Соответственно, мы знаем, что мы хотим получить на выходе заранее и спокойно его разрабатываем.

а тут уже понял, что о другом речь.
касательно приведенных примеров не буду спорить, так как согласен.
можете обобщить признаки для указанной ниши? чтоб определить область неприменимость СКРАМа?

Відповісти

Підтримати

Дмитрий Мирошник

Дмитрий Мирошник Lead QA Automation Engineer 25.01.2015 21:26

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

Відповісти

Підтримати

Євген Козлов

Sergii Surskykh Software Engineer 26.01.2015 10:31

1. Изменения в первоначальный проект вносятся нечасто -> скрам неэффективен.

Если проект не совсем в области текущей компетенции команды, то изменения дизайне будут возникать и без изменения исходных требований.

Відповісти

Підтримати

Дмитрий Мирошник

Alex Fogol Software Developer, C/C++ Expert 25.01.2015 10:48

предлагает забить на потребности бизнеса и их изменения?

Что вы знаете о потребностях бизнеса и об их изменениях?

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 25.01.2015 19:24

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

Відповісти

Підтримати

Sergii Surskykh Software Engineer 26.01.2015 10:58

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

Відповісти

Підтримати

Mykhailo Vezovyk

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

Ваша пошта

Не підписуватись