Внедрение гибкой разработки после традиционного начала проекта

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

Теперь мне было поручено сделать команду более гибкой, и я был уверен, что у меня есть полный бай-ин от разработчиков и бизнес-команды. В качестве пилотной программы они дали мне проект, который только что завершил 15-месячный сбор требований, имеет 110-страничный документ «Анализ и дизайн» (который должен рассматриваться как «написанный в камне»), и где у меня нет доступа к концу пользователи (только для комитета, состоящего из менеджеров пользователей, которые фактически не будут использовать продукт).

Я начал с малого, предоставив им список ожидаемых результатов для первых 5 спринтов (оставляя будущие спринты неопределенными), список целей для первого спринта, и я проанализировал документ A & D, чтобы получить достаточно пользовательских историй, чтобы соответствовать целям первого спринта. ,

С тех пор они спросили, почему у нас нет всех требований для всех спринтов, почему я не начал работать над вещами для третьего спринта (который они считают более важным, но основан на результатах первого 2 спринта) и требуют еще больше документации, которую вся моя ИТ-команда считает занятой работой или не связанной с нами (например, написание руководства пользователя заранее, документирование всех полей данных со всех спринтов заранее и т. Д.) «прямая» работа).

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

Итак, мои вопросы:

1. Что я могу сделать, чтобы более эффективно внедрять изменения в устойчивый бизнес?
2. Существуют ли другие методы, которые я могу внедрить на стороне ИТ, чтобы помочь бизнесу показать преимущества Agile?
3. Бремя документации душит нас - бизнес по-прежнему рассматривает его как стратегию управления рисками, а не как риск. Что мы можем сделать, чтобы облегчить их проблемы и требования к документации (в частности, количество документации и их потребность во всем этом заранее)?
4. Мы находимся в отдельном здании от нашего бизнеса, примерно в 3 кварталах, и они отказываются привлекать своих людей к совместной работе над проектом, поскольку этот человек "не сможет работать над другими своими проектами, пока они в нашем здание." Они ожидают, что мы всегда пойдем туда и свяжем наши вопросы, чтобы мы могли задать их всем сразу, а не тратить время этого человека на «постоянные перерывы». Что мы можем сделать, чтобы получить от них больше информации?

Любые дополнительные советы также будут оценены.

Спасибо!

Я был уверен, что у меня есть полный бай-ин от разработчиков и бизнес-команды [...] У меня нет доступа к конечным пользователям [...]

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

Мой лучший совет для вас - вообще отложить ярлык «Agile». Забаньте слово из разговора, насколько это возможно. Вместо этого сосредоточьтесь на следующих вещах:

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

«Делать команду более гибкой» - недостижимая цель. Это не достаточно конкретно, это не измеримо, у него нет конечного условия. То, что вам нужно, - это что-то конкретное: цель, выраженная в X процентах меньшего количества дефектов или Y проценте фактически поставленных вами дат поставки к Z дате.

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

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

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

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

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

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

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

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

Что касается вашего второго вопроса, я настоятельно рекомендую вам приносить по одной вещи за раз.

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

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

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

Since then, they've asked why we don't have all the requirements for all the sprints, why I haven't started working on stuff for the third sprint (which they consider more important but is based off of the deliverables of the first 2 sprints) and are pressing for even more documentation that my entire IT team considers busy-work or un-related to us (such as writing the user manual up-front, documenting all the data fields from all the sprints up front, and more "up-front" work).

Это твоя проблема. Они этого не понимают. Кто-то не может попросить вас быть более проворным и не желать отправиться в поездку. У них неправильные ожидания. Вещи сломаны, прежде чем вы даже начнете. Исправьте ожидания или у вас ничего не получится. Это как если бы я попросил вас проехать 150 миль в час, и я дал вам Chevette, чтобы сделать это.

Определите время / ресурс / стоимость документации, которую они хотят, и дайте им понять, как далеко она продвигает график.

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