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

Проблема в том, что во многих объяснениях концепции не проводится различие между гибкими и связанными с ним фреймворками (такими как LeSS, SAFe, Scrum и т. Д.) И практиками (написание пользовательских историй, спринтов, бэклогов). Без четкого представления о границах между этими идеями легко приписать недостатки конкретной практики всей концепции Agile.

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

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

На самом деле Agile Manifesto состоит всего из четырех ценностей и 12 принципов. Важно отметить, что эти ценности и принципы возникли не на пустом месте. Они были воплощением того, что, казалось, работало хорошо, и реакцией на бюрократическое, жесткое и иерархическое мышление, которое характеризовало разработку программного обеспечения в стиле Waterfall в большинстве корпоративных сред. Я не буду здесь подробно останавливаться на проблемах Waterfall. На данный момент просто имейте в виду, что для каждой ценности и принципа, выраженных как часть Agile, Waterfall в значительной степени попадает в прямо противоположный конец спектра и в результате обычно неэффективен.

Легко отнести недостатки конкретной практики ко всей концепции Agile.

Agile Manifesto устанавливает следующее:

Ценности Agile:

  1. Люди и взаимодействие важнее процессов и инструментов
  2. Рабочее программное обеспечение, а не исчерпывающая документация
  3. Сотрудничество с клиентами вместо переговоров по контракту
  4. Реагирование на изменения вместо следования плану

Принципы гибкой разработки:

  1. Нашим высшим приоритетом является удовлетворение потребностей клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения.
  2. Приветствуем меняющиеся требования даже на поздних стадиях разработки. Изменения в гибких процессах используются для обеспечения конкурентного преимущества клиента.
  3. Часто доставляйте работающее программное обеспечение, от пары недель до пары месяцев, с предпочтением более коротких сроков.
  4. Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.
  5. Создавайте проекты вокруг мотивированных людей. Обеспечьте им среду и поддержку, в которых они нуждаются, и доверьте им выполнение работы.
  6. Самый действенный и действенный метод передачи информации команде разработчиков и внутри нее - это личное общение.
  7. Работающее программное обеспечение - это главный показатель прогресса.
  8. Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп бесконечно.
  9. Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
  10. Простота - искусство максимизировать объем незавершенной работы - очень важна.
  11. Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
  12. Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.

Вот и все. Все, что вам действительно нужно знать об Agile, находится прямо здесь.

Манифест не содержит предписаний относительно конкретных практик. Он не говорит вам точно, что делать, когда это делать, как это делать или какие инструменты использовать. Вместо этого он устанавливает некоторые общие рекомендации, о которых следует подумать, когда вы поймете, что имеет смысл в вашем контексте. Если вы хотите найти недостатки в Agile (что, безусловно, возможно), вы должны иметь возможность выражать свои мысли в соответствии с тем, что написано выше. Я думаю, что многие люди, однако, поймут, что большая часть контента настолько интуитивно понятна, что кажется почти слишком очевидной.

Однако то, что эти идеи представлены, не означает, что их легко усвоить или применить на практике. Легко прочитать что-то вроде «самоорганизующиеся команды» и кивнуть, не осознавая полностью, насколько это радикально отличается от рабочих мест, где менеджеры диктуют структуру команды и говорят своим сотрудникам, как работа должна быть завершена.

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

В Agile Manifesto нет точных указаний о том, что делать. Вместо этого он устанавливает некоторые рекомендации, о которых следует подумать, когда вы поймете, что имеет смысл в вашем контексте.

Из всех этих фреймворков ни одна не кажется настолько распространенной или широко используемой, как Scrum. Технически Scrum предшествовал Agile Manifesto, и Agile частично был вдохновлен тем, что хорошо работало в таких фреймворках, как Scrum. Итак, хорошая новость заключается в том, что Scrum не совсем ужасен (в отличие от SAFe, о котором я говорил здесь), и на самом деле он относительно прост. Однако я думаю, что у него определенно есть некоторые проблемы с тем, чтобы соответствовать ценностям, с которыми он пытается претендовать на индивидуальную связь.

