С какими методами гибкой разработки программного обеспечения вы добились наибольшего успеха?[закрыто]

Question

Существует множество Гибкая разработка программного обеспечения методы.Какие из них вы использовали на практике для реализации успешного проекта и как этот метод способствовал этому успеху?

Answer 1

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

Тем не менее, я, вероятно, могу прокомментировать некоторые из практик XP

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

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

• Карточки с историями пользователей хороши тем, что здорово иметь физический объект, которым можно разбрасываться для расстановки приоритетов, но они недостаточно детализированы, если только ваш разработчик действительно не знает домен или у вас нет локального клиента (которого я на самом деле никогда не видел).

• Стендап-встречи как правило, это действительно полезно для новых членов команды - познакомиться со всеми и с тем, над чем они работают.Старые сотрудники очень быстро расслабляются и просто говорят что-то вроде "Я все еще работаю над X", чем они и занимались всю прошлую неделю - нужен сильный лидер, чтобы заставить их вникать в детали.

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

Answer 2

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

Answer 3

Схватка.

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

Answer 4

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

Просто убедитесь, что человек, проводящий ретроспективу, знает, что он / она делает, иначе она может перерасти в сеанс подачи жалоб.

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

Для получения дополнительной информации выполните поиск в Google по запросу "Ретроспективы сердцебиения".

Answer 5

Я работал с командой, использующей XP и Scrum-практики, разбавленные небольшим количеством lean.Это было очень продуктивно.

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

Парное программирование- улучшил нашу кодовую базу и помог устранить "глупые" ошибки, вносимые в систему.

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

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

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

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