Александр, судя по этой статье и вашим ответам в комментариях, вы упорно пытаетесь изобрести велосипед, а точнее даже собрать нечто велосипедообразное из фрагментов конструкций, подсмотренных у других «изобретателей».
То, что вы пытаетесь сформулировать и преподнести как результат собственного исследования (по крайней мере, мне так показалось), давно известно и широко используется в кругах практиков тех самых «гибких методологий», которые вы упоминаете в качестве одного из второстепенных факторов успешности современных проектов.
В частности, стратегическое и тактическое проектное планирование, фокусирующееся на эффекте (читай: решении проблем и реализации возможностей), в последние годы находит всё большее распространение в ИТ сфере под эгидой техники «Карт влияния» (Impact mapping). Техника заключается в построении ментальных карт (mind maps), отражающих взаимосвязи между целями организации, вовлечёнными (прямо и косвенно) в достижение этих целей людьми, необходимыми изменениями в их поведении и конкретными программно-аппаратно-административными-… мерами/инструментами, необходимыми для воплощения этих изменений в жизнь.
К сожалению, время сейчас не позволяет, но, если интересно, я могу проработать с помощью этой техники пример с «хранилищем медицинских данных о состоянии здоровья населения». Разница с вашей табличкой будет колоссальная. Хотя даже моя «Карта» всё ещё будет сферическим конём в вакууме, потому что строить её будет всего один человек, который при этом ещё и слабо знаком с вопросом. Мне придётся делать огромное количество предположений относительно каждого из уровней, точно так же, как один ЛПР вынужден делать предположения, как минимум, относительно того, какие реальные изменения в поведении необходимы и какими инструментами они могут быть обеспечены. Все эти знания не могут находиться в голове одного человека (если, конечно, он не гений, которыми человечество, увы, не особенно располагает) и даже при их наличии всё равно остаётся высокая мера неопределённости, связанная с изменчивостью предметной области и мира в целом.
Именно поэтому «Карты влияния» — коллективная техника, направленная на вовлечение и со-трудничество как можно большего числа релевантных людей, чьи знания, опыт и интуиция могут существенно снизить число неверных предположений и помочь подобрать оптимальные инструменты для достижения цели. И именно поэтому такие проекты реализуются итеративно с постоянной проверкой остающихся предположений и постоянным пересмотром планов на основе этих проверок-экспериментов.
Если вдруг будете в апреле в Минске, приходите на Analyst Days, я буду рассказывать там на примере конкретного открытого проекта о применении этой техники в рамках комплексного подхода. А после можем пообщаться.
Тогда это действительно не Скрам, хотя вы явно нигде и не писали, что Разработка работает по нему. Скрам приносит максимум пользы там, где есть высокий уровень неопределённости – большая зависимость от реакции пользователей, жёсткая конкуренция, сложная динамичная предметная область или технологические зависимости. Каждая поставленная фича в этом случае позволяет получать новые важные знания о том, как развивать продукт дальше, в том числе саму эту фичу. Если фича задерживается (а при описанной модели это практически неизбежно), знания приходят позже и продукт, соответственно, развивается хуже.
Не знаю, насколько сильно у вас это выражено, но мне кажется, что вы не до конца используете основное преимущество итеративной разработки. И, возможно, формирование традиционных скрам-команд – одно из важных грядущих кнопочных улучшений +)
Поблагодарю Вас, Дмитрий, за благодарность за Василия, за статью и за ответ +)
В разработке такого разделения нет — все работают над одним проектом, но на разных этапах. UX-ребята делают прототипы и дизайн, бекенд-разработчики делают кишки, фронтенд — морду, тестировщики контролируют качество. Практически любая фича проходит через этот процесс последовательно от старта разработки до релиза. То есть все ребята сейчас работают в командах не по-принципу «одни пилят одну фичу, другие — вторую», а по принципу «одни пилят фичу на одном этапе, другие подхватывают на следующем».
Если честно, мне сложно представить итеративную разработку, строящуюся по такому принципу. Получается, внимание участников команд в единый момент времени распределено на разных фичах, иначе, завершив свой этап, они бы простаивали. Это чревато тем, что за короткую итерацию конкретная фича не успеет достигнуть всех критериев готовности и итерация будет провалена, поскольку управляющий продуктом не сможет заняться полноценной проверкой тех предположений, которую в эту фичу были заложены. Именно поэтому в Скраме команда разработки рассматривается как единое целое, и каждый её участник задействован в реализации фичи на протяжении всего спринта, а не на каком-то конкретном этапе.
Не могли бы вы так же подробно, как и обо всём остальном, рассказать о процессах в Разработке: как проходят планирования, ежедневные встречи, обзоры и ретроспективы у обозначенных команд? Есть ли там всё-таки Скрам или его нет, потому что не нужен?
Василий, спасибо Вам и всей Кнопочной команде за эту прекрасную статью. Очень вдохновляет!
Единственный вопрос: почему в холархии полного внедрения круг «Разработка» включает подкруги по специализациям, а не по командам, как в «Сервисе»? Ведь, если вы работаете по Скраму, то дизайнеры, разработчики и тестировщики неизбежно объединяются в кроссфункциональные команды. И получается такая же ошибка, как и в первом варианте сервисной холархии.
Я всё-таки надеюсь, что это полное внедрение рано или поздно произойдёт, и у нас появится возможность прочесть об этом такой же замечательный материал. Успехов! +)
В том то и дело, что, ввиду перечисленных обстоятельств, есть немалая вероятность того, что в ближайшие годы нынешнее третье издание будет оставаться одной из самых авторитетных и рекомендуемых книг по бизнес-анализу. А это чревато распространением всяких «резервов проекта» в довольно широких масштабах, чего лично мне очень не хотелось бы.
Поэтому если даже издательство посчитает невыгодным внесение правок в доптираж, то можно хотя бы попросить добавить ссылку на документ с известными ошибками в ту же аннотацию. То же самое можно попросить сделать онлайн магазины – добавить ссылку в описание товара. Ну, и продвинуть эту же ссылку через всевозможные тематические ресурсы. Думаю, комплекс подобных мер может дать некоторый ощутимый эффект.
Я бы с большим удовольствием и не меньшим пристрастием вычитал двадцатую главу +) Только уже осенью.
Специально уточнил этот вопрос у организаторов сообщества. Переводы на сто процентов легитимны, поскольку делались с личного согласия авторов на безвозмездной основе. «Те, кто просят деньги, сразу пишут об этом на своих сайтах». Авторами переведённых книг являются граждане Швеции, ведущие активисты гибкой разработки Хенрик Книберг и Маттиас Скарин.
Даже если с переводами Вигерса могут возникнуть какие-то юридические проволочки, всегда остаётся возможность выслать издательству список найденных ошибок и параллельно постараться его максимально распространить в Сети. Пусть их учтут в следующем издании, а те, кто приобретёт нынешнее, будет проинформирован.
Это не самый удачный перевод в первую очередь из-за того, что бэклог некорректно называть журналом. Термин «журнал» в техническом и околотехническом мире обладает устойчивой психологической инерцией — «документ с записями о событиях в хронологическом порядке». Бэклог же представляет собой приоритезированный список элементов не привязанный к какой-либо хронологии.
На мой взгляд, самый простой вариант термина это «список [название элементов]»: «список нереализованных компонентов продукта», «список компонентов для реализации в спринте». Или сокращённо: «список компонентов продукта», «список компонентов спринта». Если команда использует истории, то соответственно: «список историй продукта», «список историй спринта».
Что касается политики издательства в отношении переводов и редактуры, это ещё один веский довод взяться за такую работу силами сообщества. К примеру, у Agile Ukraine есть замечательная инициатива Agile Translations. Думаю, в сообществе русскоязычных аналитиков не меньше людей, у которых достаточно компетенции и желания заниматься такой полезной и интересной деятельностью. Осталось их организовать +)
Я, конечно понимаю, что для «классических требований» термин «backlog» не ключевой, но бездумная копипаста «резерва проекта» с Википедии дискредитирует это издание гораздо сильнее, чем опечатка в посвящении и всякие «повелители сайта» по тексту.
Если бы переводчик потрудился заглянуть в те же «Пользовательские истории», то нашёл бы там «Журнал запросов на выполнение работ» – не первоклассный перевод, конечно, но хотя бы отражающий общую суть. Примечательно, что «Вильямс» открыто указывает переводчика А. Г. Гузикевича, тогда как у «Русской редакций» ничего подобного я не нашёл.
Такие известные книги, на мой взгляд, лучше всего переводить силами сообщества, потому как каждая ошибка перевода в терминологии и важных описаниях порождает массу когнитивных искажений со всеми вытекающими для отрасли последствиями.
Отлично, значит есть достаточно поводов для продолжения!
1 — «если уже есть дизайн всех готовых компонент», скетча действительно будет достаточно. Спецификация не нужна +)) Именно это я и пытаюсь объяснить. Простенькое наглядное подспорье для объяснения и спецификация – это разные вещи. Нужно искать для первого более подходящее название, потому что психологическая инерция слова «спецификация» неиллюзорно вводит в заблужение. Точно так же, как подробное описание задачи кажется исчерпывающим, хотя это не так. Такие «мелочи» зачастую имеют решающее значение. И в гибкой разработке об этом знают.
2 — какую часть продукта составляют сложные проблемы, над которыми нужно думать по 2 месяца? Какая часть пользователей готова ждать 2 месяца, прежде чем кто-то что-то «родит»? А может у них уже есть идеи? Я не говорил, что большее число однотипных участников может позволить решить проблему быстрее. Я говорю о том, что регулярные поставки за счёт со-трудничества с клиентами дают больше эффекта, чем долгие решения даже самых крутых гуру, основанные на предположениях. В одном UX решении тысячи их. Я это знаю на собственном опыте. Поэтому лучше следовать пути открытий, чем пути сумрачного гения.
3 — действительно, от людей и процесса. И, если вся команда 2 месяца работает над UX решением, это действительно круто. Но что-то мне подсказывает, что в реальности происходит иначе. Разработчики отвлекаются на код – дизайнерами лабаются громоздкие (с точки зрения реализации) решения, управляющий отвлекается на клиентов – начинаются украшательства от разработчиков. Дело не в принуждении, а именно что в процессе. Я вижу основную ценность гибкого процесса в правильном управлением вниманием. Никто не хочет лажать, просто мы крайне неудачно отвлекаемся. Это можно решить вне спринтов. И это хорошая задача. Но спринты делают своё дело, хотим мы того или нет.
Если не возражаете, продолжим выращивать гриб Истины +)
1 — в своём примере я специально сделал акцент на сложности. Осознанное BDD не применяется там, где её нет. Время, затрачиваемое на проработку деталей при высокой сложности поведения системы, более чем оправдано для её дальнейшей поддержки и развития. Детальное описание сложного поведения системы (к примеру, ценообразования при продаже товара в крупном интернет-магазине) в виде сценариев и богатого пользовательского интерфейса (с большим количеством оригинальных элементов) в виде макетов высокой детализации я склонен называть спецификацией. Если вместо них попытаться использовать ЕЯ и скетчи, то суммарное время, которое придётся потратить на объяснение и итерации, существенно превысит время, затрачиваемое на разработку спецификации. Если это условие не выполняется, объяснить задачу можно в непосредственной беседе и спецификация не нужна. Если беседа в данном случае заменяется документом, это не делает получаемый документ спецификацией.
2 — мне кажется, в этом вопросе стоит определить, что подразумевается под хорошим решением. Потому что во многих ситуациях хорошим является своевременное решение, пусть даже с некоторыми неудобствами в использовании. Я, как пользователь, нередко готов простить сервису любую степень топорности интерфейса, если он позволяет решить мне ту задачу, которую не позволяет решить ни один другой. И, если я получу такую возможность раньше, а UX будет улучшаться при моём участии, то я буду куда довольнее и благодарнее, чем в случае длительного ожидания и навязываемого интерфейса.
3 — реализацией элегантного решения для выбранных важных кейсов и является процесс достижения цели спринта. При этом ключевым фактором является полное вовлечение всей команды, тогда как при долгом проектировании взаимодействия ограниченным составом теряется из вида то ценность, то реализуемость компонентов. В результате разработчиков принуждают создавать программных монстров на грани используемых технологий, которые в итоге не дотягивают до необходимых нефункциональных параметров, и весь эффект продуманности деталей смазывается проблемами с быстродействием и надёжностью. Или, того хуже, дорогущий компонент оказывается маловостребованным.
Хорошо, давайте возьмём пример прямо из Википедии. Предположим, нам необходимо построить мост через реку. Причём не обычный мост, а что-нибудь типа Аламильо. Скажем, к Олимпиаде нужно создать настоящий шедевр инженерного искусства.
Сначала архитекторы будут долго медитировать над идеей. И тут вполне работают скетчи, вплоть до рисунков на салфетках. Когда идея всё-таки родится, она обрастёт массой ярких нарративных описаний. Сделают даже небольшие макеты моста, чтобы каждому было понятно, какую удивительную штуку нам предстоит воплотить в жизнь. Но я думаю, каждый понимает, что всего этого недостаточно для начала строительных работ. Мы пока лишь сделали идею общим достоянием.
Пришло время для титанического труда инженеров-конструкторов. И пока они не сделают расчётов и не пропишут необходимые характеристики, ни один строитель не подойдёт к реке. Вот они то, на мой взгляд, и занимаются специфицированием. Полученные ими значения становятся непосредственными физическими характеристиками моста. Цена последующих изменений возрастает на порядки.
Аналогично мы можем обсуждать и открывать для себя программный продукт, помогая себе различными приёмами, множество из которых описано в статье. Но ничего больше концепции мы в итоге не получим. Прототип интерфейса и раскадровка не станут непосредсвтенной основной программного кода. Они нужны были, чтобы участники команды постепенно пришли к понимаю того, что же в действительности они будут реализовывать.
Когда же мы переходим к согласованию, мы начинаем оперировать вполне конкретными величинами. Мы начинаем специфицировать характеристики продукта. Это значения, использующиеся в тестовых сценариях, и это элементы интерфейса (с точными размерами, цветами, состояниями) на дизайнах. Любое изменение какого-то из этих элементов изменит характеристики реальной системы. И некоторые изменения не уступают в цене тем, что вносятся в конструкцию моста.
В этой связи мне наиболее интересна возможность применения принципов итеративности и инкрементности к разработке дизайна. Я на практике убедился, что дизайнеры не любят оценивать отдельные истории и в большинстве своём страдают тяжёлыми формами перфекционизма, поэтому им действительно крайне сложно вписываться в рамки спринта. Майк Кон же говорил ещё и о второй проблеме – восприятии пользователями. Если мы работаем над продуктом, находящимся в промышленной эксплуатации, кардинальные изменения в интерфейсе чреваты серьёзным ухудшением взаимоотношений с клиентами.
С другой стороны, опытные дизайнеры неплохо контролируют свой перфекционизм и могут соизмерять прикладываемые усилия с доступным временем. При этом большинство из нас, думаю, уже привыкло к частым сменам диза популярных сервисов, А-Б тестам и «гонке вооружений» интернет-гигантов. Это бывает неприятно, но абсолютно не смертельно.
У меня есть подозрения, что если дизайнер в полной мере будет понимать сущность итеративного процесса и примет его для себя, он сможет в него вписаться и создавать дизайн приложения эволюционно. Тогда можно добиться уже самой настоящей гибкости в управлении продуктом, разрезая до конца все слои пирога. Только следите себе за ситуацией и развивайте систему в нужную сторону.
Спасибо за прекрасную спорную статью! И да будет этот комментарий мицелием могучего гриба!
А источник спор заключается в сущности самого понятия спецификации – «набора параметров, которым удовлетворяет (должен удовлетворять) некоторый технический объект». И эти параметры должны быть достаточно точными для того, чтобы данный объект можно было воплотить в жизнь и проверить его на жизне-способность. На сегодняшний день в разработке пользовательских приложений есть лишь 2 артефакта, которые могут претендовать на такую роль: BDD сценарии и дизайн экранов системы. На основе сценариев пишутся тесты и реализация, на основе дизайнов делается вёрстка (в широком смысле этого слова). И то, и другое становится непосредственной частью системы. Всё остальное я склонен называть когнитивным сахаром, целью которого действительно является «донесение идей в максимально понятной и полной форме». Проще говоря: спецификация доносит не идеи, а конкретные характеристики продукта. Идеи же доносятся фасилитируемым общением. И эти понятия нельзя смешивать.
Начнём с того, что изначально у нас нет пользовательских историй, о которых идёт речь в статье. У нас есть именно идея, которую каким-то образом нужно донести до команды, чтобы прийти хотя бы к эпическим историям. Таков путь к созданию по-настоящему хороших продуктов.
Донесение идеи продукта отлично фасилитирует такой инструмент, как шаблон бизнес-модели. Совместное выявление эпических историй, в свою очередь, прекрасно фасилитируют карты эффекта. Дополнению историй до пользовательских сценариев способствуют карты историй. А вот из них уже отлично получаются упомянутые в статье потоки, которые я привык называть картами переходов.
Мы делали стори мэпы и карты переходов в Prezi и остались очень довольны. Масштабирование – это сила! Обнаруживается очень много неявных историй и начинают проклёвываться первые интерфейсные решения. Дальше дело за проектированием интерфейсов: сначала на бумаге/магнитной доске, потом в Balsamiq для общего обсуждения и согласования, затем в Axure для более тонких вещей, над которыми ломают голову и управляющий продукта, и дизайнеры, и разработчики.
И вот только после всего этого можно дойти до непосредственной спецификации продукта в BDD сценариях и дизайнах экранов. Естественно, в зависимости от сложности продукта и уровня взаимоотношений с заказчиком/управляющим продуктом, выполняются самые разные вариации этих шагов. Но общий процесс, необходимый для создания хорошего продукта, на мой взгляд, выглядит именно так. И здесь важно отметить 3 ключевых фактора:
всё перечисленное в первую очередь является общением/обсуждением, которому лишь помогают техники и результаты которого фиксируют полученные артефакты (никакого инструментопоклонства);
в обсуждении участвуют все релевантные члены команды (можно, конечно, рисовать скетчи в гордом одиночестве, но это, извините, не гибкая совместная разработка, а когнитивный онанизм);
процесс не каскадный, поскольку более низкоуровневое проектирование одних частей системы движет более высокоуровневое проектирование других (к примеру, создание полной карты переходов невозможно без подробного проектирования некоторых интерфейсов).
Второй спорный момент касается необходимости начинать реализацию истории лишь после того, как на неё готов и полностью согласован дизайн. У меня на памяти несколько крупных проектов, которые мы начинали без дизайна и благополучно доводили до конца. Благо, Drupal позволяет реализовывать и тестировать истории в рамках дефолтных топорных элементов управления. А ещё можно изначально выработать с дизайнером подходящий UI kit, сразу его затемизировать и тестировать в довольно сносном окружении.
Прямо сейчас мы работаем над продуктом, дизайн которого не могут утвердить уже месяц. Тот месяц, за который мы полностью реализовали весь основной функционал. И дело теперь стало за окончательным утвеждением дизайна и темизацией. Если бы мы ждали, проект бы, вероятнее всего, провалился (или дизайнер под давлением сделал бы свою работу на скорую руку, и продукт бы никуда не годился). Зато теперь гарантированно дизайн будет служить функциям приложения, а не наоборот, как это обычно бывает. И клиент доволен тем, что смог помедитировать над дизайном столько, сколько ему было необходимо.
Подытожим:
Спецификация = BDD сценарии + дизайн
Спецификация != донесение идей
Донесение идей = общение + (шаблон бизнес-модели + карты эффектов + карты историй + карты переходов + прототипы интерфейса)
Дизайн желателен, но не обязателен для начала разработки
P. S. Да, я писал о гибкой разработке, для которой в той или иной степени соблюдаются условия из начала статьи, поскольку описанные в статье инструменты применяются именно в ней. Их применение в иных условиях хоть и может несколько улучшить ситуацию, никогда не позволит добиться достойной ценности продукта.
P. P. S. Не так давно меня попросили высказаться по более общему вопросу документирования проектов. Я накидал заметку в Фейсбуке. Думаю, её прочтение раскроет мою позицию гораздо полнее. Надеюсь, обещанный там (и много ещё где) слайдкаст всё-таки появится в этом-следующем месяце. Он призван стать той самой «визуальной (даже аудио-визуальной) спецификацией» ко всему, что здесь написано +)
Денис, если говорить о нашей компании, то из публичных проектов мы в похожем ключе открывали мобильную версию сайта ведущего молдавского сотового оператора, сейчас так работаем над B2B порталом молдавских ИТК компаний и порталом Почты Молдовы. С апреля начинаем работу над крупным собственным продуктом.
Спасибо за прекрасную статью! Отличное продолжение статьи Алексея. Лично для меня очень важно было связать воедино всё то, к чему мы так или иначе приходили за время работы по гибким подходам.
Артём Сердюк придумал отличную альтернативу шаблону бизнес-модели Остервальдера — более интуитивный и наглядный канвас в виде воздушного шара. Думаю, скоро Артём представит его широкой общественности.
Использовал этот канвас уже в четырёх проектах и получил массу положительных отзывов — от заказчиков, партнёров и, самое главное, разработчиков, которым я первым делом объясняю бизнес-модель заказчика и дорожную карту проекта, а уж потом мы составляем карту эффекта (тот самый impact map). Это серьёзно повышает предметную ориентированность команды и хорошо проецируется на цели спринтов.
Надеюсь, со временем применение данного инструмента тоже станет общепринятой техникой для скрам-команд. По крайней мере, я буду прикладывать к этому все необходимые усилия.
Вы, видимо, не поняли, что речь идёт о скрам-команде. Это не рыночный сброд. Это союз умных людей, мотивированных профессионалов, которым нужно лишь «создать условия, обеспечить поддержку и полностью довериться» (5-ый принцип).
Трёхмесячный опыт показывает, что опозданий практически не стало (изначальная цель) и граница между «наказанием» и жестом доброй воли исчезла в принципе. Многие приносят гостинцы просто потому, что им хочется всех угостить. В этом вопросе мы вышли на уровень Ri, мы не вспоминаем о процессе, это часть нашей общей культуры.
Нет натянутых улыбок, нет жеманства. Сегодня к нам вернулся коллега из Штатов и сразу попал на оценивание сложного модуля. Мы вышли измотанные из переговорной через 3 часа, но он искренне признался, что давно так здорово не проводил время, потому что был среди своих и занимался любимым делом. У американцев он просто засыпал, участвуя в аналогичных мероприятиях.
Если не верите, попробуйте сами. Эмпирический процесс расставит всё на свои места.
А мы последовали совету Хенрика и стали мелко штрафовать опоздавших, а на «вырученные средства» приобретать приятные, и, как правило, сладкие, мелочи.
Когда же обстоятельства привели к моему собственному опозданию, я решил оптимизировать процесс и пришёл сразу с целевым продуктом +) Ребятам понравилось и теперь «все так делают» (без договорённости).
Один и тот же социальный механизм (подражание) может приводить к кардинально противоположным эффектам. Главное — удачно подобрать точку приложения ))
То, что вы пытаетесь сформулировать и преподнести как результат собственного исследования (по крайней мере, мне так показалось), давно известно и широко используется в кругах практиков тех самых «гибких методологий», которые вы упоминаете в качестве одного из второстепенных факторов успешности современных проектов.
В частности, стратегическое и тактическое проектное планирование, фокусирующееся на эффекте (читай: решении проблем и реализации возможностей), в последние годы находит всё большее распространение в ИТ сфере под эгидой техники «Карт влияния» (Impact mapping). Техника заключается в построении ментальных карт (mind maps), отражающих взаимосвязи между целями организации, вовлечёнными (прямо и косвенно) в достижение этих целей людьми, необходимыми изменениями в их поведении и конкретными программно-аппаратно-административными-… мерами/инструментами, необходимыми для воплощения этих изменений в жизнь.
К сожалению, время сейчас не позволяет, но, если интересно, я могу проработать с помощью этой техники пример с «хранилищем медицинских данных о состоянии здоровья населения». Разница с вашей табличкой будет колоссальная. Хотя даже моя «Карта» всё ещё будет сферическим конём в вакууме, потому что строить её будет всего один человек, который при этом ещё и слабо знаком с вопросом. Мне придётся делать огромное количество предположений относительно каждого из уровней, точно так же, как один ЛПР вынужден делать предположения, как минимум, относительно того, какие реальные изменения в поведении необходимы и какими инструментами они могут быть обеспечены. Все эти знания не могут находиться в голове одного человека (если, конечно, он не гений, которыми человечество, увы, не особенно располагает) и даже при их наличии всё равно остаётся высокая мера неопределённости, связанная с изменчивостью предметной области и мира в целом.
Именно поэтому «Карты влияния» — коллективная техника, направленная на вовлечение и со-трудничество как можно большего числа релевантных людей, чьи знания, опыт и интуиция могут существенно снизить число неверных предположений и помочь подобрать оптимальные инструменты для достижения цели. И именно поэтому такие проекты реализуются итеративно с постоянной проверкой остающихся предположений и постоянным пересмотром планов на основе этих проверок-экспериментов.
Если вдруг будете в апреле в Минске, приходите на Analyst Days, я буду рассказывать там на примере конкретного открытого проекта о применении этой техники в рамках комплексного подхода. А после можем пообщаться.
Не знаю, насколько сильно у вас это выражено, но мне кажется, что вы не до конца используете основное преимущество итеративной разработки. И, возможно, формирование традиционных скрам-команд – одно из важных грядущих кнопочных улучшений +)
Если честно, мне сложно представить итеративную разработку, строящуюся по такому принципу. Получается, внимание участников команд в единый момент времени распределено на разных фичах, иначе, завершив свой этап, они бы простаивали. Это чревато тем, что за короткую итерацию конкретная фича не успеет достигнуть всех критериев готовности и итерация будет провалена, поскольку управляющий продуктом не сможет заняться полноценной проверкой тех предположений, которую в эту фичу были заложены. Именно поэтому в Скраме команда разработки рассматривается как единое целое, и каждый её участник задействован в реализации фичи на протяжении всего спринта, а не на каком-то конкретном этапе.
Не могли бы вы так же подробно, как и обо всём остальном, рассказать о процессах в Разработке: как проходят планирования, ежедневные встречи, обзоры и ретроспективы у обозначенных команд? Есть ли там всё-таки Скрам или его нет, потому что не нужен?
Единственный вопрос: почему в холархии полного внедрения круг «Разработка» включает подкруги по специализациям, а не по командам, как в «Сервисе»? Ведь, если вы работаете по Скраму, то дизайнеры, разработчики и тестировщики неизбежно объединяются в кроссфункциональные команды. И получается такая же ошибка, как и в первом варианте сервисной холархии.
Я всё-таки надеюсь, что это полное внедрение рано или поздно произойдёт, и у нас появится возможность прочесть об этом такой же замечательный материал. Успехов! +)
Поэтому если даже издательство посчитает невыгодным внесение правок в доптираж, то можно хотя бы попросить добавить ссылку на документ с известными ошибками в ту же аннотацию. То же самое можно попросить сделать онлайн магазины – добавить ссылку в описание товара. Ну, и продвинуть эту же ссылку через всевозможные тематические ресурсы. Думаю, комплекс подобных мер может дать некоторый ощутимый эффект.
Я бы с большим удовольствием и не меньшим пристрастием вычитал двадцатую главу +) Только уже осенью.
Даже если с переводами Вигерса могут возникнуть какие-то юридические проволочки, всегда остаётся возможность выслать издательству список найденных ошибок и параллельно постараться его максимально распространить в Сети. Пусть их учтут в следующем издании, а те, кто приобретёт нынешнее, будет проинформирован.
На мой взгляд, самый простой вариант термина это «список [название элементов]»: «список нереализованных компонентов продукта», «список компонентов для реализации в спринте». Или сокращённо: «список компонентов продукта», «список компонентов спринта». Если команда использует истории, то соответственно: «список историй продукта», «список историй спринта».
Что касается политики издательства в отношении переводов и редактуры, это ещё один веский довод взяться за такую работу силами сообщества. К примеру, у Agile Ukraine есть замечательная инициатива Agile Translations. Думаю, в сообществе русскоязычных аналитиков не меньше людей, у которых достаточно компетенции и желания заниматься такой полезной и интересной деятельностью. Осталось их организовать +)
Если бы переводчик потрудился заглянуть в те же «Пользовательские истории», то нашёл бы там «Журнал запросов на выполнение работ» – не первоклассный перевод, конечно, но хотя бы отражающий общую суть. Примечательно, что «Вильямс» открыто указывает переводчика А. Г. Гузикевича, тогда как у «Русской редакций» ничего подобного я не нашёл.
Такие известные книги, на мой взгляд, лучше всего переводить силами сообщества, потому как каждая ошибка перевода в терминологии и важных описаниях порождает массу когнитивных искажений со всеми вытекающими для отрасли последствиями.
1 — «если уже есть дизайн всех готовых компонент», скетча действительно будет достаточно. Спецификация не нужна +)) Именно это я и пытаюсь объяснить. Простенькое наглядное подспорье для объяснения и спецификация – это разные вещи. Нужно искать для первого более подходящее название, потому что психологическая инерция слова «спецификация» неиллюзорно вводит в заблужение. Точно так же, как подробное описание задачи кажется исчерпывающим, хотя это не так. Такие «мелочи» зачастую имеют решающее значение. И в гибкой разработке об этом знают.
2 — какую часть продукта составляют сложные проблемы, над которыми нужно думать по 2 месяца? Какая часть пользователей готова ждать 2 месяца, прежде чем кто-то что-то «родит»? А может у них уже есть идеи? Я не говорил, что большее число однотипных участников может позволить решить проблему быстрее. Я говорю о том, что регулярные поставки за счёт со-трудничества с клиентами дают больше эффекта, чем долгие решения даже самых крутых гуру, основанные на предположениях. В одном UX решении тысячи их. Я это знаю на собственном опыте. Поэтому лучше следовать пути открытий, чем пути сумрачного гения.
3 — действительно, от людей и процесса. И, если вся команда 2 месяца работает над UX решением, это действительно круто. Но что-то мне подсказывает, что в реальности происходит иначе. Разработчики отвлекаются на код – дизайнерами лабаются громоздкие (с точки зрения реализации) решения, управляющий отвлекается на клиентов – начинаются украшательства от разработчиков. Дело не в принуждении, а именно что в процессе. Я вижу основную ценность гибкого процесса в правильном управлением вниманием. Никто не хочет лажать, просто мы крайне неудачно отвлекаемся. Это можно решить вне спринтов. И это хорошая задача. Но спринты делают своё дело, хотим мы того или нет.
1 — в своём примере я специально сделал акцент на сложности. Осознанное BDD не применяется там, где её нет. Время, затрачиваемое на проработку деталей при высокой сложности поведения системы, более чем оправдано для её дальнейшей поддержки и развития. Детальное описание сложного поведения системы (к примеру, ценообразования при продаже товара в крупном интернет-магазине) в виде сценариев и богатого пользовательского интерфейса (с большим количеством оригинальных элементов) в виде макетов высокой детализации я склонен называть спецификацией. Если вместо них попытаться использовать ЕЯ и скетчи, то суммарное время, которое придётся потратить на объяснение и итерации, существенно превысит время, затрачиваемое на разработку спецификации. Если это условие не выполняется, объяснить задачу можно в непосредственной беседе и спецификация не нужна. Если беседа в данном случае заменяется документом, это не делает получаемый документ спецификацией.
2 — мне кажется, в этом вопросе стоит определить, что подразумевается под хорошим решением. Потому что во многих ситуациях хорошим является своевременное решение, пусть даже с некоторыми неудобствами в использовании. Я, как пользователь, нередко готов простить сервису любую степень топорности интерфейса, если он позволяет решить мне ту задачу, которую не позволяет решить ни один другой. И, если я получу такую возможность раньше, а UX будет улучшаться при моём участии, то я буду куда довольнее и благодарнее, чем в случае длительного ожидания и навязываемого интерфейса.
3 — реализацией элегантного решения для выбранных важных кейсов и является процесс достижения цели спринта. При этом ключевым фактором является полное вовлечение всей команды, тогда как при долгом проектировании взаимодействия ограниченным составом теряется из вида то ценность, то реализуемость компонентов. В результате разработчиков принуждают создавать программных монстров на грани используемых технологий, которые в итоге не дотягивают до необходимых нефункциональных параметров, и весь эффект продуманности деталей смазывается проблемами с быстродействием и надёжностью. Или, того хуже, дорогущий компонент оказывается маловостребованным.
Сначала архитекторы будут долго медитировать над идеей. И тут вполне работают скетчи, вплоть до рисунков на салфетках. Когда идея всё-таки родится, она обрастёт массой ярких нарративных описаний. Сделают даже небольшие макеты моста, чтобы каждому было понятно, какую удивительную штуку нам предстоит воплотить в жизнь. Но я думаю, каждый понимает, что всего этого недостаточно для начала строительных работ. Мы пока лишь сделали идею общим достоянием.
Пришло время для титанического труда инженеров-конструкторов. И пока они не сделают расчётов и не пропишут необходимые характеристики, ни один строитель не подойдёт к реке. Вот они то, на мой взгляд, и занимаются специфицированием. Полученные ими значения становятся непосредственными физическими характеристиками моста. Цена последующих изменений возрастает на порядки.
Аналогично мы можем обсуждать и открывать для себя программный продукт, помогая себе различными приёмами, множество из которых описано в статье. Но ничего больше концепции мы в итоге не получим. Прототип интерфейса и раскадровка не станут непосредсвтенной основной программного кода. Они нужны были, чтобы участники команды постепенно пришли к понимаю того, что же в действительности они будут реализовывать.
Когда же мы переходим к согласованию, мы начинаем оперировать вполне конкретными величинами. Мы начинаем специфицировать характеристики продукта. Это значения, использующиеся в тестовых сценариях, и это элементы интерфейса (с точными размерами, цветами, состояниями) на дизайнах. Любое изменение какого-то из этих элементов изменит характеристики реальной системы. И некоторые изменения не уступают в цене тем, что вносятся в конструкцию моста.
В этой связи мне наиболее интересна возможность применения принципов итеративности и инкрементности к разработке дизайна. Я на практике убедился, что дизайнеры не любят оценивать отдельные истории и в большинстве своём страдают тяжёлыми формами перфекционизма, поэтому им действительно крайне сложно вписываться в рамки спринта. Майк Кон же говорил ещё и о второй проблеме – восприятии пользователями. Если мы работаем над продуктом, находящимся в промышленной эксплуатации, кардинальные изменения в интерфейсе чреваты серьёзным ухудшением взаимоотношений с клиентами.
С другой стороны, опытные дизайнеры неплохо контролируют свой перфекционизм и могут соизмерять прикладываемые усилия с доступным временем. При этом большинство из нас, думаю, уже привыкло к частым сменам диза популярных сервисов, А-Б тестам и «гонке вооружений» интернет-гигантов. Это бывает неприятно, но абсолютно не смертельно.
У меня есть подозрения, что если дизайнер в полной мере будет понимать сущность итеративного процесса и примет его для себя, он сможет в него вписаться и создавать дизайн приложения эволюционно. Тогда можно добиться уже самой настоящей гибкости в управлении продуктом, разрезая до конца все слои пирога. Только следите себе за ситуацией и развивайте систему в нужную сторону.
Спасибо за прекрасную спорную статью! И да будет этот комментарий мицелием могучего гриба!
А источник спор заключается в сущности самого понятия спецификации – «набора параметров, которым удовлетворяет (должен удовлетворять) некоторый технический объект». И эти параметры должны быть достаточно точными для того, чтобы данный объект можно было воплотить в жизнь и проверить его на жизне-способность. На сегодняшний день в разработке пользовательских приложений есть лишь 2 артефакта, которые могут претендовать на такую роль: BDD сценарии и дизайн экранов системы. На основе сценариев пишутся тесты и реализация, на основе дизайнов делается вёрстка (в широком смысле этого слова). И то, и другое становится непосредственной частью системы. Всё остальное я склонен называть когнитивным сахаром, целью которого действительно является «донесение идей в максимально понятной и полной форме». Проще говоря: спецификация доносит не идеи, а конкретные характеристики продукта. Идеи же доносятся фасилитируемым общением. И эти понятия нельзя смешивать.
Начнём с того, что изначально у нас нет пользовательских историй, о которых идёт речь в статье. У нас есть именно идея, которую каким-то образом нужно донести до команды, чтобы прийти хотя бы к эпическим историям. Таков путь к созданию по-настоящему хороших продуктов.
Донесение идеи продукта отлично фасилитирует такой инструмент, как шаблон бизнес-модели. Совместное выявление эпических историй, в свою очередь, прекрасно фасилитируют карты эффекта. Дополнению историй до пользовательских сценариев способствуют карты историй. А вот из них уже отлично получаются упомянутые в статье потоки, которые я привык называть картами переходов.
Мы делали стори мэпы и карты переходов в Prezi и остались очень довольны. Масштабирование – это сила! Обнаруживается очень много неявных историй и начинают проклёвываться первые интерфейсные решения. Дальше дело за проектированием интерфейсов: сначала на бумаге/магнитной доске, потом в Balsamiq для общего обсуждения и согласования, затем в Axure для более тонких вещей, над которыми ломают голову и управляющий продукта, и дизайнеры, и разработчики.
И вот только после всего этого можно дойти до непосредственной спецификации продукта в BDD сценариях и дизайнах экранов. Естественно, в зависимости от сложности продукта и уровня взаимоотношений с заказчиком/управляющим продуктом, выполняются самые разные вариации этих шагов. Но общий процесс, необходимый для создания хорошего продукта, на мой взгляд, выглядит именно так. И здесь важно отметить 3 ключевых фактора:
Второй спорный момент касается необходимости начинать реализацию истории лишь после того, как на неё готов и полностью согласован дизайн. У меня на памяти несколько крупных проектов, которые мы начинали без дизайна и благополучно доводили до конца. Благо, Drupal позволяет реализовывать и тестировать истории в рамках дефолтных топорных элементов управления. А ещё можно изначально выработать с дизайнером подходящий UI kit, сразу его затемизировать и тестировать в довольно сносном окружении.
Прямо сейчас мы работаем над продуктом, дизайн которого не могут утвердить уже месяц. Тот месяц, за который мы полностью реализовали весь основной функционал. И дело теперь стало за окончательным утвеждением дизайна и темизацией. Если бы мы ждали, проект бы, вероятнее всего, провалился (или дизайнер под давлением сделал бы свою работу на скорую руку, и продукт бы никуда не годился). Зато теперь гарантированно дизайн будет служить функциям приложения, а не наоборот, как это обычно бывает. И клиент доволен тем, что смог помедитировать над дизайном столько, сколько ему было необходимо.
Подытожим:
P. S. Да, я писал о гибкой разработке, для которой в той или иной степени соблюдаются условия из начала статьи, поскольку описанные в статье инструменты применяются именно в ней. Их применение в иных условиях хоть и может несколько улучшить ситуацию, никогда не позволит добиться достойной ценности продукта.
P. P. S. Не так давно меня попросили высказаться по более общему вопросу документирования проектов. Я накидал заметку в Фейсбуке. Думаю, её прочтение раскроет мою позицию гораздо полнее. Надеюсь, обещанный там (и много ещё где) слайдкаст всё-таки появится в этом-следующем месяце. Он призван стать той самой «визуальной (даже аудио-визуальной) спецификацией» ко всему, что здесь написано +)
В наших масштабах подход работает прекрасно.
Использовал этот канвас уже в четырёх проектах и получил массу положительных отзывов — от заказчиков, партнёров и, самое главное, разработчиков, которым я первым делом объясняю бизнес-модель заказчика и дорожную карту проекта, а уж потом мы составляем карту эффекта (тот самый impact map). Это серьёзно повышает предметную ориентированность команды и хорошо проецируется на цели спринтов.
Надеюсь, со временем применение данного инструмента тоже станет общепринятой техникой для скрам-команд. По крайней мере, я буду прикладывать к этому все необходимые усилия.
Трёхмесячный опыт показывает, что опозданий практически не стало (изначальная цель) и граница между «наказанием» и жестом доброй воли исчезла в принципе. Многие приносят гостинцы просто потому, что им хочется всех угостить. В этом вопросе мы вышли на уровень Ri, мы не вспоминаем о процессе, это часть нашей общей культуры.
Нет натянутых улыбок, нет жеманства. Сегодня к нам вернулся коллега из Штатов и сразу попал на оценивание сложного модуля. Мы вышли измотанные из переговорной через 3 часа, но он искренне признался, что давно так здорово не проводил время, потому что был среди своих и занимался любимым делом. У американцев он просто засыпал, участвуя в аналогичных мероприятиях.
Если не верите, попробуйте сами. Эмпирический процесс расставит всё на свои места.
Когда же обстоятельства привели к моему собственному опозданию, я решил оптимизировать процесс и пришёл сразу с целевым продуктом +) Ребятам понравилось и теперь «все так делают» (без договорённости).
Один и тот же социальный механизм (подражание) может приводить к кардинально противоположным эффектам. Главное — удачно подобрать точку приложения ))