Проблемы Agile-подхода к государственным проектам

Предыдущее обсуждение 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. Деньги были настолько хороши, что вы знаете, что можете поглотить X новых функций на разных этапах проекта и при этом выйти без потери рубашки, или
2. С самого начала вы даете понять клиенту, что из-за того, что они договариваются о жесткой цене, каждый новый запрос функции будет генерировать заказ на изменение с ценой, которую он должен будет утвердить, с сопровождающим заказом на покупку (или дополнением к первоначальный заказ на покупку), чтобы вы могли это осуществить. В порядке изменения будут указаны любые воздействия на функциональность или график. Если они говорят, что крайний срок не может быть перенесен, тогда заказы на изменение просто экспоненциально дороже по мере продвижения проекта, потому что потом менять вещи дороже.

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

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

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

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

Правительственные учреждения на самом деле медленны, неэффективны. Вы должны писать (и вести переговоры) формальные, подробные заказы на изменения все время.

Обеспечить X функций точно так, как требуется

Пока не изменен порядок изменения.

Запросы о функциях будут отброшены через стену, не беспокойте нас, мы не хотим их слышать.

Каналом связи является порядок изменения. Влияние бюджета и графика.

У клиента нет понятия приоритетности функций, все они важны, иначе мы бы их не просили.

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

Это сложная проблема.

Проект будет стоить не больше и не меньше Y независимо от перерасхода или сроков.

За исключением заказов на изменение. Которые изменяют Y и Крайний срок.

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

«не подлежит обсуждению», как правило, не соответствует действительности. Это предметом переговоров. Просто больно вести переговоры.

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

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

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

Это делает правильно Agile подход сложным.

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

В таком проекте, как этот, они связывают ваши руки по объему, ресурсам и времени. Вам остается только управлять качеством. Так...

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

Так что будьте как можно проворнее:

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

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

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

Обеспечить X функций точно так, как требуется

Мне повезло, если я предоставляю функцию X неопределенно, как предложено, и буду готов изменить ее в любой момент.

Запросы о функциях будут отброшены через стену, не беспокойте нас, мы не хотим их слышать.

Если вы знаете, чего они хотят, иди и построить это.

У клиента нет понятия приоритетности функций, все они важны, иначе мы бы их не просили.

Вы не можете проиграть на этом. Постройте их так, как считаете нужным.

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

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

К сожалению, вы описали типичный взгляд клиента на то, как следует решать программный проект. Это не значит, что клиент неразумен; в конце концов - разве не так можно было бы построить что-нибудь еще (например, дом?). При этом, однако, я не предлагаю ничего больше, чем то, что мы все уже знаем. То, что вы спрашиваете ... возможно ли применение гибкой практики в этой ситуации?

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

1. Фиксированный (в камне, черт возьми).
2. Документ о функциональных требованиях («Библия»). Неудивительно, что неадекватно.
3. Традиционные роли: руководитель проекта, бизнес-аналитик.
4. Слабо вовлеченные бизнес-пользователи (можете ли вы сказать «нет спонсора продукта»?).

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

1. 2 недели итерации;
2. Stand-окна;
3. Ретроспектива;
4. Парное программирование;
5. TDD;
6. Непрерывная интеграция.

Что-нибудь из этого имеет хоть какое-то значение для бизнеса? Нет. От двух месяцев до крайнего срока, тщательно просматриваемые итерации и встречи по планированию заброшены в безумие «без головы».

Ответы, которые другие дали выше, в большей или меньшей степени являются компромиссами. На мой взгляд, когда мы идем на компромисс, гибкое («гибкое» или «гибкое») «совершается» пагубным образом. По моему мнению:

Здесь нет компромисса или гибкости.

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

Когда я начал работать там, где я сейчас, я обнаружил, что задаю тот же вопрос, который вы задавали довольно часто. Есть кое-что, что можно сказать о водопаде с правительственными контрактами. По иронии судьбы, agile теперь стал модным словом для государственных заказчиков (которые реально работают в режиме «водопада»), поэтому теперь нам остается еще сложнее реализовать гибкий процесс с практически негибким клиентом.

У нас есть система, которая была описана как «Scrummerfall», «Agilefall» или «Беспорядок», но во многих отношениях нам постепенно удавалось принять более и более гибкий процесс, так как этот (гигантский) проект продвигался вперед в течение многих лет. , Один из способов, которыми мы это сделали, - это нахождение обратных каналов связи с ПОЛЬЗОВАТЕЛЯМИ нашей системы, в отличие от наших ЗАКАЗЧИКОВ. Наши клиенты - душный отдел, возглавляемый назначенными чиновниками, которые никогда не будут касаться нашего программного обеспечения в своей рабочей жизни и не хотят его понимать. Наши пользователи - это обычные государственные служащие, которые пытаются выполнить важную задачу. Для нас ключом к созданию коммуникационной обратной связи, которая позволила нам быть такими же гибкими, как и мы, была необходимость UAT (User Acceptance Testing).

На раннем этапе нашего проекта было решено, что репрезентативная группа АКТУАЛЬНЫХ ПОЛЬЗОВАТЕЛЕЙ из различных офисов нашего обширного правительственного клиента будет собрана на месте ЗДЕСЬ, и мы проведем пару недель с ними, когда они пройдут серию тестовые сценарии для тестирования нашего программного обеспечения. Неформальная команда разработчиков требований превратила это время в бесценный способ получения отзывов от реальных конечных пользователей. Тем временем, команда тестирования UAT в правительстве работала через свою бюрократию, чтобы оказывать все большее влияние на процесс формальных требований с их стороны, включая заказы на изменения. Конечный результат заключается в том, что такие BA, как я, выступают в качестве независимых владельцев продуктов, встроенных в команды разработчиков, и могут получить бесценное время на встречу с реальными клиентами, что позволяет нам работать очень гибко.

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

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

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