Хорошие, плохие и подходящие проекты.

При разработке продукта говорят, что можно действовать эффективно, сохраняя при этом качество, следуя процессу разработки, а не продолжая разработку на данный момент.

Поэтому я хотел бы обобщить схему репрезентативного процесса того, какой процесс развития существует.

Что такое процесс разработки?

Во-первых, слово «процесс» означает процесс, поэтому процесс разработки определяет порядок, в котором выполняется каждый процесс при разработке продукта, а также процессы и результаты, которые должны быть выполнены в этом процессе.

Цель использования процесса разработки

  • Повышение эффективности и качества разработки системы
  • Облегчить достижение общего понимания при продолжении разработки среди многих участников.
  • Сделать так, чтобы с клиентом было проще понять, что за система строится и т.д.

На этот раз будет представлена ​​модель

  • Модель водопада
  • Agile-модель (Scrum, Extreme Programming (XP))
  • Прототип модели
  • Спиральная модель

Модель водопада

Обзор

Метод, при котором каждый процесс разработки системы, такой как определение требований, внешний дизайн и внутренний дизайн, выполняется в порядке от вышестоящих к нижестоящим процессам.

Функция

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

Хорошо

  • Легко планировать, легко действовать по плану
  • Легко вписаться в бюджет
  • Простое управление ресурсами для каждого процесса
  • Легко гарантировать качество

Плохо

  • Разработка может занять много времени
  • Трудно изменить спецификации
  • Существует большая сумма возврата при обнаружении ошибки в работе (бюджет/дата доставки)

Подходящие проекты

  • Большой проект
  • Проекты, где качество важнее скорости

Кроме того, V-образная модель иногда применяется в модели водопада для улучшения качества. (Модель, определяющая, в каком процессе тестирования определения и проектные документы, созданные в каждом процессе, используются для проверки)

Гибкая модель

Обзор

Он называется agile (быстрый, проворный), потому что сокращает период разработки по сравнению с обычными методами разработки. В качестве метода разработки я представлю Scrum и экстремальное программирование (XP) позже в этот раз.

Функция

  • Разделите систему по функциям и повторите внедрение, тестирование и выпуск (итерацию).
  • Предполагая, что заранее все спланировать сложно, мы сначала определяемся примерно с 70–80% спецификаций.
  • Может реагировать гибко, потому что спецификации не доработаны
  • Требует тесного общения с пользователями
  • Подходит для разработки, которая делает упор на скорость до релиза

Хорошо

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

Плохо

  • Трудно понять общий прогресс графика
  • Поскольку разработка выполняется по принципу «функция за функцией», может возникнуть разрыв в согласованности всей системы.
  • Частые изменения спецификаций делают направление развития неясным
  • Если требования не сойдутся, это займет много времени, а бюджет разбухнет.

Подходящие проекты

  • Новый бизнес с неопределенными характеристиками
  • Разработка веб-сервисов и приложений, которые постепенно наращивают функции и т. д.

Схватка

Особенность

  • Создайте список, отсортированный по требованиям, нуждам и т. д., который называется бэклогом продукта.
  • Роли определены
  • Определены события для выполнения работы

Свернуть

  • Владелец продукта (общий продукт, менеджер бэклога продукта)
  • Скрам-мастер (управление и эффективность командной деятельности, устранение препятствий в работе)
  • Участники разработки (в идеале все должны иметь навыки от проектирования до эксплуатации, но даже в команде)

Событие (Эта последовательность событий называется спринтом)

  • Планирование спринта (планирование работы для достижения цели)
  • Ежедневный Scrum (обмен прогрессом, проблемами, решениями и т. д. для достижения целей)
  • Уточнение невыполненной работы (детальные приоритеты невыполненной работы по продукту, оценки и т. д.)
  • Обзор спринта (покажите результаты спринта и получите обратную связь)
  • Ретроспектива спринта (обзор действий и процессов во время спринта)

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

Экстремальное программирование

