×Закрыть

Почему клиенты любят Agile?

Thumbs up image via Shutterstock.

[От редакции: данную статью в редакцию прислал автор, пожелавший остаться неизвестным.]

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

Попробуем разобраться в вопросе — почему же заказчики так любят Agile?

Оставим технические подробности, и переключимся на нечто более важное — на явные и скрытые ожидания клиента. Именно они, а не рациональные рассуждения и точные расчёты, зачастую определяют выбор способа работы (увы). Итак:

Во-первых, Agile — это дешево.

  • Не нужен проектный менеджер (зачем? Мы же Agile!).
  • Не нужно тратиться на проектирование архитектуры. Для большинства заказчиков, выходцев из бизнес-среды, архитектура проекта — это вообще непонятный зверь, и тратить на него время и деньги по возможности не стоит. Лучше сразу начинать делать что-то, что «вот прям сейчас работает».
  • Не нужно тратиться на документирование. Нет, оно, конечно, будет... какое-то... пусть, в конце концов, программисты сами описывают, что они делают — они же умные.

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

В-третьих, Agile — это безопасно. Не нужно принимать на себя ответственность за решения. Сегодня я хочу одного, завтра — другого, и это нормально. Передумал — не проблема. Выбросить реализованное в корзину — запросто! Новое не налезет на то, что сделано на данный момент, и вообще приводит к краху системы? Это еще с чего вдруг? Зачем же ВЫ тогда ТАК писали код?

В общем, с какой стороны ни глянь, Agile — очень удобная система работы. Оптимальная ли? Это, как говорится, зависит. Говорю сразу: я знаю, что Agile работает. Не просто уверен — я ЗНАЮ. Так как он реально работал в некоторых проектах, в которых я сам участвовал.

Но работает он только тогда, когда соблюдаются хорошо всем известные условия:

  • Небольшая, коллоцированная, кроссфункциональная команда высококлассных специалистов (до 9 человек).
  • Реальная вовлеченность заказчика, его постоянная готовность к работе с командой.

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

Часто ли соблюдаются эти требования? Увы. Нечасто. А честно говоря — редко. Весьма и весьма.

Во-первых, сплошь и рядом команды распределены, удалены друг от друга, заказчик за океаном и не сильно горит желанием работать с командой (у него бизнес, знаете ли). Их размер достигает нескольких десятков человек, работающих над параллельными потоками задач. Их координация находится на весьма низком уровне (Scrum of Scrums, ага).

Во-вторых, кроссфункциональные команды высококлассных профессионалов — это скорее мечта, чем реальность. В большинстве команд люди разнятся по техническому уровню и мотивации. И рады бы взять только высококлассных самомотивированных профи, да только «на десять девчонок по статистике девять ребят» :). Шутка.

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

  • Уже никто не знает, как программа устроена в целом (что-ж вы доки не писали? Ай-яй-яй!).
  • Часть людей уходит, новые приходят и долго не могут разобраться в продукте.
  • Масштабируемость и производительность продукта исчерпаны, и без жесткого рефакторинга и проработки архитектуры (страшное слово) — с места не сдвинуться.
  • Добавление новых фич требует все больше времени из-за нелинейного роста сложности продукта.
  • Разработчики все громче и громче матерятся на качество кода. Это все бы ничего (пусть терпят, они же САМИ его писали), да вот беда — могут и уйти со словами «не могу так говнокодить, заказчик сам не знает, чего хочет». И новых набрать — непросто и затратно.
  • Мотивация людей, вынужденных часто работать «на корзину», закономерно снижается. Это факт. Кто там чего про «вы должны быть всегда готовы к изменениям?». Ага, должны. Мы вообще много чего должны — зарядку там по утрам, зубы на ночь и т. д. Человеческая психика — штука неумолимая, и ее так просто не обманешь и не пересилишь. Доказано, что работа на корзину — один из главных демотиваторов для профессионала. Это не обсуждается.

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

Заказчики, в общем, люди неглупые, и убедить их можно. Но от них последует закономерный вопрос — почему это случилось именно сейчас, и почему раньше об этом не говорили и не планировали? Ведь сейчас может быть не лучший момент для рефакторинга, с точки зрения клиента. На это можно только пожать плечами... ну, мы же Agile. У нас-то и менеджера нету. Который по своей должности должен прикрывать свою задницу и задницу команды, постоянно и регулярно объясняя клиенту риски и коммуницируя сложности и возможности...

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

