Agile – это не инструменты и процессы

Agile – это не инструменты и процессы

В последнее время я часто читаю обсуждения об Agile и отчаиваюсь. Почти каждый вопрос об Agile звучит так: «Какой инструмент лучше всего использовать для {…} в Agile?». Это разочаровывает. Кто-нибудь помнит Манифест Agile? В нем написано: «Люди и взаимодействие важнее процессов и инструментов». Большинство, кажется, забыли этот урок или, возможно, никогда не понимали его.

Дело не в инструментах

Многие люди делают ошибку, начиная с инструмента или процесса, а затем подбирая работу под инструмент и процессе. Они делают все задом наперед. Начинать нужно с работы – только с работы. Если у вас небольшая кросс-функциональная команда, вы работаете в новой компании и у вас нет серьезных зависимостей или бюрократических барьеров, вам, вероятно, не нужны никакие инструменты. Ладно, инструменты вам все же действительно нужны, и я отчаялся повторять: это доска, стикеры и ручки. Я не шучу, это все, что нужно.

1. Не начинайте с инструмента

Начните с необходимого минимума. Доска и стикеры, вероятно, будут работать прекрасно. Вы, наверное, подумали: «Ну, поначалу это может сработать. Но как только система станет немного сложнее, и добавится еще пара команд, внезапно появляются менеджеры, управляющие проектами и финансами, которые хотят знать, что вообще происходит. Что нам делать тогда? Конечно, нам понадобится инструмент!».

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

2. Инструменты могут способствовать плохому поведению

Такие инструменты, как Jira, иногда могут быть полезны, но часто они заменяют общение лицом к лицу. Это информационные морозильники. Доски и стикеры дешевы, быстры, просты в использовании и являются местом взаимодействия людей. Они также не являются частью традиционного командно-контрольного управления организаций. Данные и показатели, безусловно, могут быть полезными, но они должны оставаться в команде. Их следует использовать для самоанализа и экспериментов, а не для подачи бесконечных отчетов.

3. Инструменты могут изменить способы работы

Команды должны выработать свои собственные эффективные способы работы без каких-либо инструментов, а затем посмотреть, есть ли какие-либо проблемы или пробелы, которые могут исправить инструменты. Чаще всего нет. Вместо этого некоторые люди начинают с инструментов, а затем находят способы работы, которые вписываются в инструменты. «Jira требует, чтобы мы создавали тикеты вот таким образом». «В Rally встроена своя система документооборота, поэтому мы должны использовать ее, а не свою самописную систему». И так далее, и тому подобное.

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

4. У поставщиков инструментов свои интересы

У людей, продающих инструменты, есть свои интересы. Это, конечно, нормально, все так делают – и я, и вы, и ваша компания. Но важно понимать чужие интересы. Поставщики инструментов не просто хотят, чтобы вы покупали их инструменты, они хотят, чтобы вы использовали их рабочие процессы. Хорошо, если они вам подходят или настраиваются под ваши цели. Вам нужна гибкость, чтобы добавлять и удалять инструменты по мере необходимости.

Еще рекомендуем:  Как теория ограничений помогает устранить узкие места в бизнесе

Дело не в процессах

Другие вопросы касаются процессов. Вопросы обычно звучат так: «Мы пытаемся понять, что делать, когда [что-то странное] происходит. Но мы не можем найти ответ в руководстве Scrum! Помогите! Что нам делать?». Ах, эти бедные молодые scrum-мастера. Неужели тренер, выдавший им сертификат после двухдневного обучения, не дал все ответы на все случаи жизни?

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

1. Нет единого размера, подходящего для любого процесса

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

2. Не навязывайте процессы другим командам

Другим анти-шаблоном, на который стоит обратить внимание, является команда, насаждающая свои процессы в организации. Контексты могут различаться не только между компаниями, но даже между командами в одной компании. Команды могут различаться по размеру, опыту, гибкости, компетенции в области, фону, разнообразию, технологии или платформе. То, что команда нашла свой способ работать, не означает, что он подходит для другой команды. Люди должны всегда обсуждать тактику и делиться историями и знаниями, но это не значит, что нужно заставлять всех ходить одним строем. Разнообразие – это сила, а постоянство переоценено.

3. Начните с работы, затем определите процессы там, где они вам нужны

Как и в случае с инструментами, команды не должны начинать с процессов. Они должны начать с простого выполнения работы: определения и выбора высокоприоритетных задач (например, ценных фрагментов программного обеспечения) и их выпуска как можно быстрее. Если команды находят определенные шаблоны, которые хорошо работают, они могут стать процессами. Так вы можете добавить их в свои способы работы. Но если что-то дает предсказуемый, повторяемый результат, разумно попытаться просто автоматизировать этот процесс, а не определять и стандартизировать его. Мое любимое проектирование и разработка программного обеспечения – это творческий процесс, каждый раз уникальный. Стандартизированные процессы часто бывают скорее разрушительными, чем полезными.

DevOps – классический пример для управления ИТ-услугами. В отличие от крупных сложных процессов, таких как ITIL, DevOps нацелен на простые гибкие процессы, обеспечивающие большую автоматизацию.

Итог

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

Источник

Давайте обсудим...

Ваш e-mail не будет опубликован. Обязательные поля помечены *