Переосмысление 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 – это всего лишь переименование статус-митингов в ежедневные scrum-митинги, а требований – в бэклог. Это опасно для внедрения Agile, потому что фундаментальные проблемы, которые вы пытаетесь решить за счет Scrum, никуда не денутся. Большинство людей будет считать, что Scrum не может их исправить и даже что эти проблемы существуют везде и не имеют решения. Вспомните, сколько раз вы слышали фразы «Разработчики не могут заранее оценить объем работ», «Программное обеспечение постоянно глючит» или «Проекты никогда не выполняются в срок», произнесенные таким тоном, словно это законы бытия.
Хуже всего то, что, утверждая, будто Scrum может решить те проблемы, которые многим кажутся неразрешимыми в принципе, вы производите впечатление фанатика. Отсутствие явных результатов будет отталкивать людей от Scrum. Это повредит вашей карьере и настроит коллег против Scrum.
Существует еще один способ!
Дайте команде не только новые методы, которые они внедрят сегодня, но и видение того, чего они смогут достичь завтра. Тогда люди охотнее поверят в то, что делают Scrum, потому что уже освоят несколько простых методов.
Что делать, если вы реализовали практики Scrum, но еще не приступили к работе по самоорганизации и коллективной ответственности и понимаете это? Вместо того чтобы утверждать, что практики Scrum полностью внедрены, мы можем честно признать: впереди еще длинный путь по освоению ценностей Scrum, самоорганизации и превращению в команду, по-настоящему стремящуюся к результативности.
Первое отличие такого подхода заключается в том, что вы не давали обещаний, которых не сможете сдержать, а просто заявили людям, что сделали бы некоторые вещи немного лучше. Поэтому когда они видят улучшение результатов, то вместо недовольства тем, что не все проблемы устранены, испытывают удовлетворение от того, что команда производит программное обеспечение быстрее и лучшего качества. Гораздо легче начать разговор о новой ценности для компании, если у вас есть улучшения, пусть и небольшие. И ваш руководитель, вместо того чтобы слышать критику в свой адрес за недостаточное внедрение Scrum, получит от вас хорошие результаты сегодня и радужные перспективы на завтра – если только он разрешит команде реализовать свои устремления.
Совместима ли культура вашей компании с ценностями scrum?
Не каждая компания готова отказаться от командно-административного управления проектами и сделать ставку на самоорганизацию, и не все команды способны принимать коллективные обязательства. Чтобы выяснить, готовы ли к ним ваши команда и компания, необходимо оценить, совместима ли культура компании с ценностями Scrum. Но как эти ценности Scrum внести в практику реальной жизни?
Постарайтесь честно ответить на следующие вопросы. Обсудите это с вашей командой и менеджером. Если все в порядке, то ваши компания и команда готовы к ценностям Scrum. А если нет, то такие обсуждения помогут понять, как правильно внедрить Scrum в вашу команду.
Чтобы понять, готовы ли вы к обязательствам и ответственности, спросите команду и руководителя, согласны ли они:
• отказываться от контроля над проектом и доверить команде самой принимать решения;
• не заниматься самодеятельностью и не создавать изолированных элементов в надежде на то, что удастся интегрировать их в конце проекта;
• следить, чтобы в команде не появился «мальчик для битья», на которого валятся все шишки;
• прислушиваться к мнению коллег, а не навязывать свое представление о том, как надо работать;
• действительно брать на себя ответственность. Все ли в команде готовы к этому.
Чтобы понять, готовы ли вы к уважению, спросите команду (себя в том числе) и руководителя, согласны ли они:
• доверять команде работать самостоятельно и устанавливать сроки сдачи функций исходя из их относительной ценности и того, как развивается проект, даже если он займет больше времени, чем вы ожидали;
• давать команде достаточно времени на выполнение задач и не требовать от нее сверхурочных работ;
• доверять команде выбирать задачи, которые ей подходят и нужны для проекта, а не полагаться на строгое распределение ролей, матрицы 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). Такое планирование изобрел Джеймс Греннинг, соавтор 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 – это не «серебряная пуля» и не решит всех или хотя бы большинства проблем больших территориально разнесенных команд. Самая большая трудность для такой команды заключается в поддержании каждого члена команды мотивированным общей целью. Как нам уже известно из , это главным образом достигается тем, что члены команды становятся «свиньями», а не «курами». Хотя безусловно можно сделать это независимо от удаленности членов команды друг от друга, гораздо более сложно для владельца продукта сделать так, чтобы у всех существовало единое видение задач. Потому что он должен передать его другим через разные часовые пояса при помощи телеконференций и электронной почты, а это гораздо труднее, чем при личном общении.
Я понимаю, что ежедневные scrum-митинги обеспечивают работу людей над правильными задачами. Но даже добросовестные разработчики способны увязнуть во второстепенных делах. Может ли нечто подобное произойти со scrum-командами?
Да, может. Основатель Scrum Джефф Сазерленд совсем недавно опубликовал вместе со Скоттом Дауни документ под названием «Метрики для сверхпроизводительных 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 проходило эффективнее.
Назад: Акт VI. Круг почета
Дальше: Глава 6. XP и охватывающие изменения
