В нашем прошлом материал мы писали о методологиях разработки программного обеспечения, которые помогают оптимизировать рабочие процессы.
Дальше речь шла о Scrum, Kanban и экстремальном программировании.
Сегодня мы поговорим о Waterfall, FDD и Lean — оценим плюсы и минусы подходов и рассмотрим опыт организаций, которые используют их, чтобы помочь вашим компаниям оптимизировать процессы.
/Фликр/ Хамза Батт / СС
Водопад
Водопад, или водопадная модель, — это традиционная методология, которая существует с 1970 года.В нем разработка проекта разделена на этапы: от анализа системных требований до выпуска продукта.
Каждый шаг — это отдельный этап разработки программного обеспечения, и команда должен завершить один этап, прежде чем переходить к следующему.
В «чистой» реализации Waterfall возврат на предыдущий этап запрещен — можно «только плыть по течению», чтобы пройти полный цикл разработки.
Пользователи Quora сравнивать эта модель с поездом, который движется от станции к станции и не может повернуть назад. Оригинал «Водопад» Уинстона Ройса.
принес водопадная модель как пример неэффективного способа разработки ПО, приводящего к ошибкам и выпуску некачественных продуктов.
Однако позже в своем статья довел методологию до совершенства, отмечая обратную связь и переходы от тестирования к написанию кода и т.д. Согласно исследованию PMI 12% компаний используют методологию «Водопад» на постоянной основе, а 40% респондентов утверждают, что используют ее часто.
И согласно данные LiquidPlanner, водопадная модель, используется 25% организаций.
Количество этапов в Waterfall варьируется от компании к компании, но общий подход таков: следующим образом :
- Создание концепции.
Первый этап жизненного цикла разработки программного обеспечения ( СДЛК ) включает анализ затрат и выгод и оценку масштаба проекта.
- Подготовка.
Набираем команду, определяем цели и задачи.
- Анализ.
Изучение объёма работ и требований.
- Дизайн.
Создание прототипа и согласование его с заказчиком.
- Разработка/кодирование.
Создание программного обеспечения на основе утвержденного прототипа.
- Тестирование.
Готовая продукция проходит испытания.
- Выполнение.
Товар поступает на рынок.
- Обслуживание.
Устранение выявленных недостатков и поддержка.
Это позволяет легко оценить затраты и сроки до начала проекта.
Жители Куоры требовать что такие тонкости важны для финансовых и страховых компаний или компаний, занимающихся разработкой оборудования.
Кроме того, модель предполагает документирование каждого этапа.
Это помогает создать базу для последующих проектов.
Также большой объем отчетности позволяет в любой момент показать заказчику или руководству, на каком этапе находится продукт. Однако есть и недостатки.
Клиенты часто не знают, чего они на самом деле хотят, пока не посмотрят на прототип.
Но с Waterfall нужно заранее определить все требования, поэтому есть риск что-то упустить.
Изучение процесса разработки сайта Ericsson AB показал что каскадная модель привела к путанице, и 26% первоначальных требований оказались бесполезными.
Однако главный недостаток Waterfall — внесение изменений.
Продукт тестируется в конце жизненного цикла, и может быть уже поздно что-либо менять.
Именно стоимость внесения изменений побудила Toyota рассмотреть возможность перехода на другую методологию разработки.
К слова Сатоши Исии, главный менеджер проектов компании, исправлял дефекты, обнаруженные после производства, расходы В 1000–10000 раз дороже.
Поэтому в Toyota решили отказаться от Waterfall и перейти на Lean, о котором мы поговорим позже.
Наклонять
Срок означает «бережливое развитие» Его корни уход вглубь истории компании Toyota и ее подходов к решению проблем.Компания вносит только те изменения, которые выгодны, требуют минимальных затрат и занимают не более 30% запланированного времени.
Это помогло японской компании научиться переключать сборочные линии для производства очередной модели за считанные часы, тогда как другим автопроизводителям потребовались недели.
Методологию Lean использовали для разработки Мэри Поппендик и Том Поппендик.
Они написали книга «Бережливая разработка программного обеспечения».
Более подробную информацию можно также найти на их Веб-сайт , посвященный Лину.
Согласно исследованию PMI 8% компаний регулярно используют принципы бережливого производства, а 26% используют их часто.
Принципы Наклонять:
- Устранение ненужного: вещей, которые бесполезны.
- Акцент на обучении: итеративная разработка, обратная связь с клиентами.
- Решения принимаются на основе фактов, а не прогнозов.
- Честность во всем: от информирования заказчика до рефакторинга.
- Полномасштабное видение: важно оценивать проект в целом, а не по частям.
Джо Фоули, менеджер по эксплуатации Intel Fab в Лейкслипе, утверждает что 5 лет назад компании потребовалось 14 недель, чтобы начать производство новых чипов.
Благодаря принципам бережливого производства этот процесс теперь занимает 10 дней.
Более того, когда команда следует принципам бережливого развития, она не только выполняет задачи, но и стремится сделать продукт с наименьшим количеством ошибок.
В его исследовать ВВС обнаружили, что Lean увеличивает скорость разработки программного обеспечения на 37% и снижает количество ошибок на 24%.
Также, согласно исследовать В отчете Lean Business Report среди десяти преимуществ подхода указано снижение стоимости проекта – 27% ИТ-компаний сократили затраты за счет внедрения принципов Lean. Однако они подходят не всем.
Команда GlobalLuxSoft примечания , что бережливую разработку следует применять только в том случае, если к проекту привлекаются опытные разработчики, поскольку обучение на лету оказывается невозможным и ставит под угрозу создание продукта.
Все принимаемые решения должны быть подкреплены аналитическими данными и результатами мониторинга процессов, иначе команда рискует увязнуть в слишком большом количестве изменений и забыть о главной цели проекта.
Здесь можно обратиться к опыту Toyota: строгий контроль со стороны не позволяет разработчиков отклоняться от приоритетных задач.
/Фликр/ Себастьян Сикора / СС
Разработка, основанная на функциях
Разработка, основанная на функциях (FDD) — методология, объединяющая лучшие практики и фокусирующая внимание разработчиков на функциональных элементах (фичах), полезных с точки зрения клиента.К этот По этой ссылке вы можете найти примерную схему алгоритма разработки FDD. В соответствии с исследовать 11% компаний постоянно используют Feature Driven Development, а 31% прибегают к использованию этой методологии время от времени.
Создатель FDD — Джефф Де Лука, впервые предложенный методологии в 1997 году при поиске оптимального решения по разработке программного обеспечения для банка в Сингапуре.
Затем он представил комбинацию из 5 процессов:
- Разработка общей модели.
Команда разработчиков делится на группы и создает модели под отдельные задачи.
Затем выбирается одна из предложенных моделей или их комбинация.
- Создание список функций .
После того как команда разработала общую модель, она определяет функции, которые принесут пользу клиенту.
- Планирование.
Важно учитывать рабочую нагрузку команды, риски и другие аспекты, чтобы предотвратить возникновение критических проблем.
- Дизайн и развитие.
На основе данных первого процесса руководитель проекта выбирает группу функций, которые команда должна реализовать в течение определенного периода.
- Выполнение.
После того как команда разработала и протестировала код и модули, она приступает к созданию программного обеспечения.
Для этого и предыдущего этапа листья 75% усилий команды разработчиков.
В ФДД он играет все основные роли: лидера, наставника, аналитика и так далее.
В то же время методология созданный для долгосрочных проектов, так как примечание жители Stack Overflow, использовать его для мелких задач просто нет смысла.
Однако есть и преимущества.
Постоянная отчетность о проделанной работе на всех уровнях помогает отслеживать прогресс и результаты.
Это позволяет регулярно обновлять проект, выявлять ошибки и предоставлять информацию клиенту в любой момент. И один из жителей Stack Overflow утверждает , что главным преимуществом FDD является возможность в любой момент оценить, отстает ли проект от графика или движется быстрее.
Как уже отмечалось, FDD используется в масштабных проектах, поскольку первый этап — это разработка общей модели, позволяющей понять продукт. Это же свойство помогает привлечь к работе новых разработчиков.
В то же время, более глубокое понимание требований проекта и ожиданий клиента.
уменьшает риск нежелательных «сюрпризов».
P.S. О чем еще мы пишем в нашем корпоративном блоге: Управление ИТ-проектами – 5 проблем и их преодоление Управление изменениями – о целях процесса и его реализации Топ-10 самых популярных вопросов при внедрении ServiceNow Как создать и начать использовать каталог услуг Как сделать ITIL более клиентоориентированным Теги: #Гильдия ИТ #Гильдия ИТ #Гильдия ИТ #Гильдия ИТ #Гильдия ИТ #Гильдия ИТ #Гильдия ИТ #водопад #бережливое производство #FDD #ИТ-стандарты #Развитие электронной коммерции #Управление развитием #Управление проектами
-
Заправка Картриджей — Просто, Как 1-2-3
19 Oct, 24 -
Руководство По Размерам
19 Oct, 24 -
Информация Для Посетителей Cc`08
19 Oct, 24 -
Главное Правильно Разделить Вещи
19 Oct, 24 -
Telegram-Каналы О Разработке Игр
19 Oct, 24
