Инкрементальный дизайн и архитектура

Перевод оригинальной статьи Рона Джеффриза «Incremental Development»

Суть подхода Big Design (детальное проектирование до начала разработки, англ. Big Design Up Front, BUFD) заключается в том, что у нас есть тщательно отобранный набор идеальных требований, и при помощи нескольких достаточно формализованных практик мы создаем красивую архитектуру для воплощения этих требований. Этот дизайн подобно солнцу освещает мир программирования, позволяя программистам без каких-либо глубоких раздумий идеально воплощать идеальную архитектуру для выполнения этих идеальных требований.

Даже если бы это было правдой (спойлер: это не правда), в большинстве случаев Big Design не смог бы удовлетворить наши потребности. Я бы сказал, он никогда не удовлетворяет наши потребности, и уж точно не в случае, который волнует меня больше всего —

В случае работающего продукта

За свою полувековую карьеру в разработке ПО я узнал многое — и самостоятельно, и работая с командами. Если бы я мог вернуться в прошлое и вынести только одну мысль, она была бы такой:

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

Читать далее «Инкрементальный дизайн и архитектура»

Не давайте ответ, не услышав вопрос

Перевод оригинальной статьи Ceзарио Рамоса Do not provide the answer before knowing the question

Я общался с компанией, которая внедряла модель Spotify и попросила меня помочь. Они хотели понять, в чем разница между моделью Spotify и LeSS. Сначала мы обсудили, что такое LeSS. Я объяснил, что LeSS — это организационный дизайн, оптимизационные цели которого скорость, адаптивность и обучение. LeSS для организации то же самое, что Скрам для одной команды.

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

HR

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

Непрерывное улучшение

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

Но ещё хуже то, что копирование модели не даёт ощущения, что эта модель — ваша. Почувствовать, что у вас есть собственная модель, получается только тогда, когда вы создаете что-то самостоятельно. И если члены вашей команды чувствуют, что обладают чем-то, то выше вероятность, что они сами будут стремиться это улучшать. А это главное условие непрерывного совершенствования. Сложно почувствовать это, просто копируя чужие действия. Это скорее, как взять в долг — совсем не то же самое, как создать самостоятельно. Я отношусь к машинам из проката совсем не так, как к своим собственным.

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

Компания понимает этот момент, они очень серьёзно относятся к непрерывному улучшению.

Становление модели

Получается, что внедрять модель в качестве конечного решения без учета особенностей конкретной организации — это как отвечать, не узнав вопрос. На мой взгляд, это глупо. Не делайте так. Вместо этого вы можете начать с самого простого процесса, который будет работать. А потом вы выстроите свою модель с помощью Эмпирического Контроля Процессов и фреймворка, который поможет всем чётко увидеть, что надо улучшать. Этот фреймворк называется Скрам. Как мы любим говорить, лучше создать свой метод, чем пытаться подогнать под себя чужой. Вы добавляете что-то только тогда, когда ваша команда видит в этом необходимость.

Насколько я понял, в этой компании они делают именно так. И весьма успешно.

Cезарио Рамос

Сезарио занимается широкомасштабными Аджайл-трансформациями по всему миру. Автор книг «Emergent» и «Scrum Patterns». Он также является сертифицированным тренером LeSS, профессиональным тренером по Скраму (Professional Scrum Trainer™) и сертифицированным коучем.

Создаем прозрачность и ответственность в команде

О чем эта статья

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

Когда команды избегают продуктивного конфликта

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

Команды ТОП-менеджеров тоже не являются исключением. Они часто дополнительно обременены политическими конфликтами, подковерными играми и борьбой за организационные “колодцы”. Читать далее «Создаем прозрачность и ответственность в команде»

Три самых эффективных способа, позволяющих руководителям заслужить доверие

Одна из наших любимых тем — доверие. Мы уделяем ей значительное время в рамках Аджайл-консалтинга, работая с командами и организациями. В продолжении развития это темы сегодня публикуем перевод статьи  «The 3 most effective ways to build trust as a leader».

Читать далее «Три самых эффективных способа, позволяющих руководителям заслужить доверие»

Как заставить говорить ваш Cumulative Flow Diagram?

Участвуя как спикер на разных конференциях я наибольшее удовольствие получаю не от выступлений на сцене с докладом и слайдами, а от живого общения на различных мастер-классах и воркшопах. Камерная атмосфера дает возможность апробировать интересные инструменты и извлечь уникальные инсайды. Не обошлось без этого и на Agile Days 2019, где я выступал с мастер-классом про накопительные диаграммы потока (CFD). Ниже тезисы моего воркшопа. Читать далее «Как заставить говорить ваш Cumulative Flow Diagram?»

Не надо аплодисментов (Кен Швабер)

Не надо аплодисментов

Кен Швабер

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

Что в этой ситуации не так?

