«Всё — яд, всё — лекарство; то и другое определяет доза.»
Парацельс
Принято отсчитывать историю Agile от февраля 2001 года, когда появился на свет довольно странный документ — Agile Manifesto. По большому счёту текст документа скомпонован из философских очевидностей (например, «простота — искусство не делать лишней работы») и спорных утверждений (например, «лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды»). Но этот документ странен не столько своим содержанием (мало ли что может прийти в голову на лыжном курорте), сколько эпичностью последовавших изменений в отрасли разработки программного обеспечения. В кратчайшее время появилось множество методик, реализующих методологию «гибкой» разработки, которые торжественным маршем пошли по миру, захватывая умы Исполнителей и кошельки Заказчиков. Адептами этот движ преподносится как некая волшебная пилюля, решающая всё. Дошло до того, что
Для начала попытаемся понять, что же действительно нового мы получили в обёртке Agile вообще и Scrum-а в частности.
Scrum в древнем Египте
Возьму на себя смелость утверждать, что гибкая методология вообще, и методика Scrum в частности, существовали всегда, хотя так и не назывались. Они вообще никак не назывались, а были просто наиболее естественным и эффективным способом вести свои внутренние проекты (ключевое слово тут — «внутренние»).
Вот, например, задумал древнеегипетский фараон построить пирамиду и… понеслось. Обсудил идею со жрецами (stakeholders) и назначил своего виночерпия ответственным за проект (product owner). Виночерпий подыскал грамотного каменщика (scrum master). Каменщик нанял помощников (scrum team), а те пошли на невольничий рынок и набрали рабов (рабочие инструменты: ПК, сервера, софт для разработки и т.д.).
Так как фараон приказал ежемесячно докладывать ему о ходе строительства, то каменщик (с помощниками) стал ежемесячно проводить показ стройки (demo) для виночерпия. Во время показа обсуждалось не только уже сделанное (retrospective), но и составлялся план на следующий месяц (sprint). Для того, чтобы ничего не упустить, виночерпий весь месяц обсуждал со жрецами их хотелки (user stories) и записывал в специальный пергамент (backlog), из которого хотелки попадали в план следующего месяца. Ну и так далее. Я не знаю, как тогда выглядели стикеры, scrum board и burndown-диаграммы. Любой грамотный руководитель подбирает себе наиболее удобные инструменты для управления и контроля проекта. Детали тут не важны, главное, что методика работает.
Т.е. думаю, что все руководители во все времена использовали гибкую методику для создания своего внутреннего (на свой страх и риск) продукта потому, что:
- достаточно компетентны для проектирования конечного результата;
- достаточно компетентны для контроля за ходом процесса;
- имеют достаточно власти над подчинёнными участниками процесса;
- соотношение срока, стоимости и качества работ не являются для них догмой и могут при необходимости пересматриваться (так как «сам себе хозяин»);
- а самое главное — и конечный результат и процесс его достижения находится в одних руках, и преследуют один коммерческий интерес.
Но для внешнего Заказчика неприменим ни один из пунктов данного списка, поэтому для внешних (заказных) проектов гибкая методика не использовалась практически никогда (исключения только подтверждают правило). Ведь народ был простой и нетолерантный, за вопиющее превышение сроков и смет могли и на голову укоротить.
Scrum в наше время
Единственная новизна современного Scrum-а состоит в факте его использования для реализации внешних (заказных) проектов. Эту сторону вопроса стараются не выпячивать, ведь потянув за ниточку можно вытянуть на свет реальную мотивацию участников рынка. По сути дела, манифест Agile и вся аргументация Scrum являются чистой пропагандой интересов Исполнителя, для приличия завуалированной под борьбу за всё хорошее против всего плохого. В том и состоит гениальность решения, что позволяет убедить Заказчика пожертвовать результатом ради процесса!
Итак, что же меняется, если product owner является сотрудником другой, а не своей, компании? Главное отличие в том, что конечный результат и процесс его достижения теперь находится по разные стороны «баррикады» и каждая из сторон преследует только свой коммерческий интерес. Заказчику важен результат, а Исполнителю — процесс. По-другому и быть не может — ведь «ничего личного, это только бизнес».
Agile выгоден игрокам IT-рынка, так как им предоставляет возможность:
- зарабатывать на процессе и не нести ответственность за результат;
- сократить расходы на грамотные руководящие кадры (стоят они дорого, но ведь проектировать теперь ничего не нужно и ТЗ писать не нужно, а процесс теперь контролирует product owner Заказчика).
А раз это выгодно, то прямо на наших глазах программистские коллективы с костяком из высококвалифицированных и системно-мыслящих профессионалов могут превратиться в фермы сдаваемых внаём кодеров средней руки.
Попробуйте поставить себя на место человека, который нанимает бригаду строителей для ремонта своей квартиры и пытается добиться от бригадира сроков и стоимости ремонта, а в ответ слышит:
- мы люди творческие, поэтому работать будем «как пойдёт», но Вы оплачиваете каждый час работы бригады и материалы;
- общего проекта и плана мы делать не будем, разберёмся по ходу дела (если и сделаем что-то неправильно, потом переделаем за дополнительно оплаченное Вами время и дополнительные материалы);
- будем показывать результаты своей работы каждые две недели и рассказывать о своих проблемах, а затем вместе будем планировать следующие две недели.
Вряд ли кто-то согласится с таким предложением, а Заказчики IT-шников соглашаются! Вот что делает пропаганда животворящая!
Мало того, что Заказчика убеждают согласиться на непредсказуемые сроки и стоимость, так ещё и перекладывают на него всю ответственность за неудачи. Как правило, квалификация Заказчика не позволяет формализовать требования к конечному результату и профессионально контролировать ход процесса. Поэтому, всегда можно его запутать и отвлечь (при отсутствии общего ТЗ) на решение множества второстепенных вопросов (которые и возникают чаще всего из-за отсутствия долгосрочного планирования).
Последствия Agile-поклонства
Вам не кажется, что качество программных продуктов падает пропорционально широте распространения Agile в отрасли? Откуда взяться качеству, если весь процесс заточен на решении задач самым простым и быстрым способом из всех возможных? А думать вперёд официально запрещено методологией!
Вам не кажется, что программные продукты всё чаще превращаются в «лоскутные одеяла», когда с удивлением замечаешь, что разные разделы одного и того же ПО как будто сделаны совершенно разными людьми? И даже на одном экране программы могут смешаться разные стили оформления, разные подходы эргономики и разные алгоритмы функционирования аналогичных элементов управления. Но ведь ТЗ и Style Guide на продукт отсутствуют, значит кому как привычнее, тот так и сделает! А QA-персонал, как и все, зажат рамками сроков спринта.
О чём это всё?
Из всего вышеизложенного может показаться, что я являюсь ярым Agile-ненавистником. Но это вовсе не так! И я вовсе не старался кого-либо обидеть! Всего лишь старался нагляднее проиллюстрировать вынесенные в эпиграф слова великого Парацельса.
Гибкая методология вполне пригодна для внутренних малых и даже средних проектов. Размер проекта ограничивается только способностями конкретного руководителя «не потерять лес за деревьями», т.е. умением держать в уме, как все подробности, так и желаемый результат, не систематизируя это «на бумаге».
Гибкая методология ограничено пригодна и для внешних проектов. В этом случае, к product owner-у Заказчика применимы те же требования, что и к руководителю внутреннего проекта, т. е. этот человек должен быть настоящим IT-профессионалом, а не секретарём тянущим временную обузу по-совместительству. Он должен быть в состоянии проверить квалификацию нанятой команды и постоянно контролировать качество разрабатываемого продукта. Кроме того, сам разрабатываемый продукт должен позволять (в случае форс-мажора) замену команды разработчиков. Только в этом случае можно рассчитывать, что не будет «обидно и больно за бесцельно прожитые годы».
Как видите, у Agile есть своё место под солнцем, но оно сильно ограничено в сфере контрактных IT-разработок. Что же делать, если Ваш проект не попадает в категорию Agile-пригодных?
Вам не кажется подозрительным тот факт, что гибкая методология не прижилась нигде, кроме контрактных разработок программного обеспечения? Ну не делают по Scrum-у ни подводные лодки, ни самолёты, ни автомобили. Мудрость предков учит нас, что даже нормальную собачью будку нельзя сколотить без этапа проектирования (карандашный набросок с размерами) и подготовки ТЗ (перечень материалов и инструментов). Всё что вы видите вокруг (от табуретки до космического корабля) создано по старому доброму «водопаду» (waterfall). Почему бы и Вам не поступить так же? И помните — всё будет хорошо!
P.S.
Всё сказанное основано на моём личном немалом (19 лет) опыте контрактных веб-разработок с использованием как традиционного (Waterfall) так и прогрессивного (Scrum) подходов. Побудительным мотивом для написания статьи явились моральные муки от созерцания очередного «чуда враждебных технологий», слепленного по заветам великого Франкенштейна для одной уважаемой западной компании.
Комментарии (33)
sentyaev
09.11.2018 20:31-1По сути дела, манифест Agile и вся аргументация Scrum являются чистой пропагандой интересов Исполнителя, для приличия завуалированной под борьбу за всё хорошее против всего плохого.
Вот я примерно это и пытаюсь объяснить в нашей продуктовой компании. Т.к. в продуктовых компаниях скрам это совсем странный выбор.MasteR_GeliOS
11.11.2018 14:33+3Присоединяюсь, сам похожим образом всегда формулировал чем является agile в целом и scrum в частности. Особо сложно с ярыми поклонниками методологии
x67
12.11.2018 15:58Тут есть психологическая ловушка. Доя agile процесса не нужно думать о всех подводных камнях сразу, можно сказать что решим тогда, когда настанет время решать этот вопрос. И это чертовски приятно пустить все на самотек и не думать о всем грузе проблем, что могут быть. Ну и конечно же банальное отсутствме компетентности — ты не сможешь точно посчитать стоимость, сроки если такого никогда не делал.
Имхо agile хорош для динамично развивающихся проектов, где требования могут устареть быстрее, чем будут реализваны. А также для проектов, в которых ничего не понятно, но не жалко рискнуть и потратить какое то время ради перспективности.
Ну и конечно же аджайл не должен использоваться там, где нужен какой-то гарантированный результат. Отчасти именно поэтому такой подход не применим для инженеров — они должны выпустить продукт в определенные сроки с заданными характеристиками
defaultvoice
10.11.2018 01:13+1Это всё интересно, только вот Agile не ограничивается Scrum. Есть же ещё Lean и Kanban, которые перекочевали в IT из реального производства, а та же Toyota мало того, что до сих пор жива, так ещё и вполне недурно себя чувствует.
Busla
10.11.2018 12:11+2При чём тут тойотовский канбан? — это внутренний «проект», и он использовался для обслуживания а не для создания/разработки. Т.е. это пример подтверждающий тезисы статьи.
Dmitri-D
10.11.2018 05:44+2способностями конкретного руководителя «не потерять лес за деревьями»
чаще ровно наоборот — лес они видят прекрасно, они воюют за лес, а вот отдельные деревья — не различают. Им важно чтобы был правильный лес. А то что он состоит из правильных деревьев — им не очевидно.
Но с другой стороны — вот у нас уже 4 год как скрам (или как мы его зовем срам) — вполне нормально. Разработчики сами пишут тикеты в баклог. Сами ставят сроки, в пределах спринта, а продакт менеджер — выбирает или не выбирает тот или иной тикет в следующий спринт. Редко задает вопросы про сроки. И никогда не стремится сделать их короче. Интересуется в целом что пошло не так. Какие текущие проблемы от юзеров и пр.
В общем почти никакого давления. И, тем не менее, — вот само наличие обсуждений каждые 2 недели и, казалось бы, всего-лишь на час, а дает вполне ощутимый импульс в темпах разработки. Видимо, через самодисциплину, и через бОльшую открытость чем раньше.
pankraty
10.11.2018 11:37Автор, спасибо! Тоже периодически размышлял на эту тему и чувствовал, что чего-то недопонимаю. Не хватало одного кирпичика — противопоставления внутренней и заказной разработки. Теперь все встало на свои места (в моей картине мира)
DikSoft
10.11.2018 14:07+3Есть два тезиса. Первый: пока вы делаете идеальный продукт, кто-то выпустит (так себе) продукт раньше и завоюет рынок. Второй: можно и нужно выпускать лажу, чтобы потом допилить. Оба оправдывают аморальное отношение к потребителю продукта, оба могут принести прибыль ценой непорядочного поведения.
Для оправдания беспринципного извлечения прибыли Agile и особенно SCRUM подходят идеально. Херак-херак и в продакшн. Потребитель обманут, но уже заплатил (и ещё заплатит). Да ещё и добровольно. Вот и вся мораль.
Внутренние мелкие проекты, ну да. Фиг с ними. Иногда можно. Устроить ритуальные хороводы и посиделки. Внешние — это жульничество и запланированный обман потребителя. Высокие слова про гибкую методологию разработки — просто способ спрятаться от совести. Типа все ж согласились, какой-такой обман?
А ещё это очень часто просто карго-культ, помогающий прятать некомпетентность команды и руководства.
PS В первых же абзацах манифеста есть упоминание про компактные команды профессионалов, но кто ж на такие мелочи внимание обращает? И огромные и сильно разбалансированные по квалификации, все туда ломятся.dimoff66
10.11.2018 18:45"Первый: пока вы делаете идеальный продукт, кто-то выпустит (так себе) продукт раньше и завоюет рынок."
Так говорили стиву джобсу, увольняя его из эппл
Pran Автор
11.11.2018 14:57Мне кажется, что Вы слишком категоричны. Даже если принять утверждение что Agile — зло (а я так вовсе не утверждаю в статье), то и тогда правильно будет различать сознательных последователей зла и заблудших последователей. Последние часто юны, неопытны и поэтому кроме Agile ничего не видели, а значит им просто не с чем сравнивать.
mSnus
10.11.2018 14:11-3Я тут вчера пирог испёк. На начальном этапе в ТЗ были только индюшачий фарш и тесто.
Но гибкая методология позволила мне добавить в него по ходу приготовления томатный соус, овощи и сыр, и только потом всё запечь.
Получилось намного лучше, чем если бы я прямолинейно действовал по начальной спецификации, а не менял спеки по ходу разработки.
Да, процесс занял в полтора раза дольше, пришлось использовать дополнительные компоненты и тестировать взаимосвязи между ними, сложность выросла. Но результат — что надо!!
Таким образом, гибкие методики очень даже хороши, когда спецификации приходится менять по ходу дела, а заказчик не полностью уверен в том, что хочет получить в итоге — поэтому и приходится вовлекать его в процесс разработки.
Приятного аппетита))
dimoff66
10.11.2018 19:02гибкие методики очень даже хороши, когда спецификации приходится менять по ходу дела, а заказчик не полностью уверен в том, что хочет получить в итоге
Можно дождаться, когда заказчик протрезвеет и будет знать, что он хочет получить в итоге. Возможно ему сложно это сформулировать, но на то и опытный разработчик, что он может предложить варианты вплоть до прихода к единому консенсусу с заказчиком. Но говорить, что заказчик хочет платить деньги за разработку, не зная при этом чего он хочет — в высшей степени наивно.
PS Да, и я ел ваш пирог, точнее выплюнул — когда по ходу дела из него выковыривали лук по причине изменения спецификации, кто-то оставил в нем свой ноготь
dimoff66
10.11.2018 18:57+1К одному человеку ночью явился ангел и сообщил, что завтра дьявол отравит воду в городском колодце и все жители города сойдут с ума. Человек запасся чистой водой, но у него возникли проблемы. Все жители выпили отравленной воды и сошли с ума, но они не знали об этом и считали сумасшедшим того человека, который не пил воду из колодца, и ему никак не удавалось убедить других, что все они сошли с ума… Не знаю, почему мне вспомнилась эта притча, наверное потому что скрам всегда казался мне коллективным безумием интеллектуально незрелых людей и автор статьи сейчас получит от них массу пинков. И все они будут чувствовать свою абсолютную правоту, так как пили воду из одного колодца.
Pran Автор
11.11.2018 15:07Спасибо за такой дзенский комментарий! Когда писал статью, посещали и подобные мысли. Но теперь настроен гораздо позитивнее. Сейчас я удивлён, рад и благодарен. Удивлён интересом к статье. Рад количеству единомышленников. Благодарен им за неравнодушие!
visirok
10.11.2018 21:09Поставил Вам плюс. Хорошо аргументированная статья.
Хотя Вы и не упомянули о том, сколько было заработано на выдаче сертификатов Scrum мастерам. Мне кажется это они поставили под сомнение ценность сертификатов в IT в целом.
Как-то надо попробовать перейти от слов к числам. Перечислить характеристики проектов, получим многомерное пространство. В нём определить область, где agile работает, а где нет.
Не хотите попробовать?Pran Автор
11.11.2018 15:14Спасибо за плюс и предложение! Но попробовать не хочу. Привык серъёзно относиться к тому, что делаю, а Вы предлагаете целое отраслевое исследование, для выполнения которого у меня просто нет статистики и времени. Одно дело описать свои личные (субъективные) ощущения в статье, и совсем другое дело — предоставить конкретные цифры с претензией на объективность. Тут занятие не на один месяц для целого коллектива исследователей.
visirok
11.11.2018 17:55Жалко что не хотите. Статистику искать не надо, её скорее и не существует. Софтверные фирмы замалчивают свои промахи, а тем более стоимости проектов. Круппные подрядчики типа государствееных служб тоже.
А вот предложить релевантные факторы и шкалы их измерений может любой опытный разработчик. И к каждому фактору — информацию о том, как он влияет на решение использовать агильный подход — положительно или отрицательно.
Например: фактор «Размер команды». Измеряем в головах. От 3 до 9 — в пользу применения агильного подхода. Зампределами — против.
Завести проект в GitHub с табличкой…
arbox
11.11.2018 01:31У каждого есть право на свое мнение, оставлю свои две копейки здесь.
К сожалению, мне очень кажется, что автор статьи не читал вдумчиво первоисточники, если уже в первых строках ссылается на Википедию, а не на текст самого манифеста: agilemanifesto.org
Авторы методологии Скрам напрямую указывают, что проект можно развивать по любым правилам, но называть его Скрам-проектом разрешено только тогда, когда все спринт-цикл с сопутствующими ролями и артефактами выдержаны на 100 % (сравните хотя бы последний абзац из «Руководства по Скраму» (https://www.scrumguides.org/). По всей видимости, большинство проектов, заявляющие Скрам в качестве методологии разработки, живут по каким-то совершенно другим правилам.
Автор допускает ряд терминологических неточностей:
Обсудил идею со жрецами (stakeholders) и назначил своего виночерпия ответственным за проект (product owner). Виночерпий подыскал грамотного каменщика (scrum master). Каменщик нанял помошников (scrum team), а те пошли на невольничий рынок и набрали рабов (рабочие инструменты: ПК, сервера, софт для разработки и т.д.).
Виночерпий в этом случае все же отвечает не за проект, а за продукт, то есть за результат, а не за процесс.
«Грамотный каменщик» — это совершенно не роль скрам-мастера, тут скорее нужен массажист или кухарка. А высококвалифицированные каменщики будут входить в команду разработчиков (Development Team, совсем не Scrum Team). Не стоит передавать роль тимлида скрам-мастеру.
Так как фараон приказал ежемесячно докладывать ему о ходе строительства, то каменщик (с помощниками) стал ежемесячно проводить показ стройки (demo) для виночерпия. Во время показа обсуждалось не только уже сделанное (retrospective), но и составлялся план на следующий месяц (sprint). Для того, чтобы ничего не упустить, виночерпий весь месяц обсуждал со жрецами их хотелки (user stories) и записывал в специальный пергамент (backlog), из которого хотелки попадали в план следующего месяца.
В терминологии Скрама нет понятия «demo», существует «Sprint Review», и это собрание проводится отнюдь не скрам-мастером (который может даже не пристутствовать на нем), а все же самим виночерпием.
Ретроспектива проводится не во время «показа», а в виде отдельного собрания. И обсуждается тут все же не сделанное, а успехи и проблемы в процессе разработки. Ну и совершенно отдельным собранием проводится планирование. «Хотелки» записываются все же не просто в «backlog», а в Product Backlog (который отличается от Sprint Backlog и уж точно не обязан формулироваться с применением User Stories).
Следует четко понимать, что итеративные методики разработки приносят с собой высокие накладные расходы, так как проводится большой объем работы по самокоррекции каждый цикл. Поэтому применяются подобные методики там, где нет возможности (по целому ряду причин) разработать эффективный план. Пример с постройкой дома — это пример неправильного применения итеративных методик. В постройке типового дома (сайта, форума, магазина) есть давно отработанные технологии, опирающиеся на опыт создания таких же типовых продуктов. Использовать Скрам для этого — это тратить дорого оплаченное время разработчиков.
Осталось впечатление, что эта статья не про гибкие методы разработки, не про Скрам, а про то, что автор пытается нам объяснить, что гвозди не стоит забивать микроскопом, даже если сейчас это крайне «модно и молодежно» и практикуется всеми «красноглазыми пионерами».
За это автору особая благодарность!Pran Автор
11.11.2018 15:34Спасибо за обстоятельный комментарий! Спорить с Вами не буду, ибо спор получится в разных (непересекающихся) плоскостях. У каждого закона есть «буква» и есть «дух». Ваши доводы лежат в плоскости «буквы» (т.е. так как хотелось бы в идеале), мои — в плоскости «духа» (как получилось в жизни). Я старался описать практику воплощения Agile в жизни вокруг меня, а не тот идеал который можно представить прочитав теорию. К сожалению, вокруг меня «красноглазые пионеры» вовсю «забивают гвозди микроскопом» азартно расписывая «сферического коня в вакууме». Но не могу отрицать, что мне просто не повезло в жизни, и что где-то может существовать то приближение к идеалу, которое позволит решать любые задачи при помощи Agile.
feodorbene
11.11.2018 14:38+3Статья совершенно правильно и справедливо изобличает аджайл.
От себя добавлю еще несколько граней проблемы:
Во-первых, не всегда все зло идет от исполнителя. Очень часто оно идет от заказчика, и это для многих главный мотив смотреть в сторону аджайла. Заказчик, неспособный внятно сформулировать свою проблему и требуемые характеристики решения, особенно если он ещё и неспособен понять, что он неспособен — это чума и проклятье, потому что по мере прогресса он будет постоянно менять требования, вносить «маленькие» изменения, не считаясь с глубиной требуемых преобразований, будет вдруг вспоминать «самоочевидные» требования и иначе пить вашу кровь. В аналогии с ремонтом это взбалмошная домохозяйка, которая никак не видит конечного результата, приходит к вам каждый день на стройку и просит «перенести вот сюда розеточку» или ее осеняет новая гениальная идея, что-де надо вот тут все покрыть ламинатом, повесить огромную люстру и забабахать теплый пол, и вот тогда точно совсем шик будет, а на другой день она говорит, что тут нужна плитка, и она не помнит, чтобы она что-то говорила про ламинат. Да, вы можете просто отказаться работать с таким клиентом, но придет мужик с аджайлом и заберет себе этот заказ и эти деньги.
Во-вторых, аджайл очень кстати приходится, когда нужно оправдать полный бардак и ужас. Нигде в аджайле вроде бы неинаписано, что качество должно быть дерьмо, что не нужен кодстайл гайд или не должно в принципе быть никакого планирования сверх двух недель, но вся эта философия (как и полагается настоящей философии) составлена настолько абстрактно, что всяк ищущий да обрящет нужную себе трактовку. Совершенно понятно, что изматывая команду жесткими ежедвухнедельнымт дедлайнами, забив на качество кода и поправ планировпние в пользу одноразовых «костылей» можно в краткосрочной перспективе повысить отдачу — и на это руководители и ведутся. Пока станет очевидно, что код превратился в нечитаемый и нераспутываемый гигантский клубок, словно колтун на теле бродячей собаки, и его можно только выкинуть и написать заново, а лучшие инженеры разбежались, проходит достаточное количество времени. Как говорится в старом советском анекдоте, руководитель от предшественника получает три конверта: в первом надпись «вали всё на меня», во втором — «признай ошибки и проведи реорганизацию», в третьем — «готовь три конверта». Вот на втором этапе аддайл и пригождается, что дает ему непреходящую популярность.
В-третьих, аджайл работает, как секта: настоящий аджайл предусматривает наличие сертифицированного скрам-мастера, как правило — со стороны, и должностенка очень непыльная: знай — ходи, объясняй с умным видом, как другим людям жить надо, а ответственности — никакой. Неудивительно, что пророки размножаются почкованием со страшной скоростью и несут свой свет в массы. В этой роли они конкурируют с индийскими гуру, выступающими в Сбербанке, и санлайтом, утащившим на дно Уралсиб. Это происходит все вполне в духе современных мистических веяний и трудной экономической обстановке. Погреть руки еа чужой беде желающих завсегда хоть отбавляй.
В-чнтвертых, если уж выискивать в аджайла зерна здравого смысла, то надо сказать, что в каком-то облагороженном виде он подходит для опытно-конструкторских разработок и прочей кустарщины. Дело в том, что если ты не знаешь, как сделать то, что тебе надо сделать, то писать детальный план в общем-то бесполезно. Когда ты строишь дом по отточеным технологиям или ваяешь сайты, ты можешь хотя бы примерно все оценить, расписать и распланировать. Если ты делаешь что-то первый раз в истории, какой-нибудь новый, технологически насыщенный продукт с долей исследовательского труда, то никакой альтернативы итеративному подходу нет. Например, если вас заказчик попросит построить дом из пивных бутылок, едва ли вы четко ответите на все вопросы до того, как сможете начать выполнять план — надо брать и пробовать, ввязаться в бой, а там посмотрим. Тут вам пригодится аджайл.
В-пятых, я считаю, что многие проблемы современной разработки ПО идут корнями в принципиально устаревшую технологию создания программ. Вначале компьютеры программировались переключением перемычек, но довольно быстро, по мере роста сложности программ, с этого подхода переключились на перфоленты и перфокарты, а потом и на языки программирования, которые довольно быстро сэволюционировали до Си и потом с++. После этого ничего принципиально не менялось долгое время, а сложность программ продолжала расти, что выливалось во все больший объем кода. Вместо новых прорывов в способах написания кода прогресс пошел в основном по линии усовершенствоаания разделения труда — с помощью паттернов программирования, методологий организации команд, технологий хранения кода и совместной работы над ним, автоматизации тестирования и сборки, и т. п. Но у всего есть предел, и в основе всего — вме те же полотнища текста, что в современном мире визуального, рилтаймового пользовательского интерфейса смотрится весьма и весьма архаично. Последние годы народ ударился в специализировованные под узкие задачи языки программирования — для веб-разработки, для мобильников, для раьоты с данными, — но все они по сути своей примитивнее с++, решают лишь частные проблемы, и плодят многочисленные ограничения, ниши, и тонны скопированного кода. В ту же сторону пошел и сам с++, где с 11 версии в стандарт языка начали сваливать кучу всевозможных частных решений под типовые задачи. По сути, мы видим кризис и острую потребность в новой революции в программировании, нечто, что выведет написание кода на уровень современного CAD-проектирования, например, что-то задействующее современные возможности среды и интерфейсов в полной мере.
OpenPM
11.11.2018 14:40Agile это очередная попытка выстроить отношения (причем экономические) между Заказчиком и Исполнителем. Автор рассмотрел только со стороны интереса Исполнителя, мол ему интересно работать вечно, постоянно получая свои бонусы за работу. При этом, в начале статьи очень верные написал слова…
"
все руководители во все времена использовали гибкую методику для создания своего внутреннего (на свой страх и риск) продукта потому, что:
- достаточно компетентны для проектирования конечного результата;
- достаточно компетентны для контроля за ходом процесса;
- имеют достаточно власти над подчинёнными участниками процесса;
- соотношение срока, стоимости и качества работ не являются для них догмой и могут при необходимости пересматриваться (так как «сам себе хозяин»);
- а самое главное — и конечный результат и процесс его достижения находится в одних руках, и преследуют один коммерческий интерес.....
Важным является компетентность людей, которые МОГУТ гарантировать сроки и определнное качество. Почему же в течении многих лет, все активнее проталкивается идея гибких технологий на смену классической.
На мой взгляд, нежелание заказчика платить за «опытные образцы». Мы все прекрасно понимаем, что сфера программной разработки все время находится для заказчика на стадии кастомизации. Он же не желает купить то что есть, потому что у него почти все также только есть несколько нюансов. Однако Исполнителю хочется продать, заработать. Вот на этом канате финансовых интересов и начинает работать механизм торговли неведомым, но очень красивым и нужным результатом. Исполнитель естественно пытается себя оградить от «лишней» работы, а Заказчик считает, что все пробные варианты. Демо, которые устраивает Исполнитель — почему-то считается, что если я как Заказчик не принял, потому что посмотрев, я понял, что надо изменения внести — я трактую как неверно понятые Исполнителем требования. И истинно считаю, что и платить за это не должен. Встречаются 2 полюса интереса. Исполнителю кажется, что он работает вечно и бесплатно, Заказчику кажется, что вот же архаровцы — хорошо устроились. По часам с меня деньги стригут, а то, что я хочу — сделать не могут. Реальность же такова, что сущности ИТ решений иногда сложно донести до Заказчику, слишком разные понятия в голове у людей из разных предметных областей. И вот тут как раз велика роль руководителя проекта со стороны Исполнителя, который может с бизнесом разговаривать на его языке, а с проектной командой на их языке. НО! Если у заказчика только фараон, и отсутствует виночерпий ВЕЛИКИ риски врюхаться в долгострой и неплатежи. А agile — лишь способ представления грамотно выстроенной системы работы над проектом, которая увы теряет свое качество ввиду отсутствия компетентности на разных уровнях взаимодействия Заказчика и Исполнителя.
Спасибо за статью.
Mikluho
12.11.2018 08:06-2Вот вроде бы и по делу, но, всё же, искажение информации в угоду личным мотивам.
Давайте мух отдельно, котлеты отдельно, а фараонов вообще не будет теребить (ибо некому встать на защиту их методологий).
Есть теория — скрамгайд, где описано мнение авторов о том, как должен выглядеть эффективныйнабор базовых элементов и правил, своего рода каркас, на котором строится процесс разработки
Более того, у истоков этой теории не разработчики, а заказчики. Именно им важно идти в ногу со временем и не оказываться в ситуации, когда год планировали, два делали, а поезд уже ушёл.
Есть очень разная практика. На мой личный вкус — скрам очень даже годен, но, как всякое блюдо, его надо правильно готовить. :)
К сожалению, многие пытаются пихать его куда ни попадя, не разбирая целей и средств. А для некоторых он лишь реинкарнация методологии «тяп ляп и готово».
И всё это никак не связано с тем, внутренний заказчик или внешний.
Ибо для того, чтобы хорошо рулить, нужен не только руль, но и чтобы он подходил к транспортному средству и чтобы его держали прямые руки.
ggo
12.11.2018 10:58Гибкая методология ограничено пригодна и для внешних проектов. В этом случае, к product owner-у Заказчика применимы те же требования, что и к руководителю внутреннего проекта, т. е. этот человек должен быть настоящим IT-профессионалом, а не секретарём тянущим временную обузу по-совместительству. Он должен быть в состоянии проверить квалификацию нанятой команды и постоянно контролировать качество разрабатываемого продукта. Кроме того, сам разрабатываемый продукт должен позволять (в случае форс-мажора) замену команды разработчиков. Только в этом случае можно рассчитывать, что не будет «обидно и больно за бесцельно прожитые годы».
Подкину еще про неточности…
Product Owner — чувак, отвечающий за продукт, какими свойствами он (продукт) должен обладать, как его продавать, кому его продавать и т.д.
Конечно, если речь идет про продукт, основанный на ИТ, было бы замечательно, чтобы PO разбирался в ИТ. Это решило бы множество проблем. Но таких людей мало, и поэтому в PO выбирают тех, кто умеет создавать и развивать продукты, а не шарит в ИТ.
Да, в пару к PO, нужен грамотный (ну пусть будет) Team Lead. «Пусть будет», потому что его обзывают по разному. И уже Team Lead, в свою очередь, собирает команду и определяет на чем с точки зрения ИТ работает продукт.
Вам не кажется, что качество программных продуктов падает пропорционально широте распространения Agile в отрасли? Откуда взяться качеству, если весь процесс заточен на решении задач самым простым и быстрым способом из всех возможных? А думать вперёд официально запрещено методологией!
Кажется.
Только первопричина не в agile, а в целом, в глобализации и консьюмеризации (мы же про продукты на основе ИТ). Много людей знает сервисов, занимающих второе место после whatsapp, instagram, twitter, uber, etc? (с учетом локальности — ну в смысле, что в китае например свои аналоги whatsapp, instagram и т.д., но суть от этого не меняется)
Второе, третье, и тем более дальше, места — никто про них не в курсе.
Хочешь выжить на изменчивом рынке — изменяйся с той же скоростью, или быстрее.
Leg3nd
Не кажется)
sentyaev
Код программы это и есть blueprint. Просто фаза «build» у нас бесплатная, с определенной долей условности.
Leg3nd
Так, наверное, даже правильней будет проводить аналогию) А UML — это просто еще один удобный способ показать внутренний процесс или структуру, там где с помощью кода это не так наглядно или не так быстро
random1st
А вот мне очень даже кажется. Системно-инженерный подход в этом плане куда более привлекателен, чем Agile.