новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts

Развиваемкроссфункциональностьвкоманде

Сегодня прочитал статью Николая Алименкова о кроссфункциональности, и пока летел в самолете в Киев решил продолжить эту тему. С определением и глупыми трактовками данного понятия Коля разобрался в своей статье, поэтому об этом читаем там, а я, в дополнение, хочу поделиться конкретным инструментом, которым вы можете воспользоваться для того, чтобы начать конструктивно обсуждать кроссфункциональность у вас в команде.
Итак, представляю вашему вниманию “Звездную карту” (см.рисунок).Звездная карта

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

Приступаем к созданию звездной карты

Шаг 1
Сделайте видимым для всех бэклог продукта (проектор, монитор или бумага) и начинайте брейнсторм с вводным вопросом: “Какие компетенции, умения, навыки необходимы для того, чтобы самостоятельно и без привлечения сторонних лиц сделать все элементы нашего бэклога”.
Если взять для примера веб-разработку, список может выглядеть так:

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

Шаг 3
Попросите всех членов команды оценить свои собственные знания, умения и навыки по каждому из параметров, пользуясь двумя простыми обозначениями:

У вас получилась звездная карта!

Анализируем звездную карту

Теперь, когда мы знаем свои звезды в лицо, можно приступить к анализу карты. На что обращать внимание в первую очередь и какие вопросы стоит обсуждать?

1. Мы ищем колонки с одинокими звездочками. Это то, что мы называем фактор автобуса (трамвая) – сколько человек в вашей компании может сбить автобус/ переехать трамвай, чтобы ваш проект/компания по прежнему осталась на плаву. Очень часто фактор автобуса равен единице. Зная об этом, и будучи менеджером этой команды, мне бы очень плохо спалось.

2. Мы ищем колонки, где есть только точки. Эти колонки интересны нам по одной простой причине. Шансы облажаться и произвести говнокод продукт плохого качества очень высоки. Поэтому если у нас в колонке “база данных” одни точки, стоит задуматься и обсудить всей командой, что мы можем сделать, чтобы предотвратить нежелательное развитие ситуации, например, подумать о внешнем контроле вашего кода специалистом.

3. Мы ищем пустые колонки. Они замечательны тем, что знания по данной области просто отсутствуют. А это, в свою очередь, означает зависимости. Зависимости вашей команды от внешних людей. Я уже слышу фразы: “Ну, мы то всё своё уже сделали, мы этих … (вставьте что-нибудь подходящее) ждем. Это в случае, если команда забыла об ответственности. Альтернативно, просто жалко видеть неплохую команду, которая попала в подобную засаду и не может сдвинуться с места.

4. В каждой колонке мы, в идеале, хотим видеть как минимум одну звездочку и одну точку. Это означает, что у нас есть человек, который хочет учиться, и есть человек, который может учить. Отлично! Это кандидаты на парное программирование или на просто поработать вместе. Звездочки и точки в одинаковых колонках могут поговорить о планах дальнейшего развития точки по данному направлению. Подобные разговоры, на базе звездной карты, также можно вести с HR.

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

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

Я знаю, некоторые начнут кричать: “Какого черта, клиент должен платить за то, что кто-то будет прокачивать свой уровень. Да и работать пара – точка-звездочка будет медленнее”. Кричите об этом в комментах :). Кроме того, это единственный работающий способ развивать своих работников и передавать знания внутри компании. Если у вас есть другие работающие предложения, тоже пишем в комменты.

Применение звездных карт

Звездная карта может использоваться:

Вопрос в качестве домашнего задания: “Когда команда оценивает, чью оценку мы возьмем для бэклога? Звездочки или точки?”

Сергей Дмитриев Cовладелец Unusual Concepts

Плюсануть
Поделиться
Отправить
Класснуть
Линкануть
Вотсапнуть
Запинить
Ещё по теме
Студент Unusual Concepts делится ценными советами по сдаче экзамена PSM и PSPO 1. Цена попытки — 200$, но лучше сходить на тренинг Unusual Concepts. Рекомендую! Выйдет в четыре раза дороже, но оно того стоит. 2. Внимательно и вдумчиво изучить scrum guide на английском (!) языке. Что угодно делайте, чтобы понять и запомнить всё, что там написано. Мне лично помогло рисовать mind maps. Кому-то помогает внимательно прочесть 3 раза. 3. Пройти open assessments на сайте scrum.org (open, product owner, developer). Nexus не надо. Здесь задача в том, чтобы понять логику того, кто эти тесты делал (эта же самая логика используется и в сертификационном экзамене). Проходить советую вдумчиво, читая то, что написано. Не советую тупо запоминать вопросы и ответы на них, т.к. хотя в экзамене и есть copy-paste из open assessment, их, во-первых, всего лишь около половины, а во-вторых, это вам только помешает понять суть. Из этих же соображений советую тренироваться по одной попытке на каждый open assessment и потом перерыв. Потом опять по одной на каждый и опять перерыв. Идеально, если чередовать с изучением scrum guide. Обязательно читаем результаты теста! Там годные комментарии к ответам. Добивайтесь устойчивого 100% результата. 4. Если у вас с английским языком проблемы — то советую подтянуть. Лучший способ, на мой взгляд, делать всё, что я тут описал, но со словарём. Добиваемся, чтобы весь scrum guide и все open assessments были понятны без словаря. Во время экзамена словарь держите под рукой — попадаются непонятные слова, но целиком полагаться на него не стоит (один товарищ пытался загонять все вопросы в он-лайн переводчик, и в результате получил 53% правильных ответов). 5. Сертификационный экзамен сдаётся на сайте scrum.org, где другой интерфейс, чем у тестовых экзаменов. Это может добавить мандража, если станет неожиданностью. Но существенных отличий там нет. Разве только можно закладки ставить. 6. Перед сдачей самого экзамена убеждаемся, что у нас есть час времени, когда точно никто не будет отвлекать и интернет точно не отвалится. Я перестраховывался 3g модемом, но, слава Богу, не пришлось. 7. Во время экзамена ни в коем случае не надо париться над сложными вопросами! Если вопрос сложный, то выбирайте то, что вам кажется верным, ставьте на вопрос закладку (bookmark) и идите дальше. Большинство вопросов (около 60 из 80), при условии что всё вышеописанное вами сделано добросовестно, вы отобъёте за 30 минут. Оставшиеся 30 минут можно потратить, чтобы внимательно и вдумчиво разобрать все закладки. У меня даже получалось в интернете поискать варианты в это время. 8. Не надо ставить закладку на все вопросы, в которых у вас есть сомнения. Ставьте закладку только там, где вы вообще не уверены. Иначе получится неприятная картинка, когда сначала вы закладки ставили на средне-сложные вопросы, а потом стали ставить только на очень сложные, и в результате под конец теста у вас не 20 закладок, а 40, и времени в обрез. 9. Помните — это экзамен. Не надо быть самоуверенным, а то завалить его проще простого. Но и мандражить сильно не надо. Просто тщательно подготовьтесь, и всё будет хорошо. Оригинал поста в Фейсбуке
Андрей Толмачев рассказывает, как разрешить взаимное недовольство Владельца Продукта и Команды Разработки.

Условия задачи

Представьте такую ситуацию. Вы — новый Скрам-мастер. Ваша Команда Разработки состоит из системного аналитика, двух разработчиков и двух специалистов по тестированию. Длина Спринта — две недели. Команда работает со сложной системой на старой платформе, поэтому для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты. В течение последнего Спринта Команда не успела сделать работу, взятую в Спринт, поэтому на Ретро Владелец Продукта допытывается, кто чем занимался в течение Спринта. Владелец Продукта жалуется, что Команда работает очень медленно. Члены Команды жалуются, что бизнес контролирует и микроменеджит их. Как разрешить взаимное недовольство Владельца Продукта и Команды Разработки? Давайте разбираться.

Что происходит

Для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты — это означает, что элемент будет готов к выпуску только через три Спринта. В таком случае истинная длина Спринта равна шести неделям — это больше, чем допускает Руководство по Скраму.
Максимальная продолжительность Спринта — один календарный месяц. При большем сроке планирования возможны изменения целей, увеличение сложности и рост рисков.
Руководство по Скраму Когда Команда редко поставляет готовый Инкремент, то редко получает обратную связь от стейкхолдеров и клиентов. В результате:
  • возрастает риск сделать не то, что надо. Способность реагировать на изменения падает;
  • стабильность процесса падает, прогнозировать работу сложно. Например, тестирование выявляет дефекты через недели после разработки. Баги обнаруживаются поздно, поэтому объём «поддержки» будет меняться от Спринта к Спринту;
  • рабочий процесс перестаёт быть прозрачным.
По этим причинам Команда Разработки теряет доверие Владельца Продукта и стейкхолдеров, следовательно, давление возрастает и начинаются конфликты.

Решение

Скрам-мастер не может решить проблему самостоятельно, но может помочь своей Команде следующим образом:
  • объяснить описанную выше системную динамику и её вредные последствия. Скрам-команда должна понимать, что правило Скрама про Done Increment каждый Спринт — это естественное системное решение их проблемы;
  • помочь сформулировать или пересмотреть минимальный DoD, который может быть выполнен в течение Спринта и который обеспечит готовность Инкремента к релизу;
  • научить Команду Разработки правильно декомпозировать элементы Бэклога. Небольшие элементы в Бэклоге Продукта способствуют ранней поставке, оптимизации ценности Продукта и улучшению потока работы;
  • помочь договориться взять в следующий Спринт хотя бы один небольшой элемент Бэклога, но довести его до состояния Done;
  • визуализировать поток работы. Прозрачность — залог успеха;
  • устранить простои в работе. Для этого Скрам-мастер обучает Команду хорошим инженерным практикам, например, общему владению кодом, стимулирует развитие T-shaped или E-shaped людей в Команде, заключает командные соглашения;
  • объяснить Владельцу Продукта, что причина задержек — технический долг и убедить его выплатить.
Используйте Ретроспективу, чтобы найти лучшие решения по устранению препятствий. Помните, что эти решения — эксперименты, не факт, что они принесут ожидаемый эффект. Поэтому инспектируйте результаты прошлых решений и адаптируйте решения на следующих Ретроспективах.

Итоги

Готовый Инкремент в конце Спринта — это важнейшие правило Скрама, которое помогает избежать роста рисков, потери предсказуемости и гибкости. Описанные причинно-следственные связи полезно знать, чтобы понимать, почему Скрам требует соответствующий DoD, готовый к релизу Инкремент каждый Спринт. Следующие действия могут помочь в достижении этой цели:
  • декомпозиция работы на небольшие PBI;
  • визуализация потока работы в Спринте и поиск основных узких мест;
  • устранение «простоев» работы с помощью командных соглашений, хороших инженерных практик и развития T-shaped или Е-shaped людей;
  • планомерная ликвидация технического долга.
Комментарии
Сергей Дмитриев, 23 мая 2012

Тоже отличное применение, спасибо, Михаил!

Михаил, 10 мая 2012

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

Сергей Дмитриев, 11 ноября 2011

Да, все так, согласен с вами, Дмитрий. Платить в любом случае будет заказчик. И, надеюсь, мы все работаем на долгострочную перспективу :).

Сергей Дмитриев, 11 ноября 2011

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

Дмитрий Миронов, 11 ноября 2011

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

Дмитрий Миронов, 11 ноября 2011

При применении данной техники надо понимать, что скорость выполнения работы снизится не порядок, если не больше:
- "точка" не может выполнять работу с такой же скоростью и качеством как "звезда"
- "точка" должна отрываться от работ "звезды" в своей паре, на выполнение работы "звезды" (коучинг) в другой паре, где она является "звездой" и коучит другую "точку".
Таким образом, если все одновременно "точки" и "звезды" работы будет двигаться ОЧЕНЬ медленно.
Либо надо ограничивать одновременное количество пар "точка"-"звезда".

Сергей Дмитриев, 08 ноября 2011

Андрей, если руки чешутся, зуд надо утолить ;)

Андрей Ребров, 08 ноября 2011

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

Рубрика «Полезное чтиво». Выпуск 9 « XP Injection, 07 ноября 2011

[...] Развиваем кроссфункциональность в команде – инструмент для анализа и развития кроссфункциональности в команде [...]

Сергей Дмитриев, 07 ноября 2011

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

Stepan, 07 ноября 2011

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

Сергей Дмитриев, 02 ноября 2011

Спасибо за отзыв, Сергей. Хорошие команды обычно от 5 до 10 человек, при таком размере, составить звездную карту не сложно.

Sergey N., 02 ноября 2011

Очень интересный подход, спасибо.
Насколько, по вашему, зависит эффективность данного подхода от количества людей в команде? :-)