Во-первых, Обзор Спринта — это не презентация. Это не время продавать Скрам. И тем более не время высшему руководству демонстрировать свою поддержку. Все это, конечно, нужные активности, но сейчас они отвлекают от истинной цели Обзора Спринта. Обзор Спринта предназначен для того, чтобы Владелец Продукта проверил и адаптировал Продукт для увеличения возврата инвестиций. С этой целью Владелец Продукта проверяет и корректирует созданный Инкремент. Затем он консультируется с командой и другими стейкхолдерами и реорганизует Бэклог Продукта для следующего Спринта. Цель Обзора Спринта — организовать взаимодействие между Владельцем Продукта, людьми, которых он представляет, и командой. Тут должны иметь место сотрудничество, обмен важной информацией и мозговой штурм, чтобы решения были максимально обоснованы. Читать далее «Не надо аплодисментов (Кен Швабер)»

8 причин хронического незавершения работы в Спринте

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

Системы, паттерны и структуры.

Команда Разработки является системой с общей целью и взаимозависимыми между собой элементами (разработчики). Если события в системе повторяются, то они становятся паттерном. За каждым паттерном скрывается подкрепляющая структура. В данном случае паттерн системы — хроническое незавершение задач в Спринте.

Поиск структуры.

Задача Скрам-мастера — в партнерстве с командой найти структуру, которая вызывает паттерн и изменить ее. Для этого Скрам-мастер может предложить команде использовать на Ретроспективе инструменты системного мышления:

  • Пять почему
  • Fishbone
  • Causal-Loop Diagrams(CLD)
  • Дерево реальности
  • Метод А3

Фундаментальные причины, к которым приходят команды, могут сильно различаться. Приведу те, с которыми встречался в своей практике.
Читать далее «8 причин хронического незавершения работы в Спринте»

Скрам-мастер: спокойный, бескорыстный и отзывчивый

Недавно Далай Лама опубликовал статью “Почему лидеры должны быть внимательными, бескорыстными и отзывчивыми” в Harvard Business Review. Мне кажется, что эта модель отлично ложится на Скрам-мастера. Предлагаю вам небольшие выдержки. Оцените сами.

Быть спокойным и осознанным

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

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

Обзор Спринта и Ретроспектива (кейс МТС Касса 10-я часть)

Обзоры Спринта

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

  • Владелец Продукта открыл встречу и громко зачитал Цели Спринта, над которыми работала продуктовая группа. Затем Владелец Продукта перечислил элементы, которые уже были выполнены.
  • Команды по очереди кратко рассказали о сложностях, с которыми им пришлось столкнуться во время Спринта, и о том, как им удалось (или не удалось) их преодолеть.
  • Гостей пригласили посетить станции. Событие было организовано в формате «базара» или ее более структурированном варианте «выставка». На каждой станции у нас было по меньшей мере два разработчика. Один из них демонстрировал Инкремент и просил дать отзывы о нем, а другой просто все записывал.
  • После демонстрации мы вернулись к формату открытого обсуждения. Владелец Продукта рассказал о новостях рынка, изменил приоритеты элементов Бэклога Продукта и ответил на все вопросы.
  • Затем гости покинули помещение, а команды и Владелец Продукта собрали обратную связь по всем станциям и, когда это требовалось, обновили некоторые из артефактов — карту влияния (impact map), канвас ценностного предложения (value-proposition canvas), карту историй (story mapping) и, конечно, Бэклог Продукта.

Читать далее «Обзор Спринта и Ретроспектива (кейс МТС Касса 10-я часть)»

Почему фокус на Velocity убивает Agility

В этой статье я расскажу об опасной динамике, которая возникает в случае, когда Владелец Продукта, Скрам-мастер и/или менеджмент организации фокусируют Команду Разработки на Velocity.

О чем говорит Velocity.

Концепция Velocity означает:

Скорость, с которой Команда Разработки конвертирует элементы Бэклога Продукта в ГОТОВЫЙ К РЕЛИЗУ инкремент продукта.

Обратите особое внимание на выделенные слова. Velocity применима тогда, когда Команда Разработки может доставлять каждый Спринт готовый к релизу инкремент. В этом случае Done = DoD = releasable.

Но даже в этом случае Velocity не показывает:

  • Была ли решена проблема клиента.
  • Занимаемся ли мы самыми приоритетными проблемами клиента.
  • Объем поставленной ценности.
  • Степень удовлетворенности клиента.

Velocity лишь показывает, что команда была чем-то занята.

Является ли это достоверной оценкой успешности ваших продуктов и сервисов? Оценивают ли клиенты ваши продукта по тому, насколько были заняты сотрудники компании?

Если хотите, Velocity отражает объем “выработки” Команды Разработки. К сожалению, этого недостаточно для создания успешных продуктов и сервисов. Читать далее «Почему фокус на Velocity убивает Agility»