Постигая Agile Грин Дженнифер
Акт VI. Круг почета
Была половина двенадцатого ночи, все еще находились в офисе, но никто и не думал работать. На днях команда запустила сайт Lolleaderz.com, и на него уже поступили отличные отзывы. Число пользователей росло. CEO наконец-то одобрил идею вечеринки по поводу этого удачного релиза, которую настойчиво предлагали Роджер и Ави. Он позвал диджея, организовал шведский стол с закусками и спиртными напитками. Роджер и Ави намеревались хорошенько выпить.
Роджер наткнулся на Эрика, который увлеченно болтал с несколькими членами команды, и сказал ему: «Мы бы никогда не сделали этого без тебя!»
Эрик немного подумал и ответил: «Очень мило с твоей стороны. Но сам посуди, что особенного я сделал? Я просто указал на некоторые проблемы и предложил решения, которые в свое время помогли мне самому. И время от времени я позволял вам столкнуться с некоторыми из этих трудностей, чтобы вы поняли, в чем их суть».
Подошел Ави со словами: «Так как насчет пары сложных моментов, с которыми все-таки пришлось столкнуться? Почему мы не смогли их избежать? Не подумай, что я жалуюсь, ведь полученные результаты говорят сами за себя».
К этому моменту возле них оказалась большая часть команды, а также несколько менеджеров. Эрик сказал: «Если бы у тебя не было той тяжелой встречи с другими аккаунт-менеджерами, то сумели бы вы продвинуться вперед и объединить в проекте все пользовательские истории? Удалось бы вам оценить скорость работы над проектом и начать планировать свои спринты?»
Роджер задумался. «Так ты считаешь, что единственный способ чему-нибудь научиться – это нарваться на неприятности?»
На это Эрик ответил: «Я бы предложил взглянуть на ситуацию с другой стороны – позитивной – и стать более эффективными. Когда вы ищете способы совершенствования, вы растете как команда».
Все присутствующие заулыбались и закивали. Откуда-то из-за спин собравшихся прозвучало: «Именно это я и хотел услышать!»
Это сказал CEO, выглядевший очень довольным. «Я вижу, что у этой команды большое будущее. Отличная работа!»
Переосмысление scrum-ценностей
В ходе проекта Lolleaderz.com Роджер, Ави и команда встретились с множеством трудностей. Многие команды, столкнувшись с подобными проблемами, провалили бы проект. Как же этой команде удалось превратить проблемы в возможности? Как они смогли извлечь опыт из своих ошибок и достичь успеха?
Одна из важных причин – наличие эффективного наставника, Эрика, который помог им преодолеть препятствия. Прежде всего Эрик помог Роджеру, Ави и остальным членам команды вникнуть в ценности Scrum: мужество, приверженность, уважение, сосредоточенность и открытость. Он рассказывал им про «свиней» и «кур», чтобы они поняли, что такое «приверженность». Он помог им понять, как сделать ежедневные scrum-митинги эффективнее и стать более сосредоточенными. И он показал им, как научиться взаимному уважению, начав прислушиваться друг к другу. Эрик помог улучшить планирование и организацию спринтов и бэклога с использованием таких инструментов, как пользовательские истории и скорость. Это сделало команду более открытой для всех, включая других аккаунт-менеджеров и CEO. И когда настали трудные времена, Эрик показал им, как важно иметь мужество говорить правду, даже если это на какое-то время приводит к неприятным последствиям.
Каждый проект имеет свои проблемы и вызовы. Когда вы пробуете новую методику впервые, эти проблемы могут усугубляться из-за отсутствия опыта, непонимания или повторения старых ошибок. Хороший наставник, такой как Эрик, знает это. Вместо того чтобы пытаться избежать ошибок, он воспользовался ими, чтобы создать учебные ситуации для команды. Это называется позволить команде неудачу, и такой прием – один из основных в арсенале коучинга.
Лисса Адкинс пишет об этом в уже упоминавшейся здесь книге Coaching Agile Teams:
Позвольте команде неудачу: конечно, это не значит хладнокровно наблюдать, как команда приближается к краю пропасти. Но используйте десятки возможностей, которые возникают в каждом спринте, чтобы позволить команде провалить одно из заданий. Команды, попадавшие в трудные ситуации и выходившие из них благодаря в том числе сплоченности, становятся крепче и работают быстрее по сравнению с теми, которых оберегали от неудач. Такая команда может удивить вас. То, что должно было причинить ей вред, сделало ее сильнее. Наблюдайте и ждите.
Одно дело – читать такие слова, как «мужество», «приверженность», «уважение», «сосредоточенность» и «открытость», и соглашаться, что они звучат как призыв. И совсем другое – пойти к руководству и сказать, что команда не успеет поставить ПО в срок, потому что ей не хватает времени в спринте. Трудно проявлять мужество, когда ситуация грозит вам увольнением.
Вы не сможете успешно внедрить Scrum, не придерживаясь этих ценностей. Но дело в том, что только часть компаний имеют культуру, совместимую со Scrum, а у остальных ее нет. Возможно даже, что ваш руководитель требует от вас командно-административного стиля управления проектами и вы будете уволены, если попытаетесь создать самоорганизующуюся команду.
Scrum-команды учатся на своих ошибках – благодаря этому они развиваются и двигаются вперед. Команда нуждается в культуре, при которой совершать ошибки – это норма. Именно поэтому мы так тесно сотрудничаем внутри scrum-команд и взаимоуважение так ценно. Но даже если команда терпима к ошибкам и способна учиться на них, может случиться, что она работает в компании, которая их не приемлет. Как пишет новатор в области разработки программного обеспечения Грэди Буч в своей книге Beautiful Teams:
Один из известных мне признаков здоровой компании – ее терпимость по отношению к возможному неуспеху. Компании, которые крайне негативно относятся к провалам, имеют тенденцию быть менее инновационными, и работать в них не очень-то весело, потому что люди настолько боятся неудач, что всегда излишне осторожничают. А компании, допускающие большую свободу действий (хотя и не настолько, чтобы подорвать бизнес) и позволяющие сотрудникам совершать ошибки, оказываются более продуктивными, потому что в них карьере работника не угрожает случайная оплошность, допущенная в коде.
Так что же делать, если вы обнаружили, что оказались в компании, где неудача означает увольнение? Возможен ли в ней хоть какой-нибудь Scrum?
Не каждая команда и не в любой компании может самостоятельно организоваться за один день, и это нормально. Если культура вашей компании не совпадает с принципами Scrum, то вы, как адепт этого подхода, должны разъяснять окружающим ее ценности. Лучше всего делать это на личном примере: показывать, что значит открытость в работе, уважение к другим членам команды, а также умение проявлять мужество при столкновении с трудностями. Найти хорошего наставника – отличный способ продемонстрировать людям, как работают принципы Scrum, и помочь им начать менять свое отношение к делу. Часто команды пытаются использовать консультантов как наставников. Это очень удобно для руководителей: следовать чужим советам в том, какие изменения надо внести.
Но иногда, даже если вы делаете все правильно, сложившаяся культура компании, в которой вы работаете, может быть слишком далека от ценностей Scrum. В этом случае самоорганизация и коллективные обязательства могут оказаться для вашей команды недостижимыми.
А по мнению Кена Швабера, не добившись самоорганизации и коллективной приверженности, вы не получите Scrum.
И это нормально!
Даже помимо безоговорочно принятых ценностей, самоорганизации и коллективной приверженности Scrum содержит множество полезных методов. Они очень просты, легки в применении, и, как правило, вы можете внедрить их внутри команды, не спрашивая разрешения у руководства (или позже извинившись за самодеятельность).
Даже если вы работаете в среде, где невозможно изменить существующие ценности, внедрение отдельных приемов Scrum может дать полезный результат. Вы должны так поступить, потому что лучше что-то делать, чем сидеть сложа руки. Просто убедитесь, что вы и ваша команда знаете, что делаете и где проходят границы ваших возможностей по внесению изменений.
Однако не стоит просто применять отдельные методы, а потом называть это полным внедрением Scrum. Поступив так, вы обрекаете себя на борьбу в дальнейшем. Сотрудники компании, читавшие о «гиперпродуктивных командах» и «потрясающих результатах», будут спрашивать, где все это. А у вас не найдется достойного ответа. Еще неприятнее, если команда, увлекшись Scrum и рассчитывая на радикальные улучшения, обнаружит, что для нее почти ничего не изменилось. В некотором смысле это равнозначно сигналу о том, что они достигли предела возможных изменений и дальнейшие улучшения производить нельзя. Это может расстроить и даже демотивировать работников. Такие проблемы создадут препятствия для внесения улучшений в будущем. Ведь если планка установлена слишком низко, то люди будут считать, что дальнейшие улучшения находятся вне их компетенции.
Иными словами, поздравляя окружающих с использованием новой методологии, вы будете создавать у них впечатление, что Scrum – это всего лишь переименование статус-митингов в ежедневные scrum-митинги, а требований – в бэклог. Это опасно для внедрения Agile, потому что фундаментальные проблемы, которые вы пытаетесь решить за счет Scrum, никуда не денутся. Большинство людей будет считать, что Scrum не может их исправить и даже что эти проблемы существуют везде и не имеют решения. Вспомните, сколько раз вы слышали фразы «Разработчики не могут заранее оценить объем работ», «Программное обеспечение постоянно глючит» или «Проекты никогда не выполняются в срок», произнесенные таким тоном, словно это законы бытия.
Хуже всего то, что, утверждая, будто Scrum может решить те проблемы, которые многим кажутся неразрешимыми в принципе, вы производите впечатление фанатика. Отсутствие явных результатов будет отталкивать людей от Scrum. Это повредит вашей карьере и настроит коллег против Scrum.
Существует еще один способ!
Дайте команде не только новые методы, которые они внедрят сегодня, но и видение того, чего они смогут достичь завтра. Тогда люди охотнее поверят в то, что делают Scrum, потому что уже освоят несколько простых методов.
Что делать, если вы реализовали практики Scrum, но еще не приступили к работе по самоорганизации и коллективной ответственности и понимаете это? Вместо того чтобы утверждать, что практики Scrum полностью внедрены, мы можем честно признать: впереди еще длинный путь по освоению ценностей Scrum, самоорганизации и превращению в команду, по-настоящему стремящуюся к результативности.
Первое отличие такого подхода заключается в том, что вы не давали обещаний, которых не сможете сдержать, а просто заявили людям, что сделали бы некоторые вещи немного лучше. Поэтому когда они видят улучшение результатов, то вместо недовольства тем, что не все проблемы устранены, испытывают удовлетворение от того, что команда производит программное обеспечение быстрее и лучшего качества. Гораздо легче начать разговор о новой ценности для компании, если у вас есть улучшения, пусть и небольшие. И ваш руководитель, вместо того чтобы слышать критику в свой адрес за недостаточное внедрение Scrum, получит от вас хорошие результаты сегодня и радужные перспективы на завтра – если только он разрешит команде реализовать свои устремления.
Не каждая компания готова отказаться от командно-административного управления проектами и сделать ставку на самоорганизацию, и не все команды способны принимать коллективные обязательства. Чтобы выяснить, готовы ли к ним ваши команда и компания, необходимо оценить, совместима ли культура компании с ценностями Scrum. Но как эти ценности Scrum внести в практику реальной жизни?
Постарайтесь честно ответить на следующие вопросы. Обсудите это с вашей командой и менеджером. Если все в порядке, то ваши компания и команда готовы к ценностям Scrum. А если нет, то такие обсуждения помогут понять, как правильно внедрить Scrum в вашу команду.
Чтобы понять, готовы ли вы к обязательствам и ответственности, спросите команду и руководителя, согласны ли они:
• отказываться от контроля над проектом и доверить команде самой принимать решения;
• не заниматься самодеятельностью и не создавать изолированных элементов в надежде на то, что удастся интегрировать их в конце проекта;
• следить, чтобы в команде не появился «мальчик для битья», на которого валятся все шишки[45];
• прислушиваться к мнению коллег, а не навязывать свое представление о том, как надо работать;
• действительно брать на себя ответственность. Все ли в команде готовы к этому.
Чтобы понять, готовы ли вы к уважению, спросите команду (себя в том числе) и руководителя, согласны ли они:
• доверять команде работать самостоятельно и устанавливать сроки сдачи функций исходя из их относительной ценности и того, как развивается проект, даже если он займет больше времени, чем вы ожидали;
• давать команде достаточно времени на выполнение задач и не требовать от нее сверхурочных работ;
• доверять команде выбирать задачи, которые ей подходят и нужны для проекта, а не полагаться на строгое распределение ролей, матрицы RACI и т. д.;
• никогда не говорить, будто вы понятия не имеете, почему команда приняла то или иное решение.
Чтобы понять, готовы ли вы к сосредоточенности, спросите команду (себя в том числе) и руководителя, согласны ли они:
• не просить никого в команде сделать работу, которая не входит в текущий спринт;
• не просить никого из членов команды выполнить работу, которая не была включена в ее планы, только потому, что «мне нужно, чтобы это срочно было сделано»;
• ставить наиболее важные интересы компании выше всех прочих проектов и работ;
• не требовать, чтобы члены команды работали над конкретными задачами в наперед заданном порядке.
Чтобы понять, готовы ли вы к открытости, спросите команду (себя в том числе) и руководителя, согласны ли они:
• действительно прислушиваться к мнению других и размышлять над ним;
• думать о планировании проекта и пользователях, если раньше этого не делали;
• задумываться о технических деталях;
• интересоваться, над чем работает сидящий рядом программист и служит ли это общей цели;
• что программист, сидящий рядом с вами, должен действовать аналогичным образом.
Чтобы понять, готовы ли вы к мужеству, спросите команду (себя в том числе) и руководителя, согласны ли они:
• никогда не обвинять менеджера проекта в отсутствии планирования;
• никогда не сетовать на «эти дурацкие требования», не попавшие в оценку, сделанную владельцем продукта или старшими менеджерами;
• тратить время на то, чтобы действительно понять пользователей;
• не добиваться совершенства там, где клиенту нужен просто добротный продукт.
Если на большинство этих вопросов прозвучит ответ «да», то ваша команда, менеджеры и компания, скорее всего, имеют культуру, соответствующую ценностям Scrum. Но если хотя бы в одной группе вопросов будут два ответа «нет», то это причина обсудить данную тему с командой и руководством. В том случае, если открытой дискуссии не получится, вам наверняка придется заняться проблемой открытости, чтобы в дальнейшем получить максимальную отдачу от Scrum.
Не являются ли бэклог и доски задач простой разновидностью графика проекта? Не делают ли scrum-команды то же самое, что и моя команда?
Можно применять инструменты и практики Scrum способами, очень похожими на традиционный проект. Например, некоторые команды пишут пользовательские истории, близкие к сценариям использования. Но команда, не меняющая приемы работы, не изменит и своих результатов. Это означает, что команды, не изменившие собственного мышления, что необходимо для Scrum, не получают существенного прироста производительности труда. Иными словами, их работу можно охарактеризовать как «лучше-чем-ничего».
Одно из основных различий между эффективной scrum-командой и традиционными проектными командами заключается в том, что план scrum-команды не отправляется на полку сразу после составления, чтобы быть извлеченным оттуда только в случае срыва сроков. Они проверяют его выполнение на ежедневном scrum-митинге, чтобы сразу выявить возникающие проблемы. Более того, многие эффективные scrum-команды резервируют не менее часа в неделю для работы с владельцем продукта над обновлением бэклога (некоторые называют это «причесывание»). Владельцы продукта все время открывают для себя новые возможности. Во время еженедельных встреч по бэклогу команда вместе с владельцем продукта обсуждает создание новых карточек пользовательских историй с критериями удовлетворенности. Они присваивают очки новым пользовательским историям, а затем вместе с владельцем продукта расставляют приоритеты новых историй в бэклоге продукта, отталкиваясь от того, насколько они важны и как долго их делать.
Это дает команде два очень мощных инструмента. Один из них – это получение обширного опыта по оценке трудоемкости, так что, когда приходится вносить изменения, она точно знает, как спрогнозировать их влияние.
Другой дает командам возможность обсуждать с владельцем продукта, какие из пользовательских историй он считает наиболее ценными. И если команда хочет вести диалог об этом, она должна понять истинные цели проекта. Внимание к целям важно, потому что, поскольку владелец продукта проделал большую работу, объясняя командам, для чего пользователям необходимо это ПО, им будет гораздо проще выяснить, какие истории в бэклоге продукта наиболее значимы.
Этот подход полезен, когда команда взаимодействует с владельцем продукта, чтобы понимать значение каждого элемента невыполненной работы. Ведь члены команды постоянно планируют и оценивают каждый из этих элементов. Таким образом, когда появляются изменения, любой член команды может сразу оценить их воздействие на общий план работ. Именно этот процесс обозначают словами «планирование в последний ответственный момент»: почти непрерывное выполнение, для которого команда специально резервирует время, поскольку считает это естественным.
Но не терпят ли программисты неудач при планировании, особенно в отношении проектов разработки ПО, трудоемкость которых невозможно просчитать в принципе?
Вероятно, это самое распространенное заблуждение о планировании или даже самоисполняющееся пророчество. Это не означает, что только программисты бездарны в планировании. Любой новичок в этом деле будет совершать ошибки. Если бы все люди были профессионалами в составлении планов, то бизнес всегда приносил бы прибыль, рынок двигался вверх, а каждый брак длился вечно (ведь никто не планирует развод в день своей свадьбы).
Планирование – это не предсказание будущего. Многие команды и менеджеры верят в миф об идеальном плане проекта, для которого разработчики могут дать точные оценки, а руководители проектов в состоянии спланировать любой риск и добавить оптимальный резерв на случай чрезвычайных ситуаций. Планы таких команд и менеджеров меняются не реже, чем у всех остальных, а порой даже чаще, потому что они включают в них слишком много мелких деталей, которые очень часто оказываются неточными. Недаром их проекты сталкиваются с проблемами планирования, и поэтому создается впечатление, что программисты бездарны в планировании, а программные проекты непредсказуемы!
Scrum-команды способны планировать более эффективно, потому что идут от общего к частному. Сначала они обрисовывают план в общих чертах, начиная с бэклога продукта, который содержит достаточно информации от владельца продукта и пользователей, чтобы можно было решить, что в нем главное. Команды начинают детальное планирование только в начале спринта и лишь для тех невыполненных работ бэклога, которые собираются включить в спринт. Основная часть работы по планированию на ближайшие дни и часы приходится на ежедневные scrum-митинги. Если какой-то фрагмент подробного планирования должен быть сделан в начале спринта, то команда его выполнит. Но такое случается редко, так что на подробное планирование не требуется отводить много времени, да и команда может пересмотреть эти планы во время очередного scrum-митинга.
Разве не более эффективно спланировать все наперед, а позже при необходимости просто уточнить план?
Нет. Многие команды убеждаются на практике, что, откладывая решение на последний ответственный момент, они получают дополнительную гибкость и это помогает эффективнее планировать или не менять планы. Этот стиль хорош тем, что дает возможность людям принимать решения, когда они лучше к этому подготовлены, а не наспех и не имея полной информации.
Одна из важных причин провала многих крупных проектов – в чересчур подробном изначальном планировании, подробности которого далеки от реальности, потому что у разработчиков просто недостаточно информации. Это приводит к знакомому нам по предыдущим главам CYA-циклу, когда руководители проектов винят разработчиков в неточной оценке объемов работ, а программисты менеджеров – в плохом планировании. Люди обвиняют друг друга, но положение дел не меняется. Страдает только качество программного обеспечения.
Scrum дает нам свободу от CYA-цикла благодаря тому, что планирование производится с той степенью детализации, которая доступна команде в данный момент и позволяет отложить те подробности, которых мы пока не знаем, на последний ответственный момент. Мы ежедневно пересматриваем и адаптируем план, чтобы быть в состоянии быстро отреагировать, когда он оказывается ошибочным, что рано или поздно обязательно случится. Взамен Scrum требует от нас ответственности в правильном понимании того, что является ценностью создаваемого ПО.
Разве не является нереальным обещание, что в конце каждого спринта вы будете иметь работающее программное обеспечение, пригодное для демонстрации? Как быть, если команда работает над тем, что нельзя показать наглядно?
Этот вопрос очень часто задают новые scrum-команды. Некоторые функции, например новые страницы для веб-приложений, дополнительные кнопки, изменение в действиях конечного пользователя, очень легко продемонстрировать. Просто возьмите историю пользователя, запустите программу и продемонстрируйте выполнение каждого пункта условий удовлетворенности. Но некоторые функции показать не так-то просто. Как быть, если команда несколько недель оптимизировала базу данных, улучшала программные сервисы или выполняла другие нефункциональные изменения?
Любое изменение программного обеспечения можно продемонстрировать, и для программистов крайне полезно найти способ сделать это. Скажем, спринт был направлен на внесение изменений в базу данных. Разработчики не могут просто зайти в нее, внести изменения, а затем двигаться дальше, не проверив, работают ли они, – никто так не делает! Поэтому они написали код, сделали вставки, обновления, изменения, удаления и прочее, чтобы убедиться: изменения базы данных работают корректно. И вероятно, они также внесли изменения в другие части кода, которые используют эту базу.
Именно эти изменения команда и должна показать во время обзора спринта владельцу продукта, пользователям и заинтересованным сторонам. Разработчики часто пишут одноразовый код для проверки работоспособности изменений, внесенных в базу данных. Но если они знают, что им нужно наглядно показать работу изменений, внесенных в ходе спринта, то они могут взять этот код за основу и, слегка доработав его и выполнив небольшую отладку, создать модуль для демонстрации сделанного. Это вряд ли потребует много дополнительного времени, но зато у команды будет способ проверить работу изменений, который может пригодиться в будущем, если потребуется внести другие изменения или поменять тестовый сценарий.
Такой же подход полезен и в случае других видов нефункциональных изменений (которые не влияют на способы взаимодействия пользователей с программой, но требуют внесения правок в код). Команда, работающая над изменениями производительности, может продемонстрировать тесты «до и после», которые показывают достигнутое улучшение. Изменения, внесенные в архитектуру, можно продемонстрировать при помощи простой программы, которая показывает различные данные, полученные от нового API-сервиса. Любое изменение можно показать наглядно, и создание таких презентаций держит команду в тонусе. Это один из способов, который помогает scrum-командам планировать и развиваться.
Когда команда демонстрирует нефункциональные изменения, она делает это при помощи нескольких отдельных скриптов, тестов, программ или другого кода, написанного для проверки изменений. Разработчикам следует говорить о своей работе на языке, понятном клиентам. На самом деле не так уж мало пользователей способны понять то, что до них хотят донести программисты. Но главное, что такая демонстрация дает клиентам и заинтересованным сторонам реальное представление о том, что именно создает команда. Без показа могло бы сложиться впечатление, будто она провела спринт впустую, занимаясь всякой ерундой. Демонстрация же позволяет показать всем, в чем причина такой, казалось бы, неспешной работы, и это чрезвычайно ценно для команды, потому что в дальнейшем она сможет ставить реальные сроки, не подвергаясь давлению со стороны руководства, ничего не понимающего в ПО.
Когда возникает какая-то ошибка в уже готовом программном обеспечении, команда вынуждена приостановить текущую работу ради ее исправления, потому что невозможно отложить это до конца спринта. Но разве Scrum учитывает необходимость работ по поддержке?
Всем командам разработчиков постоянно приходится бороться с неожиданно возникающими проблемами. Поддержка – прекрасный пример этого. Команда, которая работает над сайтом, должна найти возможность исправить ошибку и немедленно помочь пользователям, и ей приходится потрудиться, чтобы это осуществить. Если исправление не может ждать до конца спринта, то команде остается только один вариант – заняться им немедленно.
Эффективная scrum-команда в этом отношении гораздо лучше, чем команда, придерживающаяся административно-командного стиля с «большими требованиями в начале проекта» (BRUF). Причина в том, что scrum-команды встречаются каждый день, чтобы оценить изменения и адаптировать к ним план работы. Эта команда может справиться и с проблемой изменения сроков, и с любым другим возникшим вопросом. Если это одна из тех экстремальных ситуаций, когда нет возможности дождаться следующего спринта, и владелец продукта согласился с этим от имени компании, то команда добавит эту срочную задачу в бэклог спринта, определит ее приоритет (скорее всего, установив его максимальным) и использует свои инструменты планирования – ежедневный scrum-митинг, доску задач, диаграмму сгорания, пользовательские истории, очки историй и скорость, – чтобы держать всех в курсе выполнения задачи и убедиться, что она будет сделана.
Основная разница заключается в том, что Scrum требует от нас быть честными перед самими собой и пользователями в оценке влияния этих изменений на проект. Мы не можем делать вид, что добавление такой работы происходит без затрат. Появится подъем в диаграмме сгорания, и станет очевидно: нужно принять меры для успешного завершения спринта. Впрочем, поскольку scrum-команды обычно выполняют свои обязательства по поставке ценного программного обеспечения, пользователи склонны доверять им. А раз команда демонстрирует работающее ПО, клиенты гораздо лучше понимают, как построена программа и что команда способна сделать за спринт.
Вряд ли у владельца продукта будет достаточно полномочий для принятия решений, необходимых связей с клиентами и компанией, а также свободного времени, которое он мог бы ежедневно проводить с командой. И это может создать впечатление, что Scrum не работает.
Хотите верьте, хотите нет, но существует масса эффективных scrum-команд в самых разных отраслях, которые работают именно так. Это происходит, потому что многие компании понимают: выделив команде работника с большим стажем работы и широкими полномочиями, они получают огромное преимущество и действительно оптимизируют деятельность по развитию в долгосрочной перспективе. Опытный специалист, помогающий команде понять реальную ценность программного обеспечения, которое она создает, – это ключ к достижению тех замечательных результатов, о которых любят рапортовать многие scrum-команды. Как правило, они трудятся в компаниях, вложивших достаточно усилий в назначение в команды эффективных владельцев продуктов.
Известна реальная цена такого назначения. Появление в команде успешного владельца продукта означает, что компания должна поручить его текущие обязанности кому-то другому, но продолжать платить ему зарплату не меньше прежней. Когда компания доверяет Scrum, ее менеджеры видят, что этот метод обеспечивает необходимые результаты благодаря работе команд, которые способны соответствовать постоянно меняющимся требованиям бизнеса. Назначение хорошего менеджера по продукту на такой проект окупается в долгосрочной перспективе.
Если все это кажется нереальным для той компании, в которой работаете вы, то это проблема не Scrum, а существующей в организации системы поставки ценностей. Многие компании четко предписывают своим командам не беспокоить изо дня в день руководство, бизнес-подразделения или продавцов вопросами о создаваемом программном обеспечении. Это один из наиболее распространенных видов конфликтов Scrum с ценностями компании.
Это также объясняет, почему многие компании предпочитают менее эффективный водопадный процесс «с большими требованиями в начале». Они готовы вложить больше времени, усилий и денег в создание этих документов, лишь бы снизить количество времени, которое их продавцы и руководители проведут в общении с командами. Ежедневная работа с командой – это очень трудоемкое занятие, руководителю гораздо проще прочитать документ, внести поправки, а затем смириться с не совсем удачным программным обеспечением. И компании часто пытаются исправить ситуацию, добавляя бизнес-аналитиков (улучшая тем самым качество документации), а также дополнительных инженеров по качеству и тестировщиков (чтобы убедиться, что требования были выполнены). Такой подход увеличивает количество дополнительной работы, компенсирующей нежелание исполнительных директоров утруждать себя. Но таков стиль работы во многих компаниях, и он все-таки позволяет создать хорошее программное обеспечение (правда, рано или поздно такие компании все равно окажутся в ситуации, характерной для отчетов CHAOS, и риск создания ими ненужных продуктов резко возрастет).
Если компания ценит программное обеспечение и время создающей его команды гораздо меньше, чем усилия бизнес-подразделений и продавцов, то несложно сделать анализ затрат и выгод – и тогда BRUF оказывается логичным способом построения программного обеспечения. Если вы работаете в компании именно такого типа, то успешная попытка использования Scrum поможет вашим менеджерам и остальным сотрудникам понять ценности Scrum и Agile. Но если это не сработает, вы, по крайней мере, сможете попрактиковаться в Scrum и пополнить свой послужной список неплохими (хотя и не выдающимися) результатами.
Я могу понять, как планирование спринта работает после того, как команда придумала свои оценки, но мне неясно, из чего эти оценки исходят. Как команды оценивают задачи?
Есть много различных способов оценки задач. Наиболее популярный из числа используемых scrum-командами – это покерное планирование, одна из общепринятых практик Scrum (GASPs)[46]. Такое планирование изобрел Джеймс Греннинг, соавтор Agile-манифеста. Метод стал популярным благодаря книге Майка Кона Agile Estimating and Planning. Вот как он работает.
В начале покерного планирования все оценщики получают по колоде карт. На каждой карточке написана одна из допустимых оценок. Оценщикам может быть, например, дана колода карт, которая включает 0, 1, 2, 3, 5, 8, 13, 20, 40 и 100. Карты должны быть подготовлены до проведения собрания по планированию, и цифры следует написать достаточно крупно, чтобы можно было видеть их на расстоянии. Карты можно использовать для повторных сессий покерного планирования.
Модератор поочередно читает описание каждой пользовательской истории или темы, которые должны быть оценены. Эту роль обычно поручают владельцу продукта или аналитику. Однако можно назначить на эту роль и любого другого человека, поскольку она не дает никаких особых привилегий. Владелец продукта отвечает на любые вопросы, которые задают оценщики.
После того как все вопросы заданы и все ответы получены, каждый оценщик выбирает из своей колоды карту, которая отражает его мнение. Карты не открывают, пока каждый оценщик не сделает свой выбор. Затем все карты одновременно переворачиваются, чтобы все участники могли увидеть оценки, данные другими.
Очень может быть, что разброс оценок будет велик. Это действительно хорошая новость. Если оценки разные, то оценщики объясняют, почему поставили высокие или низкие оценки. Важно, чтобы это не вызывало атак на авторов этих оценок. Вместо этого вы просто хотите узнать, о чем они думали.
Майк Кон. Agile Estimating and Planning (Pearson Education, 2005)
Покерное планирование очень эффективно, поскольку помогает людям воспользоваться накопленным опытом и объединить мнения и оценки всей команды в одно число. Значения карт не являются жестко фиксированными. Например, в прошлом некоторые команды использовали карточки с числами из последовательности Фибоначчи – 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, однако они не совсем удобны, потому что разница между соседними значениями довольно велика. Необходимо, чтобы выбор был легче, чем решение, займет задача 13 или 21 час, а история – 5 или 8 очков.
Как вы управляетесь с территориально разнесенными и большими командами?
Это непростой вопрос. Распределение команды по офисам в разных точках мира создает большие сложности. Нельзя назвать их непреодолимыми – многие agile-команды создают программное обеспечение, даже если они не сидят в одном помещении. Но когда вы снижаете возможности общения лицом к лицу и полагаетесь на менее надежные формы коммуникации, вы рискуете получить в своем проекте большее число дефектов, вызванных искажениями при передаче информации, как в детской игре «испорченный телефон».
Один из способов справиться с этой проблемой состоит в том, чтобы разделить крупные разнесенные scrum-команды на небольшие scrum-группы, работающие в одном офисе. Помимо ежедневных scrum-митингов они также планируют дополнительные ежедневные совещания (scrum-of-scrums), где члены каждой команды, собравшись вместе, отвечают на три вопроса. Используя бэклог своей команды, они самоорганизуются для работы над глобальным проектом и могут создавать друг для друга новые задачи, чтобы процесс интеграции работы каждой группы в общий проект был легким. Этот способ эффективен, потому что формирует для всей большой команды ее укрупненный план работ, который проверяется каждый день.
Scrum-of-Scrums – это не «серебряная пуля» и не решит всех или хотя бы большинства проблем больших территориально разнесенных команд. Самая большая трудность для такой команды заключается в поддержании каждого члена команды мотивированным общей целью. Как нам уже известно из главы 4, это главным образом достигается тем, что члены команды становятся «свиньями», а не «курами». Хотя безусловно можно сделать это независимо от удаленности членов команды друг от друга, гораздо более сложно для владельца продукта сделать так, чтобы у всех существовало единое видение задач. Потому что он должен передать его другим через разные часовые пояса при помощи телеконференций и электронной почты, а это гораздо труднее, чем при личном общении.
Я понимаю, что ежедневные scrum-митинги обеспечивают работу людей над правильными задачами. Но даже добросовестные разработчики способны увязнуть во второстепенных делах. Может ли нечто подобное произойти со scrum-командами?
Да, может. Основатель Scrum Джефф Сазерленд совсем недавно опубликовал вместе со Скоттом Дауни документ[47] под названием «Метрики для сверхпроизводительных scrum-команд», касающийся именно этой темы. Они работали со многими scrum-командами, чтобы определить набор параметров, позволяющий точно выяснить, насколько в действительности продуктивны «сверхпроизводительные» команды. Обнаружилось, что эффективная scrum-команда может выполнять проекты до пяти раз быстрее, чем обычная. И удержание разработчиков на главном направлении разработки имеет много общего с получением этого улучшения.
Сазерленд и другие scrum-лидеры постоянно ищут способы улучшить эту методику. Одна из многих интересных мыслей в этой статье заключается в том, что небольшая корректировка ежедневного scrum-митинга, направленная на удержание разработчиков в рамках наиболее ценных задач, создает значительную разницу в том, насколько успешно работает команда. Внесенные ими изменения состояли в том, что команда отвечала на различные вопросы по каждому элементу бэклога спринта, начиная с первого по порядку:
• Чего мы вчера достигли для истории первого элемента?
• Каков был наш вклад в историю первого элемента, выраженный в очках историй?
• Каков наш план по выполнению истории первого элемента сегодня?
• Что делать, если сегодня что-то блокирует нашу работу или замедляет ее?
Команда работает вместе, чтобы ответить на эти вопросы. Затем, вместо того чтобы поочередно опрашивать каждого ее члена, она движется по бэклогу спринта в порядке убывания важности задач, останавливаясь, когда закончится список или выйдет время ежедневного scrum-митинга.
Так почему этот процесс работает? Благодаря ежедневным scrum-митингам он удерживает членов команды от появления у них отстраненности (сквозь зевоту: «Я вчера работал над моим кодом, сегодня продолжаю над ним работать и завтра буду делать то же самое»). Митинги поддерживают всех в тонусе и фокусируют на приносимой командой ценности. Даже эффективные гибкие команды могут ненароком оступиться, если программисты чересчур увлекутся задачами, которые кажутся интересными им, отложив в сторону работу, важную для команды. Именно об этом заставляют думать всю команду приведенные выше вопросы.
Это возвращает нас к основной мысли, что scrum-митинг – фактически формальная совместная инспекция (подобная тем, о которых вы, возможно, слышали в университетском курсе по разработке ПО), цель которой – улучшить качество командного планирования и коммуникаций. Просто она проводится так, чтобы быть интересным и полезным занятием для команды.
Это одна из наилучших составляющих Scrum, потому что она постоянно развивается, а ведущие специалисты по этой методике могут вносить свой вклад в ее постоянное совершенствование.
Предлагаем несколько вариантов действий, которые вы можете предпринять уже сегодня (самостоятельно или вместе с командой).
• Если вы до сих пор не применяете пользовательские истории, то возьмите одну функцию, которую вы в настоящее время создаете, и напишите пользовательскую историю для нее. Поделитесь ею с остальными членами команды – что они думают об этом?
• Попробуйте покерное планирование уже сегодня и выделите время вместе с командой, чтобы попробовать оценить несколько задач текущего проекта. Вы можете напечатать карточки сами или купить их (свои мы приобрели в компании Mountain Goat Software – можно также попробовать их онлайновую игру по покерному планированию).
• После того как вы сформировали оценку, воспользуйтесь доской или прикрепите большой лист бумаги на стену и приступите к созданию диаграммы сгорания работ. Как долго вы сможете поддерживать ее актуальной? Обратите внимание на то, что происходит на графике в конце проекта или итерации.
• Можете ли вы проанализировать ваш последний проект или итерацию и оценить скорость работы?
Ниже перечислены ресурсы, которые помогут вам узнать больше об идеях, описанных в этой главе.
• Вы можете узнать больше о Scrum и коллективных обязательствах в книге Кена Швабера Agile Project Management with Scrum (Microsoft Press, 2004).
• Вы узнаете больше о пользовательских историях и общепринятой scrum-практике в книге Майка Кона «Пользовательские истории. Гибкая разработка программного обеспечения» (М.: Вильямс, 2012).
• Узнайте больше о планировании scrum-проекта в книге Майка Кона Agile Estimating and Planning (Addison-Wesley, 2005).
• Вы сможете узнать больше о ретроспективах в книге Эстер Дерби и Дианы Ларсен «Agile-ретроспектива. Как превратить хорошую команду в великую» (М.: Издательство Дмитрия Лазарева, 2017).
Здесь мы предлагаем советы для agile-коучей, помогающих своей команде разрабатывать идеи этой главы.
• Одна из главных задач коучинга состоит в том, чтобы помочь команде по-настоящему понять, что такое коллективные обязательства. Выявляйте ситуации, когда некоторые члены команды не решаются давать оценки, не принимают деятельного участия в планировании или пытаются заполучить scrum-мастера, который выполнил бы это за них.
• Обсудите с отдельными членами команды цели проекта. Отметьте случаи, когда люди проявляют узость мышления и думают только о конкретной функции или пользовательской истории, которую они воспринимают как зону своей ответственности. Рекомендуйте им брать на себя задачу другой пользовательской истории или функции, а другим членам команды – помогать им в этом.
• Приучайте scrum-мастеров делать все данные доступными. Поместите диаграммы сгорания и доски задач на стену и проводите ежедневные scrum-митинги там, откуда эта диаграмма хорошо видна.
• Оцените влияние внутренней политики компании: одной из причин, почему командам порой не хочется раскрывать реальный прогресс в работе над проектом, может оказаться неприятный опыт в прошлом, когда кто-то из руководства компании активно проявлял неудовольствие недостаточно успешным, на его взгляд, ходом работ. Ваша задача – не решать эту проблему за руководителей, а помочь им распознать ее, а также понять, как можно отчасти изменить корпоративную культуру, чтобы внедрение Scrum проходило эффективнее.
Глава 6. XP и охватывающие изменения
Люди ненавидят перемены… и это потому, что люди ненавидят перемены… я хочу быть уверен, что вы понимаете меня. Люди действительно ненавидят перемены. Они воистину их ненавидят.
Стив Макменамин. The Atlantic Systems Guild (1996)[48]
Вы когда-нибудь замечали, как часто программисты жалуются на своих пользователей? Немного побродив по специализированным программистским форумам, вы наверняка наткнетесь на ветку, где разработчики сетуют, что пользователи сами не знают, чего хотят, когда просят написать для них программу. Это стало частью культуры программистов: клиенты никогда не говорят, чего они хотят на самом деле, и осложняют жизнь программиста, то и дело меняя свои требования.
Выше уже говорилось, как Scrum предлагает решать эту проблему: непосредственные контакты с пользователями позволяют понять, что для них ценно, а частая поставка работающего ПО дает представление о том, как меняются потребности. Это дает руководителям проекта и владельцам бизнеса возможность постоянно пересматривать цели проекта, раз это обеспечивает максимальную отдачу. Значит, чтобы поспевать за изменением требований пользователей, команда должна постоянно корректировать код. Но разработчики знают, что внесение изменений в код приводит к ошибкам. Чем больше их вносится, тем более хрупким получается код. Любые ли правки кода приводят к ошибкам и нестабильности?
Это одна из тех проблем, с которыми справляется гибкая методология XP (Extreme Programming – экстремальное программирование). Как и Scrum, она состоит из практик, ценностей и принципов. Практики просты в освоении и весьма эффективны – они могут изменить ваш подход к работе. Но, как и в Scrum, эти изменения происходят, если члены команды воспринимают их правильно.
В этой главе вы узнаете об основных практиках XP и о том, как они могут быть применены командой программистов (или, наоборот, использованы неверно). Вы узнаете о ценностях и принципах ХР и о том, как они способствуют формированию правильного мировоззрения у каждого члена команды, помогающего создавать более качественный код. Вместо того чтобы ненавидеть изменения, каждый человек в команде учится их принимать.
Рис. 6.1. Мы разделили 10 основных XP-практик на четыре категории: программирование, интеграция, планирование и команда
Описание: команда занимается разработкой баскетбольного сайтаДжастин – первый разработчик
Даниэль – второй разработчик
Бриджит – менеджер проекта
Акт I. Сверхурочная работа
Джастина всегда охватывало странное чувство, когда он задерживался в офисе допоздна. Ему казалось, что он выпил слишком много кофе, хотя на самом деле это было не так. Но он никогда не испытывал ничего подобного, работая по ночам дома.
– Похоже, предстоит одна из таких ночей, – сказала Даниэль, напарница Джастина. Они подружились в колледже. Она училась на два курса старше на том же самом факультете информатики – одном из лучших в стране. Кроме того, они были напарниками на занятиях в химической лаборатории. Даниэль дала ему рекомендацию, когда он устраивался разработчиком онлайновой фантазийной баскетбольной игры в Chalk Player Online. Эта компания занимается разработкой сайтов на спортивную тематику, и она оказалась его первым работодателем.
Джастин никогда не имел намерений задерживаться в офисе. Не то чтобы у него были проблемы с работой по ночам. Руководитель проекта Бриджит тоже ничего не имела против того, чтобы он трудился допоздна, особенно если он делал это из дома. Но как-то вечером Джастин обнаружил, что уже 10 вечера, а он все еще сидит на рабочем месте и отправляет письмо с извинениями подружке, а соседу по комнате – просьбу выгулять собаку.
Забавно, что незадолго до этого они с Даниэль обсуждали, что неплохо было бы уйти сегодня домой вовремя. Но в конце дня Бриджит сообщила плохие новости: состоялась встреча с менеджерами продукта и появилась необходимость внести в код большое количество изменений. При запуске проекта предполагалось, что он будет включать только команды NBA. Но теперь менеджеры продукта решили, что добавление европейских баскетбольных команд принесет намного больше денег.
И вот Джастин и Даниэль снова задерживаются на работе.
– Это действительно нечестно, – сказал Джастин. – Мы твердо согласовали с ними более трех месяцев назад, что будем использовать только команды NBA.
– Мог бы и не напоминать мне об этом. Та встреча была моей идеей, – добавила Даниэль.
– И после всего этого они хотят, чтобы мы добавили эти команды. Нам придется выдрать много кода и сделать довольно серьезные изменения в базе данных. – Он замолчал на секунду. – Знаешь, я виню Бриджит. Я так зол на нее. Она просто не понимает, как это будет тяжело.
Даниэль испуганно смотрела куда-то мимо Джастина.
– Бриджит стоит у меня за спиной?
– Да, – сказала Бриджит. – Послушай, я прекрасно понимаю, насколько это серьезные изменения.
– Но это не просто изменения, – ответил Джастин. – Мы объяснили им, что именно собираемся сделать. Это было несколько месяцев назад. Они подписались под этим. Если бы они предупредили о европейских лигах тогда, то мы бы разработали нечто совершенно другое. Система, которую мы программируем, не дает возможности использовать несколько лиг, поскольку речь шла только об одной.
– Таким было исходное предположение, – добавила Даниэль, – и его изменение полностью меняет подход к проектированию системы. Мы собираемся выдирать большие куски кода, а это приведет к появлению проблем.
– Каких проблем? – спросила Бриджит.
– Вы когда-нибудь чинили автомобиль при помощи скотча и скрепок? – поинтересовался Джастин. – Так вот, это похожий случай.
Все переглянулись и поняли: впереди много бессонных ночей.
Основные практики ХР
Существует 13 основных практик экстремального программирования, которые могут помочь команде найти входы и выходы в разработке программного обеспечения и создавать легко изменяемый код. В отличие от scrum-практик, многие ХР-практики имеют особенности и направлены на решение самых распространенных проблем, провоцирующих создание плохого кода. В этих практиках все настолько тесно связано с программированием, что многие люди ошибочно считают: XP – это только для высококвалифицированных специалистов.
В этой главе мы поговорим о 10 основных практиках XP. Эти 10 практик разделены на четыре категории – программирование, интеграция, планирование и команда, – чтобы их легче было понять и удержать вас от заблуждения, будто методика XP пригодна только для суперразработчиков.
Две основные практики XP – разработка через тестирование и парное программирование – предназначены специально для программистов и помогают им писать более качественный код. Они сосредоточены на нескольких важных аспектах разработки программного обеспечения. Созданием автоматизированных тестов перед написанием кода и его последующим тестированием команды повышают качество программного обеспечения. Работая вдвоем на одном компьютере, разработчики более тщательно вычитывают код в поиске ошибок.
Когда программист делает разработку через тестирование, которую обозначают аббревиатурой TDD (test-driven development), он создает автоматизированный тест перед тем, как начнет писать код. И пока код продукта не написан, тест будет завершаться провалом. Программист понимает, что код работает, когда тест оказывается пройден. Это создает петлю жесткой обратной связи, помогающую предотвратить появление дефектов: сначала написание проверочных тестов, затем создание кода, способного их пройти, поиск проблем и путей их решения и написание дополнительных проверочных тестов. Такие автоматизированные тесты обычно называют модульными. Слово «модуль» используется неслучайно: почти во всех языках программирования код очевидным образом разделяется на модули (классы, методы, функции, подпрограммы и т. д.), и практически любой язык предоставляет как минимум один способ создания и запуска автоматических тестов, которые привязаны к каждому из этих модулей. Создав вначале тесты, программист гарантирует, что все написанные им модули будут работать корректно.
Разработка через тестирование позволяет убедиться лишь в том, что каждый отдельно взятый модуль работает. Это также помогает командам предотвратить некоторые из самых распространенных и серьезных проблем, которые могут создать трудности в ходе поддержки кода. Можно внести изменения в одну часть кода и обнаружить, что неожиданно появились ошибки в другой части, которая, казалось бы, никак не связана с первой. И это только потому, что разработчик не подозревал о существовании зависимости между ними. Когда программист пишет модульные тесты, использующиеся каждый раз при сборке кода, эти автоматизированные тесты помогают избежать появления зависимостей, которые, оставшись невыявленными, приведут к немедленному сбою. Тесты помогают программисту заметить проблему, прежде чем она окажется встроенной в общий код и ее будет трудно удалить. Кроме того, модульные тесты помогают разработчикам писать код, который легче использовать повторно. Например, программист может создать класс Java, работа с которым чрезмерно усложнена: использовать в нем сбивающие с толку имена, неудобную инициализацию или другие структурные проблемы, которые смогут легко пробраться в код любого разработчика. Когда программист создает модульный тест, использующий такой класс, изъян может стать очевидным и, так как код класса еще не написан, разработчику несложно устранить этот изъян. Затем модульный тест становится частью исходного кода, так что другие программисты могут опираться на него, чтобы увидеть, как этот метод предполагалось использовать.
Вторая основная ХР-практика, ориентированная на написание кода, – это парное программирование. В команде, занимающейся парным программированием, два разработчика пишут код, сидя за одним компьютером. В большинстве случаев один программист сидит за клавиатурой, а другой наблюдает и они постоянно обсуждают, что делают. Команды, работающие в парах, вносят гораздо меньше ошибок, потому что за процессом внимательно следят две пары глаз. Парная работа также помогает уменьшить усталость, потому что один программист может печатать, когда другой устал. Эффективные команды парного программирования обсуждают идеи и подходы, постоянно устраивают мозговые штурмы и поэтому более инновационны. Они также несут ответственность друг перед другом за правильное применение практики: одному проще словчить, а под наблюдением партнера сделать это гораздо сложнее. Многие разработчики рассказывали нам, что программисты в парах пишут код быстрее и лучшего качества, чем работая по отдельности.
Существуют две основные XP-практики, которые мы относим к категории «интеграция». Первая – это десятиминутная сборка. Команда создает автоматизированную сборку для всей кодовой базы, которая длится 10 минут. Эта сборка включает в себя автоматический запуск всех модульных тестов и генерацию отчетов с положительными и отрицательными результатами.
«Десять минут» может звучать как произвольная величина, но с точки зрения команды она имеет смысл. Если сборка проекта занимает более 10 минут, то члены команды запускают ее гораздо реже. Но для команды очень важно использовать ее часто, потому что это быстро выявляет проблемы. Например, в сборке запускаются модульные тесты, поэтому после ее завершения команда знает, достигла ли она нужного качества.
Иными словами, она позволяет быстро получить ответ на вопрос «Работает ли еще наш код?». И благодаря тому, что сборка довольно короткая, команда будет запускать ее часто, а каждый член команды получит постоянно обновляемую картину качества кода.
Другая интеграционная практика – это непрерывная интеграция. Она реализуется благодаря набору инструментов, позволяющих нескольким членам команды одновременно работать с одной версией исходного кода. Если несколько членов вашей команды должны одновременно работать с одними и теми же файлами, то они не могут использовать одну физическую копию файла на всех. Иначе они бы постоянно затирали изменения друг друга. Поэтому команда будет применять специальную систему контроля версий, которая имеет централизованный (или децентрализованный) основной набор файлов. Отдельные разработчики будут выписывать из него, или копировать, нужные файлы, которые будут использоваться только этим программистом (что часто именуют помещением в так называемую песочницу). Разработчик будет трудиться над копией кода в своей «песочнице» и периодически отправлять изменения обратно в общее хранилище.
Проблема в том, что слишком часто разработчик, внося измененную версию программы, обнаруживает конфликт своего кода с изменениями, незадолго до этого внесенными другим программистом. В большинстве случаев этот конфликт выявляется сразу же при попытке выгрузить личную копию в общую базу кода, которая перестает компилироваться. Но временами проблемы оказываются более серьезными и скомпилированная программа ведет себя неправильно. Причина в том, что один код был заменен конфликтующим с ним кодом, взятым из другой «песочницы». Все эти проблемы проявятся, когда будет проведена интеграция системы из различных частей, написанных разными программистами.
И вот тут вступает в дело практика непрерывной интеграции: команда должна достаточно часто собирать код и отслеживать ошибки компиляции или сбои модульных тестов. Многие команды настроят сборочный сервер для периодической компиляции кода из хранилища, запуска полученной сборки и уведомления команды, если обнаружатся ошибки. Но создание сервера непрерывной сборки – это лишь одна часть непрерывной интеграции. Непрерывная интеграция означает, что каждый член команды постоянно содержит свою копию исходного кода в актуальном состоянии. Члены команды периодически интегрируют последнюю версию кода из хранилища обратно в свои «песочницы». Команды, применяющие парное программирование, порой пользуются физическим маркером сборки. Это может быть плюшевая или резиновая игрушка (забавная и заметная, чтобы сразу было видно, у кого она находится). Она переходит от пары к паре. Когда пара получает этот символ, наступает ее очередь интегрировать последнюю версию кода из хранилища к себе, исправить все найденные проблемы интеграции, а затем передать маркер сборки следующей паре. Это гарантирует, что проблемы интеграции будут обнаружены на ранних стадиях и исправлены.
Для управления своими проектами XP-команды используют итеративную разработку. Как и в Scrum, практики XP-планирования основаны на большом цикле долгосрочного планирования, который разбит на короткие итерации. В практике недельного цикла XP-команды используют итерации длиной в одну неделю совместно с практикой историй (это то же самое, что и пользовательские истории, о которых вы уже знаете). Каждый цикл начинается с совещания, посвященного планированию, где члены команды проводят обзор достигнутых результатов, работают с клиентами, чтобы выбрать истории для итерации, а затем разбивают их на задачи, которые оцениваются и передаются разработчикам.
Это вам уже знакомо, потому что это очень похоже на scrum-планирование. Действительно, многие XP-команды в точности перенимают практики scrum-планирования (которые считаются популярными гибридами Scrum и ХР, описанными в отчете VersionOne State of Agile, упоминавшемся в главе 2). Закончив планирование, команда посвящает первую часть итерации написанию автоматических тестов для историй и задач, а остальное время итерации пишет код, способный пройти эти тесты. Но вместо процесса самоорганизации некоторые XP-команды помещают все задачи на данную итерацию в очередь. Каждый разработчик берет следующую задачу из этой очереди после завершения текущей. Это гарантирует, что разработчики не выбирают свои любимые задачи и они распределяются равномерно между всеми.
Для долгосрочного планирования XP-команды используют практику квартального цикла. Раз в квартал команда собирается, чтобы проанализировать ход работ над проектом. На этих встречах XP-команды обсуждают темы, то есть те идеи из реального мира, которые они могут использовать, чтобы связать воедино истории своего проекта. Такие дискуссии помогают выяснить, какие истории необходимо добавить в проект, и поддерживают связь команды с реальными проблемами бизнеса, которые должно решить программное обеспечение. Также обсуждаются внутренние и внешние трудности, которые испытывает команда, повторяющиеся ошибки и еще не внесенные исправления. Оцениваются результаты, которых добилась команда, насколько хорошо удалось удовлетворить потребности клиентов и как в целом продвигается проект. Некоторые XP-команды склонны использовать ту же практику ретроспектив, что и scrum-команды.
И последняя из ХР-практик, посвященных планированию, – временной запас. Она позволяет команде добавлять мелкие, менее приоритетные истории в каждый недельный цикл. Во время планирования эти истории разбивают на задачи, но к ним не приступают до конца итерации. И тогда, если команда сталкивается с неожиданными проблемами, она исключает из итерации эти «запасные истории» и все-таки поставляет работающее ПО в конце цикла. Как и в других методах итеративной разработки, XP-команды поставляют в конце итерации только полностью законченный функционал. Это означает, что он работает, все тесты пройдены и его можно продемонстрировать пользователям.
XP затрагивает как программирование, так и совместную работу команд. Эта методика включает в себя две основные практики, помогающие командам сплотиться, – «командные практики». Первая – коаллокация, когда команда располагается в одном помещении. Люди в команде работают лучше, когда сидят рядом друг с другом и могут легко коммуницировать. Многие люди не осознают, что, хотя программирование – это индивидуальный труд и зачастую выполняется в одиночку (за исключением парного программирования), работа в команде разработчиков требует высокой социальной активности.
Члены команды постоянно консультируются друг с другом, советуются и предупреждают о возможных проблемах. Если команда располагается в помещении типа open space, такая социализация обеспечивается естественным образом. По поводу того, каким должно быть открытое рабочее пространство, ведется много споров. Чтобы работать эффективно, программисты должны быть защищены от отвлекающих факторов. Многие из них ценят уединенность и размещают свои мониторы так, чтобы проходящие мимо люди не могли видеть экран. Популярное решение этой проблемы – модель планировки офиса «пещеры и поляны», описанная Стюартом Брэндом в книге How Buildings Learn[49]. В его схеме имеются как отдельные, так и общие рабочие места для программистов, которые одной стороной выходят в общий зал со столами для проведения совещаний и компьютерами для работы парами.
Следующая основная практика XP-команд – это информативное рабочее пространство, в котором производственная среда команды устроена таким образом, чтобы важная информация о проекте автоматически передавалась всем участникам. Один из наиболее популярных способов для этого – применение большой доски задач и диаграммы выполняемых работ (диаграммы сгорания), которые висят так, чтобы каждый мог их видеть. Наглядное размещение постоянно обновляемой информации о проекте позволяет каждому члену команды знать, на какой стадии находится проект, и принимать правильные решения. Такие диаграммы и другие способы, которые команда использует для отображения данных, делающие рабочее пространство более информативным, называются излучателями информации. Они автоматически передают текущую информацию о проекте всем, кто на них взглянет.
Большие, наглядные диаграммы – не единственный способ сделать рабочее пространство информативным. Когда у членов команды появляются вопросы, они сталкиваются с проблемами или им необходимо обговорить какие-то детали, они организуют обсуждение. Если такие дискуссии происходят в общем рабочем пространстве, а не в закрытых конференц-залах, то окружающие невольно слышат их и впитывают информацию о происходящем. Когда члены команды автоматически вбирают информацию о проекте – неважно, из диаграмм, разговоров или иным способом, – это называется осмотической коммуникацией. Командам необходимо найти баланс между пользой такой коммуникации и ее отвлекающим влиянием, и XP-команды становятся успешными, если им удается его отыскать.
Почему важны информационные рабочие пространства? Суть в том, чтобы помочь команде принимать лучшие решения и дать ей больше контроля над ходом проекта – подобно тому, как доски задач помогают scrum-командам. Главное, что информация предназначается для всей команды, а не только для ее руководителей или менеджеров. Это демократизирует распространение информации и обеспечивает ею всю команду без какой-либо фильтрации. Чем больше сведений о проекте доступно команде, тем сильнее каждый ее участник может влиять на ход событий.
Никто не любит менять уже написанный код по требованию заказчика. Внесение изменений в конце проекта может вызывать различные эмоции – от раздражения до озлобления и даже до ощущения надвигающейся катастрофы, если в ближайшие полтора месяца предстоит работа без выходных только потому, что клиент не продумал все до конца.
Именно поэтому разработчики часто жалуются, что бизнес-пользователи постоянно меняют свои решения. Очень часто, когда проект уже начался, можно услышать такие разговоры: «Так вы хотите это изменить? Если бы я знал, то написал бы код совершенно иначе! Почему в начале проекта вы не объяснили нам, чего именно хотите?»
Рис. 6.2. Каждый руководитель проекта знаком с ощущением беспомощности из-за необходимости внесения изменений, которые разработчики не в состоянии выполнить. Каждому разработчику знакомо чувство тревоги, когда, казалось бы, небольшие изменения в коде разрастаются как снежный ком и требуют слишком много времени
И разве можно их за это винить? Команды сопротивляются этим изменениям, особенно в конце проекта[50], потому что им предстоит дополнительная работа. И не просто работа – а самый плохой ее вариант, самый раздражающий. Изменения заставляют вас возвращаться к тому, что вы считали законченным, разносят сделанное в пух и прах и вынуждают переписывать большие куски кода заново. И это не просто разочаровывающая работа: ваша команда вложила в нее много душевных сил, решила массу проблем и нашла наиболее элегантные решения. А теперь вам говорят, что нужно разрушить созданный командой Тадж-Махал, потому что на самом деле нужна была Эйфелева башня.
Но у медали есть и другая сторона. Пользователь или руководитель, просивший в начале проекта одно, а к концу изменивший свои требования, делает это вовсе не с целью дезорганизовать команду. Мы уже знаем, что раздробленное видение приводит к плохим результатам, так что давайте попробуем взглянуть на эту проблему со стороны пользователя. Ему нужно программное обеспечение, позволяющее выполнять свои задачи, а это означает, что он должен сотрудничать с командой разработчиков. Теперь его просят ответить на вопросы, которые ему не совсем понятны: «Кто должен иметь доступ к этой функции?»; «Сколько людей будут использовать эту систему одновременно?»; «Каково допустимое время между нажатием кнопки “начать” и отображением результатов?»; «Какова правильная последовательность действий?»
То, что начиналось как встреча, на которой пользователь пытался объяснить свою проблему, каким-то образом превратилось в бесконечный поток обращенных к нему технических вопросов, на которые он не знает ответов. А время-то идет, и он чувствует: если не дать ответы на все вопросы, то команда отложит выполнение проекта и обвинит в этом его. (Будем честны: именно так она, скорее всего, и поступит.) Все знают, что создание ПО – дорогое удовольствие, а пользователь – не специалист в этом, поэтому дает самый лучший ответ, на который способен. И когда встреча заканчивается, он не мешает команде двигаться вперед и сжигать бюджет.
Как решить эту проблему? Кто прав?
Гибкие методологии, и в частности XP, с готовностью признают следующее: невозможно заранее знать в точности, что мы собираемся создавать, а наиболее эффективный способ это описать – начать работу над проектом. В данных методологиях исчерпывающую документацию заменяет работающее ПО, поскольку самый эффективный способ получить от пользователей обратную связь – это написать часть программы и отдать им для практического применения.
Поэтому, вместо того чтобы настраивать команду против изменений, возможно, стоит создать условия, при которых она сможет справиться с этими изменениями без шумных распрей и работы в выходные? Никто не любит вносить изменения, но, возможно, вам удастся найти способ ограничить влияние на проект каждого из них, причем не только в том, что касается целостности кода, но и в отношении морального состояния команды и пользователей.
Именно так поступают команды XP и называют такой стиль адаптацией к изменениям. Команды XP признают, что изменения – это не только неизбежное зло. Лишь в случае частого получения обратной связи от пользователей и быстрого реагирования на нее они смогут создать действительно лучшее ПО для своих клиентов. Эти команды готовы к изменениям и даже планируют их. Они не воспринимаются как плохие новости, которые всегда сопровождаются поиском виноватого, прозевавшего часть требований. Правильное мышление для XP означает не только принятие изменений, но и желание иметь их.
Адаптация к изменениям имеет два аспекта: степень охвата проекта и собственно база кода. Влияние изменений на код иногда бывает значительным – изменение, которое первоначально казалось маленьким, может ошеломить команду, потребовав существенного переписывания. Команды будут говорить о необходимости «разодрать код» и заделать дырки «скотчем, скрепками и жевательной резинкой». Мы рассмотрим тему адаптации к изменениям в главе 7. А пока обсудим, как XP-команды приспосабливаются к изменениям масштабов проекта, функциональности программного обеспечения и его поведения.
Так как же основные практики XP помогают командам делать это?
Планирование
Когда команды итерационно планируют и поставляют работающее программное обеспечение в конце каждой итерации, они постоянно получают обратную связь. Все в команде знают, что они активно просят об обратной связи. Ведь намного проще справиться с изменениями, если вы тот, кто попросил об этом в первую очередь.
Команда
Решать проблемы гораздо проще, если поблизости есть люди, готовые помочь. Когда команды располагаются рядом, они выявляют проблемы намного раньше. А информационное пространство помогает сделать так, чтобы все работали над одной и той же проблемой. Это позволяет всем членам группы взять под контроль происходящие изменения и не быть застигнутыми врасплох возможными неожиданностями. Отдельные члены команды получают автономность, которая нужна им для принятия решений, влияющих на их код и даже жизнь.
Интеграция
Одна из самых неприятных проблем, вызванных неожиданными изменениями, – это то, что они распространяются по всей базе кода. Если вы работаете с постоянными изменениями, то вам важно узнать о них как можно раньше – вот почему командные практики действительно полезны. Но человек все равно будет застигнут врасплох, если изменение, внесенное в базу кода его коллегой, вызовет неожиданную ошибку в той части кода, над которой работает он сам. Благодаря непрерывной интеграции (которую осуществлять легче, потому что наша сборка работает быстро) мы узнаем об этой проблеме очень быстро и исправим ее раньше – до того, как она станет нашей головной болью.
Программирование
Как непрерывная интеграция помогает выявлять изменения? Мы создали набор модульных тестов, которые запускаем каждый раз при выполнении интеграции кода. Поэтому, когда один из членов команды добавляет изменения, он запускает все тесты, в том числе и для той части кода, над которой работают все остальные ее участники. Если один из этих тестов терпит неудачу, то мы сможем работать вместе – и даже парами, – чтобы решить эту проблему в обеих конфликтующих частях кода.
Читать бесплатно другие книги:
