Comments 33
Вам не кажется подозрительным тот факт, что гибкая методология не прижилась нигде, кроме контрактных разработок программного обеспечения? Ну не делают по Scrum-у ни подводные лодки, ни самолёты, ни автомобили. Мудрость предков учит нас, что даже нормальную собачью будку нельзя сколотить без этапа проектирования (карандашный набросок с размерами) и подготовки ТЗ (перечень материалов и инструментов).
Не кажется)
Why do architects, aerospace engineers, and structural engineers all draw blueprints. The reason is that one person can draw the blueprints for a home that will require five or more people to build. A few dozen aerospace engineers can draw blueprints for an airplane that will require thousands of people to build. Blueprints can be drawn without digging foundations, pouring concrete, or hanging windows. In short, it is much cheaper to plan a building up front than to try to build it without a plan. It doesn't cost much to throw away a faulty blueprint, but it costs a lot to tear down a faulty building.
Once again, things are not so clear-cut in software. It is not at all clear that drawing UML diagrams is much cheaper than writing code. Indeed, many project teams have spent more on their diagrams than they have on the code itself. It is also not clear that throwing away a diagram is much cheaper than throwing away code. Therefore, it is not at all clear that creating a comprehensive UML design before writing code is a cost-effective option.
Apparently, architecture, aerospace engineering, and structural engineering do not provide a clear metaphor for software development. We cannot blithely use UML the way those other disciplines use blueprints and models
Diagrams are most useful for communicating with others and for helping you work out design
problems. It is important that you use only the amount of detail necessary to accomplish your goal.
Loading a diagram with lots of adornments is possible but counterproductive. Keep your diagrams
simple and clean. UML diagrams are not source code and should not be treated as the place to
declare every method, variable, and relationship.
Martin C. Robert, Martin Micah. Agile Principles, Patterns, and Practices in C#
UFO just landed and posted this here
Присоединяюсь, сам похожим образом всегда формулировал чем является agile в целом и scrum в частности. Особо сложно с ярыми поклонниками методологии
Тут есть психологическая ловушка. Доя agile процесса не нужно думать о всех подводных камнях сразу, можно сказать что решим тогда, когда настанет время решать этот вопрос. И это чертовски приятно пустить все на самотек и не думать о всем грузе проблем, что могут быть. Ну и конечно же банальное отсутствме компетентности — ты не сможешь точно посчитать стоимость, сроки если такого никогда не делал.
Имхо agile хорош для динамично развивающихся проектов, где требования могут устареть быстрее, чем будут реализваны. А также для проектов, в которых ничего не понятно, но не жалко рискнуть и потратить какое то время ради перспективности.
Ну и конечно же аджайл не должен использоваться там, где нужен какой-то гарантированный результат. Отчасти именно поэтому такой подход не применим для инженеров — они должны выпустить продукт в определенные сроки с заданными характеристиками
Баян конечно, но в тему:
UFO just landed and posted this here
способностями конкретного руководителя «не потерять лес за деревьями»
чаще ровно наоборот — лес они видят прекрасно, они воюют за лес, а вот отдельные деревья — не различают. Им важно чтобы был правильный лес. А то что он состоит из правильных деревьев — им не очевидно.
Но с другой стороны — вот у нас уже 4 год как скрам (или как мы его зовем срам) — вполне нормально. Разработчики сами пишут тикеты в баклог. Сами ставят сроки, в пределах спринта, а продакт менеджер — выбирает или не выбирает тот или иной тикет в следующий спринт. Редко задает вопросы про сроки. И никогда не стремится сделать их короче. Интересуется в целом что пошло не так. Какие текущие проблемы от юзеров и пр.
В общем почти никакого давления. И, тем не менее, — вот само наличие обсуждений каждые 2 недели и, казалось бы, всего-лишь на час, а дает вполне ощутимый импульс в темпах разработки. Видимо, через самодисциплину, и через бОльшую открытость чем раньше.
Тема не раскрыта, историчности нет, от фараонов сразу к нашим дням
Автор, спасибо! Тоже периодически размышлял на эту тему и чувствовал, что чего-то недопонимаю. Не хватало одного кирпичика — противопоставления внутренней и заказной разработки. Теперь все встало на свои места (в моей картине мира)
Есть два тезиса. Первый: пока вы делаете идеальный продукт, кто-то выпустит (так себе) продукт раньше и завоюет рынок. Второй: можно и нужно выпускать лажу, чтобы потом допилить. Оба оправдывают аморальное отношение к потребителю продукта, оба могут принести прибыль ценой непорядочного поведения.
Для оправдания беспринципного извлечения прибыли Agile и особенно SCRUM подходят идеально. Херак-херак и в продакшн. Потребитель обманут, но уже заплатил (и ещё заплатит). Да ещё и добровольно. Вот и вся мораль.
Внутренние мелкие проекты, ну да. Фиг с ними. Иногда можно. Устроить ритуальные хороводы и посиделки. Внешние — это жульничество и запланированный обман потребителя. Высокие слова про гибкую методологию разработки — просто способ спрятаться от совести. Типа все ж согласились, какой-такой обман?
А ещё это очень часто просто карго-культ, помогающий прятать некомпетентность команды и руководства.
PS В первых же абзацах манифеста есть упоминание про компактные команды профессионалов, но кто ж на такие мелочи внимание обращает? И огромные и сильно разбалансированные по квалификации, все туда ломятся.
Для оправдания беспринципного извлечения прибыли Agile и особенно SCRUM подходят идеально. Херак-херак и в продакшн. Потребитель обманут, но уже заплатил (и ещё заплатит). Да ещё и добровольно. Вот и вся мораль.
Внутренние мелкие проекты, ну да. Фиг с ними. Иногда можно. Устроить ритуальные хороводы и посиделки. Внешние — это жульничество и запланированный обман потребителя. Высокие слова про гибкую методологию разработки — просто способ спрятаться от совести. Типа все ж согласились, какой-такой обман?
А ещё это очень часто просто карго-культ, помогающий прятать некомпетентность команды и руководства.
PS В первых же абзацах манифеста есть упоминание про компактные команды профессионалов, но кто ж на такие мелочи внимание обращает? И огромные и сильно разбалансированные по квалификации, все туда ломятся.
"Первый: пока вы делаете идеальный продукт, кто-то выпустит (так себе) продукт раньше и завоюет рынок."
Так говорили стиву джобсу, увольняя его из эппл
Мне кажется, что Вы слишком категоричны. Даже если принять утверждение что Agile — зло (а я так вовсе не утверждаю в статье), то и тогда правильно будет различать сознательных последователей зла и заблудших последователей. Последние часто юны, неопытны и поэтому кроме Agile ничего не видели, а значит им просто не с чем сравнивать.
Я тут вчера пирог испёк. На начальном этапе в ТЗ были только индюшачий фарш и тесто.
Но гибкая методология позволила мне добавить в него по ходу приготовления томатный соус, овощи и сыр, и только потом всё запечь.
Получилось намного лучше, чем если бы я прямолинейно действовал по начальной спецификации, а не менял спеки по ходу разработки.
Да, процесс занял в полтора раза дольше, пришлось использовать дополнительные компоненты и тестировать взаимосвязи между ними, сложность выросла. Но результат — что надо!!
Таким образом, гибкие методики очень даже хороши, когда спецификации приходится менять по ходу дела, а заказчик не полностью уверен в том, что хочет получить в итоге — поэтому и приходится вовлекать его в процесс разработки.
Приятного аппетита))
гибкие методики очень даже хороши, когда спецификации приходится менять по ходу дела, а заказчик не полностью уверен в том, что хочет получить в итоге
Можно дождаться, когда заказчик протрезвеет и будет знать, что он хочет получить в итоге. Возможно ему сложно это сформулировать, но на то и опытный разработчик, что он может предложить варианты вплоть до прихода к единому консенсусу с заказчиком. Но говорить, что заказчик хочет платить деньги за разработку, не зная при этом чего он хочет — в высшей степени наивно.
PS Да, и я ел ваш пирог, точнее выплюнул — когда по ходу дела из него выковыривали лук по причине изменения спецификации, кто-то оставил в нем свой ноготь
Надеюсь, что Вы готовили пирог лично для себя. Если так, то Ваш опыт только подтверждает смысл статьи. Приятного аппетита!
К одному человеку ночью явился ангел и сообщил, что завтра дьявол отравит воду в городском колодце и все жители города сойдут с ума. Человек запасся чистой водой, но у него возникли проблемы. Все жители выпили отравленной воды и сошли с ума, но они не знали об этом и считали сумасшедшим того человека, который не пил воду из колодца, и ему никак не удавалось убедить других, что все они сошли с ума… Не знаю, почему мне вспомнилась эта притча, наверное потому что скрам всегда казался мне коллективным безумием интеллектуально незрелых людей и автор статьи сейчас получит от них массу пинков. И все они будут чувствовать свою абсолютную правоту, так как пили воду из одного колодца.
Поставил Вам плюс. Хорошо аргументированная статья.
Хотя Вы и не упомянули о том, сколько было заработано на выдаче сертификатов Scrum мастерам. Мне кажется это они поставили под сомнение ценность сертификатов в IT в целом.
Как-то надо попробовать перейти от слов к числам. Перечислить характеристики проектов, получим многомерное пространство. В нём определить область, где agile работает, а где нет.
Не хотите попробовать?
Хотя Вы и не упомянули о том, сколько было заработано на выдаче сертификатов Scrum мастерам. Мне кажется это они поставили под сомнение ценность сертификатов в IT в целом.
Как-то надо попробовать перейти от слов к числам. Перечислить характеристики проектов, получим многомерное пространство. В нём определить область, где agile работает, а где нет.
Не хотите попробовать?
Спасибо за плюс и предложение! Но попробовать не хочу. Привык серъёзно относиться к тому, что делаю, а Вы предлагаете целое отраслевое исследование, для выполнения которого у меня просто нет статистики и времени. Одно дело описать свои личные (субъективные) ощущения в статье, и совсем другое дело — предоставить конкретные цифры с претензией на объективность. Тут занятие не на один месяц для целого коллектива исследователей.
Жалко что не хотите. Статистику искать не надо, её скорее и не существует. Софтверные фирмы замалчивают свои промахи, а тем более стоимости проектов. Круппные подрядчики типа государствееных служб тоже.
А вот предложить релевантные факторы и шкалы их измерений может любой опытный разработчик. И к каждому фактору — информацию о том, как он влияет на решение использовать агильный подход — положительно или отрицательно.
Например: фактор «Размер команды». Измеряем в головах. От 3 до 9 — в пользу применения агильного подхода. Зампределами — против.
Завести проект в GitHub с табличкой…
А вот предложить релевантные факторы и шкалы их измерений может любой опытный разработчик. И к каждому фактору — информацию о том, как он влияет на решение использовать агильный подход — положительно или отрицательно.
Например: фактор «Размер команды». Измеряем в головах. От 3 до 9 — в пользу применения агильного подхода. Зампределами — против.
Завести проект в GitHub с табличкой…
У каждого есть право на свое мнение, оставлю свои две копейки здесь.
К сожалению, мне очень кажется, что автор статьи не читал вдумчиво первоисточники, если уже в первых строках ссылается на Википедию, а не на текст самого манифеста: agilemanifesto.org
Авторы методологии Скрам напрямую указывают, что проект можно развивать по любым правилам, но называть его Скрам-проектом разрешено только тогда, когда все спринт-цикл с сопутствующими ролями и артефактами выдержаны на 100 % (сравните хотя бы последний абзац из «Руководства по Скраму» (https://www.scrumguides.org/). По всей видимости, большинство проектов, заявляющие Скрам в качестве методологии разработки, живут по каким-то совершенно другим правилам.
Автор допускает ряд терминологических неточностей:
Виночерпий в этом случае все же отвечает не за проект, а за продукт, то есть за результат, а не за процесс.
«Грамотный каменщик» — это совершенно не роль скрам-мастера, тут скорее нужен массажист или кухарка. А высококвалифицированные каменщики будут входить в команду разработчиков (Development Team, совсем не Scrum Team). Не стоит передавать роль тимлида скрам-мастеру.
В терминологии Скрама нет понятия «demo», существует «Sprint Review», и это собрание проводится отнюдь не скрам-мастером (который может даже не пристутствовать на нем), а все же самим виночерпием.
Ретроспектива проводится не во время «показа», а в виде отдельного собрания. И обсуждается тут все же не сделанное, а успехи и проблемы в процессе разработки. Ну и совершенно отдельным собранием проводится планирование. «Хотелки» записываются все же не просто в «backlog», а в Product Backlog (который отличается от Sprint Backlog и уж точно не обязан формулироваться с применением User Stories).
Следует четко понимать, что итеративные методики разработки приносят с собой высокие накладные расходы, так как проводится большой объем работы по самокоррекции каждый цикл. Поэтому применяются подобные методики там, где нет возможности (по целому ряду причин) разработать эффективный план. Пример с постройкой дома — это пример неправильного применения итеративных методик. В постройке типового дома (сайта, форума, магазина) есть давно отработанные технологии, опирающиеся на опыт создания таких же типовых продуктов. Использовать Скрам для этого — это тратить дорого оплаченное время разработчиков.
Осталось впечатление, что эта статья не про гибкие методы разработки, не про Скрам, а про то, что автор пытается нам объяснить, что гвозди не стоит забивать микроскопом, даже если сейчас это крайне «модно и молодежно» и практикуется всеми «красноглазыми пионерами».
За это автору особая благодарность!
К сожалению, мне очень кажется, что автор статьи не читал вдумчиво первоисточники, если уже в первых строках ссылается на Википедию, а не на текст самого манифеста: 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).
Следует четко понимать, что итеративные методики разработки приносят с собой высокие накладные расходы, так как проводится большой объем работы по самокоррекции каждый цикл. Поэтому применяются подобные методики там, где нет возможности (по целому ряду причин) разработать эффективный план. Пример с постройкой дома — это пример неправильного применения итеративных методик. В постройке типового дома (сайта, форума, магазина) есть давно отработанные технологии, опирающиеся на опыт создания таких же типовых продуктов. Использовать Скрам для этого — это тратить дорого оплаченное время разработчиков.
Осталось впечатление, что эта статья не про гибкие методы разработки, не про Скрам, а про то, что автор пытается нам объяснить, что гвозди не стоит забивать микроскопом, даже если сейчас это крайне «модно и молодежно» и практикуется всеми «красноглазыми пионерами».
За это автору особая благодарность!
Спасибо за обстоятельный комментарий! Спорить с Вами не буду, ибо спор получится в разных (непересекающихся) плоскостях. У каждого закона есть «буква» и есть «дух». Ваши доводы лежат в плоскости «буквы» (т.е. так как хотелось бы в идеале), мои — в плоскости «духа» (как получилось в жизни). Я старался описать практику воплощения Agile в жизни вокруг меня, а не тот идеал который можно представить прочитав теорию. К сожалению, вокруг меня «красноглазые пионеры» вовсю «забивают гвозди микроскопом» азартно расписывая «сферического коня в вакууме». Но не могу отрицать, что мне просто не повезло в жизни, и что где-то может существовать то приближение к идеалу, которое позволит решать любые задачи при помощи Agile.
Статья совершенно правильно и справедливо изобличает аджайл.
От себя добавлю еще несколько граней проблемы:
Во-первых, не всегда все зло идет от исполнителя. Очень часто оно идет от заказчика, и это для многих главный мотив смотреть в сторону аджайла. Заказчик, неспособный внятно сформулировать свою проблему и требуемые характеристики решения, особенно если он ещё и неспособен понять, что он неспособен — это чума и проклятье, потому что по мере прогресса он будет постоянно менять требования, вносить «маленькие» изменения, не считаясь с глубиной требуемых преобразований, будет вдруг вспоминать «самоочевидные» требования и иначе пить вашу кровь. В аналогии с ремонтом это взбалмошная домохозяйка, которая никак не видит конечного результата, приходит к вам каждый день на стройку и просит «перенести вот сюда розеточку» или ее осеняет новая гениальная идея, что-де надо вот тут все покрыть ламинатом, повесить огромную люстру и забабахать теплый пол, и вот тогда точно совсем шик будет, а на другой день она говорит, что тут нужна плитка, и она не помнит, чтобы она что-то говорила про ламинат. Да, вы можете просто отказаться работать с таким клиентом, но придет мужик с аджайлом и заберет себе этот заказ и эти деньги.
Во-вторых, аджайл очень кстати приходится, когда нужно оправдать полный бардак и ужас. Нигде в аджайле вроде бы неинаписано, что качество должно быть дерьмо, что не нужен кодстайл гайд или не должно в принципе быть никакого планирования сверх двух недель, но вся эта философия (как и полагается настоящей философии) составлена настолько абстрактно, что всяк ищущий да обрящет нужную себе трактовку. Совершенно понятно, что изматывая команду жесткими ежедвухнедельнымт дедлайнами, забив на качество кода и поправ планировпние в пользу одноразовых «костылей» можно в краткосрочной перспективе повысить отдачу — и на это руководители и ведутся. Пока станет очевидно, что код превратился в нечитаемый и нераспутываемый гигантский клубок, словно колтун на теле бродячей собаки, и его можно только выкинуть и написать заново, а лучшие инженеры разбежались, проходит достаточное количество времени. Как говорится в старом советском анекдоте, руководитель от предшественника получает три конверта: в первом надпись «вали всё на меня», во втором — «признай ошибки и проведи реорганизацию», в третьем — «готовь три конверта». Вот на втором этапе аддайл и пригождается, что дает ему непреходящую популярность.
В-третьих, аджайл работает, как секта: настоящий аджайл предусматривает наличие сертифицированного скрам-мастера, как правило — со стороны, и должностенка очень непыльная: знай — ходи, объясняй с умным видом, как другим людям жить надо, а ответственности — никакой. Неудивительно, что пророки размножаются почкованием со страшной скоростью и несут свой свет в массы. В этой роли они конкурируют с индийскими гуру, выступающими в Сбербанке, и санлайтом, утащившим на дно Уралсиб. Это происходит все вполне в духе современных мистических веяний и трудной экономической обстановке. Погреть руки еа чужой беде желающих завсегда хоть отбавляй.
В-чнтвертых, если уж выискивать в аджайла зерна здравого смысла, то надо сказать, что в каком-то облагороженном виде он подходит для опытно-конструкторских разработок и прочей кустарщины. Дело в том, что если ты не знаешь, как сделать то, что тебе надо сделать, то писать детальный план в общем-то бесполезно. Когда ты строишь дом по отточеным технологиям или ваяешь сайты, ты можешь хотя бы примерно все оценить, расписать и распланировать. Если ты делаешь что-то первый раз в истории, какой-нибудь новый, технологически насыщенный продукт с долей исследовательского труда, то никакой альтернативы итеративному подходу нет. Например, если вас заказчик попросит построить дом из пивных бутылок, едва ли вы четко ответите на все вопросы до того, как сможете начать выполнять план — надо брать и пробовать, ввязаться в бой, а там посмотрим. Тут вам пригодится аджайл.
В-пятых, я считаю, что многие проблемы современной разработки ПО идут корнями в принципиально устаревшую технологию создания программ. Вначале компьютеры программировались переключением перемычек, но довольно быстро, по мере роста сложности программ, с этого подхода переключились на перфоленты и перфокарты, а потом и на языки программирования, которые довольно быстро сэволюционировали до Си и потом с++. После этого ничего принципиально не менялось долгое время, а сложность программ продолжала расти, что выливалось во все больший объем кода. Вместо новых прорывов в способах написания кода прогресс пошел в основном по линии усовершенствоаания разделения труда — с помощью паттернов программирования, методологий организации команд, технологий хранения кода и совместной работы над ним, автоматизации тестирования и сборки, и т. п. Но у всего есть предел, и в основе всего — вме те же полотнища текста, что в современном мире визуального, рилтаймового пользовательского интерфейса смотрится весьма и весьма архаично. Последние годы народ ударился в специализировованные под узкие задачи языки программирования — для веб-разработки, для мобильников, для раьоты с данными, — но все они по сути своей примитивнее с++, решают лишь частные проблемы, и плодят многочисленные ограничения, ниши, и тонны скопированного кода. В ту же сторону пошел и сам с++, где с 11 версии в стандарт языка начали сваливать кучу всевозможных частных решений под типовые задачи. По сути, мы видим кризис и острую потребность в новой революции в программировании, нечто, что выведет написание кода на уровень современного CAD-проектирования, например, что-то задействующее современные возможности среды и интерфейсов в полной мере.
От себя добавлю еще несколько граней проблемы:
Во-первых, не всегда все зло идет от исполнителя. Очень часто оно идет от заказчика, и это для многих главный мотив смотреть в сторону аджайла. Заказчик, неспособный внятно сформулировать свою проблему и требуемые характеристики решения, особенно если он ещё и неспособен понять, что он неспособен — это чума и проклятье, потому что по мере прогресса он будет постоянно менять требования, вносить «маленькие» изменения, не считаясь с глубиной требуемых преобразований, будет вдруг вспоминать «самоочевидные» требования и иначе пить вашу кровь. В аналогии с ремонтом это взбалмошная домохозяйка, которая никак не видит конечного результата, приходит к вам каждый день на стройку и просит «перенести вот сюда розеточку» или ее осеняет новая гениальная идея, что-де надо вот тут все покрыть ламинатом, повесить огромную люстру и забабахать теплый пол, и вот тогда точно совсем шик будет, а на другой день она говорит, что тут нужна плитка, и она не помнит, чтобы она что-то говорила про ламинат. Да, вы можете просто отказаться работать с таким клиентом, но придет мужик с аджайлом и заберет себе этот заказ и эти деньги.
Во-вторых, аджайл очень кстати приходится, когда нужно оправдать полный бардак и ужас. Нигде в аджайле вроде бы неинаписано, что качество должно быть дерьмо, что не нужен кодстайл гайд или не должно в принципе быть никакого планирования сверх двух недель, но вся эта философия (как и полагается настоящей философии) составлена настолько абстрактно, что всяк ищущий да обрящет нужную себе трактовку. Совершенно понятно, что изматывая команду жесткими ежедвухнедельнымт дедлайнами, забив на качество кода и поправ планировпние в пользу одноразовых «костылей» можно в краткосрочной перспективе повысить отдачу — и на это руководители и ведутся. Пока станет очевидно, что код превратился в нечитаемый и нераспутываемый гигантский клубок, словно колтун на теле бродячей собаки, и его можно только выкинуть и написать заново, а лучшие инженеры разбежались, проходит достаточное количество времени. Как говорится в старом советском анекдоте, руководитель от предшественника получает три конверта: в первом надпись «вали всё на меня», во втором — «признай ошибки и проведи реорганизацию», в третьем — «готовь три конверта». Вот на втором этапе аддайл и пригождается, что дает ему непреходящую популярность.
В-третьих, аджайл работает, как секта: настоящий аджайл предусматривает наличие сертифицированного скрам-мастера, как правило — со стороны, и должностенка очень непыльная: знай — ходи, объясняй с умным видом, как другим людям жить надо, а ответственности — никакой. Неудивительно, что пророки размножаются почкованием со страшной скоростью и несут свой свет в массы. В этой роли они конкурируют с индийскими гуру, выступающими в Сбербанке, и санлайтом, утащившим на дно Уралсиб. Это происходит все вполне в духе современных мистических веяний и трудной экономической обстановке. Погреть руки еа чужой беде желающих завсегда хоть отбавляй.
В-чнтвертых, если уж выискивать в аджайла зерна здравого смысла, то надо сказать, что в каком-то облагороженном виде он подходит для опытно-конструкторских разработок и прочей кустарщины. Дело в том, что если ты не знаешь, как сделать то, что тебе надо сделать, то писать детальный план в общем-то бесполезно. Когда ты строишь дом по отточеным технологиям или ваяешь сайты, ты можешь хотя бы примерно все оценить, расписать и распланировать. Если ты делаешь что-то первый раз в истории, какой-нибудь новый, технологически насыщенный продукт с долей исследовательского труда, то никакой альтернативы итеративному подходу нет. Например, если вас заказчик попросит построить дом из пивных бутылок, едва ли вы четко ответите на все вопросы до того, как сможете начать выполнять план — надо брать и пробовать, ввязаться в бой, а там посмотрим. Тут вам пригодится аджайл.
В-пятых, я считаю, что многие проблемы современной разработки ПО идут корнями в принципиально устаревшую технологию создания программ. Вначале компьютеры программировались переключением перемычек, но довольно быстро, по мере роста сложности программ, с этого подхода переключились на перфоленты и перфокарты, а потом и на языки программирования, которые довольно быстро сэволюционировали до Си и потом с++. После этого ничего принципиально не менялось долгое время, а сложность программ продолжала расти, что выливалось во все больший объем кода. Вместо новых прорывов в способах написания кода прогресс пошел в основном по линии усовершенствоаания разделения труда — с помощью паттернов программирования, методологий организации команд, технологий хранения кода и совместной работы над ним, автоматизации тестирования и сборки, и т. п. Но у всего есть предел, и в основе всего — вме те же полотнища текста, что в современном мире визуального, рилтаймового пользовательского интерфейса смотрится весьма и весьма архаично. Последние годы народ ударился в специализировованные под узкие задачи языки программирования — для веб-разработки, для мобильников, для раьоты с данными, — но все они по сути своей примитивнее с++, решают лишь частные проблемы, и плодят многочисленные ограничения, ниши, и тонны скопированного кода. В ту же сторону пошел и сам с++, где с 11 версии в стандарт языка начали сваливать кучу всевозможных частных решений под типовые задачи. По сути, мы видим кризис и острую потребность в новой революции в программировании, нечто, что выведет написание кода на уровень современного CAD-проектирования, например, что-то задействующее современные возможности среды и интерфейсов в полной мере.
Agile это очередная попытка выстроить отношения (причем экономические) между Заказчиком и Исполнителем. Автор рассмотрел только со стороны интереса Исполнителя, мол ему интересно работать вечно, постоянно получая свои бонусы за работу. При этом, в начале статьи очень верные написал слова…
"все руководители во все времена использовали гибкую методику для создания своего внутреннего (на свой страх и риск) продукта потому, что:
- достаточно компетентны для проектирования конечного результата;
- достаточно компетентны для контроля за ходом процесса;
- имеют достаточно власти над подчинёнными участниками процесса;
- соотношение срока, стоимости и качества работ не являются для них догмой и могут при необходимости пересматриваться (так как «сам себе хозяин»);
- а самое главное — и конечный результат и процесс его достижения находится в одних руках, и преследуют один коммерческий интерес.....
Важным является компетентность людей, которые МОГУТ гарантировать сроки и определнное качество. Почему же в течении многих лет, все активнее проталкивается идея гибких технологий на смену классической.
На мой взгляд, нежелание заказчика платить за «опытные образцы». Мы все прекрасно понимаем, что сфера программной разработки все время находится для заказчика на стадии кастомизации. Он же не желает купить то что есть, потому что у него почти все также только есть несколько нюансов. Однако Исполнителю хочется продать, заработать. Вот на этом канате финансовых интересов и начинает работать механизм торговли неведомым, но очень красивым и нужным результатом. Исполнитель естественно пытается себя оградить от «лишней» работы, а Заказчик считает, что все пробные варианты. Демо, которые устраивает Исполнитель — почему-то считается, что если я как Заказчик не принял, потому что посмотрев, я понял, что надо изменения внести — я трактую как неверно понятые Исполнителем требования. И истинно считаю, что и платить за это не должен. Встречаются 2 полюса интереса. Исполнителю кажется, что он работает вечно и бесплатно, Заказчику кажется, что вот же архаровцы — хорошо устроились. По часам с меня деньги стригут, а то, что я хочу — сделать не могут. Реальность же такова, что сущности ИТ решений иногда сложно донести до Заказчику, слишком разные понятия в голове у людей из разных предметных областей. И вот тут как раз велика роль руководителя проекта со стороны Исполнителя, который может с бизнесом разговаривать на его языке, а с проектной командой на их языке. НО! Если у заказчика только фараон, и отсутствует виночерпий ВЕЛИКИ риски врюхаться в долгострой и неплатежи. А agile — лишь способ представления грамотно выстроенной системы работы над проектом, которая увы теряет свое качество ввиду отсутствия компетентности на разных уровнях взаимодействия Заказчика и Исполнителя.
Спасибо за статью.
Вот вроде бы и по делу, но, всё же, искажение информации в угоду личным мотивам.
Давайте мух отдельно, котлеты отдельно, а фараонов вообще не будет теребить (ибо некому встать на защиту их методологий).
Есть теория — скрамгайд, где описано мнение авторов о том, как должен выглядеть эффективный
Более того, у истоков этой теории не разработчики, а заказчики. Именно им важно идти в ногу со временем и не оказываться в ситуации, когда год планировали, два делали, а поезд уже ушёл.
Есть очень разная практика. На мой личный вкус — скрам очень даже годен, но, как всякое блюдо, его надо правильно готовить. :)
К сожалению, многие пытаются пихать его куда ни попадя, не разбирая целей и средств. А для некоторых он лишь реинкарнация методологии «тяп ляп и готово».
И всё это никак не связано с тем, внутренний заказчик или внешний.
Ибо для того, чтобы хорошо рулить, нужен не только руль, но и чтобы он подходил к транспортному средству и чтобы его держали прямые руки.
Давайте мух отдельно, котлеты отдельно, а фараонов вообще не будет теребить (ибо некому встать на защиту их методологий).
Есть теория — скрамгайд, где описано мнение авторов о том, как должен выглядеть эффективный
набор базовых элементов и правил, своего рода каркас, на котором строится процесс разработки
Более того, у истоков этой теории не разработчики, а заказчики. Именно им важно идти в ногу со временем и не оказываться в ситуации, когда год планировали, два делали, а поезд уже ушёл.
Есть очень разная практика. На мой личный вкус — скрам очень даже годен, но, как всякое блюдо, его надо правильно готовить. :)
К сожалению, многие пытаются пихать его куда ни попадя, не разбирая целей и средств. А для некоторых он лишь реинкарнация методологии «тяп ляп и готово».
И всё это никак не связано с тем, внутренний заказчик или внешний.
Ибо для того, чтобы хорошо рулить, нужен не только руль, но и чтобы он подходил к транспортному средству и чтобы его держали прямые руки.
Гибкая методология ограничено пригодна и для внешних проектов. В этом случае, к product owner-у Заказчика применимы те же требования, что и к руководителю внутреннего проекта, т. е. этот человек должен быть настоящим IT-профессионалом, а не секретарём тянущим временную обузу по-совместительству. Он должен быть в состоянии проверить квалификацию нанятой команды и постоянно контролировать качество разрабатываемого продукта. Кроме того, сам разрабатываемый продукт должен позволять (в случае форс-мажора) замену команды разработчиков. Только в этом случае можно рассчитывать, что не будет «обидно и больно за бесцельно прожитые годы».
Подкину еще про неточности…
Product Owner — чувак, отвечающий за продукт, какими свойствами он (продукт) должен обладать, как его продавать, кому его продавать и т.д.
Конечно, если речь идет про продукт, основанный на ИТ, было бы замечательно, чтобы PO разбирался в ИТ. Это решило бы множество проблем. Но таких людей мало, и поэтому в PO выбирают тех, кто умеет создавать и развивать продукты, а не шарит в ИТ.
Да, в пару к PO, нужен грамотный (ну пусть будет) Team Lead. «Пусть будет», потому что его обзывают по разному. И уже Team Lead, в свою очередь, собирает команду и определяет на чем с точки зрения ИТ работает продукт.
Вам не кажется, что качество программных продуктов падает пропорционально широте распространения Agile в отрасли? Откуда взяться качеству, если весь процесс заточен на решении задач самым простым и быстрым способом из всех возможных? А думать вперёд официально запрещено методологией!
Кажется.
Только первопричина не в agile, а в целом, в глобализации и консьюмеризации (мы же про продукты на основе ИТ). Много людей знает сервисов, занимающих второе место после whatsapp, instagram, twitter, uber, etc? (с учетом локальности — ну в смысле, что в китае например свои аналоги whatsapp, instagram и т.д., но суть от этого не меняется)
Второе, третье, и тем более дальше, места — никто про них не в курсе.
Хочешь выжить на изменчивом рынке — изменяйся с той же скоростью, или быстрее.
Sign up to leave a comment.
Мифы и легенды Agile — oт фараонов до наших дней