Если вам нужно введение в Scrum, вам следует ознакомиться с относительно коротким Руководством по Scrum, прежде чем читать дальше.

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

  • Скрам-мастера в конечном итоге действуют как менеджеры проектов, которые пытаются поддерживать статус-кво - контролируют, а не поддерживают команду.
  • Команды могут чрезмерно сосредоточиться на спешке, чтобы «сделать» работу, не задумываясь о ценности или качестве этой работы.
  • Спринты в конечном итоге создают бесконечный поток новых функций без каких-либо итераций того, что было ранее выпущено.
  • Команды чрезмерно полагаются на специализацию и передачу полномочий, не находя способов распараллеливать или перекрестно опылять наборы навыков внутри команды.
  • Менеджеры обеспечивают согласованность процессов в командах Scrum, ограничивая способность отдельных команд к самоорганизации.
  • Команды создаются без фактического набора навыков, которые им нужны
  • Ретроспективы случаются, но люди отказываются выявлять проблемы, потому что никогда не видят, чтобы что-то изменилось.

Все это довольно ясные примеры «сделанного неправильно» Scrum, но они не обязательно являются обвинением в отношении самого Scrum. Я думаю, что немного более расплывчато определить, где фреймворк, «сделанный правильно», кажется, конфликтует с Agile. Хотя Scrum подходит для настройки, есть момент, когда вы в конечном итоге настраиваете так много, что на самом деле это совсем не похоже на Scrum.

Здесь я надеюсь предоставить некоторые дополнительные данные для рассмотрения, когда вы думаете о своей собственной практике, основываясь на моем личном опыте.

Scrum вещи, чтобы (возможно) угробить

  • Иногда мы решали не иметь специальной роли Скрам-мастера. Вместо этого команда может самостоятельно управлять и периодически менять обязанности Scrum Master. Это добавляет дополнительный слот для ценного отдельного участника и создает лучшее чувство ответственности за процесс в команде. Я бы не рекомендовал это для команды с низкой Agile-грамотностью или нуждающейся в большой защите от внешнего вмешательства.
  • Время от времени я работал в командах, где нам не требовался специальный владелец продукта. Вместо этого право собственности на продукт было распределено внутри команды. Как дизайнер в команде, я очень сильно постарался восполнить этот пробел. Если вы попробуете это сделать и у вас возникнут проблемы с достижением консенсуса, назначение PO может иметь смысл для централизации принятия решений.
  • Мы отказались от большинства концепций спринтов и планирования спринтов. Спринты помогают командам, которые привыкли к годичным циклам, выпускать релизы чаще, но если вы уже предпочитаете часто выпускать, они не так полезны. Изменения в середине спринта не приветствуются спринтами, но предполагается, что Agile поощряет изменения! Мы перешли на более непрерывный поток задач на Канбан-доске. Это также облегчило мне как дизайнеру возможность вносить небольшие изменения в UX по мере необходимости.
  • Мы полностью отказались от строгости, связанной с историями, эпосами, особенностями и т. Д., И просто отслеживали то, что нам нужно было делать, на наиболее естественном уровне. Это сделало отслеживание более простым и понятным, и, похоже, не сделало нас менее организованными или ориентированными на клиента. Во всяком случае, это позволило нам больше сосредоточиться на ценности для клиента и меньше на объеме. Честно говоря, номенклатура эпического / особенного / исторического не является официальной частью Scrum Guide, но является очень распространенной практикой.

Scrum вещи, которые (возможно) сохранить

  • Регулярные ретроспективы. Повседневное улучшение процесса - это здорово, но все может остаться незамеченным, если не уделить время для размышлений. Я поделился некоторыми своими мыслями о ретроспективах здесь.
  • Ограниченные по времени ежедневные выступления. Это помогает удержать всех на одной странице, свести к минимуму другие встречи и выявить моменты, в которых людям нужно работать вместе.
  • Наличие группового, детализированного и регулярно обновляемого бэклога как механизма для определения приоритетов работы. Это позволило легко отслеживать работу и элегантно управлять сменой приоритетов.
  • Выделенные кросс-функциональные команды для уменьшения внешних зависимостей. Это важно для работы без постоянного ожидания или спешки.

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

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