Для тех из вас, кому посчастливилось не знать, Jira - это инструмент для управления проектами, и на первый взгляд он неплохой:

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

Прокрутка доски объявлений в наши дни показывает, что я не единственный, у кого проблемы с использованием Jira. Это настолько сложно, что некоторые компании нанимают людей, единственная роль которых будет заключаться в управлении им. Другие передают его на аутсорсинг какой-то компании Jira-management-as-a-service:

Что мне особенно интересно, так это то, что Jira позиционирует себя как «инструмент номер один, используемый гибкими командами». Гибкий? Хм, если вам нужен человек, единственная задача которого - управлять Jira, или вам нужно передать его на аутсорсинг, мне это не кажется очень гибким.

Но что это за «Agile», которым все, кажется, сейчас занимаются?

Последовательное развитие

До того, как все начали заниматься Agile, они сделали Waterfall. Впервые он был официально описан Уинстоном Ройсом в статье, которую он опубликовал в 1970 году. Хотя он никогда не использовал термин водопад в статье, он все же включил это изображение, которое, казалось, напомнило многим людям водопад:

Уинстон также назвал эту модель дефектной, и окончательная модель / изображение, которое он разработал, сильно отличались, но это изображение послужило основой для так называемого метода водопада.

Основная идея состоит в том, чтобы спланировать заранее, а затем выполнить эти последовательные шаги для создания и доставки программного обеспечения. Это прекрасно сочетается со старыми идеями научного менеджмента, изложенными Фредериком Уинслоу Тейлором еще в 1911 году. Вкратце он сказал, что работникам нельзя доверять самоорганизацию, поэтому вам нужна отдельная группа людей для разработки процесса, которому рабочие будут слепо следовать. Отдельная группа организаторов процесса.

Единственная проблема, связанная с применением этого подхода к разработке программного обеспечения, заключается в том, что он постоянно дает сбой.

Встреча снежной птицы

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

Это хорошо понимала группа разработчиков, собравшаяся в Snowbird (США) в 2001 году. Они поняли, что если процесс разработки зависит от стабильных требований и требования не могут быть стабилизированы, то каждый используемый нами метод обработки обречен на неудачу. Выход из этой ситуации - сделать с этой зависимостью то, что Александр Македонский сделал с гордиевым узлом - разрубить.

Нужен другой способ разработки программного обеспечения. Тот, который не будет зависеть от стабильных требований, но будет принимать изменения.

Позднее изменение требований - конкурентное преимущество
–Мэри Поппендик

Группа Snowbird разработала некоторые ценности и принципы, которые стали известны как Манифест гибкой разработки программного обеспечения.

Основные положения этого манифеста:

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

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

Что случилось?

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

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

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

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

Нет процесса?

Но вам ведь нужен какой-то процесс, верно? Итак, какой процесс вы используете? Что ж, это просто - используйте то, что работает! Как узнать, что работает? Чтобы выяснить это, воспользуйтесь эвристическим подходом.

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

Инструменты?

А как насчет инструментов? То же, что и с процессом - используйте то, что работает. Или, если быть более точным, использовать любой инструмент, который лучше всего поддерживает ваш процесс. Но будь осторожен. Поскольку ваш процесс, вероятно, изменится, вам нужен инструмент, достаточно гибкий, чтобы поддерживать эти изменения. Вы также не хотите привязывать себя к определенному инструменту, если вам нужно переключиться на другой инструмент, который может лучше поддерживать ваш (обновленный) процесс.

Есть один инструмент, который подходит под это описание и регулярно доступен в каждом офисе.

Доска, стикеры / указатели машин и маркеры. Вот и все". Это отличный инструмент, потому что каждый может быстро научиться им пользоваться, и он настолько гибкий, насколько это возможно. Если вам нужен цифровой инструмент (как удаленная компания), я бы выбрал какой-нибудь инструмент более общего назначения, который даст вам достаточную гибкость, и выбрал бы специализированные инструменты только в том случае, если вы уверены, что они поддержат ваш процесс.

Проблема с Jira

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

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

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