Хорошие, плохие и подходящие проекты.
При разработке продукта говорят, что можно действовать эффективно, сохраняя при этом качество, следуя процессу разработки, а не продолжая разработку на данный момент.
Поэтому я хотел бы обобщить схему репрезентативного процесса того, какой процесс развития существует.
Что такое процесс разработки?
Во-первых, слово «процесс» означает процесс, поэтому процесс разработки определяет порядок, в котором выполняется каждый процесс при разработке продукта, а также процессы и результаты, которые должны быть выполнены в этом процессе.
Цель использования процесса разработки
- Повышение эффективности и качества разработки системы
- Облегчить достижение общего понимания при продолжении разработки среди многих участников.
- Сделать так, чтобы с клиентом было проще понять, что за система строится и т.д.
На этот раз будет представлена модель
- Модель водопада
- 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 .