Comments 38
Спасибо за статью, но она все же спорная, потому что очень категоричная, даже для меня =)
1) мы делаем веб-сервис для интеграции с партнерами
2) в приложении много алгоритмов и внутренней логики, например, валидация ряда параметров или какая-то миграция данных
В этих ситуациях все таки приходится писать текст и вот тут BDD, кстати, работает максимально хорошо.
Опять таки, непонятно, что в итоге с тестировщиками? От тест-кейсов в большом продукте не получается уйти, потому что регрессионное тестирование и прочие вещи. Как вы у себя решаете этот вопрос?
1) мы делаем веб-сервис для интеграции с партнерами
2) в приложении много алгоритмов и внутренней логики, например, валидация ряда параметров или какая-то миграция данных
В этих ситуациях все таки приходится писать текст и вот тут BDD, кстати, работает максимально хорошо.
Опять таки, непонятно, что в итоге с тестировщиками? От тест-кейсов в большом продукте не получается уйти, потому что регрессионное тестирование и прочие вещи. Как вы у себя решаете этот вопрос?
Конечно, все зависит от контекста. Тут контекст — веб приложение. Для описания алгоритмов может и BDD подойдет нормально.
У нас большое количество автоматических тестов. Для них пишутся кейсы и они автоматизируются. Остальное exploratory тестирование в основном. Баланс примерно 4 разработчика на 1 тестировщика.
Если статья спорная — это же прекрасно, есть о чем поговорить.
У нас большое количество автоматических тестов. Для них пишутся кейсы и они автоматизируются. Остальное exploratory тестирование в основном. Баланс примерно 4 разработчика на 1 тестировщика.
Если статья спорная — это же прекрасно, есть о чем поговорить.
Мы тоже столкнулись с тем, что BDD отлично подходит для описания на высоком уровне. А вот для описания UI подходит плохо — получается огромный оверхед. Придумали так, что можно писать стори + основные сценарии. Алгоритмы расписывать подробно в Gherkin, а для UI — прототипы.
о, а по какому принципу у вас строится exploratory тестирование? SBTM или что-то свое? Как я понимаю, на вход помимо всего тестировщики получают и скетчи?
SBTM — это исследовательсткое тестирование, только более регламентированное. Поскольку нас не беспокоит отчетность о проведенных тестах, мы имеем каждый свой вид исследования. Никто не ограничивает временем, сценарием мыльной оперы и описанием хронологии теста.
На выходе должен быть функционал, смоук тест которого автоматизирован, и фича протестана так, чтобы мы могли искренне и уверенно сказать, что сделали всё, на что способны, чтобы из продакшена не пришли баги.
У тестера есть все материалы по этому функционалу на входе. Но вход у всей команды (Dev+QA) один. Когда они готовы начать разработку новой юзер стори, они зовут на кик-старт митинг продукт оунера (дизайнеров, верстальщиков, и ещё кого-нибудь, если он нужен), чтобы еще раз обсудить всю входную инфу, спеку, скетчи, побрейнстормить о пути разработки, тестирования, о потенциально опасных местах. С этого митинга все выходят с полным одинаковым пониманием что, зачем и как будет сделано через пару дней.
На выходе должен быть функционал, смоук тест которого автоматизирован, и фича протестана так, чтобы мы могли искренне и уверенно сказать, что сделали всё, на что способны, чтобы из продакшена не пришли баги.
У тестера есть все материалы по этому функционалу на входе. Но вход у всей команды (Dev+QA) один. Когда они готовы начать разработку новой юзер стори, они зовут на кик-старт митинг продукт оунера (дизайнеров, верстальщиков, и ещё кого-нибудь, если он нужен), чтобы еще раз обсудить всю входную инфу, спеку, скетчи, побрейнстормить о пути разработки, тестирования, о потенциально опасных местах. С этого митинга все выходят с полным одинаковым пониманием что, зачем и как будет сделано через пару дней.
Отличная статья. У меня в свое время хорошо прижился такой формат спеков:
1. Рассказ о том, что за проблема. Текст на абзац в свободном стиле.
2. Как сделать. Прояснение тех. деталей для разработчиков, желательно пошагово.
3. Как проверить. Прояснение тех моментов, которые будут тестироваться. Краткий сценарий тестирования.
Итоговая история смотрится примерно так (условно набросал сейчас):
В моем примере «как сделать» и «как проверить» очень похожи, так бывает в коротеньких задачах. В реальных примерах они могут различаться довольно сильно, давая взгляды на проблему с разных сторон.
Если задача не влезает в такой формат спека, то все равно описываем ее так же, а потом разбиваем на подзадачи. Очень важно не допускать разрастания одного документа.
1. Рассказ о том, что за проблема. Текст на абзац в свободном стиле.
2. Как сделать. Прояснение тех. деталей для разработчиков, желательно пошагово.
3. Как проверить. Прояснение тех моментов, которые будут тестироваться. Краткий сценарий тестирования.
Итоговая история смотрится примерно так (условно набросал сейчас):
Нашим пользователям очень неудобно создавать новые задачи. Создать задачу им может прийти в голову в любой момент, а сейчас это можно сделать только из определенного меню. Нужно сделать так, чтобы это было возможно из любого экрана программы.
Для этого необходимо:
— Создать на экране кнопку [рисунок], которая будет вести на карточку создания задачи.
— Некоторые поля там будут предзаполнены, например пользователь создал карточку из экрана клиента или сделки. [список экранов и типов предзаполнения]
— В некоторых ситуациях создать задачу нельзя. Например, нет прав. В этом случае показывать кнопку в неактивном состоянии.
Как проверить:
— На всех страницах есть кнопка создания задачи.
— По клике на кнопке на новом экране открывается карточка задачи, некоторые поля предзаполняются. Карточка задачи работает в полном объеме, предзаполненые поля можно отредактировать.
— Если у пользователя такие-то права, то задачу создать нельзя, кнопка неактивна.
В моем примере «как сделать» и «как проверить» очень похожи, так бывает в коротеньких задачах. В реальных примерах они могут различаться довольно сильно, давая взгляды на проблему с разных сторон.
Если задача не влезает в такой формат спека, то все равно описываем ее так же, а потом разбиваем на подзадачи. Очень важно не допускать разрастания одного документа.
Спецификации не пишу, думал пройти мимо, но «В жопу спецификации!» меня заманило, спасибо :)
Отличная статья, спасибо! Пора закупать цветные карандаши.
Моя презентация на подобную тему www.slideshare.net/i_kender/ii-2527016
Уфф, в статье много методологических ляпов, буду описывать их в процессе чтения.
Ляп №1 про нарративные спецификации.
Автор дал такой пример: «Карточки прыгают обратно в левую колонку и остаются желтыми, чтобы Вася мог сполна почувствовать собственное ничтожество по сравнению разработчиками системы.»
Спецификации должны описывать сценарии пользователей без деталей реализации! Дело в том, что такая спецификация вербальная. Сам UI невербален и переход из одного в другое делает человек в другой роли. Иначе будет смешение зон ответственности между тем, кто делал спецификацию, кто ее реализовал в каркасе и кто ее имплементировал.
Ляп №1 про нарративные спецификации.
Автор дал такой пример: «Карточки прыгают обратно в левую колонку и остаются желтыми, чтобы Вася мог сполна почувствовать собственное ничтожество по сравнению разработчиками системы.»
Спецификации должны описывать сценарии пользователей без деталей реализации! Дело в том, что такая спецификация вербальная. Сам UI невербален и переход из одного в другое делает человек в другой роли. Иначе будет смешение зон ответственности между тем, кто делал спецификацию, кто ее реализовал в каркасе и кто ее имплементировал.
Мое мнение такое — спецификация должна описывать все детали реализации, иначе их придумает разработчик и часто придумает херню. Типа сообщение об ошибке «You can't do that». Как только начинается разработка — должна быть такая спецификация.
Разработчики могут принимать участие в обсуждениях UX и конечных решениях, что у нас и происходит. Но фазы UX и разработки должны быть разделены.
Разработчики могут принимать участие в обсуждениях UX и конечных решениях, что у нас и происходит. Но фазы UX и разработки должны быть разделены.
Насчет набросков интерфейса:
проблема не в том, чтобы уметь рисовать. Проблема в том, чтобы вспомнить все кнопочки во время рисования и расположить равномерно по всему интерфесу.
Картинка из примера — это вероятно результат десятков интераций, каждая из которых требует выбрасывать целый лист бумаги и перерисовывать рисунок с нуля. Это требует чертовски много времени и бумаги!!!
проблема не в том, чтобы уметь рисовать. Проблема в том, чтобы вспомнить все кнопочки во время рисования и расположить равномерно по всему интерфесу.
Картинка из примера — это вероятно результат десятков интераций, каждая из которых требует выбрасывать целый лист бумаги и перерисовывать рисунок с нуля. Это требует чертовски много времени и бумаги!!!
Какая именно картинка?
С другой стороны, скетчи помогают собрать все в одном месте. А за одно еще раз подумать над задачей. Хотя это, конечно, индивидуально. Я вот без листа бумаги уже не могу.
Это понятно. Я тоже люблю писать списки на бумаге. Я вижу как обожают чиркаться коллеги по распечатанным скетчам.
Но дополнять и упорядочивать — проще в гуглодоке. А эскизы редактировать в бальзамике.
Мне, как программисту, проще написать список всех функций, а вторым этапом нарисовать интерфейсы.
Три кнопки — OK. Но когда этих кнопок 43 — замучаешься все прорисовывать. Не будешь прорисовывать — будут отбирать кофе и булочки.
Но дополнять и упорядочивать — проще в гуглодоке. А эскизы редактировать в бальзамике.
Мне, как программисту, проще написать список всех функций, а вторым этапом нарисовать интерфейсы.
Три кнопки — OK. Но когда этих кнопок 43 — замучаешься все прорисовывать. Не будешь прорисовывать — будут отбирать кофе и булочки.
Меня интересует следующий вопрос. Управляющие продуктом — кто они? Это бывшие программисты с некоторыми управляющими способностями или это больше менеджеры с определенными дополнительными знаниями или кто-то еще? С чего начать, чтобы работать на этой должности?
В продакты попадают из проджект-менеджеров, из аналитиков, из дизайнеров. Из разработчиков по-моему реже. Важные качества — не просто уметь управлять, планировать и т.д. функции проджекта, а способность видеть и рынок и пользователей и технологии. Т.е. это скорее предпринимательский склад мышления.
Спасибо за ответ, значит я не ошибался, видя данную должность в сфере своих интересов, начиная с проджект-менеджера. Тем более предпринимательский опыт имеется.
Слышал противоположные мнения, мол не проработав программистом не поймешь процессов, что и вызывало сомнения. Но как мне всегда казалось – хочешь работать программистом, иди работать программистом, хочешь работать управляющим проектом/продуктом, то и начинай с соответствующих должностей, зачем заниматься тем, что тебе не нужно и в ваших словах еще раз нашел этому подтверждение.
Тем не менее, всё ещё остается открытым вопрос входа в сферу. Потому как, несмотря на техническое образование, до этого вёл проекты не связанные с разработкой. Не считая в студенческие годы создания нескольких сайтов с приятелем, которому под конец стал писать очень подробные спецификации из-за проблем с первыми заказами. Но такой любительский опыт мало кого интересует. Так вот, если карьеру программиста я более-менее представляю и много где берут новичков, то прийти в фирму управляющим без опыта невозможно просто по самой сути этой профессии. Также довольно наивно сразу пытаться создать что-то своё — процесс получения сравнимого опыта затянется на гораздо большее время, если вообще окажется успешным. Поэтому, вопрос с чего начать всё ещё открыт.
Слышал противоположные мнения, мол не проработав программистом не поймешь процессов, что и вызывало сомнения. Но как мне всегда казалось – хочешь работать программистом, иди работать программистом, хочешь работать управляющим проектом/продуктом, то и начинай с соответствующих должностей, зачем заниматься тем, что тебе не нужно и в ваших словах еще раз нашел этому подтверждение.
Тем не менее, всё ещё остается открытым вопрос входа в сферу. Потому как, несмотря на техническое образование, до этого вёл проекты не связанные с разработкой. Не считая в студенческие годы создания нескольких сайтов с приятелем, которому под конец стал писать очень подробные спецификации из-за проблем с первыми заказами. Но такой любительский опыт мало кого интересует. Так вот, если карьеру программиста я более-менее представляю и много где берут новичков, то прийти в фирму управляющим без опыта невозможно просто по самой сути этой профессии. Также довольно наивно сразу пытаться создать что-то своё — процесс получения сравнимого опыта затянется на гораздо большее время, если вообще окажется успешным. Поэтому, вопрос с чего начать всё ещё открыт.
Истина, как плесень – зарождается в спорах.
Спасибо за прекрасную спорную статью! И да будет этот комментарий мицелием могучего гриба!
А источник спор заключается в сущности самого понятия спецификации – «набора параметров, которым удовлетворяет (должен удовлетворять) некоторый технический объект». И эти параметры должны быть достаточно точными для того, чтобы данный объект можно было воплотить в жизнь и проверить его на жизне-способность. На сегодняшний день в разработке пользовательских приложений есть лишь 2 артефакта, которые могут претендовать на такую роль: BDD сценарии и дизайн экранов системы. На основе сценариев пишутся тесты и реализация, на основе дизайнов делается вёрстка (в широком смысле этого слова). И то, и другое становится непосредственной частью системы. Всё остальное я склонен называть когнитивным сахаром, целью которого действительно является «донесение идей в максимально понятной и полной форме». Проще говоря: спецификация доносит не идеи, а конкретные характеристики продукта. Идеи же доносятся фасилитируемым общением. И эти понятия нельзя смешивать.
Начнём с того, что изначально у нас нет пользовательских историй, о которых идёт речь в статье. У нас есть именно идея, которую каким-то образом нужно донести до команды, чтобы прийти хотя бы к эпическим историям. Таков путь к созданию по-настоящему хороших продуктов.
Донесение идеи продукта отлично фасилитирует такой инструмент, как шаблон бизнес-модели. Совместное выявление эпических историй, в свою очередь, прекрасно фасилитируют карты эффекта. Дополнению историй до пользовательских сценариев способствуют карты историй. А вот из них уже отлично получаются упомянутые в статье потоки, которые я привык называть картами переходов.
Мы делали стори мэпы и карты переходов в Prezi и остались очень довольны. Масштабирование – это сила! Обнаруживается очень много неявных историй и начинают проклёвываться первые интерфейсные решения. Дальше дело за проектированием интерфейсов: сначала на бумаге/магнитной доске, потом в Balsamiq для общего обсуждения и согласования, затем в Axure для более тонких вещей, над которыми ломают голову и управляющий продукта, и дизайнеры, и разработчики.
И вот только после всего этого можно дойти до непосредственной спецификации продукта в BDD сценариях и дизайнах экранов. Естественно, в зависимости от сложности продукта и уровня взаимоотношений с заказчиком/управляющим продуктом, выполняются самые разные вариации этих шагов. Но общий процесс, необходимый для создания хорошего продукта, на мой взгляд, выглядит именно так. И здесь важно отметить 3 ключевых фактора:
- всё перечисленное в первую очередь является общением/обсуждением, которому лишь помогают техники и результаты которого фиксируют полученные артефакты (никакого инструментопоклонства);
- в обсуждении участвуют все релевантные члены команды (можно, конечно, рисовать скетчи в гордом одиночестве, но это, извините, не гибкая совместная разработка, а когнитивный онанизм);
- процесс не каскадный, поскольку более низкоуровневое проектирование одних частей системы движет более высокоуровневое проектирование других (к примеру, создание полной карты переходов невозможно без подробного проектирования некоторых интерфейсов).
Второй спорный момент касается необходимости начинать реализацию истории лишь после того, как на неё готов и полностью согласован дизайн. У меня на памяти несколько крупных проектов, которые мы начинали без дизайна и благополучно доводили до конца. Благо, Drupal позволяет реализовывать и тестировать истории в рамках дефолтных топорных элементов управления. А ещё можно изначально выработать с дизайнером подходящий UI kit, сразу его затемизировать и тестировать в довольно сносном окружении.
Прямо сейчас мы работаем над продуктом, дизайн которого не могут утвердить уже месяц. Тот месяц, за который мы полностью реализовали весь основной функционал. И дело теперь стало за окончательным утвеждением дизайна и темизацией. Если бы мы ждали, проект бы, вероятнее всего, провалился (или дизайнер под давлением сделал бы свою работу на скорую руку, и продукт бы никуда не годился). Зато теперь гарантированно дизайн будет служить функциям приложения, а не наоборот, как это обычно бывает. И клиент доволен тем, что смог помедитировать над дизайном столько, сколько ему было необходимо.
Подытожим:
- Спецификация = BDD сценарии + дизайн
- Спецификация != донесение идей
- Донесение идей = общение + (шаблон бизнес-модели + карты эффектов + карты историй + карты переходов + прототипы интерфейса)
- Дизайн желателен, но не обязателен для начала разработки
P. S. Да, я писал о гибкой разработке, для которой в той или иной степени соблюдаются условия из начала статьи, поскольку описанные в статье инструменты применяются именно в ней. Их применение в иных условиях хоть и может несколько улучшить ситуацию, никогда не позволит добиться достойной ценности продукта.
P. P. S. Не так давно меня попросили высказаться по более общему вопросу документирования проектов. Я накидал заметку в Фейсбуке. Думаю, её прочтение раскроет мою позицию гораздо полнее. Надеюсь, обещанный там (и много ещё где) слайдкаст всё-таки появится в этом-следующем месяце. Он призван стать той самой «визуальной (даже аудио-визуальной) спецификацией» ко всему, что здесь написано +)
Я по обоим «спорным» вопросам согласен. Но определение Спецификация = BDD сценарии + дизайн — слишком узкое. Есть много способов, и эти два на мой взгляд не являются единственными.
По поводу реализации и дизайна все зависит от обстоятельств. В идеальном мире у разработчиков есть все, что нужно перед началом работы. В реальном конечно же нет. Если есть возможность, надо приближаться к идеалу. Если нет, работать с имеющейся информацией. Мы тоже когда начинали v.3 не имели готового дизайна, а всего лишь общую идею с приличной глубиной проработки. Дизайн устаканивался несколько месяцев, и конечно вся команда работала над функционалом в это время. Просто потом было много переделок, но тут уж нужно решить, что важнее — деньги сэкономить или время.
По поводу реализации и дизайна все зависит от обстоятельств. В идеальном мире у разработчиков есть все, что нужно перед началом работы. В реальном конечно же нет. Если есть возможность, надо приближаться к идеалу. Если нет, работать с имеющейся информацией. Мы тоже когда начинали v.3 не имели готового дизайна, а всего лишь общую идею с приличной глубиной проработки. Дизайн устаканивался несколько месяцев, и конечно вся команда работала над функционалом в это время. Просто потом было много переделок, но тут уж нужно решить, что важнее — деньги сэкономить или время.
Хорошо, давайте возьмём пример прямо из Википедии. Предположим, нам необходимо построить мост через реку. Причём не обычный мост, а что-нибудь типа Аламильо. Скажем, к Олимпиаде нужно создать настоящий шедевр инженерного искусства.
Сначала архитекторы будут долго медитировать над идеей. И тут вполне работают скетчи, вплоть до рисунков на салфетках. Когда идея всё-таки родится, она обрастёт массой ярких нарративных описаний. Сделают даже небольшие макеты моста, чтобы каждому было понятно, какую удивительную штуку нам предстоит воплотить в жизнь. Но я думаю, каждый понимает, что всего этого недостаточно для начала строительных работ. Мы пока лишь сделали идею общим достоянием.
Пришло время для титанического труда инженеров-конструкторов. И пока они не сделают расчётов и не пропишут необходимые характеристики, ни один строитель не подойдёт к реке. Вот они то, на мой взгляд, и занимаются специфицированием. Полученные ими значения становятся непосредственными физическими характеристиками моста. Цена последующих изменений возрастает на порядки.
Аналогично мы можем обсуждать и открывать для себя программный продукт, помогая себе различными приёмами, множество из которых описано в статье. Но ничего больше концепции мы в итоге не получим. Прототип интерфейса и раскадровка не станут непосредсвтенной основной программного кода. Они нужны были, чтобы участники команды постепенно пришли к понимаю того, что же в действительности они будут реализовывать.
Когда же мы переходим к согласованию, мы начинаем оперировать вполне конкретными величинами. Мы начинаем специфицировать характеристики продукта. Это значения, использующиеся в тестовых сценариях, и это элементы интерфейса (с точными размерами, цветами, состояниями) на дизайнах. Любое изменение какого-то из этих элементов изменит характеристики реальной системы. И некоторые изменения не уступают в цене тем, что вносятся в конструкцию моста.
В этой связи мне наиболее интересна возможность применения принципов итеративности и инкрементности к разработке дизайна. Я на практике убедился, что дизайнеры не любят оценивать отдельные истории и в большинстве своём страдают тяжёлыми формами перфекционизма, поэтому им действительно крайне сложно вписываться в рамки спринта. Майк Кон же говорил ещё и о второй проблеме – восприятии пользователями. Если мы работаем над продуктом, находящимся в промышленной эксплуатации, кардинальные изменения в интерфейсе чреваты серьёзным ухудшением взаимоотношений с клиентами.
С другой стороны, опытные дизайнеры неплохо контролируют свой перфекционизм и могут соизмерять прикладываемые усилия с доступным временем. При этом большинство из нас, думаю, уже привыкло к частым сменам диза популярных сервисов, А-Б тестам и «гонке вооружений» интернет-гигантов. Это бывает неприятно, но абсолютно не смертельно.
У меня есть подозрения, что если дизайнер в полной мере будет понимать сущность итеративного процесса и примет его для себя, он сможет в него вписаться и создавать дизайн приложения эволюционно. Тогда можно добиться уже самой настоящей гибкости в управлении продуктом, разрезая до конца все слои пирога. Только следите себе за ситуацией и развивайте систему в нужную сторону.
Сначала архитекторы будут долго медитировать над идеей. И тут вполне работают скетчи, вплоть до рисунков на салфетках. Когда идея всё-таки родится, она обрастёт массой ярких нарративных описаний. Сделают даже небольшие макеты моста, чтобы каждому было понятно, какую удивительную штуку нам предстоит воплотить в жизнь. Но я думаю, каждый понимает, что всего этого недостаточно для начала строительных работ. Мы пока лишь сделали идею общим достоянием.
Пришло время для титанического труда инженеров-конструкторов. И пока они не сделают расчётов и не пропишут необходимые характеристики, ни один строитель не подойдёт к реке. Вот они то, на мой взгляд, и занимаются специфицированием. Полученные ими значения становятся непосредственными физическими характеристиками моста. Цена последующих изменений возрастает на порядки.
Аналогично мы можем обсуждать и открывать для себя программный продукт, помогая себе различными приёмами, множество из которых описано в статье. Но ничего больше концепции мы в итоге не получим. Прототип интерфейса и раскадровка не станут непосредсвтенной основной программного кода. Они нужны были, чтобы участники команды постепенно пришли к понимаю того, что же в действительности они будут реализовывать.
Когда же мы переходим к согласованию, мы начинаем оперировать вполне конкретными величинами. Мы начинаем специфицировать характеристики продукта. Это значения, использующиеся в тестовых сценариях, и это элементы интерфейса (с точными размерами, цветами, состояниями) на дизайнах. Любое изменение какого-то из этих элементов изменит характеристики реальной системы. И некоторые изменения не уступают в цене тем, что вносятся в конструкцию моста.
В этой связи мне наиболее интересна возможность применения принципов итеративности и инкрементности к разработке дизайна. Я на практике убедился, что дизайнеры не любят оценивать отдельные истории и в большинстве своём страдают тяжёлыми формами перфекционизма, поэтому им действительно крайне сложно вписываться в рамки спринта. Майк Кон же говорил ещё и о второй проблеме – восприятии пользователями. Если мы работаем над продуктом, находящимся в промышленной эксплуатации, кардинальные изменения в интерфейсе чреваты серьёзным ухудшением взаимоотношений с клиентами.
С другой стороны, опытные дизайнеры неплохо контролируют свой перфекционизм и могут соизмерять прикладываемые усилия с доступным временем. При этом большинство из нас, думаю, уже привыкло к частым сменам диза популярных сервисов, А-Б тестам и «гонке вооружений» интернет-гигантов. Это бывает неприятно, но абсолютно не смертельно.
У меня есть подозрения, что если дизайнер в полной мере будет понимать сущность итеративного процесса и примет его для себя, он сможет в него вписаться и создавать дизайн приложения эволюционно. Тогда можно добиться уже самой настоящей гибкости в управлении продуктом, разрезая до конца все слои пирога. Только следите себе за ситуацией и развивайте систему в нужную сторону.
1 — разработка ПО и строительство моста вещи довольно разные. Если для моста нужны все детали и просчет, для ПО обычного этого не нужно. И время затраченное на такую проработку деталей будет потрачено впустую. Поэтому скетчи вполне могут стать частью спека.
2 — хорошее решение невозможно придумать за 2 недели. Если перед спринтом нет ничего, а только юзер стори, то для любой мало-мальски сложной проблемы не будет сделано хорошее решение. Посредственные — сколько угодно. Хорошие решения требуют времени. После 10 лет в продукте мы пришли к тому, что фазы UX и разработки разделены. UX фаза длинная и обычно нужно десяток итераций, чтобы найти хорошее решение.
3 — разбиение большой задачи на маленькие и решение каждой задачи в контексте спринта — плохая практика. Очень легко потом получить странный функционал, который нужно будет переделать. Гораздо эффективнее продумать важные кейсы заранее и придумать решение, которое будет элегантно решать большинство из них. Конечно, можно ошибиться с самими кейсами. Поэтому если знания в домене невелики, то лучше выпустить хоть что-то на рынок и собрать фидбек. Если знаний много — это не обязательно делать.
2 — хорошее решение невозможно придумать за 2 недели. Если перед спринтом нет ничего, а только юзер стори, то для любой мало-мальски сложной проблемы не будет сделано хорошее решение. Посредственные — сколько угодно. Хорошие решения требуют времени. После 10 лет в продукте мы пришли к тому, что фазы UX и разработки разделены. UX фаза длинная и обычно нужно десяток итераций, чтобы найти хорошее решение.
3 — разбиение большой задачи на маленькие и решение каждой задачи в контексте спринта — плохая практика. Очень легко потом получить странный функционал, который нужно будет переделать. Гораздо эффективнее продумать важные кейсы заранее и придумать решение, которое будет элегантно решать большинство из них. Конечно, можно ошибиться с самими кейсами. Поэтому если знания в домене невелики, то лучше выпустить хоть что-то на рынок и собрать фидбек. Если знаний много — это не обязательно делать.
Если не возражаете, продолжим выращивать гриб Истины +)
1 — в своём примере я специально сделал акцент на сложности. Осознанное BDD не применяется там, где её нет. Время, затрачиваемое на проработку деталей при высокой сложности поведения системы, более чем оправдано для её дальнейшей поддержки и развития. Детальное описание сложного поведения системы (к примеру, ценообразования при продаже товара в крупном интернет-магазине) в виде сценариев и богатого пользовательского интерфейса (с большим количеством оригинальных элементов) в виде макетов высокой детализации я склонен называть спецификацией. Если вместо них попытаться использовать ЕЯ и скетчи, то суммарное время, которое придётся потратить на объяснение и итерации, существенно превысит время, затрачиваемое на разработку спецификации. Если это условие не выполняется, объяснить задачу можно в непосредственной беседе и спецификация не нужна. Если беседа в данном случае заменяется документом, это не делает получаемый документ спецификацией.
2 — мне кажется, в этом вопросе стоит определить, что подразумевается под хорошим решением. Потому что во многих ситуациях хорошим является своевременное решение, пусть даже с некоторыми неудобствами в использовании. Я, как пользователь, нередко готов простить сервису любую степень топорности интерфейса, если он позволяет решить мне ту задачу, которую не позволяет решить ни один другой. И, если я получу такую возможность раньше, а UX будет улучшаться при моём участии, то я буду куда довольнее и благодарнее, чем в случае длительного ожидания и навязываемого интерфейса.
3 — реализацией элегантного решения для выбранных важных кейсов и является процесс достижения цели спринта. При этом ключевым фактором является полное вовлечение всей команды, тогда как при долгом проектировании взаимодействия ограниченным составом теряется из вида то ценность, то реализуемость компонентов. В результате разработчиков принуждают создавать программных монстров на грани используемых технологий, которые в итоге не дотягивают до необходимых нефункциональных параметров, и весь эффект продуманности деталей смазывается проблемами с быстродействием и надёжностью. Или, того хуже, дорогущий компонент оказывается маловостребованным.
1 — в своём примере я специально сделал акцент на сложности. Осознанное BDD не применяется там, где её нет. Время, затрачиваемое на проработку деталей при высокой сложности поведения системы, более чем оправдано для её дальнейшей поддержки и развития. Детальное описание сложного поведения системы (к примеру, ценообразования при продаже товара в крупном интернет-магазине) в виде сценариев и богатого пользовательского интерфейса (с большим количеством оригинальных элементов) в виде макетов высокой детализации я склонен называть спецификацией. Если вместо них попытаться использовать ЕЯ и скетчи, то суммарное время, которое придётся потратить на объяснение и итерации, существенно превысит время, затрачиваемое на разработку спецификации. Если это условие не выполняется, объяснить задачу можно в непосредственной беседе и спецификация не нужна. Если беседа в данном случае заменяется документом, это не делает получаемый документ спецификацией.
2 — мне кажется, в этом вопросе стоит определить, что подразумевается под хорошим решением. Потому что во многих ситуациях хорошим является своевременное решение, пусть даже с некоторыми неудобствами в использовании. Я, как пользователь, нередко готов простить сервису любую степень топорности интерфейса, если он позволяет решить мне ту задачу, которую не позволяет решить ни один другой. И, если я получу такую возможность раньше, а UX будет улучшаться при моём участии, то я буду куда довольнее и благодарнее, чем в случае длительного ожидания и навязываемого интерфейса.
3 — реализацией элегантного решения для выбранных важных кейсов и является процесс достижения цели спринта. При этом ключевым фактором является полное вовлечение всей команды, тогда как при долгом проектировании взаимодействия ограниченным составом теряется из вида то ценность, то реализуемость компонентов. В результате разработчиков принуждают создавать программных монстров на грани используемых технологий, которые в итоге не дотягивают до необходимых нефункциональных параметров, и весь эффект продуманности деталей смазывается проблемами с быстродействием и надёжностью. Или, того хуже, дорогущий компонент оказывается маловостребованным.
Я не согласен по всем пунктам.
1 — детальный дизайн не лучше скетча во многих случаях, если уже есть дизайн всех готовых компонент. В этом случае, например, скетча более чем достаточно. И так ясно, где какая компонента будет. Думаю, таких случаев можно придумать еще
2 — Хорошее решение любой более-менее сложной проблемы невозможно придумать за 2 недели. Точка. Понятно, что форму логина можно придумать за час. Таймлайны в Targetprocess можно придумать за месяца 2 при достаточно интенсивной работе. 9 женщин не могут родить ребенка за месяц. С проектирование часто тоже так.
3 — Ничего не теряется. Надо просто правильно организовать процесс. И на выходе говно тоже зависит полностью от процесса и людей, которые в этом участвуют. Никаких принуждений не нужно. Нужно вовлекать в процесс всех на ранних стадиях и все будет хорошо.
1 — детальный дизайн не лучше скетча во многих случаях, если уже есть дизайн всех готовых компонент. В этом случае, например, скетча более чем достаточно. И так ясно, где какая компонента будет. Думаю, таких случаев можно придумать еще
2 — Хорошее решение любой более-менее сложной проблемы невозможно придумать за 2 недели. Точка. Понятно, что форму логина можно придумать за час. Таймлайны в Targetprocess можно придумать за месяца 2 при достаточно интенсивной работе. 9 женщин не могут родить ребенка за месяц. С проектирование часто тоже так.
3 — Ничего не теряется. Надо просто правильно организовать процесс. И на выходе говно тоже зависит полностью от процесса и людей, которые в этом участвуют. Никаких принуждений не нужно. Нужно вовлекать в процесс всех на ранних стадиях и все будет хорошо.
Отлично, значит есть достаточно поводов для продолжения!
1 — «если уже есть дизайн всех готовых компонент», скетча действительно будет достаточно. Спецификация не нужна +)) Именно это я и пытаюсь объяснить. Простенькое наглядное подспорье для объяснения и спецификация – это разные вещи. Нужно искать для первого более подходящее название, потому что психологическая инерция слова «спецификация» неиллюзорно вводит в заблужение. Точно так же, как подробное описание задачи кажется исчерпывающим, хотя это не так. Такие «мелочи» зачастую имеют решающее значение. И в гибкой разработке об этом знают.
2 — какую часть продукта составляют сложные проблемы, над которыми нужно думать по 2 месяца? Какая часть пользователей готова ждать 2 месяца, прежде чем кто-то что-то «родит»? А может у них уже есть идеи? Я не говорил, что большее число однотипных участников может позволить решить проблему быстрее. Я говорю о том, что регулярные поставки за счёт со-трудничества с клиентами дают больше эффекта, чем долгие решения даже самых крутых гуру, основанные на предположениях. В одном UX решении тысячи их. Я это знаю на собственном опыте. Поэтому лучше следовать пути открытий, чем пути сумрачного гения.
3 — действительно, от людей и процесса. И, если вся команда 2 месяца работает над UX решением, это действительно круто. Но что-то мне подсказывает, что в реальности происходит иначе. Разработчики отвлекаются на код – дизайнерами лабаются громоздкие (с точки зрения реализации) решения, управляющий отвлекается на клиентов – начинаются украшательства от разработчиков. Дело не в принуждении, а именно что в процессе. Я вижу основную ценность гибкого процесса в правильном управлением вниманием. Никто не хочет лажать, просто мы крайне неудачно отвлекаемся. Это можно решить вне спринтов. И это хорошая задача. Но спринты делают своё дело, хотим мы того или нет.
1 — «если уже есть дизайн всех готовых компонент», скетча действительно будет достаточно. Спецификация не нужна +)) Именно это я и пытаюсь объяснить. Простенькое наглядное подспорье для объяснения и спецификация – это разные вещи. Нужно искать для первого более подходящее название, потому что психологическая инерция слова «спецификация» неиллюзорно вводит в заблужение. Точно так же, как подробное описание задачи кажется исчерпывающим, хотя это не так. Такие «мелочи» зачастую имеют решающее значение. И в гибкой разработке об этом знают.
2 — какую часть продукта составляют сложные проблемы, над которыми нужно думать по 2 месяца? Какая часть пользователей готова ждать 2 месяца, прежде чем кто-то что-то «родит»? А может у них уже есть идеи? Я не говорил, что большее число однотипных участников может позволить решить проблему быстрее. Я говорю о том, что регулярные поставки за счёт со-трудничества с клиентами дают больше эффекта, чем долгие решения даже самых крутых гуру, основанные на предположениях. В одном UX решении тысячи их. Я это знаю на собственном опыте. Поэтому лучше следовать пути открытий, чем пути сумрачного гения.
3 — действительно, от людей и процесса. И, если вся команда 2 месяца работает над UX решением, это действительно круто. Но что-то мне подсказывает, что в реальности происходит иначе. Разработчики отвлекаются на код – дизайнерами лабаются громоздкие (с точки зрения реализации) решения, управляющий отвлекается на клиентов – начинаются украшательства от разработчиков. Дело не в принуждении, а именно что в процессе. Я вижу основную ценность гибкого процесса в правильном управлением вниманием. Никто не хочет лажать, просто мы крайне неудачно отвлекаемся. Это можно решить вне спринтов. И это хорошая задача. Но спринты делают своё дело, хотим мы того или нет.
1.Открыл пост 2.Дошел до фразы «в ж… спецификации!» 3.Закрыл пост
Где-то я это уже слышал…
Очень порадовало второе упоминание Гёделя, дивергенции и корреляции.
“пользователь осуществляет операцию перехода на следующий раздел клиентского приложения путем двойного нажатия на левую кнопку манипулятора типа мышь”
В этом предложении явно чего-то нехватает. Совершенно же непонятно, о чем речь. Надо так: пользователь обладает возможнорстью осуществить операцию перехода на следующий раздел клиентского приложения путем последовательного выполнения двойного нажатия на левую кнопку манипулятора типа мышь
Sign up to leave a comment.
Визуальные спецификации