Как представить гибкий проект людям, ориентированным на водопад [закрыто]

Нашу команду попросили представить наши усилия по разработке в плане проекта. Никто не недоволен нашей работой или не ставит под сомнение нашу способность доставлять, мы просто участвуем в конкурсе ИТ-проектов для планов проектов. Проблема в том, что мы - гибкая команда и не думали о нашей работе с точки зрения формального плана проекта.

Хотя у нас есть общее представление о том, над чем мы работаем дальше, мы не уверены на 100%, пока не планируем итерацию. До сих пор наша команда в основном работала в вакууме, и от нас не требовалось представлять нашу методологию или показатели сторонним организациям. Мы следуем большинству практик, используемых в экстремальном программировании .

Мы проводим ежеквартальные встречи по планированию, чтобы иметь общее представление об историях, над которыми мы будем работать в течение четверти. Тем не менее, наши истории документированы на картах 3х5 и оцениваются только в начале итерации, в которой они будут работать. После оценки мы документируем историю в Team Foundation Sever . Во время итерации мы прикрепляем код к историям и помечаем истории как завершенные после завершения. Из этих данных мы можем генерировать диаграммы выгорания и скорости. Самое главное, что мы знаем нашу среднюю скорость за итерацию, которая не дает нам откусывать больше, чем мы можем пережевывать.

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

• Гибкий план проекта основан на особенностях
• Agile Project Plan организован в итерации
• План Agile Project имеет разные уровни детализации в зависимости от сроков
• Agile Project Plan принадлежит команде

Умение объяснить различия - это здорово, но как лучше представить данные?

Покажите им наполовину проворный манифест .

Это определенно говорит вам, что представляет собой система Agile , сравнивая ее с методами водопада :

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

Работа программного обеспечения над исчерпывающей документацией,
если это программное обеспечение полно документировано

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

Реагирование на изменения в соответствии с планом
при условии наличия подробного плана для реагирования на изменения и его точного соблюдения

Я должен был сделать это, один раз. Команда хотела сделать Agile, Клиент хотел (и понял Agile), стороннюю стороннюю организацию (называемую их «Аудиторами»), хотел видеть отчеты Waterfall.

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

Не делайте этого, если третье лицо имеет значение и НАСТОЯЩЕМУ заботится, что вы используете водопад . Если Аудиторы знают, что вы Agile, и просто не обновили свои документы, чтобы поддержать вас - тогда вы можете лгать.

Чем ты занимаешься? Ложь , но белая ложь.

• Перефразируйте Особенности, поскольку требование "Должен иметь Функцию".
• Ваша работа выполняется в итерациях, итерации обычно идут в течение X недель, план водопада любит видеть вещи в основном в течение недель, так что нет большой проблемы. Вы можете пометить конец каждой итерации как этап. Вехи водопада. Итерации, как правило, имеют тему (или связанный с ней эпос), поэтому вы можете прикрепить заголовок темы / эпоса к вехе (например, 21/11 Завершить GUI).
• Рассчитайте свою скорость (исходя из графиков выгорания / повышения) и определите, сколько времени в среднем представляет Story Point (по крайней мере, при вашей текущей скорости), это даст вам длительность задачи. Часто дикие неточные, но они будут значимыми до некоторой степени.
• Ваш план имеет разный уровень детализации в зависимости от таймфрейма - в основном это касается водопада. Возможный разный план водопада имеет разные детали в зависимости от аудитории.

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

• Конечно, вы не знаете, что делаете в следующей итерации, но вы примерно знаете, что делаете. У вас есть чувство, и после Итерации все еще грубее. (Я слышал, это называется итерационный радар). Ложь и скажи, что ты делаешь. и когда лежишь сквозь зубы о карточке истории, которой нет на твоем итерационном радаре, и просто кладешь ее куда-нибудь. Надеюсь, вам не нужно отправлять слишком много обновлений о плане проекта, иначе они заметят, что вы не сделали того, о чем говорили.

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

Первый вопрос, который нужно задать: чего на самом деле хочет бизнес? Некоторый бизнес совершенно счастлив видеть гибкие спринты, представленные / разбитые на диаграмму Ганта. Это может не иметь никакого смысла для любого, кто действительно понимает спринты и может регулярно меняться, но это знакомо людям, которые просят об этом. Затем, вместе с диаграммой Ганта, представьте выгрузку и т. Д.

Мы пережили нечто подобное и в конце концов (если Agile работает) он будет продавать себя (если этого не произойдет, то почему вы это делаете?). Люди начинают понимать «усилие» и то, что определенная команда способна «сжечь» 40 очков усилий за 2-недельный спринт, и на самом деле они достаточно хороши в среднем для оценки этих усилий. Как только они увидят преимущества для них, они продадут процесс остальной части бизнеса для вас. Но главное в том, что вы никогда не сможете навязать это кому-либо, поскольку они просто будут сопротивляться.