Чистый Agile. Основы гибкости - [52]

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

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

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

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

Авторы Тим Оттингер и Джефф Лангр,

16 апреля 2019 года[61]

Мастера осваивают свои инструменты. Столяры овладевают молотком, метром, пилой, долотом, рубанком и уровнем. Все эти инструменты недороги и отлично подходят мастеру в начале его трудового пути. По мере роста своих потребностей столяр учится пользоваться инструментами посерьезнее (которые, как правило, и дороже): дрелью, гвоздезабивным пистолетом, токарным и фрезерным станком, САПР, ЧПУ и много чем еще.

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

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

Средства разработки

Разработчикам ПО в начале работы требуется освоить целый ряд инструментов:

• Хотя бы один язык программирования, а чаще больше.

• Интегрированную среду разработки или текстовый редактор, подходящий программисту (vim, Emacs и т. д.).

• Различные форматы данных (JSON, XML, YAML и т. д.) и языки разметки (в том числе HTML).

• Командную строку и скрипты для взаимодействия с операционной системой.

• Системы управления версиями (Git. Тут без вариантов).

• Средства для непрерывной интеграции и сборки (Jenkins, TeamCity, GoCD и т. д.).

• Средства развертывания и управления сервером (Docker, Kubernetes, Ansible, Chef, Puppet и т. д.).

• Средства коммуникации (электронная почта, Slack, английский язык).

• Инструменты тестирования (фреймворки для модульного тестирования, Cucumber, Selenium и т. д.).

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

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

Что делает инструмент эффективным?

Набор инструментов стремительно меняется, потому что мы постоянно узнаем более действенные способы достигать своих целей. За последние несколько десятков лет мы видели широкое разнообразие систем управления версиями: PVCS, Clear Case, Microsoft Visual Source Safe, Star Team, Perforce, CVS, Subversion, Mercurial и прочие. Все они страдали от каких-то недостатков: слишком нестабильные, слишком проприетарные или закрытые, слишком медленные, слишком въедливые, слишком жуткие или сложные. В итоге победил тот, который преодолел большинство ограничений, — Git.

Одна из сильных сторон Git в том, что он дает уверенность, что исходный код будет в сохранности. Если вы уже давно работаете, то наверняка использовали какие-то из перечисленных систем и, вероятно, время от времени нервничали. Требуется соединение с сервером в реальном времени, иначе ваша работа под угрозой. Репозиторий CVS время от времени повреждал файлы, после чего приходилось устраивать пляски с бубном в надежде восстановить данные. Сервер репозитория иногда падал, даже при наличии резервной копии, и можно было прождать пол рабочего дня. Некоторые проприетарные системы также страдали повреждением данных в репозиториях. Вы висите на телефоне часами, разговаривая с поддержкой, при этом отстегивая деньги на сторону за возможность привести их в порядок. При использовании Subversion вы опасались вести много веток, потому что чем больше файлов находилось в репозитории, тем дольше переключались ветки (иногда это занимало несколько минут).