Текст книги "Искусство Agile-разработки. Теория и практика гибкой разработки ПО"

См. также

Командная комната (глава 7)

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

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

Первые несколько раз, после каждого контакта с группами ваших стейкхолдеров, уделите некоторое время оценке и корректировке плана коммуникации. Со временем ваше общение станет комфортным для всех.

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

Что, если у нас отсутствуют необходимые ресурсы, но спонсор не хочет слушать?

Это трудная ситуация. Если вы знакомы с кем-то имеющим навыки дипломатии (например, продакт-менеджером, менеджером проекта или коучем), попросите их помочь донести это сообщение до спонсора. Тем временем работайте с тем, что есть, и продолжайте напоминать спонсору и бизнес-стейкхолдерам, что от вас ожидают, что вы сделаете X, Y и Z, но вы можете сделать только X и Z из-за ограниченности в ресурсах.

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

Когда ваша команда понимает свой контекст и обладает необходимыми подтвержденными ресурсами:

• она имеет доступ ко всему, что ей требуется для выполнения задачи;

• ее не застать врасплох внезапно появившейся и неизвестной ранее группе стейкхолдеров или требованию;

• общение с группами стейкхолдеров ровное и стабильное.

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

1. Знание того, кто ваши группы стейкхолдеров и что вам нужно друг от друга.

2. Определение способов, с помощью которых вы будете общаться друг с другом.

3. Корректировка вашей цели и ожиданий стейкхолдеров в соответствии с навыками, разрешениями и ресурсами, доступными команде.

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

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

Вы все еще сможете проводить эксперименты, даже если будете придерживаться базовой идеи сессии подготовки устава. Начните с практики, описанной здесь, предпочтительно задействовав опытного фасилитатора, просто чтобы получить некоторые представления о том, как это должно работать. Затем начните экспериментировать.

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

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

Аудитория

Продакт-менеджеры, коучи

Мы договорились о том, как будем работать вместе.

Что такое «команда»? Это не просто группа людей, сидящих в одной комнате. Это даже не группа людей, которой поручили работать над одной и той же задачей.

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

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

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

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

См. также

Цель (глава 7)

Контекст (глава 7)

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

Как и в случае с другими дискуссиями об уставе, тема согласования может поднять некоторые деликатные вопросы. Будет лучше, если вы привлечете нейтрального фасилитатора. Хороший фасилитатор поможет уладить конфликты и сделать так, чтобы мнение каждого участника было услышано.

В процессе согласования вы узнаете больше о людях в команде, создадите рабочие договоренности, которые будут направлять поведение команды, и установите стандарты[45]45
  Эта программа основана на [Larsen2016] (гл. 6), с некоторыми изменениями.


[Закрыть].

Узнайте друг друга

Начните ваше обсуждение с того, что поможет лучше узнать друг друга. Врезка «Упражнение на построение взаимоотношений в команде» выше в этой главе – хороший способ положить начало общению. Затем проведите групповое обсуждение следующих вопросов.

1. Кто я? (Расскажите немного о себе, поделитесь своими положительными личными качествами, например, «внимательность к деталям», «терпеливость» или «дружелюбие».)

2. Что люди сразу узнают обо мне, как только знакомятся? (Это может быть хобби, любимые места для поездки в отпуск или любимое домашнее животное.)

3. Почему я думаю, что эта группа хорошо подходит для достижения цели команды?

4. Каков самый важный факт из того, что другие должны знать обо мне, чтобы эффективно работать со мной?

5. Что все это для меня значит? Что я хочу получить от участия в работе команды и достижении ее цели?

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

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

Заключите рабочие соглашения

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

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

1. Вспоминая ваш прошлый опыт работы в команде (любого типа, включая спортивные команды, церковные или музыкальные группы либо хоры), подумайте, когда вы были наиболее эффективны как член команды. Расскажите коротко об этом времени. Какие рабочие условия привели к эффективной работе?

2. Поразмышляйте о том времени и тех ситуациях в вашей жизни, когда вы сотрудничали с командой. Что вы заметили в отношении себя, своего вклада, что вам кажется ценным? Что вы больше всего цените в тех группах?

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

4. Какие три желания вы бы загадали, чтобы ваш опыт в этой команде стал наиболее ценным?

Пока люди делятся своими воспоминаниями, сделайте паузу, чтобы записать идеи потенциальных рабочих соглашений. Они могут относиться к чему угодно: стандарты поведения, например, «мы не прерываем говорящего»; особенные практики, например, «мы используем парное программирование для всего промышленного кода»; рабочие привычки, например, «меняя задачи, мы пишем сообщение об этом в групповой чат» и т. д. Запишите все, что может помочь команде лучше работать вместе. Пока не критикуйте предложения; просто собирайте их.