Функция

  • Подходит для мелкомасштабной разработки
  • Многие виды деятельности требуют развития технологий
  • Определены «пять ценностей», которые следует подчеркнуть
  • Он разделен на четыре области для практики / 19 практик (первоначально 12 практик, но содержание было добавлено и изменено)

Пять значений

  • Коммуникация (гладкая коммуникация между разработчиками и клиентами)
  • Простой (Не делать сложный дизайн с самого начала и менять дизайн по ситуации с минимумом необходимого)
  • Обратная связь (частая обратная связь, автоматизация модульных тестов для повторяемости)
  • Мужество (бросайте вызов, даже если на этом пути будут большие изменения в дизайне)
  • Уважение (уважайте других участников и повышайте производительность)

4 области/19 практик

Совместная практика

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

Практики разработки

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

Практики администратора

  • Принятие ответственности (принятие ответственности за разработку)
  • Помощь (помощь в развитии/устранении препятствий)
  • Ежеквартальный обзор (обзор ежеквартально и пересмотр плана в зависимости от ситуации)
  • Зеркало (понимание общей ситуации и визуализация текущего состояния и положения)
  • Устойчивый темп (плановые корректировки работы и повышенная концентрация во избежание перегрузки)

Клиентская практика

  • Создайте историю (создайте карточку, описывающую концепцию функции)
  • План релиза (согласно консенсусу, решите, какие истории повторять)
  • Приемочный тест (проверяет, реализовано ли содержание карты истории в каждой итерации)
  • Частые выпуски (рабочее ПО выпускается от 2–3 недель до 2–3 месяцев)

Поток разработки

  • Основной поток опускается для итеративной разработки, создавая план из истории, в которой написаны требования.
  • Характеризуется реализацией разработки через тестирование и парного программирования в процессе разработки.

Прототип

Обзор

Модель прототипа — это метод, при котором прототип продукта многократно проектируется, разрабатывается, оценивается и улучшается на ранней стадии. Конечный продукт завершается на основе завершенного прототипа.

Функция

  • Создайте рабочий прототип, оценивая и улучшая его
  • Даже если окончательный образ неясен, начальная проявка может исходить из грубого изображения.
  • Легко понять изображение после завершения продукта

Хорошо

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

Плохо

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

Подходящие проекты

  • Запуск новых предприятий и услуг с неопределенными характеристиками
  • Случай, когда клиент не привык заказывать разработку системы

Спиральная модель

Обзор

Спиральная модель делит систему на несколько функций (подсистем) и продолжает разработку, получая отзывы от клиента по каждой функции.

Функция

  • Повторите процесс определения требований, проектирования, разработки, тестирования, оценки прототипа и улучшения для каждой подсистемы.
  • Модель, которая устраняет недостаток невозможности вернуться к водопаду, потому что это функциональный блок.

Хорошо

  • Относительно легко изменить расписание и гибко реагировать
  • Поскольку пользователь проверяет на ранней стадии, пробел в распознавании невелик (= меньше вероятность того, что он будет переработан)
  • Качество, как правило, высокое из-за частых обзоров и отзывов

Плохо

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

Подходящие проекты

  • Может применяться для разработки, ориентированной на качество, потому что водопадный процесс остается
  • Запуск новых предприятий и услуг с неопределенными характеристиками
  • Случай, когда клиент не привык заказывать разработку системы

В заключение

Что касается процесса разработки, существуют различные методы, каждый из которых имеет свои преимущества и недостатки. Кроме того, предположим, что заказчик понимает ход процесса разработки. В этом случае будет легче получить общее представление о графике и задачах, например, где мы находимся в целом и что делать дальше, а в некоторых случаях будет легче продолжать проект.

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

Помимо процессов, представленных на этот раз, есть еще методы DevOps. Участники разработки и эксплуатации постоянно повышают ценность бизнеса, автоматизируя разработку с помощью инструментов, облегчающих совместную разработку и повышающих скорость разработки и производительность.

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

Дополнительные материалы на PlainEnglish.io.

Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .