Может ли Agile быть реализован без участия клиента?


23

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

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

Я не прав? Может ли Agile работать без участия клиента? Если да, то как и как вы преодолеваете проблемы, которые я обсуждал?


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

1
По моему опыту, предпочтение подходов с водопадом обычно связано с отсутствием понимания того, как работает программное обеспечение или дизайн. Хорошая новость заключается в том, что Agile - это не большая проблема, это отношение / понимание клиента. Плохая новость - отношение клиента.
Бен Броцка

@BenBrocka: Это не очень удивительно, учитывая, что именно для этого был специально разработан Waterfall. Автор хотел написать статью о том, как может выглядеть процесс разработки, созданный кем-то, кто не понимает разработку программного обеспечения, и почему такой процесс не может работать. Так, он специально изобрел Waterfall в качестве примера процесса, который разработан кем-то, кто не понимает разработку программного обеспечения и который не может работать. Очевидно, что это не удивительно, что это привлекает людей, которые не понимают разработку программного обеспечения, и не является сюрпризом…
Йорг Миттаг

@BenBrocka: ... что это не работает. Что удивительно, так это то, что кому-то даже захочется использовать процесс, специально разработанный для того, чтобы он не работал. Я думаю, что никто не мешает на самом деле читать газету.
Йорг Миттаг

1
@ JörgWMittag Фактическое принятие «Водопада» ( понимают ли они, что это водопад или нет) в основном только потому, что это стандартная модель деловых решений; босс хочет чего-то, подчиненный делает это, клиент счастлив, верно? Конечно, это не работает, но это хорошая простая модель для хороших простых умов :)
Бен Брока

Ответы:


17

Как это могло? Сама природа техники диктует своего рода обратную связь между заказчиком и разработчиком.

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

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

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


5
Однако часть вашей команды может выступать в роли «прокси-клиентов» - по моему опыту, тестеры создали довольно эффективные «прокси-серверы», о которых вы упомянули. Когда я сам был тестером, я иногда притворялся, что носил, так сказать, костюм клиента . У такого прокси есть свои ограничения - например, парень по контролю качества, жалующийся на то, сколько времени требуется для установки продукта, может просто так думать, потому что он делает это ежедневно, в то время как клиент делает это раз в год или два
комнат

it's just a matter of how much they want the rework to cost (the longer it is delayed, the more expensive it is).Кто на самом деле дороже, хотя? Большинство клиентов не видят в этом необходимости платить за ваше время, чтобы получить свое текущее видение решения на месте. Иногда они просто сталкиваются с проблемой и не могут знать, каким должно быть решение, пока вы не скажете им, каким оно будет. В этот момент, если то, что вы им сказали, на самом деле не решает их проблему, то это ВАША ОШИБКА, а не их. Какова их вина, что вы неправильно поняли их настоящие проблемы? продолжение ...
maple_shaft

продолжение ... почему они должны платить за это? Просто чтобы сохранить контакт с клиентом и не полностью упустить любую возможность повторного бизнеса, вам придется развернуться и сделать переделку бесплатно, потому что в первую очередь они требовали контракт с фиксированной ценой. Это более распространенное отношение и именно то, что испытывает P.Brian.Mackey. Клиенты активно поддерживают эти переговоры, и когда вы только один из 100 стартапов, пытающихся выиграть контракт, парню с реалистичным и справедливым контрактом, основанным на Agile, придется подождать позади. Прямо сейчас там тяжело.
maple_shaft

@maple_shaft: Очевидно, вы были сожжены этим. Но, как и во всем, все сводится к выбору. Ловкий существует, потому что у водопада есть свои проблемы, и люди не совершенны. Если клиент был проинформирован о рисках и в любом случае хочет водопад, это его выбор. Это также выбор магазина программного обеспечения, чтобы решить, стоит ли рисковать водопадом для клиента, который не понимает риски или отрицает обоснованность этих рисков.
Роберт Харви

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

7

Краткий ответ на ваш вопрос «нет». Вот комментарии к некоторым частям вашего вопроса. Если быть точным, большинство ответов основаны на моем личном опыте и наблюдениях.

По моему опыту, водопад не работает.

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

Клиенты не знают, чего хотят, пока не увидят.

