Инфраструктура и средства обороны нашей обширной, охватывающей весь земной шар цивилизации — прямое свидетельство того, что мы уже решили проблему организации больших команд.
Большие команды — проблема уже решенная.
Та проблема, которую все еще не решили тогда, в конце 1980-х, когда зарождалось движение Agile — это проблема организации работы малых команд разработчиков. Мы не знали, как эффективно организовать относительно малую группу программистов так, чтобы была максимальная отдача. И эту проблему решил Agile.
Важно понимать, что Agile создали для решения проблемы организации небольшой команды разработчиков, а не просто небольшой команды. Проблему небольших команд решили еще в древние времена военные и производственные организации по всему миру. Римляне бы не покорили Европу, если бы не смогли решить проблему организации небольших отрядов.
Agile — это набор дисциплин, с помощью которых мы организуем небольшие команды разработчиков ПО. Зачем нам нужен отдельный способ для организации разработчиков? Потому что программное обеспечение особенно.
На него похожи только несколько областей знаний. Соотношения «вложение/выгода» и «риск/вознаграждение» в разработке ПО отличаются от тех, что имеются в других видах деятельности. Разработка похожа на строительство, за исключением того что не строится ничего осязаемого. Разработка похожа на математику, за исключением того что ничего нельзя доказать. Разработка похожа на естествознание своей эмпиричностью, но при этом не открывается никаких законов природы. Разработка похожа на бухгалтерское дело, за исключением того что она описывает поведение, упорядоченное по времени, а не факты о числах.
Разработка ПО действительно не похожа ни на что другое. Поэтому для того, чтобы организовать небольшую команду разработчиков, нужен набор особых дисциплин, которые подстроены под уникальность разработки.
Посмотрите на дисциплины и методы, о которых мы говорили на страницах этой книги. Обратите внимание, что они все до единого, почти без исключения, подстроены и отлажены под уникальные стороны разработки. Присмотритесь к методам, начиная от очевидных вроде разработки через тестирование и рефакторинга до более неоднозначных вроде игры в планирование.
Суть в том, что Agile создан для сферы разработки ПО. В частности, речь идет о небольших командах программистов. Мне неприятно, когда меня спрашивают, как внедрить Agile в сферу производства аппаратного обеспечения, строительства или в другой процесс. Я всегда отвечаю, что не знаю, потому что Agile существует для сферы разработки ПО.
А что, если масштабировать Agile? Думаю, ничего не выйдет. Организовать большие команды можно, разбив их на несколько мелких. Agile решает проблему небольших команд разработчиков. Проблема организации небольших команд в большие уже решена. Поэтому мой ответ на вопрос о применении Agile в крупном масштабе таков: просто распределите ваших разработчиков по небольшим командам, которые будут работать по Agile, а потом применяйте обычные способы управления и научно-исследовательские методы, чтобы руководить этими командами. Не нужно никаких особых правил.
Теперь мне могут задать еще один вопрос. Если разработка ПО в небольших командах настолько уникальна, что пришлось изобрести Agile, почему такая уникальность не относится к организации маленьких команд разработчиков в большие? Разве не существует чего-то уникального в области разработки ПО, что выходит за пределы организации небольших команд разработчиков и влияет на организацию больших?
Сомневаюсь, потому что проблема больших команд, которую мы решили более пяти тысяч лет назад, — это вопрос слаженного сотрудничества самых разных команд. Команды, работающие по 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 вы опасались вести много веток, потому что чем больше файлов находилось в репозитории, тем дольше переключались ветки (иногда это занимало несколько минут).
Хороший инструмент должен быть удобен в использовании, а не заставлять вас содрогаться при одном лишь его виде. Git быстрый, он дает возможность вносить изменения в код локально, а не только на сервере, позволяет работать из локального репозитория без соединения по сети; он отлично поддерживает работу в нескольких репозиториях и нескольких ветках, а еще искусно выполняет слияние версий.
У Git достаточно ясный и понятный интерфейс. Получается, что научившись работать в Git однажды, вам не придется особо думать о самом инструменте. Вас будут волновать куда более насущные вопросы: безопасность хранения данных и управление версиями исходного кода. Инструмент стал прозрачен.
Git — это функциональный и сложный инструмент. И что значит изучить его хорошо? К счастью, работает принцип 80/20. Достаточно малая часть возможностей Git, скажем, процентов 20, поможет вам справиться с более чем 80 % повседневных задач, которые будут встречаться во время управления исходным кодом. Большую часть всего необходимого можно освоить за минуты. Сведения по всему остальному можно найти в Сети.