И все это как-то работает.


[От редакции: для полноты картины мы решили взять несколько комментариев у практиков Agile.]

Алексей Солнцев, Delivery Manager в Infopulse:

По-правде, в статье всё перевёрнуто с ног на голову. В первую очередь, заказчики любят Agile за счёт скорости вывода продукта или его новой версии на рынок. Во-вторых, те из них, кто когда-то встречался с процессами управления изменениями и такими понятиями, как «Change Request, Impact Analysis, Change Control Board», понимают, насколько дешево им может обходиться внесение изменений в требования, если они будут играть по правилам Agile.

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


Артем Сердюк, ScrumMaster и Agile Coach компании ISM Ukraine:

Если клиенты вмешиваются в выбор процесса (а им и кроме этого есть, чем заняться), в дело вступают не «предрассудки», а ценности: то, что для заказчиков важно в ИТ-проектах. А важна для них надежность, предсказуемость, стабильность. Любой стандартный процесс разработки для заказчика лучше, чем бардак. Неважно, как это называется — Scrum, RUP или CYADD, до тех пор, пока команда выполняет обещания и есть ощущение контроля, клиенту глубоко плевать на процесс.

Другое дело, что Scrum, который мы в этом случае внедрили, — ни в коем случае не Agile-процесс. Agile-процесс — это процесс, который рождается по ходу разработки. Повторю: не продукт эволюционирует (заказчик сам не знал, чего хотел), а процесс. Те правила, которые есть на старте, не работают и все время меняются. Роли меняются. Длина итераций меняется. Только очень-очень базовые вещи остаются... да и то не всегда.

В той среде, о которой говорит автор (кросс-функциональная команда профессионалов, и все в одной комнате, включая заказчика), Agile-процесс не нужен! Все стабильно, все правила известны — к чему тут адаптироваться? Будет работать абсолютно любой процесс.

А вот когда у вас распределенная команда, разница с клиентом в 12 часов, новая для него и для вас предметная область — вот тогда процесс будет и правда Agile. Эксперименты, провалы, эксперименты, успехи. И этот Agile ненавидят как заказчики, так и команды разработки, потому изобретение нового — это постоянный стресс, это невыносимо. Но Agile — единственный известный нам способ работать в таких сложных и непонятных условиях. Поэтому так и работаем.

LinkedIn

60 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

IMHO. Гнучкі методології працюють по тому ж принципу, що й еволюція, вільний ринок тощо. Звідси плюси й мінуси. Плюси: висока адаптивність, порівняно невелика вартість, висока залученість замовника, дуже гарно працює для проектів невисокого рівня складності. Мінус в основному один, як і в усьому, що створюється шляхом поступового пристосування до обставин (вимог) — висока ймовірність застрягнути на локальному естремумі. І щоб з нього вистрибнути треба провести рефакторинг чи навіть переглянути архітектуру рішення. Тобто, хоч на короткий проміжок часу вийти за межі Agile

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

Тогда Scrum — это он самый. Используй его всегда и везде.

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

Такой комментарий достоин отдельной статьи!
=))

Схоже, критики з коментів статтю дочитали лише до середини :)

Автор, очевидно, принадлежит к тому же племени, что и нелюбимые им заказчики и менеджеры, т.к. постоянно называет «cowboy coding» «Agile-процессом» (это ни разу не процесс и не методология, а просто набор ценностей и принципов, продиктованных здравым смыслом). Хотя я, конечно, понимаю, что соломенного человечка забороть просто и приятно.

И еще, для протокола: нет таких понятий, как «не чистый Scrum» или «не чистый XP». У вас или есть процесс, или его нет. Если ваш процесс не соответствует Scrum Guide на 100%, то это не Scrum, если вы не выполняете все правила XP — это не XP.

В этом случае ответственность за фэйл лежит не на Швабере, Сазерленде, Коне, Беке или других евангелистах, а на вас самих, потому что процесс «изобретен» и «внедрен» именно вами.