Это миф Большой тоже. Это может иметь место в дизайне / макете веб-страницы, но для обработки бизнес-данных большинство пользователей хотят что-то, что работает. Некоторые из этих пользователей по-прежнему используют экраны AS / 400 и мониторы 3270 CICS с RGB, и они могут делать свое дело с помощью этих инструментов. Кроме того, те же пользователи принимают системы SAP и ORACLE ERP без какого-либо влияния на дизайн интерфейса (а иногда и на функциональность). Большинство бизнес-пользователей даже адаптируют свои рабочие привычки и процессы, если система производит правильную функцию. Упор здесь на функцию не смотрится. Деловые люди понимают, как они делают свою работу очень хорошо 90% времени.

Дилемма водопада далее распространяется большим сообществом разработчиков, которые хотят иметь все требования заранее. Таким образом, они знают, что строят, могут соответствующим образом спроектировать, и клиент виноват, потому что они «подписали» указанные требования.

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

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


3
+1 - за соперничество "клиенты не знают". Это разные домены разных типов клиентов. Вот почему агилисты не могут понять людей водопада. Они верят, что ты можешь говорить то, что хочешь, только когда видишь это. Это не правда, но это все, что они видят от своих клиентов. Сторонники водопада не могут понять, почему вы не можете понять подавляющее большинство требований заранее, чтобы дизайн мог учесть все проблемы. Вероятно, потому, что люди, работающие в водопаде, не слишком много общаются с волей-неволей.
Данк

1
@ Данк, спасибо за ваш комментарий. Мне нравится ваша формулировка "волей-неволей клиентов"!
NoChance

2

Они не хотят тратить время и, если им будет предоставлен выбор, они предпочтут получить программное обеспечение бесплатно, но вы все равно будете брать с них плату, верно? Это размыто, если вы разрабатываете программное обеспечение для своей компании. Они считают, что ИТ-отдел был куплен и оплачен (наемные работники), поэтому они могут получить от вас столько работы, сколько смогут.

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

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

В какой-то момент вы должны сказать им, что не думаете, что водопад сработает. Спросите их, удовлетворены ли они этим подходом, и если да, то почему у них не последний парень, который сделал этот проект?


2

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


2
Разве это не вопрос количества и частоты участия клиента, а не вопрос всех или ничего?
JeffO

3
Клиент, который часто отказывается участвовать, на мой взгляд, нуждается в образовании. Для бизнес-экспертов клиента нет ничего необычного в том, что им приходится взаимодействовать с компанией-разработчиком программного обеспечения и при этом выполнять свои повседневные обязанности, и это необходимо решить, поговорив с их руководителями.
Otávio Décio

2

Я думаю, что одним из главных преимуществ Agile является возможность получить более подробные требования для каждой функции в целом. Когда клиент предоставляет все свои требования заранее, каждая функция имеет тенденцию быть расплывчатой ​​идеей с определенной долей функциональности. Agile заставляет клиента пересмотреть каждую функцию и сосредоточиться на том, чего именно они хотят, и на том, как эта функция будет вписываться в общую картину. Чтобы получить такое же количество деталей (достаточно деталей для реализации функций) в спецификации, водопад действительно требует, чтобы вы сделали одну из двух вещей:

  1. Угадай. Реализуйте, пока не столкнетесь с чем-то расплывчатым, а затем примите решение о том, как, по вашему мнению, эту функцию лучше всего реализовать. Это, очевидно, не идеально, так как приводит к «Подождите, это не то, что я просил!» сценарий.

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

  3. Возьмите недоделанную спецификацию, но все равно попросите разъяснений. Работайте, пока не дойдете до расплывчатой ​​части спецификации, затем попросите клиента уточнить. Конечно, это не то, о чем просил клиент, но если он не хочет, чтобы приложение было таким же мутным, как спецификация, и отказывается определять спецификацию заранее, это единственный оставшийся вариант. Он не обладает всеми преимуществами Agile (такими как регулярное одобрение клиентов, чтобы убедиться, что все находятся на одной странице), однако он позволяет вам получать информацию, необходимую для разработки. Поскольку вариант 1, вероятно, оставит вас с продуктом ниже номинала, вариант 2 расточителен и разочаровывает клиента (вам, вероятно, придется потратить как минимум вдвое больше времени на разработку дизайна и сборку спецификаций в целом, если вы делаете это полностью заранее), это действительно не такой плохой вариант. Ключевым моментом здесь должно быть усердие в изменении сроков и цены с каждым возникающим изменением. Если вы все сделаете правильно, вы можете обнаружить, что большинство методов Agile совместимы с этим соглашением, даже если клиент не знает об этом. ИМХО, это действительно соответствует духу Agile, так как вы должны адаптировать методологии к вашему конкретному соглашению.

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


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

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

