Содержание[Скрывать][Показывать]
Компьютерная индустрия изобилует двусмысленными формулировками, грубым жаргоном и сложными идеями, которые трудно понять и которые могут привести к безумию вычислительной буферизации.
Водопад? Скрам? Гибкий?
Если эти фразы вам совершенно чужды, не волнуйтесь; ваша полезная команда технических специалистов HashDork здесь, чтобы помочь вам понять различия между этими важными этапами процесса разработки, чтобы вы могли стать более осведомленными.
В этом посте блога будут рассмотрены методы Agile, Scrum и водопада, а также то, как каждый из них может помочь вашей команде в целом.
Начнем с agile, а остальные понесем.
Что такое Agile?
Гибкая разработка программного обеспечения следует итеративному, поэтапному подходу. Вместо обширной подготовки в начале проекта Agile-методы гибки к изменяющимся потребностям с течением времени и способствуют постоянной обратной связи с конечными пользователями.
Кросс-функциональные команды работают над итерациями продукта с течением времени, и эта работа классифицируется как невыполненная работа и расставляется по приоритетам в зависимости от ценности для бизнеса или клиента. Цель каждой итерации — создать полезный продукт.
Лидерство способствует сотрудничеству, ответственности и личному общению в методологиях Agile.
Заинтересованные стороны бизнеса и разработчики должны сотрудничать, чтобы гарантировать, что продукт соответствует требованиям потребителя и целям компании.
Фраза «гибкая разработка» относится к множеству методов и структур, основанных на идеалах и принципах, изложенных в Agile-манифест.
Эксперты советуют придерживаться гибких принципов и ценностей и использовать их в качестве руководства для принятия правильных действий в конкретной среде при подходе к разработке программного обеспечения.
Совместная и самоорганизующаяся команда является основным направлением деятельности сообщества гибкой разработки программного обеспечения.
Команды могут самостоятельно решать, как они будут заниматься конкретным проектом, но это не означает, что руководителей не существует. Таким образом, Agile-команды являются кросс-функциональными.
В agile-парадигме менеджеры по-прежнему необходимы. Они следят за тем, чтобы каждый член команды обладал или приобретал необходимые для проекта способности.
Менеджеры в agile-структуре работают, создавая атмосферу, которая способствует развитию лучших качеств в команде. Но вместо того, чтобы взять на себя инициативу, они часто отходят на второй план и позволяют команде решать, как они будут действовать.
Менеджеры вовлекаются только в том случае, если команды неоднократно безуспешно пытаются решить проблемы.
Цикл гибкой разработки
Этапы цикла разработки Agile перечислены ниже. Крайне важно помнить, что эти фазы не должны выполняться по порядку, потому что они гибкие и постоянно меняются. Многие из этих этапов происходят одновременно.
- Меню: После того, как команда проекта решила, что идея практична и осуществима, они начинают искать функции. Этот этап направлен на определение приоритета каждой функции и назначение ее итерации после разбиения идеи на более мелкие части (функции).
- Анализ требований: Чтобы определить бизнес-требования, этот шаг влечет за собой несколько обсуждений с менеджерами, заинтересованными сторонами и пользователями. Кто будет использовать продукт и как они будут его использовать, это одна из деталей, которые команда должна собрать. Эти стандарты должны быть конкретными, применимыми и количественными.
- Проект: Требования, выявленные на предыдущем этапе, используются для подготовки системы и дизайна программного обеспечения. Группа должна учитывать внешний вид продукта или решения. Команда тестирования также разрабатывает стратегию или план тестирования.
- Внедрение, кодирование или разработка: основное внимание на этом этапе уделяется созданию и оценке функций, а также планированию развертывания итераций (в соответствии с итеративным и инкрементным подходом к разработке [IID]). Поскольку функции не предоставляются, начинается итерация 0 периода разработки. Выполняя такие действия, как заключение контрактов, настройка параметров и финансирование, эта итерация обеспечивает основу для будущего роста.
- Тестирование: После того, как код создан, он тестируется на соответствие требованиям, чтобы убедиться, что продукт действительно удовлетворяет потребности пользователей и соответствует бизнес-целям. На этом этапе выполняются модульное, интеграционное, системное и приемочное тестирование.
- развертывание: После тестирования продукт отправляется клиентам, чтобы они могли его использовать. Однако проект не завершен после развертывания. Клиенты могут столкнуться с дополнительными проблемами после того, как они начнут использовать продукт, для решения которых потребуется команда проекта.
Преимущества
- Более быстрая и качественная доставка: Разбивая проект на итерации (управляемые единицы), команда может сосредоточиться на более качественном сотрудничестве, разработке и тестировании. Когда тестирование проводится с каждой итерацией, проблемы обнаруживаются и устраняются быстрее. Кроме того, с постоянными последующими версиями это высококачественное программное обеспечение может поставляться быстрее.
- Изменения приветствуются: Несмотря на то, что циклы планирования короче, принять и учесть изменения на любом этапе проекта просто. Бэклог всегда можно улучшить и изменить приоритеты, что позволит командам внести изменения в проект за пару недель.
- Конечная цель может быть неизвестна: Agile отлично подходит для проектов, когда конечная цель четко не определена. По мере продвижения проекта цели будут становиться ясными, и разработка сможет легко приспособиться к этим меняющимся потребностям.
- Постоянное совершенствование: Agile-программы продвигают вклад пользователей и команд на всех этапах проекта, позволяя применять полученные знания для улучшения следующей итерации.
- Мнение клиентов ценно: у клиентов есть несколько возможностей наблюдать за выполнением работы, оставлять отзывы и реально влиять на конечный результат. Взаимодействуя так тесно с проектной командой, они могут развить чувство сопричастности.
- Сильная командная работа: Agile подчеркивает важность регулярного общения и личных встреч. Люди могут брать на себя ответственность и владеть определенными компонентами проекта, работая в команде.
Недостатки бонуса без депозита
- Члены команды должны обладать знаниямиe: Agile-команды часто бывают небольшими. Таким образом, члены команды должны обладать широким спектром навыков. Кроме того, они должны понимать и чувствовать себя комфортно, используя выбранную технику Agile.
- Планирование может быть менее точным: Иногда может быть сложно определить точную дату доставки. Agile построен на ограниченном времени доставки, и руководители проектов часто меняют приоритеты задач. Таким образом, вполне вероятно, что некоторые из результатов, которые изначально были запланированы к доставке, не будут завершены вовремя. Кроме того, в любой момент проекта можно добавить дополнительные спринты, что удлинит весь график.
- Документация может быть проигнорирована: Некоторые члены команды могут подумать, что концентрация на документации менее важна, поскольку Agile Manifesto отдает предпочтение работающему программному обеспечению, а не тщательной документации. Agile-команды должны найти идеальный баланс между документацией и диалогом, даже если тщательная документация сама по себе не может гарантировать успех проекта.
- Конечный результат может сильно отличаться: Возможно, у первоначального Agile-проекта не было четкой стратегии, и поэтому окончательный результат может сильно отличаться от того, что ожидалось изначально. В результате добавления новых итераций, основанных на изменении входных данных клиента, может получиться существенно другой конечный результат, поскольку Agile легко адаптируется.
- Затраченное время разработчиков: Команда разработчиков должна быть полностью вовлечена в проект, чтобы Agile был эффективным. Метод Agile, который занимает больше времени, чем обычный подход, требует постоянного активного участия и сотрудничества. Кроме того, это подразумевает, что разработчики должны зафиксировать полную длину проекта.
Что такое Водопад?
Самая популярная итерация жизненного цикла разработки системы (SDLC) для разработки программного обеспечения и ИТ-проектов известна как «водопадный подход», который следует последовательной линейной процедуре.
Диаграмма Ганта, форма гистограммы, которая отображает даты начала и окончания каждой работы, иногда используется для ее планирования.
Команда разработчиков переходит на следующий уровень после завершения одного из восьми этапов. Команда не может вернуться к предыдущему этапу без перезапуска всей процедуры.
Кроме того, клиенту может потребоваться оценить и принять требования, прежде чем команда сможет перейти на следующий уровень.
Водопадная модель была разработана в высокоорганизованной среде производственного и строительного секторов, где корректировки могли быть непомерно дорогими или даже невозможными.
Техника водопада названа так потому, что она предназначена для течения только в одном направлении — вниз — точно так же, как водопад. Его этапы включают анализ, запуск, тестирование, проектирование, создание, развертывание, обслуживание и тестирование.
Метод водопада имеет ряд преимуществ, как и любая другая стратегия. Во-первых, этапы планирования и проектирования проекта более устоялись.
Клиенты и команда разработчиков более согласованы, когда речь заходит о результатах проекта при использовании каскадной разработки программного обеспечения. Поскольку вы с самого начала знаете масштаб проекта, каскадная разработка также упрощает отслеживание прогресса.
В водопадном процессе специалисты, разработчики, аналитики и тестировщики концентрируются на своей работе в проекте, а не на одном этапе всей команды.
Этапы водопада
Все шесть шагов Водопада должны происходить один за другим:
- Сбор и хранение требований: Вы должны накопить исчерпывающие знания о том, что требует этот проект в настоящее время. Существует несколько методов сбора этих данных, включая интервью, опросы и совместный мозговой штурм. Потребности проекта должны быть очевидны к моменту завершения этого этапа, и ваша команда должна получить копию документа с требованиями.
- Дизайн системы: Система разработана вашей командой с использованием заранее определенных спецификаций. На этом этапе кодирование не выполняется, но команда устанавливает требования к оборудованию или языку программирования.
- Реализация: Этот этап включает в себя кодирование. Данные предыдущего этапа используются программистами для создания пригодного для использования продукта. Код часто реализуется небольшими фрагментами, которые объединяются в конце одной фазы или в начале другой.
- Тестирование: Продукт можно начать тестировать после завершения кода. Любые проблемы тщательно обнаруживаются и сообщаются тестировщиками. Возможно, вашему проекту придется вернуться к первому этапу для переоценки, если обнаружатся серьезные проблемы.
- Доставка/развертывание: Продукт готов к этому моменту, и ваша команда отправляет результаты для развертывания или выпуска.
- Обслуживание: Клиент получил продукт и использует его. Вашей команде может потребоваться разработать исправления и обновления, когда появятся проблемы, чтобы исправить их. Опять же, серьезные проблемы могут потребовать возврата к первому шагу.
Преимущества
- Простота в эксплуатации и управлении: Водопадный подход прост в использовании и понимании, поскольку каждый проект обрабатывается одним и тем же последовательным образом. Прежде чем приступить к проекту Waterfall, от команды не требуется никакого предварительного опыта или обучения. Подход водопада очень строг; каждый этап имеет набор результатов и обзор, что упрощает администрирование и обслуживание.
- Требуется хорошо документированная методология: Документация, требуемая методологией водопада, помогает прояснить причины, лежащие в основе тестов и кода. Кроме того, он создает документальный след на тот случай, если заинтересованным сторонам потребуется дополнительная информация об определенном этапе или любых будущих инициативах.
- Соблюдение дисциплины: у каждого шага каскадного проекта есть начало и конец, что упрощает информирование заинтересованных сторон и клиентов о прогрессе. Команда может снизить вероятность несоблюдения сроков, поставив требования и дизайн на первое место перед созданием кода.
Недостатки бонуса без депозита
- Может быть сложно собрать точные требования: Общение с потребителями и заинтересованными сторонами для определения их потребностей — один из начальных этапов проекта Waterfall. На этой ранней стадии проекта может быть сложно определить их конкретные требования. Клиенты часто узнают о своих требованиях по мере разработки проекта, а не высказывают их заранее.
- Изменения трудно приспособить: Экипаж не может возобновить работу после завершения фазы. Очень сложно и дорого вернуться и исправить это, если они узнают на этапе тестирования, что функциональность отсутствовала в процессе создания требований.
- Программное обеспечение предоставляется после установленного срока: От двух до четырех этапов проекта должны быть завершены, прежде чем можно будет начать реальное кодирование. В результате заинтересованные стороны не увидят функциональное программное обеспечение до конца жизненного цикла.
Что такое Скрам?
Одной из самых популярных структур процессов для применения Agile на практике является Scrum, который является подмножеством Agile.
Это итеративная парадигма управления созданием сложного программного обеспечения и продуктов. Спринты, представляющие собой итерации фиксированной продолжительности, длящиеся от одной до двух недель, позволяют команде выпускать программное обеспечение по регулярному графику.
Заинтересованные стороны и члены команды собираются вместе, чтобы обсудить следующие шаги после каждого спринта. Роли, обязанности и встречи в Scrum остаются неизменными.
Например, Scrum определяет планирование спринта, ежедневную стойку, демонстрацию спринта и ретроспективу спринта как четыре ритуала, которые обеспечивают структуру каждого спринта.
Команда будет использовать визуальные артефакты, такие как доски задач или диаграммы выгорания, во время каждого спринта, чтобы продемонстрировать прогресс и получить дополнительную обратную связь.
В схватке команда и владелец продукта тесно сотрудничают, чтобы определить функциональность системы и расставить приоритеты. Они достигают этого, создавая бэклог продукта, который содержит все задачи, необходимые для создания программного обеспечения, которое функционирует должным образом.
Исправления ошибок, нефункциональные требования и функции должны быть включены в очередь. Кросс-функциональные команды должны оценить и подписаться на предоставление обновлений программного обеспечения в течение непрерывных спринтов, которые обычно длятся 30 дней после установления целей.
Только команда может добавлять функциональные возможности в спринт после фиксации невыполненной работы для этого спринта.
Поставка следующего спринта, бэклог продукта оценивается и, при необходимости, перераспределяется по приоритетам, после чего выбирается следующий набор результатов, который станет частью следующего спринта.
Скрам процесс
- Задержка продукта: Чтобы упорядочить элементы в бэклоге продукта, Владелец продукта и Скрам-команда встречаются (работа над бэклогом продукта происходит из пользовательских историй и требований). Бэклог продукта — это список всех желаемых функций продукта, а не список задач, которые необходимо выполнить. После этого команда разработчиков выбирает задачи из бэклога продукта для выполнения в течение каждого спринта.
- Планирование спринта: Перед каждым спринтом Владелец Продукта доставляет команде основные элементы бэклога на совещании по планированию спринта. Затем группа выбирает элементы из бэклога продукта, которые они могут закончить во время спринта, и перемещает их в бэклог спринта (который представляет собой список задач, которые нужно выполнить в спринте).
- Уточнение/уход за бэклогом: чтобы убедиться, что бэклог подготовлен для следующего спринта, команда и владелец продукта встречаются по завершении одного спринта. Команда может отбросить пользовательские истории, которые больше не актуальны, добавить новые, изменить порядок их рассмотрения или разделить пользовательские истории на более мелкие задачи. Во время этой «обрабатывающей» встречи будет удостоверено, что в список невыполненных работ входят только уместные, подробные и соответствующие целям проекта.
- Scrum-встречи каждый день: На 15-минутном стендап-совещании, называемом Daily Scrum, каждый член команды обсуждает свои цели и любые возникшие проблемы. Каждый день в течение спринта команда участвует в ежедневном скраме, который держит всех на задании.
- Встреча для оценки спринтаt: Команда представляет свою работу на собрании по обзору спринта в конце каждого спринта. Вместо доклада или презентации в PowerPoint эта встреча должна включать настоящую демонстрацию.
- Ретроспективная спринтерская встреча: Команда обсуждает любые изменения, которые необходимо внести в следующем спринте, а также то, насколько хорошо Scrum работает для них в конце каждого спринта. Команда может обсудить положительные аспекты спринта, отрицательные аспекты и области для улучшения.
Преимущества
- Больше ответственности от команды: Нет менеджера проекта, инструктирующего скрам-команду, что и когда делать. Работа, которая может быть завершена в каждом спринте, вместо этого решается командой в целом. Все они сотрудничают и помогают друг другу, укрепляя командную работу и развивая индивидуальность каждого члена команды.
- Улучшенная видимость и прозрачность проекта: Меньше недоразумений и неуверенности, так как каждый в команде осознает свои обязанности благодаря частым стендап-совещаниям. Команда может решать проблемы до того, как они выйдут из-под контроля, поскольку проблемы обнаруживаются заранее.
- Улучшенное снижение затрат: Постоянная связь информирует команду о любых проблемах или изменениях, как только они происходят, что помогает сократить расходы и повысить качество. Небольшие фрагменты функций обеспечивают постоянную обратную связь и позволяют своевременно исправлять ошибки до того, как их исправление станет слишком дорогим.
- Простота адаптации к изменениям: легче справляться с изменениями и адаптироваться к ним, когда есть частые циклы обратной связи и короткие спринты. Например, если команда сталкивается с совершенно новой пользовательской историей во время одного спринта, она может быстро добавить эту функцию в следующий спринт на совещании по уточнению невыполненной работы.
Недостатки бонуса без депозита
- Опасность ползучести области: из-за отсутствия установленной даты завершения некоторые проекты Scrum могут столкнуться с расползанием объема. Заинтересованные стороны могут быть соблазнены продолжать требовать больше функций, если нет крайнего срока для завершения.
- Плохой скрам-мастер может все испортить: Менеджер проекта — это не то же самое, что скрам-мастер. Скрам-мастер должен доверять команде, за которой он наблюдает, и никогда не давать ей инструкций. Скрам-мастер не имеет власти над командой. Проект потерпит неудачу, если скрам-мастер попытается управлять командой.
- Проблемы с точностью могут возникнуть из-за плохо сформулированных задач: Если задачи четко не определены, расходы по проекту и графики не будут точными. Планирование становится сложной задачей, и спринты могут занимать больше времени, чем предполагалось, если первоначальные цели не определены.
- Опыт и самоотверженность необходимы для команды: Чтобы команда была успешной, роли и обязанности должны быть четко определены. В Scrum Team требуются члены команды с техническими навыками, потому что нет четко определенных ролей (все делают все). Команда также должна принять участие в ежедневных сессиях Scrum и держаться вместе на протяжении всей жизни проекта.
Agile против Scrum
Несмотря на то, что Agile и Scrum используют одну и ту же методологию, между ними есть некоторые различия. Манифест Agile описывает набор принципов создания программного обеспечения посредством итеративной разработки.
Scrum, с другой стороны, представляет собой набор рекомендаций, которых необходимо придерживаться при разработке программного обеспечения Agile. Agile — это концепция, а Scrum — это метод ее применения на практике.
Scrum — это метод реализации Agile, поэтому они оба имеют много общего. Оба подхода являются итеративными, отдают приоритет ранней и частой доставке программного обеспечения и принимают изменения. Они также поддерживают открытость и постоянное развитие.
Agile против водопада
Жесткие и гибкие лучше всего описывают различия между процессом Waterfall и Agile. В то время как Agile изменчив и постоянно меняется, Waterfall — гораздо более жесткая методология.
Эти дополнительные различия между ними заключаются в следующем:
- Agile не требует линейного подхода, тогда как Waterfall — последовательный.
- В то время как потребности часто предопределены в проектах Waterfall, ожидается, что они изменятся и адаптируются в инициативах Agile.
- В отличие от Agile, проекты Waterfall не позволяют вносить изменения в работу, которая была завершена на предыдущем этапе.
- Водопад — это организованная процедура, в которой вы должны закончить каждый шаг, прежде чем переходить к следующему. Однако Agile — это гибкая методология, которая позволяет вам работать над проектом в своем собственном темпе.
Agile против Waterfall против Scrum
- Водопад повышает доверие к тому, что будет предоставлено очень скоро после того, как это запланировано. Agile опирается на лучшие практики среды разработки. Здесь можно хорошо управлять рядом проектных рисков, поскольку результаты постоянно оцениваются.
- Waterfall не предполагает, что команда и проект будут базироваться в одном месте. В то время как scrum и agile нуждаются в совместном размещении сотрудников.
- Agile фокусируется на сокращении переделок проекта и поощряет внесение изменений намного раньше. В отличие от водопада, который реагирует по-разному, скрам также позволяет обнаруживать изменения на ранней стадии.
- Agile и scrum обеспечивают более компактный план конечного продукта. Это создает проблему с обещаниями, данными покупателю. Напротив, каскадная графика дает клиентам и разработчикам лучшее представление о конечном результате.
- Каждая из этих техник имеет набор инструментов для организации и моделирования задач, связанных с их созданием.
Заключение
Если вы дошли до этого момента и уверены в своих знаниях различий между процессами Waterfall, Agile и Scrum, вы уже должны знать, какая стратегия лучше всего подойдет вам и вашей команде.
Техника водопада, предназначенная для проектов с определенным объемом, сроками и бюджетом, может быть вашим лучшим вариантом, если вам нравятся жесткие правила и процедуры, и вы обнаружите, что они вносят ясность.
С другой стороны, если свобода и адаптируемость, которые предлагает Agile, вдохновляют вас, возможно, вам стоит обратить на это внимание.
Однако Scrum — это то, что вам нужно, если вы хотите немного дисциплины в гибкой структуре.
Однако вы должны рассматривать эти подходы в свете проекта, над которым вы работаете, и вашего конечного результата.
Оставьте комментарий