Как работать с клиентами и итерациями в Agile team?[закрыто]

Question

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

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

Что делать на первой итерации?

Что, как правило, делать на первых нескольких итерациях, если мы начнем с нуля?Просто потратить месяц на разработку ядра кода приложения или начать с простых wire-фреймов с ограниченной предварительно закодированной функциональностью?Что обычно хотят видеть клиенты?Блестящие вещи, которые не работают, или уродливые вещи, которые работают?

Как общаться с клиентами?

Наша первоначальная мысль заключалась в том, чтобы настроить процесс примерно так:

альтернативный текст http://img690.imageshack.us/img690/2553/communication.png

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

---

Любые мысли приветствуются!Заранее благодарю.

Answer 1

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

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

Что касается общения с клиентами, я думаю, что ваш график должен быть немного скорректирован.Говоря в терминах scrum, ваш "координатор" называется "владелец продукта".Наличие одного человека, координирующего работу с клиентами, - это хорошо, поскольку может потребоваться довольно много времени, чтобы различные заинтересованные стороны пришли к согласию относительно потребностей.Однако владелец продукта (или координатор) должен находиться в прямом контакте с разработчиком, минуя менеджера проекта.На самом деле, у владельца продукта и руководителя проекта совершенно разные роли, которые многое выигрывают, будучи разделенными на двух человек.

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

Answer 2

Я бы согласился с ответом Андерса.Мое еще одно наблюдение заключается в том, что многие клиенты считают невозможным игнорировать Некрасивое.Они больше заботятся о презентации, чем о функционировании.Следовательно, вам, возможно, придется стиснуть зубы и сделать хотя бы один "Приятный" экран, чтобы показать, что вы будете обращать внимание на детали презентации.

Answer 3

Что, как правило, делать на первых нескольких итерациях, если мы начнем с нуля?

Многие команды используют Нулевая итерация Для:

• настройка инфраструктуры разработки (система управления версиями, компьютеры разработки, автоматизированная сборка, процесс непрерывной интеграции, среда тестирования и т.д.),
• обучите заказчика и согласуйте с ним методологию,
• создайте первоначальный список функций, определите наиболее важные и проведите первоначальную оценку,
• определите время проведения собраний (совещание по планированию, демонстрация, ретроспектива), выберите продолжительность итерации.

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

Просто потратить месяц на разработку ядра кода приложения или начать с простых wire-фреймов с ограниченной предварительно закодированной функциональностью?

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

Что обычно хотят видеть клиенты?Блестящие вещи, которые не работают, или уродливые вещи, которые работают?

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

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

Вам нужно один лицо, представляющее интересы клиентов (которое называется Владелец продукта в Scrum):

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

Answer 4

Agile, как правило, стремится быстро предоставить клиенту что-то ценное.

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

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

Я бы сделал свои итерации как можно короче (ваши 2 недели могли бы сработать, я предлагаю рассмотреть возможность 1 недели). Если вы абсолютно не можете разместить свою команду разработчиков и своих клиентов вместе, я предлагаю провести встречу вместо телефонного разговора с клиентами.Продемонстрируйте, что вы сделали на предыдущей итерации, и запросите обратную связь о том, что должно остаться, что должно измениться и что следует добавить.

Как уже говорили другие, ваш "Координатор" звучит как Владелец продукта.Что меня беспокоит в вашем рисунке, так это то, подразумевает ли он, что разработчики не взаимодействуют с заказчиком или клиентами.Одна вещь, которая делает гибкую работу эффективной, - это когда есть много общения.Общение с командой разработчиков всегда фильтруется через менеджера проекта, что почти наверняка приведет к недопониманию, ненужной работе и упущенным деталям.

Answer 5

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

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

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

Ваше здоровье