Ваш вариант 4 - именно то, что я намеревался описать в варианте 3.
Морган Херлокер,

Как я могу сделать свой ответ лучше? Я не могу сказать, согласны ли вы или не согласны с тем, что я говорю.
Морган Херлокер

Вы можете улучшить его, возможно, убрав слово «недоделанный» для начинающих. Удалить часть об этом не то, что хотел клиент. Удалите мутную спецификацию и т. Д. В водопаде важной частью определения требований является получение архитектурно значимых и тех, которые система должна сделать, чтобы быть полезной сразу. После этого изменения обычно не так уж важны. Верьте или нет, есть и всегда были итерации, будь то формальные или неформальные в развитии водопада. Задолго до того, как появился agile.
Данк

1

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

Но в какой-то момент вам нужно будет показать программное обеспечение «настоящему» клиенту ...


0

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


0

Agile требует узкой петли, чтобы заменить большой дизайн, который сложен - довольно сложен, но на самом деле это можно сделать, Agile - не единственный способ.

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

Все эти процессы были сделаны умными людьми - и умные люди могут заставить любой процесс работать. Вы не думаете, что водопад был изобретен, потому что он никогда не работал ни для кого, не так ли? Он развивался потому, что некоторые люди могли заставить его работать, а другие смотрели на него и говорили: «Я должен улучшить это и передать это МОЕЙ команде, которая, кажется, не может производить так же эффективно» - на тот момент это, вероятно, работало лучше, чем они делали, но если вы не понимаете, что не каждый программист может решить каждую проблему, это может сбить вас с толку, почему две команды, использующие один и тот же процесс, могут иметь разные результаты.

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

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


0

Определите клиента.

Это другая компания? Другой человек?

Это другая команда в вашей компании?

Является ли продукт чемпионом в вашей компании?

Это ты?

Все вышеперечисленное возможно и вполне разумно в зависимости от обстоятельств. Вы не хотите взглянуть вниз по туннелю о том, что значит быть гибким, поэтому сказать, что категорическое НЕТ было бы неправильно. ДА, с другой стороны, требует немного латерального мышления.

Подумайте о слове Agile на мгновение. Очень умная группа людей, придумавших этот термин, не могла бы выбрать лучшую метафору для концепции, которую они пытались описать. Когда вы говорите, ловкость , что приходит на ум? Быть флотом ног? Быстро реагировать что ли? Быстро адаптироваться?

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

Я являюсь заказчиком всех намерений и целей моих сольных проектов. Иногда я даже ношу настоящую шляпу, когда я действительно хочу внести особые умственные изменения в мою роль клиента . Это делает меня не менее проворным, чем когда я на работе. Для меня все равно, мой кот может быть менеджером, Он следит за тем, чтобы я делал перерыв на отдых, и напоминает мне, чтобы я не был слишком одержим какой-либо одной задачей. Вы можете предпочесть использовать свою «Технику Помадоро», но я предпочитаю Таймер «Мошенник» !! Дело в том, что я работаю в строго Agile-процессе, когда пишу код для себя. Я не хакерский тип ковбоя, который живет бесконечными скачками развития и ничего не делает. Мне нравится создавать свое программное обеспечение, планировать разработку вокруг моей работы и личной жизни, и завершать его так, как я ожидал бы, если бы работал на реального клиента. Когда что-то мешает моему графику, я соответствующим образом корректирую и расставляю приоритеты в работе над проектом. Я использую все стандартные Agile практики и приемы, которые я могу применять в одиночку, и я «доставляю» рабочий код для себя (или друга или коллеги для тестирования) так часто, как я могу. Если все это не Agile, я спрашиваю вас, что это?

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

Тем не менее, если вы работаете в дисциплинированной манере, строго придерживаясь своей методологии выбора, и применяете Agile-методы, и если вас отвлекают, или вы передумаете (надев шляпу клиента) и свой дизайн продукта или направление Если вы можете адаптировать свой график и скорректировать свои приоритеты так, как вы себе представляете, ваш клиент будет ожидать от вас, тогда вы будете Agile.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.