Гибкий - Когда это работает хорошо, и когда не делает этого? [закрытый]

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

Ваша ситуация напоминает мне проект, над которым я работал. Разработчик проекта в самом начале задал один вопрос: "Вы хотите, чтобы я делал все правильно или был отзывчивым?". Я был на проекте, когда он длился два года и шесть месяцев. В течение недели одна и та же функциональность внедрялась в понедельник, среду и пятницу. Вторник и четверг были потрачены на удаление функциональности.

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

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

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

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

Перепубликация моего ответа , связанного с :

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

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

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

IMHO, Scrum был бы полезен, потому что:

• Раз в две недели (или каждый месяц, в зависимости от времени итерации) вы сможете увидеть, что работает, а что нет. И это очень ценно, особенно для «любительской» команды, которая, как ожидается, будет постоянно учиться и узнавать новые вещи.
• Как любители, вы, вероятно, не сможете все предвидеть (и это то, что принимает agile).
• Есть больше места для обмена опытом (встреча в стойке, ретроспектива и даже встреча по планированию). И вы делитесь НАСТОЯЩИМ опытом (вы должны писать код каждую неделю, а не просто планировать)

По моему опыту, для работы Agile (как минимум XP или Scrum) вам абсолютно необходимы следующие компоненты. Без этих предпосылок вы, скорее всего, потерпите неудачу. Жесткий.

1. Команда должна быть стабильной и на все 100% посвященной этому.
2. Команда должна быть размещена в одном рабочем пространстве.
3. Заказчик / владелец продукта должен быть на месте в любое время.
4. Поддержка со стороны руководства. Это означает предоставление средств и смелости для выполнения вышеуказанных пунктов.

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

Я говорю только исходя из опыта; YMMV.

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

• В первый раз команда разработчиков услышал бы о проекте, это было в форма документа требований и крайний срок.
• Заинтересованные стороны часто сопротивлялись найти время, чтобы посмотреть на результат работы спринта, поэтому они не будут предпринимать никаких действий между спринтами, если посчитают, что проект движется в неправильном направлении.
• Когда мы показали заинтересованным сторонам свою работу, они обычно просто ОК. Они говорили бы о том, что бы они нравится, на что мы ответим "Это можно сделать примерно за X время ", на что они ответят, "Что ж, не нужно выходить за рамки срока для этого »
• . Процесс развертывания был долгим и сложные, обескураживающие частые развертывания. Итак, на практике мы часто разворачивает вещи, когда за 2 месяца проект был выполнен, а не в конце спринт.
• Наши встречи по планированию спринта были долго и неэффективно.
• Кажется, все были сбиты с толку относительно того, что такое схватка (и каков был наш процесс), за исключением евангелистов схватки.

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

Некоторые вещи, которые ускорили нас, мы продолжаем использовать:

• автоматизированные сборки, которые работают над машина каждого (ОГРОМНАЯ помощь!)
• формальная договоренность для нашего кода репозиторий
• учимся подавать заявку механизмы абстракции к коду пользовательского интерфейса
• рефакторинг
• модульные и интеграционные тесты
• непрерывная интеграция

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

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