После того как вы поделились своими историями, проверьте, рассмотрели ли вы категории, приведенные ниже в перечне. Если нет, то предложите рабочие соглашения и относительно них. Вам не обязательно будет их выбирать, просто убедитесь, что вы их приняли во внимание.

• Практики, которые будет использовать ваша команда. Я рекомендую начать с каждой практики на уровнях, выбранных вашей командой.

• Для виртуальных команд – как вы будете общаться (см. пункт «Организация удаленного взаимодействия» выше в данной главе).

• Как вы будете принимать решения.

• Для физических команд – как вы будете решать проблему отвлекающего фонового шума.

• Для команд, которые не используют парное или групповое программирование, – как вы будете просить помощи, не отвлекая коллег (см. пункт «Всегда просите помощи, всегда помогайте» выше в данной главе).

• Обязательные рабочие часы, в течение которых вы можете ожидать, что все члены команды будут доступны.

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

Убедитесь, что все согласны с окончательным списком, проведя голосование о согласии (см. пункт «Стремитесь к согласию» выше в данной главе). Если не получается достичь согласия по определенному пункту рабочего соглашения, то просто пока исключите его из списка. Вы сможете вернуться к нему позже.

См. также

Командная комната (глава 7)

В завершение сформулируйте все рабочие соглашения и внесите их в окончательный список. Каждое должно заканчиваться предложением «Мы работаем вместе лучше, когда…» Опишите то, что надо делать, а не то, что не надо делать. Другими словами, вместо «мы не прерываем друг друга» запишите «мы даем людям закончить мысль и только потом выражаем свою».

Прикрепите список где-нибудь на видном месте в вашей командной комнате. Вы можете сразу начать им пользоваться.

Задайте стандарты

Стандарты – это особые рабочие соглашения, применяемые к определенным типам задач. Примерами могут служить стандарты кодирования, рекомендации по UI-дизайну и эксплуатационные стандарты.