В этом случае ответственность за фэйл лежит не на Швабере, Сазерленде, Коне, Беке или других евангелистах, а на вас самих, потому что процесс «изобретен» и «внедрен» именно вами.

Ответственность всегда лежит на вас. ПМ, продакт оунер или не важно как еще это называется. Даже если вы выполняете 100% чистый без-гмо Scrum Kanban, но проект зафейлился — виноваты только вы.

Это понятно. Просто набила оскомину ситуация, когда изобретение головожопых менеджеров с обеих сторон выдается за Scrum, а потом следует заявление, что Scrum-де «не работает». В задаче спрашивается: чем такой доморощенный аналитик отличается от тех менеджеров, которых критикует?

Учитывая эту цитату:

Если ваш процесс не соответствует Scrum Guide на 100%, то это не Scrum,
так может Вы как раз и принадлежите к тем самым истинно правоверным евангелистам, которые в любом неудачном скрам-проекте найдут тот самый 1%, которого не хватило для «100% Скрама»? Благодаря чему все неудачи можно списать на недостаточную скрам-правоверность. Скрам-то, оказывается, не виноват — народ нам не тот попался правоверные у нас недостаточно правоверны.

Как вообще Скрам может быть в чем-то виноват? Это не полноценный процесс, а, по удачному выражению Алистера Коберна, «reflective improvement framework». Если не обращать внимания на проблемы, которые Скрам вскрывает (например, когда из-за длинного цикла тестирования в конце спринта нет potentially shippable product increment), то лучше не станет. Хотя Скрам свое дело сделал — показал узкое место, а дальше нужно включать мозг, все-таки.

В этом обсуждении Денис Муратов написал:

— Ты ощущаешь себя умным, когда в речи заменяешь слова на родном языке иностранными?

Два года назад я писал (привожу цензурную часть):


Адекватный человек, оперирующий идеей на уровне понимания, а не набора словесов, способен эту идею изложить другим на родном языке. Не можешь? Значит идею так и не понял: твой уровень — брифинг с продакт-манагером о чекпоинтах.

Будет интересно увидеть более полную цитату — Гугль поможет ;-)

А Скрам, он ни в чем не виноват. Как может быть виновато что-нибудь ненужное? Виноваты только люди, которые делают ненужные и глупые вещи.

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

Приношу искренние извинения, если мой комментарий затронул Вас лично.

Мой комментарий носил обобщающий характер, Ваше высказывание было лишь поводом.

То, что в Agile нет менеджера — это глубокое заблуждение. Есть, дествительно, интересная перестановка в ролях и названиях, но суть человека, который управляет проектом/продуктом никуда никогда не денется. Называться может как угодно, но не исчезает, конечно. Заявляю как заказчик и как практик agile.

Тогда «пишите код блять» — ещё более нравится заказчику. Эта методология ещё более дёшева. Позволяет взять индусов.
Мало документации? «Пишите код документацию блять».
Много матерятся? Так это фичи!
Мотивация людей? Так это ж основа методологии :)
Масштабируемость? Прикупите второй дрын.
Часть людей уходит? Применить методологию к эйчарам! «Ищите людей млять».

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

Недостаток только один:
Нужно качество? А вот теперь включайть мозг. Млять. И без него ни одна методология не даст качества! А без качества — вы конкурируете с индусами, и численное преимущество на их стороне.

Кто конкурирует с индусами? Заказчик или R&D?

У нас в команде Agile работает, работает хорошо и реально помогает.
Самое полезное — ретроспектива. Классная идея органичивать work in progress на борде.
Общение с заказчиками очень хорошее — так как они реально понимают scrum. Раньше казалось иногда, что Agile излишен (особенно держать физическое тело перпендикулятно полу на стендапе) — со временем убедилась, что просто некоторые не умеют его готовить.

Сегодня, как в тему:
Kanban is like homeopathy ( @flowchainsensei)

Не нужен проектный менеджер (зачем? Мы же Agile!).

Опа, от воно як виявляється, піду завтра своєму ПМ-у на еджайл проекті заявлю, що він «не нужен»

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

Для процесса разработки он не нужен
противоречит
взять отгул, отпуск и решает прочие задачи, косвенно касающиеся проекта.

