Роберт Мартин - Чистый Agile. Основы гибкости
- Название:Чистый Agile. Основы гибкости
- Автор:
- Жанр:
- Издательство:Питер
- Год:2020
- Город:Санкт-Петербург
- ISBN:978-5-4461-1552-5
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Роберт Мартин - Чистый Agile. Основы гибкости краткое содержание
По сути Agile — это всего лишь небольшая подборка методов и инструментов, помогающая небольшим командам программистов управлять небольшими проектами,… но приводящая к большим результатам, потому что каждый крупный проект состоит из огромного количества кирпичиков. Пять десятков лет работы с проектами всех мыслимых видов и размеров позволяют Дяде Бобу показать, как на самом деле должен работать Agile.
Если вы хотите понять преимущества Agile, не ищите лёгких путей — нужно правильно применять Agile. «Чистый Agile» расскажет, как это делать разработчикам, тестировщикам, руководителям, менеджерам проектов и клиентам.
Чистый Agile. Основы гибкости - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Обратите внимание, что этот метод относится к методам взаимодействия с клиентом, а не к методам взаимодействия внутри команды. Основные выгоды от метода «одна команда» получает клиент.
Когда команда находится в одном пространстве, дело идет слаженнее.
В одном пространстве
В начале 2000-х я помогал некоторым организациям внедрить методы Agile. Во время предварительных визитов, до того как начинать активный коучинг, мы попросили наших клиентов подготовить пространство и расположить в нем всех членов команды. Заказчик неоднократно сообщал, что эффективность команд заметно возросла просто потому, что ее члены находились в одном пространстве.
Размещение другим способом
В 1990-х интернет открыл широкие возможности использования труда программистов в странах с очень низкой стоимостью рабочей силы. Искушение воспользоваться этой возможностью было бешеным. Бухгалтеры делали расчеты и с горящими глазами представляли, сколько средств можно было сэкономить.
Но мечта мечтой, а действительность опустила всех с небес на землю. Оказалось, что рассылать мегабиты исходного кода по всему миру не совсем то же самое, что расположить в одном пространстве команду из клиентов и программистов. Была огромная разница как в расстоянии, так и в часовых поясах, языке и культуре.
Несогласованность зашкаливала. Качество оставляло желать лучшего. Нужно было много переделывать [41] Это мои личные впечатления, основанные на разговорах с ребятами, которые напрямую сталкивались с подобными проблемами. Сейчас у меня нет актуальных данных. Действуйте на свой страх и риск.
. В последующие годы технологии в какой-то мере стали совершеннее. В наши дни скорость передачи данных позволяет регулярно связываться по видео и передавать изображение на экране. Два разработчика в разных концах света теперь могут работать в паре над тем же кодом почти так же, как если бы сидели за одним столом. Конечно, такой прогресс не решает проблему разных часовых поясов, культурных и языковых различий, но электронное написание кода лицом к лицу несомненно предпочтительнее, чем пересылка исходного кода туда-обратно по электронной почте.
Можно ли так работать по методам Agile? Я слышал, что можно. Но сам никогда не видел, чтобы это хорошо удавалось. Может быть, вы видели.
Удаленная работа из дома
Повышение пропускной способности интернет-соединения существенно облегчило людям возможность работы из дома. В этом случае различия в языке, культуре и часовом поясе не составляют существенной проблемы. Кроме того, не нужно передавать данные через океаны, нет сбоев. Совещания команды могут проходить почти так же, как если бы ее члены находились в одном помещении.
Не поймите меня неправильно. Когда члены команды работают из дома, есть значительная нехватка невербального общения. Разговоры, приводящие к случайным открытиям, происходят гораздо реже. Неважно, насколько хороша связь посредством электроники, члены команды все равно физически не в одном пространстве. Поэтому люди, работающие из дома, находятся в невыгодном положении. Они всегда пропускают какие-нибудь разговоры или импровизированные встречи. Несмотря на широкополосный доступ, они будто смотрят через глазок по сравнению с теми, кто находится рядом друг с другом.
Если в своем большинстве команда находится в одном пространстве, но один-два члена команды пару дней в неделю работают из дома, скорее всего, никаких трудностей не возникнет, особенно если используются средства связи с хорошей пропускной способностью. С другой стороны, если члены команды почти все работают из дома, такая команда никогда не сработается так же хорошо, как если бы была вместе.
Не поймите превратно. В начале 1990-х мы с моим партнером Джимом Ньюкирком благополучно управляли командой, все члены которой находились на удаленке. Почти все работали только из дома. Некоторые жили в других часовых поясах. Мы лично встречались от силы пару раз в год. С другой стороны, мы все говорили на одном языке, у нас был один менталитет, а разница во времени не превышала двух часов. У нас получалось работать. И мы работали. Весьма хорошо. Но мы бы работали лучше, если бы находись в одной комнате.
Заключение
На встрече в Сноуберде в 2000 году Кент Бек выразил мысль, что одна из наших задач — построить мост над пропастью, существующей между клиентами и разработчиками. Методы взаимодействия с клиентами играют важную роль при выполнении этой задачи. Если применять этот метод, то у разработчиков и клиентов будет простой и однозначный способ общения. Такое общение порождает доверие.
Глава 4. Методы взаимодействия внутри команды

Средняя полоса модели жизненного цикла Рона Джеффриса состоит из методов взаимодействия внутри команды. Эти методы регулируют отношения членов команды и их отношение к создаваемому продукту. Методы, которые мы обсудим, — это метафора, 40-часовая рабочая неделя, коллективное владение и непрерывная интеграция .
А потом кратко обсудим стендап-митинги .
Метафора
В годы накануне и после подписания Манифеста Agile метафора была методом расплывчатым, нам было стыдно, что не могли дать ему нормального описания. Мы знали, что это важно, поэтому могли привести удачные примеры. Но четко выразить то, что имели в виду, у нас не получалось. В некоторых наших беседах, на курсах и лекциях мы просто вскакивали и, выпучив глаза, восклицали: «Да вы сами все поймете, когда увидите!»
Для плодотворного общения команде требуется ясный и упорядоченный словарный запас из понятий и концепций. Кент Бек предложил понятие «метафора», так как это связывало его проекты с чем-то, о чем у всех команд было общее представление.
Первым примером Бека была метафора, которая использовалась в проекте расчета заработной платы «Крайслер» [42] https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System .
. Он сравнил оформление зарплатных чеков с конвейером. Чеки движутся от одной точки к другой, где к ним присоединяют разные «запчасти».
Пустой чек перемещается на точку, где на нем ставят идентификационный номер сотрудника. Потом он попадает на точку, где начисляется зарплата до вычета налогов. Затем он добирается до точки, где вычитаются налоги, затем до точки, где вычитаются расходы на медицинское страхование, затем до точки, где идут отчисления в пенсионный фонд… Ну вы поняли.
Программисты и клиенты могут довольно просто применить такую метафору к подготовке зарплатного чека. Она дала им словарный запас, чтобы говорить о программах.
Читать дальшеИнтервал:
Закладка: