Являются ли фиксированные даты поставки элементов «гибким» способом работы?

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

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

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

Это справедливое суждение или я слишком остро реагирую на этот план !?

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

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

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

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

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

Давайте пройдемся по различным пунктам здесь:

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

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

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

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

ни одна из них не была оценена командой разработчиков.

Так как же руководство знает , что этот план является жизнеспособным на всех ? В Agile работа - это переговоры. Бизнес говорит: нам бы этого хотелось. Инженерное дело говорит: ладно, при условии XYZ, это займет 3 недели. В том, что вы описываете, нет сотрудничества с клиентами. Нет лиц и взаимодействий.

Мне кажется, что старшие заинтересованные стороны не купились на Agile, и поэтому мы обречены на провал в реализации этого на более низком уровне.

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

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

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

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

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

Если вы можете заставить команду разработчиков представить единый фронт, вы действительно должны отодвинуться и придерживаться линии качества. Мой опыт показывает, что руководители проектов склонны думать, что программные продукты линейны. Таким образом, каждый период X будет производить Y 'precentage complete'. То есть, если вы не «завершены на 50%» в середине разрешенного времени, клаксоны начинают мигать. В действительности, если вы все делаете правильно, первая функция имеет тенденцию занимать намного больше времени, чем 50-я функция (аналогичного размера). Если вы сможете пройти через этот начальный период опасного кризиса («что происходит?», «Я не знаю») ничего не получится! ") вы, вероятно, будете в порядке.

Добро пожаловать в реальный бизнес.

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

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

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

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

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

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

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

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

Agile не мешает вам планировать этапы (например, мы выпустим V 1.0 через 3 месяца), но то, что входит в каждый этап, не может быть исправлено.

Я думаю, как вы должны реагировать, зависит от характера проекта. Если проект направит человека на Луну ко второму кварталу 2017 года, все согласятся, что он обречен на провал. Если вы думаете, что сможете предоставить MVP к концу второго квартала 2017 года, вам нужно работать над этим спринтом за спринтом.

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

КАЖДЫЙ бизнес релевантный проект имеет ограничения:

• Время
• Ресурсы
• Ожидаемый минимальный набор функций

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

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

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

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

Как уже указывал кто-то, прежде чем манифест говорит:

Индивидуумы и взаимодействия над процессом

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

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

Это тот момент, когда это может пойти двумя путями.

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

2. Они могут все еще хотеть придерживаться своей собственной версии против коллективного мнения команды.

Если результат # 2, то это не Agile.

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

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

Каким бы ни был ваш ответ, вы ошибаетесь. Вот и все.

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

Кстати, если вы (как команда) принимаете эти даты, вы ошибаетесь.

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

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

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

Его не планируют, нет.

Но если вы притворяетесь, вы не знаете план и просто работаете спринт за спринтом. Это может быть просто работа.

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

Если вы работали гибко, то план Б, мы надеемся, является демонстрацией последнего спринта.