Стандарты могут становиться источниками конфликтов, если к ним не обращаются, поэтому будет лучше сразу дать им определение. Их содержание не очень важно. Вы будете их расширять и корректировать с течением времени. Помните, что в Agile мало решений, которые нельзя изменить. Уорд Каннингем сказал об этом так (https://oreil.ly/IcikH):

«Переломный момент в моей программистской карьере наступил, когда я осознал, что мне не нужно побеждать в каждом споре. Допустим, я разговаривал с кем-то о коде и говорил: “Я думаю, что лучший способ это сделать – это А”. А они отвечали: “Мы думаем, что лучший способ это сделать – это Б”. Я говорил: “Нет же. Это точно А”. Они отвечали: “А мы хотим это сделать с помощью способа Б”. Поворотный момент настал, когда я смог сказать: “Хорошо. Делайте с помощью способа Б. Если я ошибаюсь, это не причинит нам особого вреда. Даже если я прав, а вы делаете Б – нам и это не слишком повредит, поскольку мы можем исправить ошибки. Так что давайте узнаем, является ли это ошибкой”».

Исходя из этого, используйте следующие две рекомендации для создания своих стандартов.

1. Создайте минимальный набор стандартов, который позволит выполнять работу.

2. Предпочтите последовательность и согласованность, а не совершенство.

См. также

Сделано Сделано (глава 9)

В качестве первого стандарта решите, что подразумевать под сделанной работой. Начните обсуждение, попросив участников предложить промышленный стандарт в качестве основы. (Для определения понятия «сделано» можете использовать чек-лист «Сделано Сделано» (Done Done) из главы 9.) Если в вашей компании уже есть стандарты, то начните с них.

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

Далее, используя одновременный мозговой штурм, подумайте о дополнениях или изменениях. Сгруппируйте идеи, используя диаграмму сходства (см. пункт «Работайте одновременно» выше в данной главе), а затем проведите точечное голосование, чтобы выбрать наиболее важные категории.

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

Ограничьте обсуждение каждого варианта пятью минутами. Если не удалось договориться за это время, то пока просто пропустите это предложение. Повторюсь: у вас будет возможность пересмотреть свои стандарты позже. Отведите на все обсуждение 45 минут.

После того как сформулируете определение понятия «сделано», повторите процесс с любыми другими нужными вам стандартами. Можно это сделать параллельно, разбившись на специализации, такие как программирование, UX-дизайн и эксплуатация.

Резюмируем.

1. Начните с согласования по поводу базового стандарта. (Ограничьтесь пятью минутами.)

2. Внесите дополнения или поправки с помощью мозгового штурма. Сгруппируйте их по категориям. Проведите точечное голосование.

3. Для каждой категории заключите соглашение об определенном стандарте. (Ограничьтесь пятью минутами.)

4. Отведите на все обсуждение 45 минут.

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

Помимо форматирования

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

Результат был предсказуем: у нас было три разных подхода к форматированию нашего кода. Я даже увидел три разных варианта отступа в пределах одного короткого метода.

Знаете, что меня удивило? Это было не так уж плохо. Конечно, текст программы выглядел скверно, и я бы предпочел что-то более последовательное, но все же код был читаемым. В конце концов, остальные наши стандарты кодирования имели большее значение, чем форматирование.

Мы договорились, что важно именовать переменные и короткие методы понятным образом. Мы договорились использовать утверждения (assertions), чтобы быстро обнаруживать неправильно работающий код, не оптимизировать без измерений и никогда не передавать пустые ссылки (ссылки, которые не ссылаются ни на какой объект, null references) между объектами. Мы договорились о том, как надо и не надо обрабатывать исключения (exceptions), что делать с отладочным кодом (debugging code), когда и куда регистрировать события (events). Эти стандарты помогли нам гораздо больше, чем это мог бы сделать единый стиль форматирования. Каждый стандарт приносил конкретную пользу. Вероятно, именно поэтому мы смогли договориться о них, когда не смогли договориться о форматировании.

Не поймите меня неправильно: иметь единое форматирование было бы лучше! Но, собирая в единое целое ваши стандарты программирования, не загоняйте себя в ловушку бесконечных споров о форматировании.

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

Стандартам нужно какое-то время, чтобы устояться. Запланируйте встречу, на которой вы сможете обсудить ваши стандарты, через несколько дней после начала вашей совместной работы, и еще одну – еще через несколько недель. Одного часа должно быть достаточно. Это поможет вам применять ваши стандарты на практике. Если после этого возникнут разногласия по поводу стандарта, то договоритесь поэкспериментировать с одним подходом, потом с другим и затем вернитесь к этому вопросу.

См. также

Ретроспективы (глава 11)

Вы можете изменить ваши рабочие соглашения и стандарты в любой момент. Просто объявите о своем намерении команде, получите согласие и замените флипчарт или его виртуальный эквивалент. Кроме того, удобно изменять рабочие соглашения во время ретроспектив.

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

См. также

Парное программирование (глава 12)

Групповое программирование (глава 12)

Коллективное владение кодом (глава 12)

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

Автоматизированное соблюдение стандартов, как правило, менее эффективно. Некоторые используют автоматизированные системы для проверки своего исходного кода на соответствие стандартам или автоматически переформатируют код после регистрации. Это может работать, если команда все согласовала, однако обычно это заводит команды в ловушку чрезмерного принуждения.

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

Вместо этого лучше начать, предположив, что человек имел добрые намерения. Возможно, он неправильно понял соглашение, или думает, что оно больше неприменимо, или по каким-то причинам не может соблюдать это соглашение.

Если кто-то постоянно нарушает командные соглашения, то поговорите с ним наедине, чтобы узнать, нет ли с его стороны принципиального несогласия. Займите позицию коллективного решения проблем. Вместо того чтобы спросить: «Почему ты не работаешь с нулевыми значениями, как мы договаривались?», задайте вопросы: «Что ты думаешь о стандарте работы с нулями, о котором мы договорились? Не нужно ли нам его изменить?» Примите к сведению все возражения, доведите их до всей остальной команды и подумайте об изменении соглашения.

Если кто-то согласен с соглашением, но все же не соблюдает его, то, возможно, оно применимо не в каждой ситуации. Спросите о конкретных случаях, замеченных вами. И повторюсь: делайте это в манере сотрудничества, а не конфронтации. Скажите нечто вроде: «Я согласен с тобой насчет того, как мы должны работать с нулями. Можешь объяснить, что происходит в этом случае в данной функции? Я не понимаю, почему этот код не проверяет на нули».

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

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

В этом случае, возможно, лучшее решение – позволить нарушению просуществовать несколько месяцев. Со временем, привыкнув к изменениям в своей среде, члены команды расслабятся и будут более склонны идти на компромисс.

Рабочие соглашения и коучинг

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

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