Что такое гибкая методология? Объяснение современной разработки программного обеспечения

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

Но что такое гибкая методология и как ее применять при разработке программного обеспечения? Чем гибкая разработка отличается от водопада на практике? Что такое жизненный цикл гибкой разработки программного обеспечения или гибкий SDLC? И чем отличается Scrum Agile от Kanban и других гибких моделей? 

Agile был официально запущен в 2001 году, когда 17 технологов разработали Agile Manifesto. Они написали четыре основных принципа гибкого управления проектами с целью разработки лучшего программного обеспечения:

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

До Agile: эпоха водопадной методологии

Старые руки вроде меня помнят те времена, когда водопадная методология была золотым стандартом в разработке программного обеспечения. Процесс разработки программного обеспечения требовал наличия тонны документации, прежде чем начинать кодирование. Кто-то, обычно бизнес-аналитик, сначала написал документ о бизнес-требованиях, в котором зафиксировано все, что бизнесу необходимо в приложении. Эти документы с бизнес-требованиями были длинными, подробно описывая все: общую стратегию, исчерпывающие функциональные спецификации и дизайн визуального пользовательского интерфейса.

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

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

Мы, разработчики, должны были знать «спецификацию», как называлась полная документация, точно так же, как и авторы документов, и нас часто ругали, если мы забывали должным образом реализовать ключевую деталь, описанную на стр. 77 из 200 документов. страница документа.

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

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

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

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

Видео по теме: Как на самом деле работает гибкая методология

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

Поворот к гибкой разработке программного обеспечения

Методология водопада, изобретенная в 1970 году, была революционной, потому что она привнесла дисциплинированность в разработку программного обеспечения, чтобы гарантировать наличие четкой спецификации, которой необходимо следовать. Он был основан на методе производства «водопад», заимствованном из инноваций на конвейере Генри Форда 1913 года, который обеспечивал определенность на каждом этапе производственного процесса, чтобы гарантировать, что конечный продукт соответствует изначально заданным спецификациям.

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

Методология разработки программного обеспечения начала меняться, когда разработчики начали работать над интернет-приложениями. Большая часть ранней работы выполнялась в стартапах, где команды были меньше, располагались в одном месте и часто не имели традиционных знаний в области компьютерных наук. Для ускорения вывода на рынок веб-сайтов, приложений и новых возможностей возникло финансовое и конкурентное давление. Инструменты и платформы разработки быстро изменились.

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

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

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

В 2001 году группа опытных разработчиков программного обеспечения собралась и поняла, что они коллективно практикуют разработку программного обеспечения, отличную от классической методологии водопада. И не все они были в стартапах. Эта группа, в которую вошли технологические знаменитости Кент Бек, Мартин Фаулер, Рон Джеффрис, Кен Швабер и Джефф Сазерленд, разработала Agile Manifesto, в котором задокументированы их общие убеждения в том, как должен работать современный процесс разработки программного обеспечения. Они подчеркнули, что сотрудничество важнее документации, самоорганизация, а не жесткие методы управления, и способность управлять постоянными изменениями, а не ограничиваться жестким водопадным процессом разработки.

Из этих принципов родилась гибкая методология разработки программного обеспечения.

Роли в гибкой методологии

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

Пользователь

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

Владелец продукта

Сам процесс гибкой разработки начинается с того, кто должен быть голосом заказчика, включая всех внутренних заинтересованных лиц. Этот человек извлекает все идеи, идеи и отзывы для создания видения продукта. Эти видения продукта часто бывают краткими и простыми, но, тем не менее, они рисуют картину того, кто является клиентом, какие ценности рассматриваются, и стратегию того, как их решать. Я могу представить, что первоначальное видение Google выглядело примерно так: «Давайте упростим для любого, имеющего доступ в Интернет, поиск релевантных веб-сайтов и веб-страниц с помощью простого интерфейса на основе ключевых слов и алгоритма, который поднимает авторитетные источники в результатах поиска».

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

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

Команда разработчиков программного обеспечения

В Agile команда разработчиков и обязанности ее членов отличаются от обязанностей при традиционной разработке программного обеспечения.

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

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

Scrum, Kanban и другие Agile-фреймворки

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

Самый популярный гибкий фреймворк называется scrum . Основное внимание в нем уделяется тактике выполнения работ, называемой спринтом и структурами встреч, которые включают следующее:

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

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

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

Хотя Scrum доминирует, существуют и другие гибкие фреймворки:

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

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

Так, например:

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

Почему гибкая методология лучше