Предыдущее обсуждение Agile здесь содержало хорошие ответы, в которых указывалось, что имеет решающее значение для успеха внедрения Agile-методологии в разработке программного обеспечения. Большинство моментов были типичными организационными и управленческими проблемами, но меня беспокоит одно: клиент должен быть вовлечен в процесс.
Клиент - это единственная вещь, которую вы не можете реально контролировать, возможно, ваша бизнес-модель направляет вас на работу по контракту, например, когда очень строгий контракт обязывает компанию:
Обеспечить X функций точно так, как требуется
Запросы о функциях будут отброшены через стену, не беспокойте нас, мы не хотим их слышать.
У клиента нет понятия приоритетности функций, все они важны, иначе мы бы их не просили.
Проект будет стоить не больше и не меньше Y независимо от перерасхода или сроков.
Абсолютный, строгий, окончательный и не подлежащий обсуждению крайний срок для полной сдачи всех работ.
Мы никогда не работали с таким клиентом раньше, но деньги на проект слишком хорошие, чтобы их упустить. Нам нужна эта работа.
Я пришел сюда и работал с HARD, чтобы изменить процессы внутри, чтобы перейти к гибкой разработке, и здесь я не знаю, как согласовать, где этот проект вписывается в наш новый процесс. У меня никогда раньше не было такой роскоши, как непредубежденное управление, которое бы доверяло мне руководить командой разработчиков и обрабатывать этот путь, и теперь, когда мы здесь, я не могу честно сказать себе, что этот проект действительно будет выполнен в Проворный способ. Я чувствую, что руководство доверило мне руководство этим путем и что я подвела их, потому что ситуация, в которой мы сейчас находимся, явно требует Водопада. Я боюсь, что я могу потерять их доверие, если я отступлю сейчас.
Другие ответы, такие как здесь, говорят, что Agile невозможен с таким клиентом, вы согласны? Кто-нибудь из вас был в подобной ситуации и заставил ее работать? Какие стратегии вы реализовали, чтобы Agile успешно прошел?
источник
Ответы:
Я думаю, что первое, что нужно осознать, - это то, что между гибкостью и гибкостью есть разница. Медленно внедряемые гибкие методы и характеристики - кросс-функциональные группы, адаптивное планирование, эволюционные / инкрементальные поставки, временные итерации и даже представление концепций из Lean сильно отличаются от внедрения Extreme Programming, Scrum или Crystal.
Вы прямо упоминаете участие клиентов. Да, многие из Agile методологий требуют участия клиентов, но это не обязательно, чтобы быть гибким. В каждой правительственной / оборонной программе у меня всегда был менеджер программы или проекта, который был контактным лицом с заказчиком. Этот человек становится «голосом клиента». Это может замедлиться, когда они проводят телеконференции, отправляют электронные письма, звонят и уточняют, но у вас может быть один человек (или группа, если у вас также есть заместители руководителя), который является представителем клиентов вашей команды. По общему признанию, это не совсем то же самое. Но разве не быть гибким в том, чтобы быть гибким и реагировать на изменения?
Вы также упомянули несколько ключевых понятий: предопределенные требования, наличие запросов функций, «выброшенных за стену», отсутствие расстановки приоритетов, потому что «они все важны», и проекты с фиксированной стоимостью и / или с фиксированным графиком. К каждому из них можно обратиться по-разному.
Если вы думаете, что у вас есть все ваши требования заранее, скорее всего, у вас нет. Требования меняются. Только то, что у вас есть «законченная и подписанная» спецификация, не означает, что она установлена в камне. В зависимости от того, какой документ требований у вас есть, запишите их, как вам удобно и / или так, как указано в контракте, и предоставьте требования, дизайн и архитектуру. Кроме того, посмотрите, можете ли вы относиться к этим живым документам (проектный документ, который я видел сегодня на работе, помечен как Revision G, что означает, что он находится в восьмом обновлении). Спросите о том, сколько вы можете оставить как TBD в любой данной итерации, и сколько нужно укрепить сейчас - может быть, что-то получится.
Будьте проворны с вашей документацией. Не дублируйте усилия между «тем, что хочет ваша команда» и «тем, что хочет клиент». Например, если вашему клиенту нужна традиционная спецификация требований к программному обеспечению, а ваша команда хочет использовать пользовательские истории, попробуйте адаптироваться к традиционной SRS и использовать элементы действий и скользящий список элементов вместо пользовательских историй, чтобы не тратить время формулировка как «система должна ...» и «должна быть в состоянии, потому что». Это требует дисциплины со стороны команды, чтобы адаптироваться к различиям между проектами. Захват проблем в отражениях.
Как только вы приступите к разработке, вы можете выполнить 5 или 6 итераций, а затем пригласить своего клиента на ваше предприятие, чтобы увидеть подмножество вашей реализации. Сполосните и повторите этот процесс. Это не постоянное участие, требуемое некоторыми методологиями, но у вас есть преимущество высокой видимости. Если ваш клиент говорит нет, по крайней мере, вы пытались. Если они скажут «да», вы можете просветить их, будучи гибкими. В одном проекте, который я принимал, клиент посещал сайт каждые несколько месяцев (обычно 3-5 месяцев). Они наблюдали за тем, как мы проходим тестирование качества, обсуждали проблемы с инженерами и бизнес с офисом программы / проекта. Для всех это была возможность попасть на одну и ту же страницу.
Тестирование и обслуживание происходят так же, как и в других гибких проектах. Создайте процедуры тестирования и документируйте дефекты соответствующим образом, отслеживайте показатели по контрактным обязательствам и документируйте результаты тестирования. Если вы хотите следовать TDD, пойти на это. Непрерывная интеграция - еще одна хорошая идея. Во время совещаний по статусу проекта ваш менеджер проекта может использовать эту информацию, чтобы сказать: «Мы выполнили N требований, прошли M тестов, X тестов пройдены», а также сообщить о состоянии и статусе проекта людям, у которых есть деньги.
Говоря о деньгах, у нас есть проблема с фиксированной стоимостью и / или с фиксированным графиком.
Работа с фиксированным графиком довольно проста. Учитывая ваши требования, вы знаете, сколько итераций вы можете выполнить. Ваша рабочая нагрузка для каждой итерации в значительной степени определяется возможностями реализации, тестирования и интеграции. Это может быть сложно, но не исключено, что можно разбить функции и заранее назначить их для итераций. Это восходит к моей мысли о приглашении клиента - если у вас есть один год и вы используете двухнедельную итерацию, возможно, приглашайте клиента ежеквартально (и приглашайте его каждый квартал) и показывайте ему результаты предыдущей работы. Пусть они увидят ваши приоритеты требований, ваши планы на будущее и как вы планируете.
Работа с фиксированным бюджетом аналогична. Вы знаете, сколько у вас есть времени, сколько ресурсов у вас есть для проекта, сколько они стоят и, следовательно, сколько часов каждый может работать за одну итерацию. Это просто вопрос того, чтобы все внимательно следили за этим. Если ваша компания может съесть расходы на сверхурочную работу, сделайте это. В противном случае, убедитесь, что все работают в надлежащее время, и используйте хорошие навыки управления временем и временные рамки, чтобы сохранить продуктивность каждого. Более продуктивные часы - это то, что вам нужно для снижения затрат - предоставьте больше документов и программного обеспечения с добавленной стоимостью без затрат на совещания и накладные расходы.
В конечном счете, речь идет не обязательно о том, чтобы быть гибким, а о том, что делает Agile хорошим и проворным. Уметь реагировать на изменения в требованиях, иметь возможность поставлять частое программное обеспечение, даже если заказчик этого не хочет, только создавать дополнительную документацию (вместе с тем, что вы обязаны по контракту), и так далее.
источник
Да, agile не подходит для такого проекта, потому что кажется, что требования уже выполнены и зафиксированы в камне, вероятно, в результате многолетнего анализа дорогими консультантами, заседаний комитетов и политического компромисса. Водопад работает хорошо, если клиент настолько дисциплинирован, что может в письменной форме сказать вам, чего он хочет. Они могут ошибаться, но, по крайней мере, у вас есть это в письменной форме, и вы получите оплату, если доставите это. (Конечно, это ничего не говорит об удовлетворенности клиентов. Скорее всего, вы доставите то, что им на самом деле не нужно.)
Agile был создан для решения проблемы, которой у вас нет: риск из-за неопределенности в требованиях.
Это правда, что клиент может запросить изменения, но вы можете выбрать один из двух способов:
В ситуации № 1 отношения кажутся более дружелюбными, но на самом деле довольно редко можно встретить отделы закупок, которые не будут снижать цены, поэтому большую часть времени вы находитесь в ситуации № 2. Это означает, что отношения носят конфронтационный характер, но если вы хотите выжить в бизнесе, вы должны научиться управлять отношениями, сохраняя при этом свои позиции. Это большая часть работы менеджера проекта.
Похоже, вы находитесь в ситуации № 1, и это хорошо. Я полагаю, что государственные контракты - единственное место, где им нет дела до денег, потому что, в конце концов, они не тратят свои деньги, они тратят ваши деньги.
источник
Первый. Это строгое Но это не негибко. Это просто требует внимания к деталям и длинной, длинной цепочке заказов на изменения.
Правительственные учреждения на самом деле медленны, неэффективны. Вы должны писать (и вести переговоры) формальные, подробные заказы на изменения все время.
Пока не изменен порядок изменения.
Каналом связи является порядок изменения. Влияние бюджета и графика.
Это трудно обойти. Даже негосударственные предприятия, которые тратят много денег на «анализ требований», не хотят, чтобы им говорили, что большая, плоская, парящая куча требований, не обремененная приоритетами и информацией о компромиссах, является неполной. Они заплатили хорошие деньги, чтобы получить все требования. Как вы можете получить больше информации?
Это сложная проблема.
За исключением заказов на изменение. Которые изменяют Y и Крайний срок.
«не подлежит обсуждению», как правило, не соответствует действительности. Это предметом переговоров. Просто больно вести переговоры.
Важной частью переговоров с государственными органами является тот факт, что вам нужны «доказательства на уровне адвоката» для изменения стоимости и графика. Несколько осторожных технических презентаций с красивым слайдом в формате PowerPoint не являются «доказательством». Вам нужно много документации, чтобы сделать ваше дело.
Правительственные люди должны предоставить безупречные доказательства того, что они сделали все, что в их силах, чтобы сделать это как можно дешевле и эффективнее. Они знают, что каждое решение воспроизводится в публичной прессе и тщательно анализируется задним числом.
Сложность разработки программного обеспечения и послеполуденный аспект работы правительства в понедельник утром заставляют их неохотно вносить изменения в контракт без явных доказательств.
Это делает правильно Agile подход сложным.
«Индивидуумы и взаимодействия над процессами и инструментами» - это жестко. Вы работаете не с отдельным человеком, а с представителем правительства, чья работа ограничена процессом.
источник
В таком проекте, как этот, они связывают ваши руки по объему, ресурсам и времени. Вам остается только управлять качеством. Так...
Вы не получите большую выгоду от гибкого подхода, который вы могли бы использовать в противном случае, но вы можете сделать все возможное, чтобы снизить риски, связанные с качеством, и иметь возможность информировать клиента о проблемах раньше, чем позже.
Так что будьте как можно проворнее:
Если вы начнете работать в сжатые сроки, вы сможете показать, что сделано, и, возможно, в этот момент клиент, зная, что он не получит все, будет расставлять приоритеты достаточно, чтобы сказать вам, чего он хочет. Вы также должны выполнить самые рискованные действия, а это означает, что задачи, выполняемые в установленные сроки, легче всего вложить в дополнительные часы работы.
источник
Я думаю, что этот тип клиента не является нормой. Вы имеете дело с группой, которая ранее запрашивала подобные проекты, поэтому они точно знают, чего хотят. Вы никогда не говорите, что их характеристики будут меняться.
Мне повезло, если я предоставляю функцию X неопределенно, как предложено, и буду готов изменить ее в любой момент.
Если вы знаете, чего они хотят, иди и построить это.
Вы не можете проиграть на этом. Постройте их так, как считаете нужным.
Это сложно, если вы никогда не создавали проект для правительства. Если у вас есть история, вы можете определить, можете ли вы доставить. Это не значит, что они плохо платят (они печально известны тем, что платят 50 долларов за молоток 10 долларов) или имеют необоснованные ожидания. С этими спецификациями кто-то из вашей команды должен выступить в роли заказчика и одобрить работу по сравнению со спецификациями. Даже если вы нашли недостаток и попросили их изменить требования, они, вероятно, не будут.
источник
К сожалению, вы описали типичный взгляд клиента на то, как следует решать программный проект. Это не значит, что клиент неразумен; в конце концов - разве не так можно было бы построить что-нибудь еще (например, дом?). При этом, однако, я не предлагаю ничего больше, чем то, что мы все уже знаем. То, что вы спрашиваете ... возможно ли применение гибкой практики в этой ситуации?
У меня есть преимущество в том, что я только что закончил проект, который во многом похож на ситуацию, которую вы описываете, т.е.
... и, конечно, дальновидная команда разработчиков пытается работать гибко, несмотря на вышесказанное:
Что-нибудь из этого имеет хоть какое-то значение для бизнеса? Нет. От двух месяцев до крайнего срока, тщательно просматриваемые итерации и встречи по планированию заброшены в безумие «без головы».
Ответы, которые другие дали выше, в большей или меньшей степени являются компромиссами. На мой взгляд, когда мы идем на компромисс, гибкое («гибкое» или «гибкое») «совершается» пагубным образом. По моему мнению:
Здесь нет компромисса или гибкости.
Сам дух проворства заключается в том, чтобы идти в погоню, убирать отходы, быть предельно честным с самим собой. В настоящее время хорошо задокументирован и неоспорим тот факт, что оценка программного обеспечения в больших проектах - в лучшем случае, игра на деньги. Разве мы не обязаны как профессионалы в области программного обеспечения обучать потенциальных клиентов этому? Если клиенты не хотят признавать, что мы являемся экспертами, разве это не наша профессиональная обязанность уходить?
источник
Когда я начал работать там, где я сейчас, я обнаружил, что задаю тот же вопрос, который вы задавали довольно часто. Есть кое-что, что можно сказать о водопаде с правительственными контрактами. По иронии судьбы, agile теперь стал модным словом для государственных заказчиков (которые реально работают в режиме «водопада»), поэтому теперь нам остается еще сложнее реализовать гибкий процесс с практически негибким клиентом.
У нас есть система, которая была описана как «Scrummerfall», «Agilefall» или «Беспорядок», но во многих отношениях нам постепенно удавалось принять более и более гибкий процесс, так как этот (гигантский) проект продвигался вперед в течение многих лет. , Один из способов, которыми мы это сделали, - это нахождение обратных каналов связи с ПОЛЬЗОВАТЕЛЯМИ нашей системы, в отличие от наших ЗАКАЗЧИКОВ. Наши клиенты - душный отдел, возглавляемый назначенными чиновниками, которые никогда не будут касаться нашего программного обеспечения в своей рабочей жизни и не хотят его понимать. Наши пользователи - это обычные государственные служащие, которые пытаются выполнить важную задачу. Для нас ключом к созданию коммуникационной обратной связи, которая позволила нам быть такими же гибкими, как и мы, была необходимость UAT (User Acceptance Testing).
На раннем этапе нашего проекта было решено, что репрезентативная группа АКТУАЛЬНЫХ ПОЛЬЗОВАТЕЛЕЙ из различных офисов нашего обширного правительственного клиента будет собрана на месте ЗДЕСЬ, и мы проведем пару недель с ними, когда они пройдут серию тестовые сценарии для тестирования нашего программного обеспечения. Неформальная команда разработчиков требований превратила это время в бесценный способ получения отзывов от реальных конечных пользователей. Тем временем, команда тестирования UAT в правительстве работала через свою бюрократию, чтобы оказывать все большее влияние на процесс формальных требований с их стороны, включая заказы на изменения. Конечный результат заключается в том, что такие BA, как я, выступают в качестве независимых владельцев продуктов, встроенных в команды разработчиков, и могут получить бесценное время на встречу с реальными клиентами, что позволяет нам работать очень гибко.
Очевидно, что есть много проблем, и мы все еще не очень гибки, но мы достаточно проворны, чтобы быть примером для крупного гибкого проекта, фактически использующего эту методологию в секторе государственных контрактов.
Подводя итог: используйте свой опыт в качестве гибкого евангелиста в своей организации, чтобы проникнуть в вашего клиента. Пройдите вместе с ними учебный процесс, установите партнерские отношения, основанные на доверии с ключевыми людьми на их стороне, и работайте вокруг формального, окостеневшего процесса требований, который у них неизбежно возникнет. Вам будут благодарны ребята на местах, которые должны реально использовать то, что вы разрабатываете!
источник
Вы предполагаете, что требования хорошо написаны, и вы думаете, что они имеют в виду то, что они думают, что они имеют в виду. Обратный ход гибкого процесса поможет гарантировать, что они получают то, что имели в виду, в дополнение к тому, что они просили.
источник