Agile - Когда это работает хорошо, а когда нет?

Ответ 1

Матрица сложности Ральфа Стейси обычно используется для иллюстрации сладкого пятна для Agile:

alt text http://nooperation.typepad.com/.a/6a00e54ff8b9c1883400e553fdfccb8834-400wi

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

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

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

Ответ 2

Я говорю только по опыту; YMMV.

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

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

Итак, я уверен, что мы все это делали неправильно. Не делайте это неправильно.

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

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

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

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

Ответ 3

Отправляя связанный ответ:

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

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

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

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

• Раз в две недели (или каждый месяц, в зависимости от времени итерации) вы сможете увидеть, что работает или нет. И это очень ценно, особенно как "любительская" команда, которая, как ожидается, будет учиться и находить вещи намного более постоянно.
• Как любители, вы, вероятно, не сможете предвидеть все (и что-то подвижное объятия)
• Там больше места для обмена опытом (стенд-встреча, ретроспектива и даже планирование встречи). И вы делитесь опытом REAL (вы должны писать код каждую неделю, а не просто планировать).

Ответ 4

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

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

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

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

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

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

Ответ 5

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

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

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