Я постоянно слышу и много читаю о методологиях разработки Agile и Scrum, но я понятия не имею, что они могут или их использования, какие проекты подходят для этого метода?
Не могли бы вы указать мне какую-то полезную информацию об этом?
С чего начать?
В чем преимущества?
В разработке программного обеспечения Agile - это набор ценностей и принципов, составленный группой ведущих лидеров отрасли в 2001 году.
Scrum - это конкретная методология разработки программного обеспечения, которая может быть прослежена до 1995 года и создана двумя из первых сторонников Agile Manifesto, Scrum поддерживает значения Agile.
Ранний подход к управлению проектами программного обеспечения, обычно называемый модель водопада, подразумевает последовательность четко определенных шагов, необходимых для завершения любого проекта: определять, планировать, организовывать, выполнять и затем закрывать.
Это представляет собой очень аккуратную, простую и, прежде всего, удобную абстракцию с точки зрения теоретиков управления проектами. Когда один этап следует за другим, можно определить четкие входы и выходы для каждого этапа, выделить и определить методы и инструменты, которые наиболее полезны на каждом этапе. Это явный пример редукционизма в решении сложностей управления проектами: продолжайте разделять целое на более мелкие кусочки, пока вы не поймете каждый бит в изоляции, а затем, надеюсь, вы овладеете механикой их совокупности.
Но как только была представлена абстракция водопада, она начала течь. Во-первых, оказалось, что реальный процесс не может быть четко перечеркнут на стадии, часто определение все еще меняется по тому, что, по-видимому, представляет собой планирование, организация или даже этап исполнения. Таким образом, теоретически этапы позволяли перекрываться, и теоретики начали рисовать всевозможные диаграммы там, где можно было увидеть, как этап определения постепенно заканчивается, так как исполнение начинается на этапе организации. Затем, опять же только теоретически, на этапе планирования можно точно оценить, сколько времени потребуется для разработки части программного обеспечения. Очевидно, что на практике оценки и другие планы должны корректироваться прямо через этап выполнения, который породил ряд сложных, но не очень значимых методов, поскольку Earned Управление стоимостью.
Хронические проблемы с абстракцией водопада породили ряд " agile" методы управления проектами (Agile, Scrum, XP Programming и т.д.), что, несмотря на множество различий на более детальном уровне, используют одни и те же фундаментальные принципы для решения проблемы сложности разработки продукта:
Проект организован как ряд небольших итераций на классических этапах проекта (определение, планирование, организация, выполнение и закрытие).
Каждая итерация нацелена на относительно небольшое, но семантически полное приращение функциональности продукта или нефункциональных характеристик.
Сильное вовлечение конечных пользователей во всем проекте.
Поскольку каждая итерация проходит через отдельное определение и этап планирования, временной горизонт для различных мероприятий оценки и планирования значительно сокращается. Это помогает достичь большей точности, следовательно, облегчает доступ к выполнимости, измерению стоимости и стоимости и т.д.
Малые приращения помогают управлять областью, оценивать полезность изменений и удерживать пользователей, поскольку всегда есть новая версия полностью функционирующего продукта. Кроме того, гораздо проще организовать несколько команд, работающих над большим проектом одновременно, когда приращения сохраняются небольшими, что действительно помогает решать задачи зависимостей.
Пользовательская обратная связь является ключом к итеративным методам, поскольку она помогает продукту постепенно развиваться в правильном направлении, обеспечивая большую полезность в конце, в отличие от неуверенной реакции пользователя, естественной для прерывистое равновесие, обусловленное подходом "большого взрыва" водопада.
Agile - это набор практик. Хотя формального определения сбора гибкой практики нет, существуют исследования, которые измеряли эффективность различных гибких практик.
В широком смысле гибкие практики могут быть категориями в две группы, методы управления и инженерные практики. SCRUM - самый популярный набор методов управления. XP или Extreme Programming - это самый известный набор технических решений.
Если гибкая команда только обслуживает практику управления, то есть SCRUM, они, вероятно, не смогут поддерживать устойчивый темп в течение неопределенного периода времени. Например, без автоматических функциональных тестов для проверки каждой итерации потребуется больше времени и дольше. Если вы не используете парное или тестовое развитие, вы, скорее всего, обнаружите, что ваши дефекты выходят из-под контроля.
Практика управления позволяет команде успешно сотрудничать с деловым партнером. Приоритизация того, что необходимо сделать, работая совместно с областью действия в приоритетном порядке. SCRUM сам по себе обеспечит выгоду немедленно. Практика управления, как правило, проще всего изучать и внедрять в практику.
Примерами методов управления являются открытое рабочее пространство, владелец продукта, приоритетные отчеты о отставаниях продуктов, итерации, итерации и выпуска, показы и рассказы и т.д.
В то время как технические практики сложнее изучать и выполнять хорошо, они необходимы, если команда должна поддерживать устойчивые темпы высококачественного программного обеспечения. Примерами инженерных практик являются совместная разработка разработчика, разработка тестового диска, простой эволюционный дизайн, автоматические функциональные и эксплуатационные тесты, непрерывная интеграция и совместное использование кода.
Много написано об Agile и еще больше путанице. Если вы заинтересованы в использовании гибкой находки, тренер может помочь вашей команде изучить как управленческие, так и инженерные практики. Вы будете вознаграждены командой, которая является высокоэффективной и деловым партнером, которая очень довольна.
extremeprogramming.org - хороший обзор Agile.
Обратите внимание, что Scrum предназначен для управления проектами, это не методология разработки. Scrum часто используется вместе с Agile.
Пожалуйста, проигнорируйте первый ответ выше как религиозную бессмыслицу. Это сталинский стиль переписывания истории, который меня очень беспокоит, когда я это слышу: "Вначале был водопад, но это было плохо, и, таким образом, существовал Agile и Scrum, и программисты радовались". Просто этого не произошло. Это произошло вот так:
a) Давным-давно были Водопад, Спираль и некоторые другие.
b) Менее давным-давно существовали итеративные разработки, UP, RUP и целый ряд других итерационных подходов к разработке, которые были в ярости, и евангелисты рассказывали всем, как итерации смягчают риски.
c) Компании все еще использовали водопад в любом случае, а инструменты для Итеративного развития, такие как Rational Rose и т.д., были слишком дорогими и слишком сложными для понимания.
d) Вся эта сложность вызвала ряд задержек, таких как XP, и, в конечном счете, манифеста Agile, в котором в основном говорится: "Процессы и инструменты сложны и сложны и отвлекают от требований, поэтому мы должны просто говорить неформально с клиентом"
e) Agile была быстро принята каждым чрезмерно мятежным головающим программистом на планете, который нес манифеста Agile в своих карманах так же, как ирландские эмигранты 4-го поколения по-прежнему несут манифест IRA в своих.
f) Агрессивные попытки переписать историю, сказав: "Мы использовали водопад, пока не появился Скрам", и с этим и тем фактом, что это загубленная толстая версия Итеративного, инкрементального развития, он надеется сделать больше вторжений в корпоративную культуру водопада.
Наконец, Scrum - ничто - это лучшая лексика. Он опирается на силу одной небольшой команды. Вот и все. Игнорируйте его, и оно может исчезнуть.
"Водопад" как принятый способ создания программного обеспечения произошел случайно. На самом деле программное обеспечение не было разработано с самого начала, но его простота и представление о том, что все можно было узнать и контролировать с самого начала, привлекательны.
Бизнес-сторона должна уметь прогнозировать, как долго будет выполняться проект с заданными ресурсами, чтобы они могли рассчитывать возврат инвестиций до принятия решения о начале проекта, и поэтому они могут привести в действие такие вещи, как маркетинг, продажа и знание когда их ресурсы будут доступны для следующего проекта.
Подход водопада к достижению этих целей включает в себя определение и планирование каждой последней детали впереди. Неожиданности и открытия в ходе проекта рассматриваются как неудачи на ранних стадиях. Программное обеспечение разработано в архитектурных слоях, которые объединяются во время "интеграции" после того, как код концептуально завершен. Поскольку все первоначальные требования считаются жизненно важными, это почти сценарий "все или ничего". Некоторые интерпретации даже препятствуют изменениям после требований и фаз планирования. Если что-то происходит слишком долго, когда приходит исходный срок, вы должны решить, нужно ли бросать функции или долго идти (или требовать тонны сверхурочной работы) или комбинации. Наиболее критичные функции так же вероятно работают или не работают как наименее критические; в этом случае у вас просто нет возможности остановиться, где вы находитесь.
Agile предлагает альтернативные способы достижения одних и тех же бизнес-целей. ИМО гибко менее интуитивно, но на практике лучше работает. Проворный подход говорит, что невозможно знать каждую деталь впереди для всех, кроме самых маленьких/самых простых проектов, и что проект должен быть в состоянии удовлетворить сюрпризы и обновленные требования. Кроме того, завершая и проверяя функции программного обеспечения в порядке важности, прикоснувшись ко всем соответствующим архитектурным слоям в пути, гибкость может сделать возможным более полезный продукт в срок, требуемый бизнес-стороной.
Техническая практика, такая как переплетение действий по тестированию и разработке, не указана в Scrum, но если вы продолжаете пересматривать код так, как требуется постепенное развитие, и у вас нет безопасности автоматических тестов, вы просите о проблемах.
Как упоминалось выше людьми.
Scrum - это итеративный и инкрементный гибкий способ разработки программного обеспечения для управления проектами программного обеспечения и разработки продуктов или приложений. Таким образом, Scrum представляет собой тип Agile-подхода, который широко используется в разработке программного обеспечения.
Таким образом, Scrum является особым вкусом Agile, в частности, он называется гибкой структурой управления проектами.
Я уже ввел свой вопрос по этому вопросу ранее:
В чем разница между Scrum и Agile Development?
Запись снова.
Также Scrum имеет в основном две роли внутри него: 1. Основная/основная роль 2. Вспомогательная роль
Основная/основная роль: она состоит в основном из трех ролей: а). Scrum Master, b). Владелец продукта, c). Команда разработчиков.
Вспомогательная роль: вспомогательные роли в командах Scrum - это те, у кого нет официальной роли и нечастая вовлеченность в процесс Scrum, но тем не менее они должны быть приняты во внимание. а именно Заинтересованные стороны, Менеджеры.
а). Scrum Master: - В схватке есть 6 типов встреч: ежедневный Scrum/Standup Backlog grooming: storytime Scrum of Scrums Спринт планирование встречи Спринт обзор встречи ретроспектива Sprint
Сообщите мне, если кому-то нужно больше ресурсов для этого.
Наша команда начала использовать SCRUM несколько месяцев назад. Все нормально. Это дает команде лучшую покупку в результатах, поскольку они являются тем, чтобы вести истории пользователей, назначать точки и создавать для них задачи.