Когда люди используют термин Agile, они часто имеют в виду не что-то конкретное, а свою правоту.
Например, если вы не писали тесты — не Agile, если не проводили встречу с командой — не Agile, если не заполняли тайм-трек — опять же не Agile. Есть объективные причины, связанные с его происхождением, по которым каждый трактует термин Agile по-своему.
Слова на доске
Ни для кого не секрет, что зарождением всех Agile-движений стал митинг, прошедший в феврале.2001 на горнолыжном курорте в Юте.
Как выразился Роберт К.
Мартин, инициатор мероприятия, существовала группа умных людей, которые никогда раньше не встречались и не планировали встречаться в будущем.
Цель встречи была одна – выразить что-то общее, что объединило бы всех присутствующих.
О том, как создавался Agile-манифест, написано участниками процесса [ 1 ], [ 2 ], [ 3 ].
Суть происходящего заключалась в следующем: каждый из участников записывал на карточках идеи, выражающие его точку зрения, и после того, как карточки были организованы по категориям, становились очевидными четыре пункта, в которых каждый был единогласный .
Затем они были красиво сформулированы:
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее, чем исчерпывающая документация.
- Сотрудничество с заказчиком важнее согласования условий договора.
- Быть готовым к переменам важнее, чем придерживаться первоначального плана.
Документу пришлось придумать название, для которого путем голосования было выбрано слово Agile, так как признает Мартин Фаулер – не то слово.
Незначительное дополнение
Кроме того, Agile-манифест был расширен.12 принципов , но их окончательное утверждение заняло еще несколько месяцев переписка по электронной почте , что говорит об их вторичном значении.
Кстати, один из принципов — выпускать с периодичностью от двух недель до двух месяцев, что по сравнению с современными нормами — пара релизов в день — звучит архаично.
С другими пунктами тоже не все гладко, вот еще пример: « Работающее программное обеспечение является основным показателем прогресса проекта.
«Это сомнительный показатель просто потому, что приложение, которое протестировали и выпустили, еще не означает, что оно будет кому-то полезно.
Неожиданные последствия
В мероприятии приняли участие семнадцать далеко не простых людей.Краткий список их достижений и вклада в отрасль можно посмотреть под катом
- Кент Бек — Сооснователь XP, TDD, xUnit, Software Design Patterns.
- Майк Бидл — 2-й участник Scrum.
- Арье ван Беннекум — Прагматичный.
- Алистер Кокберн — Кристаллические методы , Шаблоны проектирования программного обеспечения .
- Уорд Каннингем — разработал первую Wiki, шаблоны проектирования, соучредитель XP, изобрел Фреймворк для интегрированных тестов .
- Мартин Фаулер — Рефакторинг кода и внедрение зависимостей, UML, шаблоны проектирования, XP.
- Джеймс Греннинг — обучает, тренирует и консультирует по всему миру, ТДД для встраиваемых систем.
- Джим Хайсмит — Адаптивная разработка программного обеспечения (методика).
- Эндрю Хант — Прагматичный программист соавтор книги.
- Рон Джеффрис — Соучредитель XP.
- Джон Керн - в целом солидный человек.
- Брайан Марик — Мастерство тестирования программного обеспечения (книга).
- Роберт С.
Мартин
— ТВЕРДЫЙ принципы Мастерство программного обеспечения , Чистый код (книга). - Стив Меллор - разработчик Метод Шлера – Меллора и Исполняемый UML .
- Кен Швабер — соучредитель Scrum, www.agilealliance.org .
- Джефф Сазерленд — Соучредитель Scrum.
- Дэйв Томас — Прагматичный программист соавтор книги.
В целом участников можно разделить на три категории:
- Инженеры: Роберт К.
Мартин, например, — это те, кто в первую очередь повлиял на развитие технологий.
- Менеджеры: Кен Швабер, Джефф Сазерленд – внесли значительный вклад в развитие методологий, но не технологий.
- Инженерные менеджеры: Кент Бек и Уорд Каннингем - повлияли как на технологию, так и на методологии.
Инженеры-менеджеры с ХР и другими подобными методиками проиграли, об этом чуть ниже.
Самое интересное, что в результате инженеры встали в оппозицию и даже начали бороться с Agile. Например, несмотря на то, что Роберт К.
Мартин был одним из главных организаторов мероприятия, теперь он не только выступает против него, но и создал свой собственный Манифест мастерства программного обеспечения .
Гибкость гибкостью, но мы профессионалы и должны работать как профессионалы, не скатываясь к халтуре и спешке.
XP и другие устаревшие методологии
Существуют веские причины, по которым подходы XP, ASD или Crystal потерпели неудачу, и многие из них.Эти методологии имеют много общего, поэтому давайте посмотрим, что в них плохого, на примере XP, поскольку, в отличие от остальных, она, по крайней мере, все еще приходит на ум.
Возможно, основная проблема XP в том, что она слишком многословна.
Книга XP содержит 160 страниц : Трудно представить, что такой объём указаний можно будет полностью реализовать в массовой разработке, ведь каждый проект имеет свою специфику.
Более того, помимо принципов организации работы, XP накладывает огромное количество способов добиться этого , и дорогой пути.
Парное программирование — очень значимый метод, но это всего лишь средство достижения определенного уровня качества и владения кодом.
Что, если вы сможете добиться тех же результатов с меньшими усилиями? Что, если, работая по-другому, например, быстро решая проблемы, вы сможете достичь большего? Но некоторые технические концепции, представленные в XP, стали отраслевыми стандартами.
Сегодня никого не удивишь Continuous Integration или Daily Deployment. Но в том то и дело, что оно есть у каждого.
Скрам всех
Из всех Agile-методологий широкое распространение получил только Scrum, и его распространенность во многом оправдана.Да, это сложная методика.
Да, очень часто Скрам реализуется неправильно, а результат какой черт. Да, работа Scrum имеет тенденцию увеличивать технический долг.
И многое другое.
Но все же Scrum — лучшее, что есть на рынке.
Если применять это осмысленно и целенаправленно, результат будет. Проблема в том, что нет хороших альтернатив Скраму, нет конкуренции.
И это нездоровая ситуация как для отрасли в целом, так и для Scrum-сообщества в частности.
О'Жал
Многие из них были изобретены под лозунгом Agile. частный методологии, и они, вероятно, работают довольно хорошо для авторов , но применимы ли они к отрасли в целом? Почему нет хороших альтернатив Scrum? Учитывая, что Scrum появился раньше Agile, есть ли основания ожидать, что методологии того же уровня будут создаваться на основе Agile? Agile — это четыре утверждения, выражающие общие мысли нескольких умных и успешных людей.Но у каждого из них гораздо более обширная картина ценностей, и это лишь тот минимум, в котором они сошлись на основе своего личного опыта на тот момент времени.
Неудивительно, что манифест содержит множество проблем.
незавершенность — если из двух хороших идей, скажем, «пойти в кино» или «пойти в театр», попытаться механически вычленить общее, то в итоге получится «пойти куда-то», что уже не кажется хорошим идея.
В своей работе каждый из участников руководствовался большим количеством принципов, поэтому вполне разумно предположить, что того минимума, о котором все договорились, недостаточно для достижения успеха.
Поверхностность — код важнее документации, сразу видно, что инженеры собрались.
Решение проблем клиента важнее соблюдения бюрократических формальностей; возможно, это было бы правильнее.
Неопределенность — только на первый взгляд все кажется ясным, но как только эти принципы применимы к конкретной ситуации, правильное решение становится далеко не очевидным.
Более того, при желании вы можете найти статью, подтверждающую любую из возникших точек зрения.
Наивный альтруизм — сотрудничество важнее, чем договариваться об условиях только до тех пор, пока не прибудут штрафы.
Требование подписать манифест подразумевает, что вы должны согласиться со всеми четырьмя утверждениями.
Но что, если обстоятельства не позволяют этого сделать? Могу ли я следовать только трем из них, не чувствуя при этом особой вины из-за того, что не последовал четвертому? Узкая аудитория — привлекательность манифеста вот-вот будет разработана, а как насчет клиентов? Наивно надеяться, что правила можно будет изменить только со стороны разработки, если клиенты продолжат работать в прежнем режиме.
Основная цель манифеста заключалась в том, чтобы показать индустрии развития, что процессы, методологии и саму разработку можно делать по-другому, и заставить людей задуматься об этом.
В этом смысле манифест следует считать полным успехом.
По содержанию это скорее интересный документ, отражающий актуальные проблемы развития начала 2000-х годов, а не основополагающие принципы, которым мы все должны следовать.
И все же Agile
Главным достижением инициативы Agile стал посыл — работать можно по-другому.Вы можете искать другие пути достижения целей, пробовать нестандартные решения задач, творчески подходить к организации работы, смотреть на вещи шире своей специализации, пробовать и совершать ошибки.
Все это было возможно и до Agile, но нужно было иметь большую смелость и авторитет, чтобы предложить что-то новое.
Agile позволил нам открыто говорить о проблемах и обсуждать инновационные решения для них.
Теги: #методологии разработки #методологии управления #scrum #agile #agile development #IT-стандарты #Управление разработкой #Управление проектами #agile
-
Настройка Ретрокомпьютера Или 386 Страданий
19 Oct, 24 -
Гугл Проник В Тело
19 Oct, 24 -
Gamlist — Ваш Список Игр
19 Oct, 24