Несмотря на то, что сама статья написана неплохо, я прохладно отношусь к эджайлу, который превратился в средство зафейлить проект без персональной ответственности. На эту тему писал статейку «Тренды, возведенные в культ». Выдержка по эджайлу:

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

В свое время, когда Agile еще не вошел плотно в нашу жизнь, я считал, что просто не дорос до такого понятия как гибкие методологии. Пиши код, блять — все, что я знал и умел и это было наше все. Ну еще GDD — google driven development.

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

К сожалению, появление такого понятия как agile принес, на мой взгляд, больше вреда, чем пользы.

Вот причины, которые я выделил для себя:

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

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

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

— аджайлисты часто больше зациклены на процесс, а не на результат;
Читали манифест? Там кажется противоположное написано.
— еще никто мне ответил внятно, как оценивать велосити команды, которой еще нет (146% реальный случай), а контракт уже подписан;
А что говорят по этому поводу «альтернативные методики»? Тоже самое что и гибкие — взять и прикинуть это одним человеком с потолка.
— очень часто команды, в которых начинают внедрять гибкие методологии, не соответствуют минимальным требованиям к командам, где можно и нужно внедрять гибкие методологии;
— аджайлисты часто наивно полагают, что гибкие методологии можно и нужно применять везде. Это не так;
Кто вам это говорит? Я вот даже от «евангелистов» слышал что есть случае где waterfall’ное управление проектом эффективнее.
— у каждой компании, команды, скрам-мастера свое понимание гибких методологий;
Потому что гибкие методологие во первых слово очень общее. Во вторых на то они и гибкие чтобы адаптироваться под конкретный случай.
— наличие скрам-доски не делает автоматически проект успешным.
Покажите на человека, который вам это сказал.

Александр, вы спорите с ветрянными мельницами. Просто возьмите полезные для вас практики и идите дальше. Не тратьте время на критику.

Просто возьмите полезные для вас практики и идите дальше.

Поддержу здесь на 146%.

Но в этом обсуждении есть и такие мнения:

Если ваш процесс не соответствует Scrum Guide на 100%, то это не Scrum, если вы не выполняете все правила XP — это не XP.

Кому верить?

«Запомните, Штирлиц: никому верить нельзя, даже себе. Мне — можно» ©

Так вот, никакого противоречия тут нет. Использование отдельных элементов Скрама не означает, что нужно называть свой процесс Скрамом. Можно же назвать «замечательный процесс разработки Команды А», и там определить те роли, ответственности, рабочие соглашения, расписания и артефакты, которые актуальны для конкретно этой команды. Но для этого же нужно собраться и включить головной мозг, гораздо проще взять Scrum Guide, выбросить из него половину (т.к. «мы особенные», «к нам это неприменимо») а потом рассказывать всем, что а) у нас Скрам, б) он не работает.

Вы вроде бы правильно говорите...

Но вот скажите, на 99% Скрам это Скрам или уже нет?

Ну можно в «шубе» заменить, например, селедку на телятину.
Получится не менее вкусный салат, но уже не шуба.

Если ваш процесс не соответствует Scrum Guide на 100%, то это не Scrum, если вы не выполняете все правила XP — это не XP.
Это пряма дзен аджайл какой то :))) Как там говорят мудрецы «Если встретишь Будду на дороге — убей его!»

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

Но для начала надо попробовать и понять оригинальные процессы
youtu.be/wxlEQsIYL8Q
Только раньше это называлось адекватностью и здравым смыслом, а сейчас — эджайлом.
К сожалению, заказчик может не понять, если ему сказать «Наша команда будет работать по процессу, продиктованному адекватностью и здравым смыслом».
С комментарием согласен — хотя перечисленные фэйлы и не связаны напрямую с аджайлом, но они очень легко и часто возникают на стыке аджайла и некомпетентного менеджмента.
нет адекватных критериев оценки и статистики для сравнения результатов разработки с помощью разных методологий

Вообще-то, есть:
www.infoq.com/...e-methodologies

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

Жалко что совсем одинаковых людей нет, но медицина же как-то все-таки развивается.

