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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это ты?

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

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

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

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

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

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