ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.10.2023
Просмотров: 353
Скачиваний: 11
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
1 ... 12 13 14 15 16 17 18 19 20
Глава 6. Внедрение Agile
210
и показали высокий уровень мастерства в применении методов
Agile .
AGILE В КРУПНЫХ МАСШТАБАХ
Движение Agile появилось в конце 1980-х . Его быстро признали способом организовать небольшую команду, размером от 4 до
12 разработчиков . Эти числа были нестрогими и редко озвучива- лись, однако все понимали, что Agile (или как мы его там называли до 2001-го) не подходит для гигантских команд из тысяч разработ- чиков . Это не та задача, над решением которой мы бились . Тем не менее вопрос подняли почти сразу . А что насчет больших команд?
Что, если применить Agile в крупном масштабе?
Долгие годы люди искали ответ на этот вопрос . В самом начале авторы Scrum предложили метод Scrum-of-Scrums . Позже мы ста- ли наблюдать появление некоторых фирменных подходов вроде
SAFe
1
и LeSS
2
. На эту тему написано несколько книг .
Я уверен, что в этих подходах нет ничего плохого . Я уверен, что эти книги замечательны . Но я не пробовал этих методов и не читал книг . Вы можете подумать, что я какой-то пустомеля, что выска- зываюсь на тему, которую не изучил . Может, вы и правы . Однако у меня есть своя точка зрения .
Agile создан для малых и средних команд . Точка . Он хорошо ра- ботает для таких команд . Agile никогда не предназначался для больших команд .
1
https://ru.wikipedia.org/wiki/Scaled_Agile_Framework.
2
https://less.works/ru/.
Agile в крупных масштабах
211
Почему мы не пробовали решить проблему больших команд?
Да потому что проблема больших команд решается огромным количеством специалистов вот уже больше пяти тысяч лет . Эта проблема больших команд — проблема культур и цивилизаций .
И если в какой-то мере судить о нашей нынешней цивилизации, эту проблему решили достаточно неплохо .
Как построили пирамиды в Египте? Надо было решить проблему больших команд . Как получилось победить во Второй мировой войне? Надо было решить проблему больших команд . Как удалось отправить человека в космос и благополучно вернуть его на Зем- лю? Надо было решить проблему больших команд .
Но такие большие проекты — не единственные достижения боль- ших команд, не правда ли? Как получилось развернуть телефон- ную сеть, построить автомагистраль, создать интернет, произвести мобильные телефоны или автомобили? Это все сотворили большие команды .
Инфраструктура и средства обороны нашей обширной, охваты- вающей весь земной шар цивилизации — прямое свидетельство того, что мы уже решили проблему организации больших команд .
Большие команды — проблема уже решенная.
Та проблема, которую все еще не решили тогда, в конце 1980-х, когда зарождалось движение Agile — это проблема организации работы малых команд разработчиков . Мы не знали, как эффектив- но организовать относительно малую группу программистов так, чтобы была максимальная отдача . И эту проблему решил Agile .
Важно понимать, что Agile создали для решения проблемы органи- зации небольшой команды разработчиков, а не просто небольшой
Глава 6. Внедрение Agile
212
команды . Проблему небольших команд решили еще в древние времена военные и производственные организации по всему миру .
Римляне бы не покорили Европу, если бы не смогли решить про- блему организации небольших отрядов .
Agile — это набор дисциплин, с помощью которых мы органи- зуем небольшие команды разработчиков ПО . Зачем нам нужен отдельный способ для организации разработчиков? Потому что программное обеспечение особенно .
На него похожи только несколько областей знаний . Соотношения
«вложение/выгода» и «риск/вознаграждение» в разработке ПО отличаются от тех, что имеются в других видах деятельности .
Разработка похожа на строительство, за исключением того что не строится ничего осязаемого . Разработка похожа на математику, за исключением того что ничего нельзя доказать . Разработка похожа на естествознание своей эмпиричностью, но при этом не откры- вается никаких законов природы . Разработка похожа на бухгал- терское дело, за исключением того что она описывает поведение, упорядоченное по времени, а не факты о числах .
Разработка ПО действительно не похожа ни на что другое . По- этому для того, чтобы организовать небольшую команду разработ- чиков, нужен набор особых дисциплин, которые подстроены под уникальность разработки .
Посмотрите на дисциплины и методы, о которых мы говорили на страницах этой книги . Обратите внимание, что они все до единого, почти без исключения, подстроены и отлажены под уникальные стороны разработки . Присмотритесь к методам, начиная от оче- видных вроде разработки через тестирование и рефакторинга до более неоднозначных вроде игры в планирование .
Agile в крупных масштабах
213
Суть в том, что Agile создан для сферы разработки ПО . В частно- сти, речь идет о небольших командах программистов . Мне непри- ятно, когда меня спрашивают, как внедрить Agile в сферу производ- ства аппаратного обеспечения, строительства или в другой процесс .
Я всегда отвечаю, что не знаю, потому что Agile существует для сферы разработки ПО .
А что, если масштабировать Agile? Думаю, ничего не выйдет . Орга- низовать большие команды можно, разбив их на несколько мелких .
Agile решает проблему небольших команд разработчиков . Про- блема организации небольших команд в большие уже решена . По- этому мой ответ на вопрос о применении Agile в крупном масштабе таков: просто распределите ваших разработчиков по небольшим командам, которые будут работать по Agile, а потом применяйте обычные способы управления и научно-исследовательские методы, чтобы руководить этими командами . Не нужно никаких особых правил .
Теперь мне могут задать еще один вопрос . Если разработка ПО в небольших командах настолько уникальна, что пришлось изобре- сти Agile, почему такая уникальность не относится к организации маленьких команд разработчиков в большие? Разве не существует чего-то уникального в области разработки ПО, что выходит за пределы организации небольших команд разработчиков и влияет на организацию больших?
Сомневаюсь, потому что проблема больших команд, которую мы решили более пяти тысяч лет назад, — это вопрос слаженного сотрудничества самых разных команд . Команды, работающие по
Agile, — лишь один вид несметного числа команд, которые нужно скоординировать для создания чего-то большего . Координация ко- манд различных назначений — уже решенная проблема . Я не вижу
Глава 6. Внедрение Agile
214
никаких признаков того, что уникальность команд разработчиков плохо влияет на их включение в более крупные объединения .
Так что, опять-таки с моей точки зрения, не существует никакого
Agile для применения в крупном масштабе . Agile — необходимое нововведение для организации небольших команд разработчиков
ПО . Но будучи уже организованными, такие команды можно встроить в структуры, которые в крупных организациях применя- ются уже тысячелетиями .
Это не та тема, которую я усердно исследовал . Все, что вы только что прочитали, лишь мое мнение, я могу оказаться неправ . Воз- можно, я просто старый ворчун, который посылает всех желаю- щих применить Agile в крупных масштабах идти развлекаться в свой двор . Время лучший судья . Но теперь вы знаете, в чем я точно уверен .
ИНСТРУМЕНТЫ AGILE
Авторы Тим Оттингер и Джефф Лангр,
16 апреля 2019 года
1
Мастера осваивают свои инструменты . Столяры овладевают мо- лотком, метром, пилой, долотом, рубанком и уровнем . Все эти инструменты недороги и отлично подходят мастеру в начале его трудового пути . По мере роста своих потребностей столяр учится пользоваться инструментами посерьезнее (которые, как правило, и дороже): дрелью, гвоздезабивным пистолетом, токарным и фре- зерным станком, САПР, ЧПУ и много чем еще .
1
Приводится с разрешения .
Инструменты Agile
215
Однако мастера столярного дела не расстаются с ручным инстру- ментом, который отлично подходит для работы . Используя только ручной инструмент, умелый мастер может выполнить работу ка- чественнее и иногда даже быстрее, чем приводным инструментом .
Как следствие, толковый столяр осваивает ручной инструмент, прежде чем перейти к более совершенным . Столяры изучают пре- дел возможностей ручного инструмента, и поэтому у них есть по- нимание, когда нужно прибегнуть к приводному .
Вне зависимости от того, какой инструмент используется, ручной или приводной, столяр всегда стремится овладеть каждым ин- струментом из своего арсенала . Такое мастерство позволяет ему сосредоточиться непосредственно на ремесле, например на изго- товлении изящной мебели высокого качества, а не на инструменте .
Без должного овладения инструмент — плохой помощник, а при неумелом применении может даже нанести вред как изделию, так и незадачливому работнику .
Средства разработки
Разработчикам ПО в начале работы требуется освоить целый ряд инструментов:
z
Хотя бы один язык программирования, а чаще больше .
z
Интегрированную среду разработки или текстовый редактор, подходящий программисту (vim, Emacs и т . д .) .
z
Различные форматы данных (JSON, XML, YAML и т . д .) и язы- ки разметки (в том числе HTML) .
z
Командную строку и скрипты для взаимодействия с операци- онной системой .
z
Системы управления версиями (Git . Тут без вариантов) .
Глава 6. Внедрение Agile
216
z
Средства для непрерывной интеграции и сборки (Jenkins,
TeamCity, GoCD и т . д .) .
z
Средства развертывания и управления сервером (Docker,
Kubernetes, Ansible, Chef, Puppet и т . д .) .
z
Средства коммуникации (электронная почта, Slack, английский язык) .
z
Инструменты тестирования (фреймворки для модульного те- стирования, Cucumber, Selenium и т . д .) .
Все эти инструменты необходимы для создания ПО . Без них на се- годняшний день невозможно ничего сделать . В некотором смысле, это «набор ручных инструментов» разработчика .
Чтобы освоить многие из этих инструментов и использовать их с отдачей, придется попотеть . Тем временем положение дел по- стоянно меняется, поэтому мастерски овладеть тем или иным инструментом становится все большим испытанием . Грамотный разработчик ищет пути наименьшего сопротивления и наиболь- шую пользу от применяемых инструментов, выбирая те, которые при затраченных усилиях дают большую отдачу .
Что делает инструмент эффективным?
Набор инструментов стремительно меняется, потому что мы по- стоянно узнаем более действенные способы достигать своих целей .
За последние несколько десятков лет мы видели широкое разно- образие систем управления версиями: PVCS, Clear Case, Microsoft
Visual Source Safe, Star Team, Perforce, CVS, Subversion, Mercurial и прочие . Все они страдали от каких-то недостатков: слишком нестабильные, слишком проприетарные или закрытые, слишком медленные, слишком въедливые, слишком жуткие или сложные .
Инструменты Agile
217
В итоге победил тот, который преодолел большинство ограниче- ний, — Git .
Одна из сильных сторон Git в том, что он дает уверенность, что исходный код будет в сохранности . Если вы уже давно работаете, то наверняка использовали какие-то из перечисленных систем и, вероятно, время от времени нервничали . Требуется соединение с сервером в реальном времени, иначе ваша работа под угрозой .
Репозиторий CVS время от времени повреждал файлы, после чего приходилось устраивать пляски с бубном в надежде восстановить данные . Сервер репозитория иногда падал, даже при наличии резервной копии, и можно было прождать пол рабочего дня . Не- которые проприетарные системы также страдали повреждением данных в репозиториях . Вы висите на телефоне часами, разгова- ривая с поддержкой, при этом отстегивая деньги на сторону за воз- можность привести их в порядок . При использовании Subversion вы опасались вести много веток, потому что чем больше файлов находилось в репозитории, тем дольше переключались ветки (ино- гда это занимало несколько минут) .
Хороший инструмент должен быть удобен в использовании, а не заставлять вас содрогаться при одном лишь его виде . Git быстрый, он дает возможность вносить изменения в код локально, а не толь- ко на сервере, позволяет работать из локального репозитория без соединения по сети; он отлично поддерживает работу в несколь- ких репозиториях и нескольких ветках, а еще искусно выполняет слияние версий .
У Git достаточно ясный и понятный интерфейс . Получается, что научившись работать в Git однажды, вам не придется особо думать о самом инструменте . Вас будут волновать куда более насущные вопросы: безопасность хранения данных и управление версиями исходного кода . Инструмент стал прозрачен .