К сожалению, появление такого понятия как agile принес, на мой взгляд, больше вреда, чем пользы.
Agile приносит много пользы, вред приносят те, кто не умеет им пользоваться.
— аджайлисты часто больше зациклены на процесс, а не на результат;
Agile-анархисты народ вредный. Но инструмент-то при чем?
Если мартышку посадить за станок тоже дела не выйдет, но станок в этом не виноват, если ты понимаешь о чём я.
— очень часто команды, в которых начинают внедрять гибкие методологии, не соответствуют минимальным требованиям к командам, где можно и нужно внедрять гибкие методологии;
Это да, без правильных людей вообще всё фейлится, а не только процессы.
еще никто мне ответил внятно, как оценивать велосити команды, которой еще нет (146% реальный случай), а контракт уже подписан;
± точно — никак.
не ± точно — исходя из прошлых проектов и опыта.
По-моему вполне внятно.
— аджайлисты часто наивно полагают, что гибкие методологии можно и нужно применять везде. Это не так;
Всё те же agile-анархисты.
— нет адекватных критериев оценки и статистики для сравнения результатов разработки с помощью разных методологий;
Нет и сделать это невозможно. Единственный вариант, как изобретут клонирование, — клонировать несколько раз команду и сделать один и тот же проект использую разные методологии.
— у каждой компании, команды, скрам-мастера свое понимание гибких методологий;
У каждого человека своё понимание всего. Вопрос в том в какие действия это выливаются. Agile-идиотов еще больше чем Agile-анархистов...
— наличие скрам-доски не делает автоматически проект успешным.
Факт.
при наличии адекватного руководителя команды и адекватной команды. Впрочем, в таком случае скрам до задницы — у них и так все будет хорошо.
Опытный, сплоченный и профессиональный тим так и иначе сам приходит к скрам-подобной разработке. Да только таких команд не много на самом деле по многим причинам.

Началось...

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

У вас есть конкретные вопросы по процессам и артефактам Scrum? Можем об этом поговорить :)

Похоже, тут не соблюдаются нужные требования для аджайл.

Не важно, какой тип аджайла, какие ролевые игры придумали, все они где-то одни и те же принципы соблюдают. Аджайл не будет без них работать нормально.
Дополнить надо то что выше:
1. KISS, DRY, YAGNI
2. YAGNI никогда не распространяется на рефакторинг. Рефакторинг делается всегда — это важное требование для линейного роста сложности. Если с т.з. функционала можно говорить: программа работает и этого функционала достаточно, больше делать ничего не будем. То НЕЛЬЗЯ думать: программа работает, не будем делать рефакторинг.
3. Взаимное ревью кода. Хоть иногда. Это уменьшает принадлежность кода разным людям, зависимость от конкретных людей (болезнь, уход), вообще препятствует нехорошим вещам в архитектуре (я боюсь копаться в чужом коде, поэтому сделаю логику у себя на клиенте, и т.д.), уменьшает потребность в документации (документация всегда врет, т.к. устаревает).

Видимо мало кто понял эти вещи и их фундаментальность. Расшифрую, почему они относятся к гибким технологиям напрямую, несмотря, что это технические детали.
1 принцип говорит о минимизации функционала и деятельности по созданию функционала. Без этого «гибкость» — это всего лишь слова. Для того, чтобы проект был готов к изменениям в любом направлении, он должен быть минимальным в любой момент. KISS, DRY, YAGNI — это вроде разные термины, но по сути описывают одно и то же — минимизацию.

2 принцип говорит о накоплении мусора. Обязательно убирать мусор. Если этого не делать, в любом случае дойдете до точки, что проще квартиру продать и искать новую. Уборка при изменении проекта должна происходить постоянно, иначе мусор начнет мешать развивать проэкт.

3 принцип обязателен для взаимодействия, уменьшая потребность в документации. Документирование — это удвоение работы, это кодирование на другом языке — языке схем, слов и тому подобное. Это по сути противоречит 1 принципу, т.е. это предугадывание требование, кристаллизация и затвердевание проекта, что опять же идет в разрез с понятием «гибкость».

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

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

Автору +1, «практиків» не коментуватиму.

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

Ну а если серьёзно — то все эти новомодные методологии — перетасовка старой колоды.

Да какие они новомодные, Скрам не намного моложе Вас.

