Методологии разработки

Waterfall - Модель Waterfall относится к классическому пониманию разработки ПО. Весь процесс является жестким и линейным, имеет четкие цели для каждого этапа, новая фаза начинается по завершению предыдущей, нет возврата назад. Преимущества водопадной методологии — децентрализация и строгий контроль над сроками и качеством исполнения. На практике Waterfall часто не оправдывает ожиданий, поскольку игнорирует динамические изменения. Так, после тестирования очень сложно откатить процесс и заложить функции, не учтенные на стадии разработки. Waterfall неэффективен ещё и потому, что предполагает временные простои сотрудников в рамках одного проекта. Тестирование проводится только в конце разработки, хотя проблемы, найденные на этом этапе — это дорогостоящие исправления.

Agile - метод гибкой разработки программного обеспечения, предполагающий большое количество итераций. Документ Agile Manifesto описывает 4 идей и 12 принципов гибкого подхода.

Основные идеи:

• Люди и взаимодействие важнее процессов и инструментов.
• Работающий продукт важнее исчерпывающей документации.
• Сотрудничество с заказчиком важнее согласования условий контракта.
• Готовность к изменениям важнее следования первоначальному плану.

Принципы, которые разъясняет Agile Manifesto:

• Удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения.
• Приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта.
• Частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще.
• Тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта.
• Проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием.
• Рекомендуемый метод передачи информации — личный разговор (лицом к лицу).
• Работающее программное обеспечение — лучший измеритель прогресса.
• Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок.
• Постоянное внимание улучшению технического мастерства и удобному дизайну.
• Простота — искусство не делать лишней работы.
• Лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды.
• Постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы.
• Улучшения эффективности и соответственно корректировать стиль своей работы.

Scrum - итеративно-инкрементальная разработка, «итеративная» означает, что разработка разбивается на равные по длительности промежутки времени - спринты. Один спринт занимает от одной до четырёх недель, «инкрементальная» - в результате итерации получается новый, потенциально рабочий продукт, решающий бизнес-проблему. Такой продукт называется инкрементом продукта. целью которого является повышение производительности труда в командах, ранее парализованных более тяжелыми методологическими процессами. В основе концепции лежат «спринты». Спринт - короткая итерация, строго ограниченная по времени (обычно 2−4 недели). В это время минимизируется длительность совещаний, но увеличивается их частота (они называются «схватками»). Благодаря этому контроль за выполнением становится более гибким, а разработчики быстрее реагируют на возникающие проблемы. Традиционное планирование отходит на второй план, его место занимает журнал спринтов.

Артефакты Scrum:
• Product backlog.
• Sprint backlog.
• Scrum board - To do, busy, done.

Роли:
• Scrum Master - проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса. Руководитель проекта скорее относится к владельцу продукта и не должен фигурировать в качестве скрам-мастера.
• Product Owner - представляет интересы конечных пользователей и других заинтересованных в продукте сторон.
• Development Team - кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет от 3 до 9 человек. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто, кроме команды, не может вмешиваться в процесс разработки на протяжении спринта

Этапы спринта:
• Планирование спринта (Sprint Planning Meeting) - Из бэклога проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда. На основе выбранных задач создается бэклог спринта. Каждая задача оценивается в идеальных человеко-часах. Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи.
• Ежедневное совещание (Daily Scrum meeting) - длится не более 15 минут. В течение совещания каждый член команды отвечает на 3 вопроса:
  • Что я сделал с момента прошлой встречи для того, чтобы помочь Команде Разработки достигнуть Цели Спринта?
  • Что я сделаю сегодня для того, чтобы помочь Команде Разработки достичь Цели Спринта?
  • Вижу ли я препятствия для себя или Команды Разработки, которые могли бы затруднить достижение Цели Спринта?
• Обзор итогов спринта (Sprint review meeting) - Проводится в конце спринта. Команда демонстрирует прирост функциональности продукта всем заинтересованным лицам.
• Ретроспективное совещание (Retrospective meeting) - Проводится в конце спринта. Члены команды высказывают своё мнение о прошедшем спринте. И на основе выводов улучшают будующие спринты. Сайт для удобного ретро - https://retrotool.io/
  • Bad
  • Good
  • Ideas
  • Kudos

XP(Экстремальное программирование) - возможность вести разработку в условиях постоянно меняющихся требований. Вот несколько признаков:

• Игра в планирование. В начале проекта есть только приблизительный план, после каждой итерации его чёткость возрастает.
• Высокая частота релизов. Новая версия продукта имеет незначительные изменения по сравнению с предыдущей, но время на выпуск при этом минимально.
• Контакт с клиентом. Для удовлетворения требований конечной аудитории необходимо оперативное реагирование на замечания и пожелания.
• Рефакторинг. Улучшение качества кода без уменьшения функциональности.
• Стандарт выполнения кода. Или применяются общие правила, или разногласия в оформлении не подлежат обсуждению и критике.
• Коллективная ответственность. Несмотря на то, что каждый член команды выполняет свой участок работ, за код в целом отвечает весь коллектив.

Канбан(kanban) - метод управления разработкой, реализующий принцип «точно в срок» и способствующий равномерному распределению нагрузки между работниками. При данном подходе весь процесс разработки прозрачен для всех членов команды. Задачи по мере поступления заносятся в отдельный список, откуда каждый разработчик может извлечь требуемую задачу.

Вопросы

kanban - не имеет Sprints. По этому сколько успел сделать для 2 недели то и будет в демо.

kanban - рекомендуется для суппорта. Scrum - для разработки.