Слова на доске
Не секрет, что истоком всех Agile движений был митинг, произошедший в феврале 2001 года на горнолыжном курорте в штате Юта. Как выразился Robert C. Martin, зачинщик мероприятия, там собралась группа умных людей, которые никогда не встречались ранее и не планировавших встретиться в будущем. Цель собрания была одна — выразить нечто общее, что объединяло бы всех присутствующих.
О том, как создавался Agile манифест, есть много статей написанных самими участниками процесса [1], [2], [3]. Суть происходящего была в следующем: каждый из участников выписал на карточки идеи выражающие его точку зрения, и после того как карточки были организованы по категориям, стали очевидны четыре пункта, в которых все были единодушны. Далее они были красиво сформулированы:
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
Документу нужно было придумать название, для которого голосованием было выбрано слово Agile, как признает Martin Fowler — не слишком подходящее слово.
Несущественное дополнение
Далее Agile манифест был расширен 12 принципами, но на их финальное согласование ушло еще несколько месяцев переписки по e-mail, что наводит на мысль о их второстепенной важности.
К слову, одним из принципов является релиз с частотой от двух недель до двух месяцев, что по сравнению с современными нормами — пара релизов в день — звучит архаично.
С другими пунктами тоже не все гладко, вот еще один пример: “Рабочее программное обеспечение — это главная мера прогресса проекта”. Это сомнительная метрика уже потому, что протестированное и выпущенное приложение совсем не означает, что оно окажется хоть кому-то полезным.
Неожиданные последствия
В событии участвовало семнадцать далеко не ординарных человек. Краткий список их достижений и вклада в индустрию можно посмотреть
- Kent Beck — XP co-founder, TDD, xUnit, Software Design Patterns.
- Mike Beedle — 2nd Scrum Adopter.
- Arie van Bennekum — Pragmatic.
- Alistair Cockburn — Crystal Methods, Software Design Patterns.
- Ward Cunningham — developed first Wiki, Design patterns, XP co-founder, invented Framework for integrated tests.
- Martin Fowler — Code Refactoring & Dependency Injection, UML, design patterns, XP.
- James Grenning — trains, coaches and consults worldwide, TDD for embedded systems.
- Jim Highsmith — Adaptive Software Development (methodology).
- Andrew Hunt — The Pragmatic Programmer book co-author.
- Ron Jeffries — XP co-founder.
- Jon Kern — in general respectable person.
- Brian Marick — The Craft of Software Testing (book).
- Robert C. Martin — SOLID principles, Software craftsmanship, Clean Code (book).
- Steve Mellor — developer of the Shlaer–Mellor method and Executable UML.
- Ken Schwaber — Scrum co-founder, www.agilealliance.org.
- Jeff Sutherland — Scrum co-founder.
- Dave Thomas — The Pragmatic Programmer book co-author.
Если визуализировать список создателей Agile по их отношению к технологиям и методологиями, получается любопытная картина:
В общем участников можно разделить на три категории:
- Инженеры: Robert C. Martin, для примера — те, кто в первую очередь повлияли на развитие технологий.
- Менеджеры: Ken Schwaber, Jeff Sutherland — внесли существенный вклад в развитие методологий, но не в технологии.
- Инженеры-Менеджеры: Kent Beck и Ward Cunningham — повлиявшие как на технологии, так и на методологии.
Удивительно ли, но наибольшую пользу от появления Agile получили именно менеджеры.
Инженеры-менеджеры с XP и другими подобными методологиями проиграли, чуть подробнее об этом далее.
Интереснее всего то, что в итоге инженеры встали в оппозицию и даже начали бороться с Agile. Например, несмотря на то, что Robert C. Martin был одним из основных организаторов мероприятия, теперь он не только выступает против, но и составил свой Software Craftsmanship Manifesto. Гибкость гибкостью, но мы профессионалы и должны работать как подобает профессионалам, не скатываясь до халтуры и спешки.
XP и другие устаревшие методологии
Тому что подходы XP, ASD или Crystal потерпели неудачу, есть вполне разумные причины, и более того, их много. У этих методологий много общего, поэтому посмотрим, что с ними не так на примере XP, поскольку в отличие от остальных он хотя бы еще всплывает в памяти.
Пожалуй, главная проблема XP в том, что он слишком подробный. Книга по XP содержит 160 страниц: трудно представить, что такого объема руководство может быть в полной мере реализовано в массовой разработке, ведь в каждом проекте есть своя специфика.
Кроме того, в дополнении к принципам организации работы, XP навязывает огромное количество способов ее выполнения, причем дорогих способов. Парное программирование — вполне осмысленная техника, но это лишь средство достижения определенного уровня качества и владения кодом. А вдруг можно добиться тех же результатов с меньшими усилиями? А что если работая другим способом, например, быстро исправляя проблемы, можно добиться большего?
Зато отдельные технические концепции, представленные в XP, стали стандартами индустрии. Сейчас уже никого не удивишь Continuous Integration или Daily Deployment. Но в том-то и дело, что это есть у всех.
Всем Scrum
Из всех Agile методологий в широкое обращение вошел только Scrum, и его распространенность по большому счету оправдана. Да, это сложная методология. Да, очень часто Scrum реализуют неправильно, получается черт-те что. Да, работа по Scrum склонна приводить к росту технического долга. Да еще много чего. Но все же Scrum — это лучшее, что есть на рынке. Если применять его осмысленно и целенаправленно, результат будет.
Проблема в том, что для Scrum нет хороших альтернатив, конкуренция отсутствует. А это нездоровая ситуация как для индустрии в целом, так и для Scrum сообщества в частности.
О’Жаль
Под флагом Agile придумано множество частных методологий, и, вероятно, они неплохо работают для авторов, но применимы ли они для индустрии в целом? Почему для Scrum нет хороших альтернатив? При том что Scrum появился до Agile, есть ли причины ожидать, что на базе Agile будут созданы методологии того же уровня?
Agile — это четыре утверждения, выражающие общие мысли нескольких умных и успешных людей. Но каждый из них имеет существенно большую картину ценностей, и это лишь тот минимум, в котором они сошлись исходя из их личного опыта на тот момент времени. Не удивительно, что в манифесте видится много проблем.
Неполнота — если из двух хороших идей, скажем, “пойти в кино” или “пойти в театр”, попытаться механически выделить общее, получится “пойти куда-нибудь”, что уже не кажется хорошей идеей. В своей работе каждый из участников руководствовался большим количеством принципов, так что вполне разумно предположить, что того минимума с которым согласились все, недостаточно для достижения успеха.
Поверхностность — код важнее документации, сразу видно, что собрались инженеры. Решение задач клиента важнее соблюдения бюрократических формальностей, возможно, так было бы правильнее.
Неопределенность — только на первый взгляд все кажется понятно, но как только эти принципы ложатся на конкретную ситуацию, правильное решение становится далеко не очевидно. Более того, при желании можно найти статью, подтверждающую любую из возникших точек зрения.
Наивный альтруизм — сотрудничество важнее согласования условий только до тех пор, пока не пришли штрафные санкции. Требование подписаться под манифестом подразумевает, что нужно согласится со всеми четырьмя утверждениями. Но что если обстоятельства не позволяют? Могу ли я следовать только трем из них без лишнего чувства вины за несоблюдения четвертого?
Узкая аудитория — обращение манифеста идет к разработке, а как же клиенты? Наивно надеяться, что правила можно поменять только со стороны разработки, если клиенты продолжают работать по-старому.
Ключевой целью манифеста было показать индустрии разработки, что процессы, методологии и саму разработку можно вести по-другому, заставить людей задуматься об этом. В этом смысле за манифестом следует признать полный успех. Что касается содержания, это скорее любопытный документ, отражающий наболевшие проблемы разработки начала нулевых, нежели фундаментальные принципы, которым мы все должны следовать.
И все же Agile
Главным достижением Agile-инициативы стал посыл — работать можно по-другому. Можно искать другие пути достижения целей, пробовать нестандартные варианты решения проблем, творчески подходить к организации работы, смотреть на вещи шире своей специализации, пробовать, ошибаться.
Все это можно было и до Agile, но нужно было иметь большую смелость и авторитет, для того чтобы предложить что-то новое. Agile позволил нам открыто говорить о проблемах и обсуждать небанальные варианты их решения.
Комментарии (15)
khabib
13.02.2018 14:51для Scrum нет хороших альтернатив, конкуренция отсутствует.
А как же Kanban?dm_wrike Автор
13.02.2018 16:151. Kanban был придуман в Toyota в конце 40-х прошлого века.
2. Kanban это мелкий тактический инструмент, и далеко не главная часть системы Lean.
Kanban не конкурент Scrum просто потому что это тактический инструмент огранизации
процесса передачи работы и все. Это не методология.khabib
13.02.2018 19:11Все что придумано до 2001го года не может быть гибким? Канбан доска это мелкий тактический инструмент, ровно в той же мере что и скрам доска. Канбан в целом это законченный и достаточно эффективный фреймворк. Ровно в той же мере, что и Скрам.
dm_wrike Автор
13.02.2018 23:57Конечно может, и не только гибким но и хорошим.
Если ?? для вас работает, это отлично.
На всякий случай, хочу порекомендовать вам пару книг:
Джеффри К. Лайкер, Дао Toyota и
Мэри и Том Попендик, Бережливое производство программного обеспечения (увлекательное чтение).
Тем не менее, Kanban это всего лишь способ _сокращения_ waste перепроизводства
за счет ограничения объема незавершенной работы. Суть, если у вас на команду
уже, скажем, 6 задач в работе, вы не можете взять седьмую пока не закончите
одну из уже начатых. Очень разумно. Тем не менее, есть тонкости.
Вообще говоря, с точки зрения Toyota, Kanban это _один из самых плохих_
способов организации работы, и то к чему нужно стремиться — организации
потока производства единичных изделий. То есть вообще не браться за
вторую задачу пока не сделана первая. Это идеал, он не всегда достижим.
Также, нет ничего плохого в тактических инструментах, наоборот, они важны и нужны.
Kanban это техника организации _процессов_, это важно, но это тактика.
Scrum «больше» Kanban, поскольку позволяет работать с проектами,
а с точки зрения организации проекты сложнее процессов.
И да, Kanban был придуман до Agile, вот уж не знаю когда он был адаптирован к разработке. Scrum тоже был придуман до Agile. А что было придумано после 2001?
DexterHD
13.02.2018 15:24Интереснее всего то, что в итоге инженеры встали в оппозицию и даже начали бороться с Agile. Например, несмотря на то, что Robert C. Martin был одним из основных организаторов мероприятия, теперь он не только выступает против, но и составил свой Software Craftsmanship Manifesto.
Во первых хотелось бы получить пруфы на то, где дядюшка Боб откровенно выступает против Agile? Я пока что видел только его выступления где он вещает о том, что Agile неправильно поняли и неверно используют. Что кстати безусловно так и есть.
Во вторых он говорит о том, что пришли менеджеры и сделали на Agile бизнес, похоронив все то что за ним стоит и оставив все эти тренинги, покеры и прочую хрень.
В третьих Software Craftsmanship Manifesto — этот манифест совершенно о другом. Это манифест программистов ремесленников если быть буквальным. Этот манифест не о процессах разработки ПО а о разработке как о ремесле. И о разработчиках профессионалах. И Agile он не отменяет, а наоборот дополняет общие принципы личной ответственностью.
А еще он говорил и не раз о том, что по тем принципам по которым построен Agile IT профессионалы работали задолго до появления waterfall, а сама модель водопада стала ответом на то что рынок наводнили полчища низкоквалифицированных кодеров которые по сути или не являются профессионалами или являются слишком зелеными и молодыми и не имеют должного опыта чтобы работать по Agile и следовать Software Craftsmanship Manifesto.
Если не верите, один из пруфов, его выступление: «The Future of Programming».dm_wrike Автор
13.02.2018 15:49Спасибо за комментарий, в основном вы правы, но есть тонкости.
1. Позиция Robert C. Martin относительно Agile высказан им прямо в статье:
techbeacon.com/uncle-bob-martin-agile-manifesto-15-years-later
That said, today’s agile is not the same agile that was discussed at the meeting.
и далее по тексту.
2. Software Craftsmanship Manifesto — конечно о другом, об индивидуальном профессионализме
и профессиональной этике. Это все безусловно важно, но работает уровнем ниже.
Agile это идея для коллектива, Craftsmanship — для отдельно взятого профессионала.DexterHD
13.02.2018 16:08That said, today’s agile is not the same agile that was discussed at the meeting.
Вот это и есть суть того как мне кажется: «Что не так с гибкими методологиями».
То не так, что их исказили до неузнаваемости, отбросили из них все важное и добавили кучу всего второстепенного и теперь толкают в каждом втором переходе. И imho в том числе и Роберт Мартин об этом говорит.
pnovikov
13.02.2018 17:28+1Главным достижением Agile-инициативы стал посыл — работать можно по-другому. Можно искать другие пути достижения целей, пробовать нестандартные варианты решения проблем, творчески подходить к организации работы, смотреть на вещи шире своей специализации, пробовать, ошибаться.
Вы меня, конечно, извините, но это утверждение несколько… как бы то выразиться… Самоочевидно. Класс, блеск, "работать можно по-другому!" и последующее молчание навевает на мысль "но как именно — мы не знаем...". Agile как общественное явление "подсветил" подзабытые практики управления, а местами добавил новые. Sapienti sat. Адекватные управленцы возьмут и внедрят то, что работает для их организации и проекта, а что избыточно или неэффективно — не будут внедрять. Неадекватные управленцы, видимо, воспринимают Agile как религию и занимаются тем, что ходят по конференциям, тыкают друг в друга пальцами и качая головой подмечают: "ой, а вот тут у вас не agile" или "ооо, вы классные, у вас полный agile". То есть выполнение определенных ритуалов (покер, митинги, доски) в медийной плоскости стало показанием к увеличению авторитета той или иной команды, которая использует оный для… чего? Для красочных презентаций начальству? Начальство смотрит в бухгалтерию и без того всё прекрасно понимает. Для инженеров? Хорошие инженеры в гробу видали методологии управления и справедливо смотрят на них с непониманием. Вот и получается, что agile — это религиозное верование для менеджеров среднего звена, которым, видимо, нечем себя занять, а ответственно, быстро и качественно управлять процессом они не способны. Вот и ходят, смотрят друг на друга и меряются — у кого agile-нее.
Все это можно было и до Agile, но нужно было иметь большую смелость и авторитет, для того чтобы предложить что-то новое.
Смелость? Авторитет? Други мои, у вас есть компания, вы на короткой ноге с её руководителем. Какая, позвольте поинтересоваться, смелость вам нужна, чтобы прийти к CEO и сказать "коллега, у нас вот тут такие-то и такие-то проблемы, давай попробуем поступить так-то и вот так, у меня есть парочка идей"? При чем тут Agile, божечки?
Какой авторитет? Если ваша практика будет работать для вашей компании и обеспечивает вашим клиентам стабильные поставки и качественный продукт по минимальным костам — те, кому надо — просто придут и спросят как вы так сделали, а вы им расскажете. Или не расскажете. Или для них это работать не будет. О каком авторитете речь?
Agile позволил нам открыто говорить о проблемах и обсуждать небанальные варианты их решения.
Для того, чтобы открыто говорить о проблемах никакой agile не нужен. Нужно осознание что shit happens и чем быстрее о проблеме узнать — тем больше шансов её решить. И это не такое уж сакральное знание, чтобы создавать для этого целую новую идеологию. Это необходимый и базовый навык, без которого в бизнесе и управлении делать нечего.
dm_wrike Автор
13.02.2018 19:05+1«но как именно — мы не знаем...»
— готового рецепта нет, факт.
Адекватные управленцы
— все приходит с опытом, чтобы что то уметь, сначала нужно этому научиться.
Хорошие инженеры в гробу видали методологии управления
— не совсем взрослая позиция, если человеку все равно как он работает, он получит то что получит.
вы на короткой ноге с её руководителем
— а если не на короткой ноге, а наоборот, вы первый месяц в компании. У вас свежий взгляд, проблемы к которым все привыкли для вас очевидно, но, видите ли, ноги оказываются недостаточно короткими чтобы быть услышанным. Такое бывает.
те, кому надо — просто придут и спросят
— такое тоже случается, но не всегда.
Для того, чтобы открыто говорить о проблемах никакой agile не нужен.
— вы правы, нужна культура допускающая такую возможность. Как она называется не суть важно.pnovikov
13.02.2018 19:37все приходит с опытом, чтобы что то уметь, сначала нужно этому научиться.
Кхм… Так, простите, зачем тогда так называемые "управленцы" посещают всякие курсы, тренинги, покупают книжки, получают MBA? Тут или крестик или трусы. Или признать, что только на практике можно познать все тонкости управления, а все эти обучалки — чистой воды надувательство. Или признать, что преподаваемый на них материал управленцы не могут применить "в полевых условиях" и надо бы наших управленцев сдавать на утилизацию.
не совсем взрослая позиция
Взрослая. Разработчик решает задачи, которые ему ставят. Как именно это делается и через какие тернистые пути проходят эти задачи в идеале разработчика касаться не должно. На практике я допускаю, что возможна двусторонняя консультация по приоритетам и порядку выполнения задач, но в целом собирать целый отдел разработчиков и заставлять показывать друг другу свои достижения и активно общаться — извините, это противоестественно и порождает корпоративную контркультуру ("меньше дела — больше слова"). Сугубо ИМХО.
нужна культура допускающая такую возможность
Дело не в культуре, а… Я даже не знаю как объяснить. В общем нежелание какого-то отдельного начальника признавать существование проблем, равно как и отрубать голову гонцу, принесшему дурную весть — это из области общей психологии. Комплексы, страхи, незакрытые гештальты… И как по мне — то (если брать сферический случай в вакууме) психологическая проработка даст гораздо больший результат, нежели тактика "просто миримся со странностями начальника — он в праве быть таким, какой он есть".
а если не на короткой ноге, а наоборот, вы первый месяц в компании
Напрямую относится к написанному выше. Если вы нанимаете менеджера, чтобы он разрулил конкретные проблемы с проектом, но выдаете ему при этом полномочия рядового программиста, то на какой же, пардон, результат вы рассчитываете? Это как отдать машину в автосервис, но настрого запретить открывать капот без присутствия и комментариев хозяина авто. И это опять же психологические проблемы нанявшего менеджера начальства.
Если же в такой ситуации оказывается разработчик, который видит проблемы, но не может донести до начальства, то… Печалька. Оптимально — попытаться реквизировать некоторые рычаги управления, а если не получится — то проще уволиться.
tangro
14.02.2018 12:07+2Всегда меня забавляло, что суть Agile прямо противоположна названию, ведь как только мы начинаем «гибкую разработку» у нас железными гвоздями прибиваются в график совещания, релизы, ретроспективы и всё прочее. До этого, когда было «не гибко», можно было туда-сюда это всё двигать (или вообще иногда игнорировать), но как только мы стали agile — всё, отливаем процесс в бетоне и ставим на постамент.
Dmitry_10
15.02.2018 16:00Две недели писали одну процедуру, но не доделали. Все равно потрать ресурсы на демо, пустую поставку и т.п.
В этом весь аджайл.
bex2014
15.02.2018 16:00С хорошей командой можно работать по любой известной методологии. Вот и все, что вам нужно знать. )))))))))))))))))))
dopusteam
Так что же всё таки не так? Аналогичную статью можно про что угодно написать, имхо
GarudaJI
Имхо, не так — это профессиональные скрам менеджеры, не разработчики, которым по всей видимости, нечем заняться и они выдумывают всякие ритуалы — у нас например бумажная джира и надо на дейли бумажечки передвигать, или когда говоришь надо в руках держать предмет относящийся к продукту — футбольный мячик мягкую игрушку для игры про футбол (не знаю что они придумают если игру «для взрослых» придется делать) и много всякой другой ерунды.