Недавно перевели процесс на Скрам, в связи с чем у меня проявилось некоторое недовольство. Возможно это просто старческое брюзжание, развейте...
Основное недовольство заключается в том, что поскольку итерации у нас 2 недели, то не все User Story помещаются и их начинают резать на какие-то малоосмысленные части.
Т.е. допустим есть логически единая User Story — добавить диалог с выбором параметров, которые нужно получать с различных серверов и заиспользовать эти параметры.
Поскольку работы там много (legacy, незнакомые облясти кода, не слишком чёткая постановка задачи) то US разбивается на несколько US
1. Показать пустой диалог
2. Получить и показать параметры с локального сервера
3. Получить и показать параметры с удалённого сервера
4. Смержить локальные и удалённые параметры
...
Завершив только часть из этих US нельзя делать релиз — пользователь вряд ли оценит пустой диалог... Но при этом каждый кусок работы сопровождается написанием UT, отдачей в QA, показом этого всего Product Owner-у.
Ну и в результате, приступая к очередному куску функционала частично ломаются UT и часть уже оттестированного кода, что-то переписывается, что-то дописывается всё это снова перетестируется. Как-то неприятно осознавать, что часть усилий по "вылизыванию" кода и тестов уходит в /dev/null
Собственно вопрос — что не так? Что-то с процессом или с моим восприятием оного?
Что можно улучшить?
Здравствуйте, Sergey J. A., Вы писали:
SJA>Поскольку работы там много (legacy, незнакомые облясти кода, не слишком чёткая постановка задачи) то US разбивается на несколько US
Это нормально. Ваши User Stories выглядят адекватными. Только мы такие задачи не называем US, потому что US — это то, что можно показать конечному пользователю (или продюсеру). А Ваши задачи выглядят скорее, как технические. Собственно, мы так их и называем.
SJA>Завершив только часть из этих US нельзя делать релиз — пользователь вряд ли оценит пустой диалог... Но при этом каждый кусок работы сопровождается написанием UT, отдачей в QA, показом этого всего Product Owner-у.
У нас нет жёсткой привязки features (в Вашем случае — user stories) к спринтам. Т.е. фичу можно начать делать в одном спринте, а закончить — в другом. Важно, чтобы фича была сделана к майлстоуну. Для каждой фичи существует график их поставки (называется release plan). Там-то и указывается — какая фича в каком спринте будет поставлена. Но начать её реализацию можно в предыдущем спринте или в пред-предыдущем.
SJA>Ну и в результате, приступая к очередному куску функционала частично ломаются UT и часть уже оттестированного кода, что-то переписывается, что-то дописывается всё это снова перетестируется. Как-то неприятно осознавать, что часть усилий по "вылизыванию" кода и тестов уходит в /dev/null
У нас проверяется, чтобы неполностью реализованная фича не ломала билд и flow. Тестирование же фичи начинается только тогда, когда она полностью реализована (или реализована в заданном качестве).
SJA>Что можно улучшить?
Думаю, что следует осознать, что реализация User Story может занять больше, чем 1 спринт. Можете поступить, как и мы — создать график поставки User Stories. И тестировать features в соответствии с этим графиком. А в спринтах следить, чтобы все технические задачи, запланированные на спринт, были бы выполнены.
SJA>Завершив только часть из этих US нельзя делать релиз — пользователь вряд ли оценит пустой диалог... Но при этом каждый кусок работы сопровождается написанием UT, отдачей в QA, показом этого всего Product Owner-у.
SJA>Собственно вопрос — что не так? Что-то с процессом или с моим восприятием оного?
Не так с выделенным. Другими словами, выбран неверный критерий для декомпозиции пользовательской истории.
SJA>Что можно улучшить?
Изменить способ разбивки. Основная идея: выделить самый простой базовый сценарий (mainflow) и дополнительные сценарии, которые наворачивают на него варианты использовани, юзабилити, защиту от дурака и прочие конфетки.
Т.е. допустим есть логически единая User Story — добавить диалог с выбором параметров, которые нужно получать с различных серверов и заиспользовать эти параметры.
Поскольку работы там много (legacy, незнакомые облясти кода, не слишком чёткая постановка задачи) то US разбивается на несколько US
Давай разберем твой пример. Я немного дофантазировал постановку задачи прикинул свой вариант разбиения.
Mainflow: Сделать вырвиглазный диалог, который получает с одного сервера захардкоженный набор параметров и выводит их без возможности редактирования и виде простых строк (value.ToString()).
Я тут выделил те ограничения, которые намеренно ввел в этот сценарий, чтобы упростить его работу и снизить трудоемкость.
Дальше этот сценарий можно развивать в разных направлениях (подпункты — ветки развития):
1. Добавлять юзабилити:
1.1. Натянуть дизайн.
1.2. Добавить поиск на форме
1.3. Добавить сортировки и группировки параметров.
1.4. Добавить групповые операции по параметрам.
2. Добавить выбор сервера с которого будут запрашиваться параметры.
2.1 Добавить возможность выбора нескольких серверов для одного запроса.
2.1.1 Добавить запоминание прошлого выбора.
2.2. Добавить типовые конфигурации для запроса.
2.2.1 Сделать конфигурации настраиваемыми пользователем.
3. Добавить возможность редактирования и отправки параметов в простой форме (строки):
3.1 Добавить валидацию введеных значений.
3.2 Добавить специальные редакторы для разных типов параметров.
И т.п.
Главная идея этого разбиения состоит в том, что ты всегда имеешь законченный сценарий, проходящий от начала и до конца, но сначала этот сценарий убогй и неудобный, а потом он становится всё лучше и лучше.
На каждом этапе его можно демонстрировать клиенту и снимать с него фидбек на тему того, в каком направлении его улучшать и достаточно ли он готов для выкатки в релизную ветку. После выкатки его можно так же полировать по запросам клиента.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Т.е. допустим есть логически единая User Story — добавить диалог с выбором параметров, которые нужно получать с различных серверов и заиспользовать эти параметры. SJA>Поскольку работы там много (legacy, незнакомые облясти кода, не слишком чёткая постановка задачи) то US разбивается на несколько US SJA>1. Показать пустой диалог SJA>2. Получить и показать параметры с локального сервера SJA>3. Получить и показать параметры с удалённого сервера SJA>4. Смержить локальные и удалённые параметры SJA>... SJA>Завершив только часть из этих US нельзя делать релиз — пользователь вряд ли оценит пустой диалог... Но при этом каждый кусок работы сопровождается написанием UT, отдачей в QA, показом этого всего Product Owner-у.
Вы хорошо описали проблему: обычно первое, что приходит в голову — это порезать большую задачу в базисе шагов реализации. Обычно в этом случае получаются нелепые стори типа "я безумно хочу пустое окно, в котором ничего не работает" Этот подход синтетический и толку от него почти нет. Есть несколько других подходов, один из которых — резать стори в терминах геморройности её отдельных частей. Например, думается мне, среди всех этих параметров есть какие-то, поддержку которых добавить легче, чем других. Пусть вообще есть всего 1 простой параметр, остальные — сложные. В этом случае:
1. "Я хочу редактировать параметр A через диалог". Стори предполагает добавление диалога, который тут же имеет ненулевую ценность: можно редактировать аж целый 1 параметр. (для девелоперов с этим 1 параметром меньше всего проблем, но юзеру пофигу)
2. "Я хочу редактировать параметры B, C, D". Пачка параметров с общей геморройностью. Геморройность решается 1 раз, добавляется пачка параметров, value растёт.
3. "Я хочу редактировать параметры E, F, G". Пачка параметров с общей геморройностью. Геморройность решается 1 раз, добавляется пачка параметров, value растёт.
и т.д.
Если юзер изначально не озвучил, что какие-то параметры важнее других, нет проблем добавлять параметры в том порядке, в каком удобно девелоперам. Более того, при таком подходе стори намного проще делать параллельно.
Здравствуйте, Кирилл Лебедев, Вы писали:
SJA>>Что можно улучшить?
КЛ>Думаю, что следует осознать, что реализация User Story может занять больше, чем 1 спринт. Можете поступить, как и мы — создать график поставки User Stories. И тестировать features в соответствии с этим графиком. А в спринтах следить, чтобы все технические задачи, запланированные на спринт, были бы выполнены.
Спасибо. Меня посещают схожие мысли. Но вот только как это обосновать... AFAIK скрам утверждает, что каждая US должна завершаться в спринте и быть готова к релизу.
Нет ли каких-либо ссылок где описывается подобная организация процесса?
Здравствуйте, Sergey J. A., Вы писали:
SJA>Спасибо. Меня посещают схожие мысли. Но вот только как это обосновать... AFAIK скрам утверждает, что каждая US должна завершаться в спринте и быть готова к релизу. SJA>Нет ли каких-либо ссылок где описывается подобная организация процесса?
Я бы не заморачивался с каноничностью по скраму, тем более что представление о "правильном скраме" у всех различается, вот весьма показательный пример
Здравствуйте, 0x7be, Вы писали:
0>Главная идея этого разбиения состоит в том, что ты всегда имеешь законченный сценарий, проходящий от начала и до конца, но сначала этот сценарий убогй и неудобный, а потом он становится всё лучше и лучше. 0>На каждом этапе его можно демонстрировать клиенту и снимать с него фидбек на тему того, в каком направлении его улучшать и достаточно ли он готов для выкатки в релизную ветку. После выкатки его можно так же полировать по запросам клиента.
Спасибо. Пока мы пытаемся двигаться в этом направлении — более правильно формировать US.
Но есть тут некоторые проблемы, неуверен что их можно будет обойти. А именно:
Убогий диалог не уйдёт пользователю. Скорее фичу исключат из релиза или сдвинут релиз. Некоторые уступки конечно происходят, но в одну US это всё равно не укладывается.
Более того, есть желание руководства иметь плавную кривую принятия(accept) US. Т.е. нельзя делать 2 недели одну US. Нужно обязательно много мелких.
Т.е. как ни крути — выйдет определённого вида диалог, но он будет оттестирован несколько раз.
Опять таки сложно рассуждать о дроблении без реального примера... Но просто что бы иметь представление о чём мы говорим. В среднем "толстые" фичи делаются ~3 месяца командой из 6 человек. Она может является самодостаточной и отдаваться клиенту.
Здравствуйте, andyag, Вы писали:
A>1. "Я хочу редактировать параметр A через диалог". Стори предполагает добавление диалога, который тут же имеет ненулевую ценность: можно редактировать аж целый 1 параметр. (для девелоперов с этим 1 параметром меньше всего проблем, но юзеру пофигу) A>2. "Я хочу редактировать параметры B, C, D". Пачка параметров с общей геморройностью. Геморройность решается 1 раз, добавляется пачка параметров, value растёт. A>3. "Я хочу редактировать параметры E, F, G". Пачка параметров с общей геморройностью. Геморройность решается 1 раз, добавляется пачка параметров, value растёт. A>и т.д.
Возможно это возможно Пока я не вижу как можн было бы так разрезать... Если продолжать пример с диалогом — все параметры однородны. Простое их отображение не имеет никакой ценности. Нужно ещё их применять, передавать и прочие радости.
Ну, принцип я понял. Пока мы движемся именно в этом направлении. Неуверен, что оно не тупиковое...
Здравствуйте, Sinix, Вы писали:
SJA>>Спасибо. Меня посещают схожие мысли. Но вот только как это обосновать... AFAIK скрам утверждает, что каждая US должна завершаться в спринте и быть готова к релизу. SJA>>Нет ли каких-либо ссылок где описывается подобная организация процесса? S>Я бы не заморачивался с каноничностью по скраму, тем более что представление о "правильном скраме" у всех различается, вот весьма показательный пример
. "Scrum, Inc", agile manifesto, как бы главный идеолог и всё такое, а толку-то
Просто не я решаю. Я могу "встрять" с советом а для этого нужена какя то доказательная база.
А так — процесс закастомизирован в сторону и Скрам и всё остальное, что было раньше
Здравствуйте, Sergey J. A., Вы писали:
SJA>Поскольку работы там много (legacy, незнакомые облясти кода, не слишком чёткая постановка задачи) то US разбивается на несколько US
Первая проблема на лицо. Скорее всего генерация задач идет "по ТЗ" без понимания ценности для пользователя.
SJA>1. Показать пустой диалог SJA>2. Получить и показать параметры с локального сервера SJA>3. Получить и показать параметры с удалённого сервера SJA>4. Смержить локальные и удалённые параметры SJA>...
Для начала опишите стори в виде "Как <персонаж> я хочу <фича>, чтобы <ценность>", причем начинать надо именно с ценности.
SJA>Завершив только часть из этих US нельзя делать релиз — пользователь вряд ли оценит пустой диалог...
Есть путаница в понятиях "итерация" и "релиз". В конце итерации надо показать работающее ПО. В конце релиза надо иметь работающее ПО с добавленной ценностью относительно предыдущего релиза.
SJA>Но при этом каждый кусок работы сопровождается написанием UT, отдачей в QA, показом этого всего Product Owner-у. SJA>Ну и в результате, приступая к очередному куску функционала частично ломаются UT и часть уже оттестированного кода, что-то переписывается, что-то дописывается всё это снова перетестируется. Как-то неприятно осознавать, что часть усилий по "вылизыванию" кода и тестов уходит в /dev/null
Скорее всего UT проверяют не контракт, а реализацию, от этого и ломаются. UT проверяющие реализацию писать не надо.
SJA>Собственно вопрос — что не так? Что-то с процессом или с моим восприятием оного? SJA>Что можно улучшить?
Слишком мало конкретики, чтобы давать конкретные советы.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Спасибо. Меня посещают схожие мысли. Но вот только как это обосновать...
Точно теми же словами, какими Вы это сделали на форуме.
SJA>AFAIK скрам утверждает, что каждая US должна завершаться в спринте и быть готова к релизу.
Не важно, что утверждает скрам. Вам нужен процесс, который хорошо подходит под Ваши нужды, не так ли?
SJA>Нет ли каких-либо ссылок где описывается подобная организация процесса?
К сожалению, нет. Не думаю, что такой процесс описан где-либо в литературе. Однако если Вам нужны какие-то детали, то могу рассказать. Обращайтесь.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Поскольку работы там много (legacy, незнакомые облясти кода, не слишком чёткая постановка задачи) то US разбивается на несколько US
Научившись забивать гвозди, Вы забиваете шурупы.
US это то, что имеет хоть какую-то ценность для заказчика, а не технические решения. Кривой написанный в кротчайшие сроки на коленке прототип — это US, дополнительные фишки в нем — это другая US.
Как уже писалось скрам ценен тем, что позволяет договориться с заказчиком, который сам четко не знает что ему надо. Постоянно итерируя — Вы просто не сделаете много принципиально ненужного клиентам функционала (не купите шахту, когда нужно ведро угля). А если большая задача четко поставлена и ее необходимость для клиента ясна от начала до конца — то лучше водопад — так вы не сделаете лишнего в техническом плане.
Здравствуйте, Bazaea, Вы писали:
B>US это то, что имеет хоть какую-то ценность для заказчика, а не технические решения. Кривой написанный в кротчайшие сроки на коленке прототип — это US, дополнительные фишки в нем — это другая US.
Тем не менее, имеет смысл выделять качественные уровни реализации User Story (в нашем случае — feature), и если реализация feature занимает более, чем 1 спринт, определять качественный уровень, на котором данная feature будет реализована в текущем спринте.
Например, в одном из проектов мы использовали градацию из 6-ти качественных уровней:
Почему это важно? Потому что, посмотрев на реализацию feature даже на уровне 1st Look, владелец feature может её опробовать и дать обратную связь, внеся изменения в изначальную формулировку feature.
Здравствуйте, Bazaea, Вы писали:
B>А если большая задача четко поставлена и ее необходимость для клиента ясна от начала до конца — то лучше водопад — так вы не сделаете лишнего в техническом плане.
Причём водопад "сверху" превосходно уживается с типовым аджилем снизу. Мелкие итерации , очередь тикетов на итрацию и корректировки по итогам каждой итерации никто не отменял.
1. Пользователю важно получить законченную историю, которая решает его проблему. Появление одного поля в диалоге без возможности выполнить какие-то действия — это не решение проблемы, поэтому такого уровня фрагментация не имеет смысла.
Пример хорошей истории: "Я как пользователь интернет-банка хочу открыть депозит на выбранных условиях в долларах США" (простой и понятный сценарий для демо, не уточняющий, каким образом пользователь выбрал условия и сумму депозита!).
Пример неплохой истории: "Я как пользователь интернет-банка хочу знать, на что я трачу свои деньги" (больше похоже на эпик, потому что фрагментируется на анализ трат по категориям, информацию о банковских комиссиях и историю операций)
Пример приемлемой истории: "Я как пользователь интернет-банка хочу изменить лимит на покупки в интернете по моей карте" (проблема иная — защита от кражи или экономия средств, но _бизнес_ ее переформулировал).
Пример плохой истории: "Я как пользователь интернет-банка хочу ввести БИК в форме банковского перевода" (пользователи не хотят вводить БИК в форме, они хотят перевести пять тысяч рублей Навальному, и бизнес не против эту задачу облегчить, например, реализовав поиск по названию банка).
2. Истории нужно показывать на демо бизнесу, а менеджеру разработки интереснее burndown chart и скорость команды — и кто сказал, что для измерения и анализа нужны истории? Берем истории, бьем на технические задачи, оцениваем и закрываем именно их. Менеджер видит прогресс, разработчики четко понимают задачу, все довольны. История закрывается и уходит на демо, если сделаны все технические задачи.
3. Разработка должна начинаться с фазы проектирования интерфейса, которая должна быть завершена до фазы написания функциональных требований и выполнена на основе пользовательских историй. Соответственно, в момент формулировки user story вы вообще не должны мыслить в категориях диалогов, серверов и прочего. Пример плохой истории выше (про БИК) наглядно это иллюстрирует: бизнес-аналитик, сформулировавший эту историю, отталкивался от предметной области (для банковского перевода нужен БИК), а не от потребностей пользователя. Проектировщик интерфейса постарался бы упростить пользователю задачу, предоставив пользователю возможность осуществить перевод, не понимая этого узкоспециализированного термина и не владея информацией о БИК банка-получателя. Менеджер проекта после этого может решить, что реализация поиска требует дополнительных трудозатрат, и в таком случае его обязанность — обсудить приоритет этого функционала с бизнесом (маркетинг?), после чего план реализации этой фичи может быть составлен из двух этапов, на первом из которых пользователь вводит только БИК (первая версия банка), на втором — пользуется поиском по названию (вторая версия банка).
Здравствуйте, Sinix, Вы писали:
S>Причём водопад "сверху" превосходно уживается с типовым аджилем снизу. Мелкие итерации , очередь тикетов на итрацию и корректировки по итогам каждой итерации никто не отменял.
Сомнительно, что если у вас все срослось — то это имеет всеобщий характер.
Все дело в ролях. Даже в MSF4 методологии, в которой попытались водопад соединить со спиралью и заявили мол все для удовлетворения заказчика — роль разработка не совместима со всеми остальными ролями (почти). В аджиле все не так. А если смешивать — то рано или поздно начнутся проблемы с ответственностью и мотивацией.
Здравствуйте, Bazaea, Вы писали:
S>>Причём водопад "сверху" превосходно уживается с типовым аджилем снизу. Мелкие итерации , очередь тикетов на итрацию и корректировки по итогам каждой итерации никто не отменял. B>Сомнительно, что если у вас все срослось — то это имеет всеобщий характер.
Угу. Это обычная реакция, я сам пока не поучаствовал, очень сомневался, что это работает.
B>Все дело в ролях. Даже в MSF4 методологии, в которой попытались водопад соединить со спиралью и заявили мол все для удовлетворения заказчика — роль разработка не совместима со всеми остальными ролями (почти). В аджиле все не так. А если смешивать — то рано или поздно начнутся проблемы с ответственностью и мотивацией.
Ну вот представь (сорри, без деталей, поэтому описано будет слегка не так, как на самом деле): большая контора, бизнес-процессы, которые надо автоматизировать (допустим, технологические, но это непринципиально) чисто объективно настолько сложны, что для их описания и формализации нужен специалист (а лучше два) с профильным образованием. Приоритеты, разбиение по командам и чёткие milestones есть, очередной выпуск — раз в квартал. Ну, т.е. родное поле для rup/msf.
Теперь финт ушами: замечаем, что после работы аналитика всё превосходно разбивается на отдельные задачи (причём на каждую есть какое-никакое ТЗ). Приоритеты и планы на большую итерацию есть. Всё, что остаётся — это превратить ТЗ в очередь тикетов и запустить внутри больших итераций мелкие от аджиля. Я не знаю, как оно смотрится с точки зрения каноничности, но на практике проблем с разделением ролей что-то не наблюдается
Здравствуйте, Sergey J. A., Вы писали:
SJA>Завершив только часть из этих US нельзя делать релиз — пользователь вряд ли оценит пустой диалог... Но при этом каждый кусок работы сопровождается написанием UT, отдачей в QA, показом этого всего Product Owner-у.
SJA>Ну и в результате, приступая к очередному куску функционала частично ломаются UT и часть уже оттестированного кода, что-то переписывается, что-то дописывается всё это снова перетестируется. Как-то неприятно осознавать, что часть усилий по "вылизыванию" кода и тестов уходит в /dev/null
SJA>Собственно вопрос — что не так? Что-то с процессом или с моим восприятием оного? SJA>Что можно улучшить?
Мы используем Feature Toggle. Один конфигурационный файлик с булевскими флажками, которые мы используем в if-else условиях в разных участках кода. В начале реализации фичи мы добавляем новый флаг "SUPER_COOL_PARAMETRISATOR = true" и начинаем кодить. Надо пункт меню добавить — "if(SUPER_COOL_PARAMETRISATOR) addMenuItem()" надо подставить дефолтное значение "return SUPER_COOL_PARAMETRISATOR ? parametrisator.getValue() : DEFAULT_VALUE" и т.п.
Так же на тесты навешиваем assume-условия — т.е. будет два набора тестов для true и false.
Во время итераций тестеры сразу видят что получается. Перед тем как отрезать release версию, проходимся по файлику и решаем что достойно релизить, что нет, соответственно меняя значения флажков. После того, как фича достаточно зрелая, флаг удаляется и false-бранчи тупо удаляются из кода.
Т.е. "сырые" фичи попадают в ближайший релиз, но всё _нежелательно видимое_ поведение отключается простым конфигом.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
SJA>Т.е. допустим есть логически единая User Story — добавить диалог с выбором параметров, которые нужно получать с различных серверов и заиспользовать эти параметры.
Вы уверены, что это логически единая User Story?
Сколько всего параметров в этом диалоге? Пусть, скажем, там 10 параметров. Если юзеру дать для начала, например, только 2 из этих 10 — будет ли юзеру польза? Если уже будет, значит, user story — "дать регулировать вот эти 2 параметра".
Более того, если возможность регулировать один параметр юзеру полезно — значит, юзер стори — это именно "дать юзеру возможность регулировать вот этот параметр". То есть ваш диалог на самом деле может из себя представлять 10 или больше различных юзер стори.
SJA>Поскольку работы там много (legacy, незнакомые облясти кода, не слишком чёткая постановка задачи) то US разбивается на несколько US SJA>1. Показать пустой диалог SJA>2. Получить и показать параметры с локального сервера SJA>3. Получить и показать параметры с удалённого сервера SJA>4. Смержить локальные и удалённые параметры SJA>...
Это неверное разбиение, попытка натянуть waterfall на scrum.
Юзеру нет пользы в пустом диалоге. Если ему нет пользы от "параметров локального сервера", значит, и (2) тоже не юзер стори. Аналогично про (3) и (4). Юзер стори должна нести какой-то смысл для юзера.
SJA>Собственно вопрос — что не так? Что-то с процессом или с моим восприятием оного?
С процессом все ОК, но вам бы не мешало найти хорошего Product Owner.
SJA>Что можно улучшить?
КЛ>Думаю, что следует осознать, что реализация User Story может занять больше, чем 1 спринт.
Такая ситуация — исключительная редкость.
Я где-то уже писал, если оценка user story вылетает за пределы возможностей оценочного ряда (1-2-4-8-16-32, или Фибоначчи, или какой у вас принят), скорее всего, формулировка юзер стори ошибочна и юзер стори на деле не атомарна.
Если рассматривать проблему выше, то там есть как минимум три вектора разбиения этой фичи (диалог — именно фича, а не юзер стори, потому что диалог решает сразу много юзер сторис) на user stories. Во-первых, можно разбивать по параметрам. Во-вторых, можно разбивать по read/write. В-третьих, если я верно понял, можно разбивать по local/remote servers. Таким образом, вполне естественным будет для начала реализовать диалог, где будет только один-два параметра, причем оба — read-only, взятые с local server. Уже это будет полезно для юзера, и стори будет звучать так: "Как администратор локалхоста, я хочу знать, какие значения параметров XXX и YYY сейчас активны".
SJA>Убогий диалог не уйдёт пользователю. Скорее фичу исключат из релиза или сдвинут релиз. Некоторые уступки конечно происходят, но в одну US это всё равно не укладывается.
Релиз у вас ведь не каждый спринт? Скорее всего, к планируемому релизу у вас будет сделана существенная часть требуемого диалога. Попадёт она в релиз или нет, будет решать продакт менеджмент.
SJA>Т.е. как ни крути — выйдет определённого вида диалог, но он будет оттестирован несколько раз.
И это прекрасно!
Более того, это все следует автоматизировать, и тестировать как можно чаще.
S>Теперь финт ушами: замечаем, что после работы аналитика всё превосходно разбивается на отдельные задачи (причём на каждую есть какое-никакое ТЗ). Приоритеты и планы на большую итерацию есть.
Во всей этой идиллии есть только одно слабое место — тот самый аналитик. Не знаю, как сейчас, но до 2010 в России на эту роль традиционно забивали. Выделяли смешные бюджеты, набирали на них кого попало, и результаты труда аналитиков зачастую попросту игнорировались (вне зависимости от качества). По разным причинам — где-то менеджер "я знаю как лучше, и нечего мне тут свои анализы подсовывать, у меня стопицот лет опыта". Где-то аналитики были недопущены к телу (клиенту, или программистам, или и тем и другим сразу).
Повторюсь, это могло измениться.
Здравствуйте, SkyDance, Вы писали:
SD>Во всей этой идиллии есть только одно слабое место — тот самый аналитик.
Там не только аналитик слабое место, вся команда, от тимлида до qa. Если нет постоянного общения внутри команды и понимания, что "странные вещи" нужны не аналитику, а клиенту, получается полная фигня, вне зависимости от того, аджилят команду или нет.
Я самого начала процесса не застал, но насколько понимаю, в начале был именно что традиционный "тяжелый" процесс, а там без аналитиков никуда.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Недавно перевели процесс на Скрам, в связи с чем у меня проявилось некоторое недовольство. Возможно это просто старческое брюзжание, развейте...
SJA>Ну и в результате, приступая к очередному куску функционала частично ломаются UT и часть уже оттестированного кода, что-то переписывается, что-то дописывается всё это снова перетестируется. Как-то неприятно осознавать, что часть усилий по "вылизыванию" кода и тестов уходит в /dev/null
SJA>Собственно вопрос — что не так? Что-то с процессом или с моим восприятием оного? SJA>Что можно улучшить?
ВСе просто надо убрать все ненужное. И не следовать написанному только потому что так написано.
Фича/ юзер стори/хотелка юзера как не назовите пользователю нужна целиком, либо не нужна. Если вы на гите, то проблем нет. Делается "большая" юзер стори, бьется на технические задачи, исследование, дизайн и так далее, реализуется, тестится девелопером, если все ок фича уходит тестировщику, после функционал мержится и выпускается релиз. Пускать задачи по процессу UserStory — оверхед.