Все относительно, когда я начинал работать — в моде был CMMI.
Потом мода менялась, а залог успеха оставался тем же:
— квалифицированная (слаженная и мотивированная) команда,
— постоянная вовлечённость заказчика, знающего что ему нужно и имеющего реалистичные ожидания (по фичам, срокам и стоимости)
— вовлеченность команды в предметную область (не делаем как во всех WSF черный ящик по бумажкам непонятной прослойки в виде BA)
— ???

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

не понял, почему автор скрыл себя....

Давайте будем честными, скрам — это методология окучивания клиента. Принципы заложенные в его каркас лишь гарантируют коммуникации клиента и команды, а сама разработка — как хотите. В итоге скрам нужно дополнять именно техническими практиками — unit CI, unit testing, bdd, story bdd, парное программирование, код ревью, покер плэнинг, рефакторинг и т.д. Как можно не планировать архитектуру?

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

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

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

СкрамМастер это член команды разработки, то есть чаще всего тоже программист. Ну если брать по канонам и книжкам :)

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

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

Давайте будем честными, скрам — это методология окучивания клиента.
У вас аутсорсинг головного мозга.

Так это и есть одно из общепринятых определений Агиле. ;)

Кем это они общеприняты? Что за мифические определения? Идите читать манифест.

У автора тоже, это видно хотя бы по тому, что в качестве «заказчика» описывается не бизнес-спонсор проекта, а типичный IT PM со стороны клиента, чья работа — отжать вендора по рейтам, а также обеспечить попадание в сроки, скоуп и бюджет.

Хорошая аргументация — перейти на личности и стрелять наугад. Но мимо, последние годы всё больше аутстафинг или работа напрямую с клиентом.

При чем тут личности. Вы же дальше схемы «заказчиик-окучить» не видите.

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

Вы там наверное считаете, что очень ловко ведете дискуссию, набирая очки вот этими вот пресуппозициями типа «опять кержаковите» или «перейти на личности»? )

Вы считаете, что если не внедрить

unit CI, unit testing, bdd, story bdd, парное программирование, код ревью, покер плэнинг, рефакторинг и т.д
то
нормальный продукт без этих практик не получится, если получится вообще.

Это довольно харакерная точка зрения, еще раз выдающая в вас аутсорсингового программиста. В этом нет ничего обидного, это просто такая профдеформация, очень харакерная для всех нас тут. Вам кажется, что «создание продукта» — это получение требований от заказчика, выполнение их в лучших инженерных практиках, и сдача заказчику. И вся соль, стало быть, чтобы заказчик был посговорчивее, да практики посовременнее. И тогда хороший продукт и получится. В этом своем уютном мирке вы абсолютно правы — внедряйте себе planning poker и code review — и живите счастливо.

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

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

p.s. Ещё раз, я не аутсорсер и почти всегда работал на бизнес, а не продавал человеко часы. Потому и не поклонник скрама в чистом виде. Хотя и поаутсорсил, но уже когда был сложившимся специалистом и тоже набрался идей оттуда.

ШОК!

скрам — это методология окучивания клиента
ФОТО ВИДЕО

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

unit CI, unit testing, bdd, story bdd, парное программирование, код ревью, покер плэнинг, рефакторинг
наблюдал/лично проделывал такое со всем кроме плэннинг покера(полагаю, он ещё ждёт своей очереди :) ).
Так что все фейлы/успехи этих ваших/наших Аджайлов — детали имплементации(о чём, кстати, евангелисты на конференциях всё-таки упоминают).

Мущина, внезапно, рефакторинг это щитай синоним слова эджайл. Четайте Мартина Фаулера. Если у вас не делается постоянно рефакторинг то это гавно, а не скрам. Полностью согласен с Лешей. Описанные «недостатки» в статье имеют отдаленное отношение к скраму. ИМХО, самая большая проблема скрама в том, что все сука «знают» как его делать... вернее думают что знают. И начинается по списку автора: доки не пишем, не рефакторим, тесты ненужны и тд. Повторюсь, это все от неумения и к скраму не имеет никакого отношения.

в принципі, можна було зупинитись на слові «коллоцированная»...

Що зупинило не зупинятись?))

надо было добавить: мачурная, смартовая, драйвовая ...

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