Что значит быть проворным?

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

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

Разработчики почти не разговаривали друг с другом, и в разработке не было никакого TDD. Фактически, у большинства разработчиков была спецификация в начале, и они продолжали заниматься ею в течение 2 или 3 недель, для которых был организован спринт. С клиентом / держателем кола почти не было общения.

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

Итак, мой вопрос: где мы ошиблись и как я могу предотвратить то, что команда допустила те же ошибки?

То, что вы описываете, не Agile по определению (Agile Manifesto), это Waterfall с ежедневными статусными встречами. Agile означает легкую адаптацию к изменениям, если нет никакого интерактивного цикла обратной связи с владельцем продукта и, следовательно, с клиентами, то какие изменения происходят?

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

Похоже, ваше руководство делает «SCRUM, но ...», где «но» - это то, где они выбрасывают все SCRUM-вещи, с которыми они не понимают или не соглашаются, и просто делают вещи так же, как всегда, но случайный водопад, но с новыми блестящими модными именами ко всему этому.

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

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

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

Джаррод дал хороший ответ (+1 к этому), и я хотел бы немного остановиться на этом.

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

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

Другой вариант - вместо того, чтобы навязывать команде другой процесс и заставлять всех следовать тому, что вам скажет Скрам, попробовать гибкий подход : общаться с командой и посмотреть, сможете ли вы вместе определить проблемные области и решения для каждой из них. Затем постепенно вносите изменения в работу, чтобы решать проблемы.

Это может занять некоторое время, но ...

1. Сначала вы исправите самые большие проблемы, которые окажут наибольшее влияние на способность вашей команды предоставлять продукт.
2. Выявляя насущные проблемы и участвуя в поиске решений, члены вашей команды поймут, почему определенные практики важны, и не будут просто выполнять их, потому что им предписано их выполнять.

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

Ключ к пониманию заключается в том, что Agile - это не создание нового процесса для действий; речь идет о постоянных изменениях и постоянной адаптации к существующим процессам / практикам.

если команда (и ее руководство) действительно хотят «быть гибкими», они должны начать с чтения и обсуждения в команде Agile Manifesto и его принципов. Затем выберите одну из созданных гибких методологий ( например, Scrum ), изучите ее и начните с нее. Я бы порекомендовал внимательно следить за ним, прежде чем изменять его, но это только я.

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