Agile — различия между версиями

м (См. также)
Строка 1: Строка 1:
'''Agile''' (на русский обычно не переводится, хотя иногда говорят о “гибких методах”) — серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.  
+
'''Agile''' (на русский обычно не переводится, хотя иногда говорят о “гибких методах”) — [[:Категория:Гибкие методологии разработки ПО|серия подходов к разработке программного обеспечения]], ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.  
  
 
В [[Системная инженерия|системной инженерии]] “железных” [[система|систем]] методы agile пока используются мало, но в последние годы ситуация быстро меняется: разработка определения системы в существенной мере оказывается похожей на разработку программного обеспечения, и в ней для разработки моделей могут быть использованы практики, зарекомендовавшие себя при разработке ПО.
 
В [[Системная инженерия|системной инженерии]] “железных” [[система|систем]] методы agile пока используются мало, но в последние годы ситуация быстро меняется: разработка определения системы в существенной мере оказывается похожей на разработку программного обеспечения, и в ней для разработки моделей могут быть использованы практики, зарекомендовавшие себя при разработке ПО.
 
== Agile-манифест разработки ПО ==
 
Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:
 
# Люди и взаимодействие важнее процессов и инструментов
 
# Работающий продукт важнее исчерпывающей документации
 
# Сотрудничество с заказчиком важнее согласования условий контракта
 
# Готовность к изменениям важнее следования первоначальному плану
 
 
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
 
Важно понимать, что мы не отрицаем то, что написано в правой части манифеста. Мы только говорим о том, что мы больше ценим написанное в левой части чем то, что написано в правой части.
 
 
== Основополагающие принципы Agile-манифеста ==
 
# Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
 
# Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
 
# Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
 
# На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
 
# Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
 
# Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
 
# Работающий продукт — основной показатель прогресса.
 
# Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
 
# Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
 
# Простота — искусство минимизации лишней работы — крайне необходима.
 
# Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
 
# Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
 
 
Из этих принципов важно понять, что главная цель – удовлетворить заказчика (бизнес, стейкхолдеров, пользователей).
 
 
Agile манифест заявил, что '''изменяющиеся требования – это не зло, а благо''' и не надо с этим бороться, так как оно позволяет заказчику достигать конкурентного преимущества.  То есть это и есть тот очень важный инструмент, с помощью которого мы сможем удовлетворить заказчика.
 
 
Следует также знать, что '''единственной метрикой того, как идет разработка продукта – является сам продукт''' (работающий продукт). Никакие метрики, никакие отчёты напрямую не показывают насколько вы успешны в достижение требуемой цели.
 
 
Agile в качестве определенной аксиомы ставит условие взаимного сотрудничества и уважения. С самого начала авторы Agile говорят о том, что работать по таким принципам возможно и следует только в условиях, когда люди работающие над общим продуктом (в том числе заказчики, пользователи и представители бизнеса), выстраивают свое сотрудничество на основе взаимного доверия.
 
 
Постоянное самосовершенствование является одним из ключевых факторов достижения цели проекта.
 
 
== Роли ==
 
Ответственность за результат делится между тремя ролями:
 
* '''Владелец продукта'''
 
** определяет проектные цели,
 
** разрабатывает оптимальный график при заданных проектных параметрах,
 
** адаптирует процесс выполнения проекта к изменившимся требованиям,
 
** устанавливает приоритеты в характеристиках продукта
 
* '''Scrum мастер'''
 
** устанавливает приоритеты в выполнении задач командой проекта,
 
** устраняет возникающие затруднения, препятствующие выполнению задач
 
* '''Члены команды'''
 
** выполняют большинство поставленных задач,
 
** осуществляют ежедневный менеджмент,
 
** создают отчеты о ходе выполнения проекта,
 
** контролируют качество продукта
 
 
== Agile-методологии ==
 
* '''Agile Data Method''' — группа итеративных методов разработки программного обеспечения, в которых требования и решения достигаются в рамках сотрудничества разных кросс-функциональных команд.
 
* '''Agile Modeling''' — набор понятий, принципов и приёмов (практик), позволяющих быстро и просто выполнять [[моделирование]] и [[документирование]] в проектах разработки программного обеспечения. Не включает в себя детальную инструкцию по проектированию, не содержит описаний, как строить диаграммы на UML. Основная цель: эффективное моделирование и документирование; но не охватывает программирование и тестирование, не включает вопросы управления проектом, развёртывания и сопровождения системы. Однако включает в себя проверку модели кодом.
 
* '''AUP''' (Agile Unified Process) упрощенная версия IBM Rational Unified Process ([[RUP]]), разработанная Скоттом Амблером, которая описывает простое и понятное приближение (модель) для создания программного обеспечения для бизнес-приложений.
 
* '''[[ASD]]''' (adaptive software development, адаптивная разработка).
 
* '''Crystal Methods''' - семейство методологий (the Crystal family), разработанных Alistair Cockburn в середине 1990х. Все методологи семейства Crystal строятся на следующих базовых принципах: "усиленная коммуникация" + "облегченные рабочие продукты". Количество методологических элементов можно уменьшать для того, чтобы чаще выпускать работающие варианты системы и как можно шире использовать каналы межличностного общения. Оба эти принципа можно легко применять и видоизменять в любом проекте.
 
* '''[[DSDM]]''' (Dynamic Systems Development Method) основан на концепции быстрой разработки приложений (Rapid Application Development, RAD). Представляет собой итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя.
 
* '''EssUP''' (Essential Unified Process).
 
* '''[[FDD]]''' (Feature driven development, функционально-ориентированная разработка)
 
* '''Getting Real''' — итеративный подход без функциональных спецификаций, использующийся для веб-приложений. В данном методе сперва разрабатывается интерфейс программы, а потом её функциональная часть.
 
* '''Бережливая разработка программного обеспечения''' (англ. lean software development) использует подходы из концепции [[Бережливое производство|бережливого производства]].
 
* '''OpenUP''' — это итеративно-инкрементальный метод разработки ПО. Позиционируется как лёгкий и гибкий вариант RUP. OpenUP делит жизненный цикл проекта на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи. Жизненный цикл проекта обеспечивает предоставление заинтересованным лицам и членам коллектива точек ознакомления и принятия решений на протяжении всего проекта. Это позволяет эффективно контролировать ситуацию и вовремя принимать решения о приемлемости результатов. План проекта определяет жизненный цикл, а конечным результатом является окончательное приложение.
 
* '''[[Scrum]]'''
 
* '''[[XP]]''' (eXtreme Programming, экстремальное программирование)
 
  
 
== Гибкое моделирование ==
 
== Гибкое моделирование ==
Строка 86: Строка 21:
 
* [http://www.infoq.com/resource/news/2010/01/kanban-scrumminibook/en/resources/KanbanAndScrum-Russian.pdf «Kanban and Scrum. Making the most of both»] – пример связи подходов [[Бережливое производство|lean]] и agile.
 
* [http://www.infoq.com/resource/news/2010/01/kanban-scrumminibook/en/resources/KanbanAndScrum-Russian.pdf «Kanban and Scrum. Making the most of both»] – пример связи подходов [[Бережливое производство|lean]] и agile.
 
* [http://www.myvi.ru/watch/WxsZCtYxMEyyp5QLEIp_Aw2 Впечатляющий пример] – как стадион разбили на 12 секторов, и пока один сектор проектировали, предыдущий строили, а пред-предыдущий отделывали (6й сезон 14й фильм из замечательной [http://en.wikipedia.org/wiki/Extreme_Engineering серии телевизионных документальных фильмов про мастерство инженеров]).
 
* [http://www.myvi.ru/watch/WxsZCtYxMEyyp5QLEIp_Aw2 Впечатляющий пример] – как стадион разбили на 12 секторов, и пока один сектор проектировали, предыдущий строили, а пред-предыдущий отделывали (6й сезон 14й фильм из замечательной [http://en.wikipedia.org/wiki/Extreme_Engineering серии телевизионных документальных фильмов про мастерство инженеров]).
 
  
 
[[Категория:Подходы]]
 
[[Категория:Подходы]]
 
[[Категория:Модели ЖЦ]]
 
[[Категория:Модели ЖЦ]]

Версия 02:30, 27 августа 2019

Agile (на русский обычно не переводится, хотя иногда говорят о “гибких методах”) — серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.

В системной инженерии “железных” систем методы agile пока используются мало, но в последние годы ситуация быстро меняется: разработка определения системы в существенной мере оказывается похожей на разработку программного обеспечения, и в ней для разработки моделей могут быть использованы практики, зарекомендовавшие себя при разработке ПО.

Гибкое моделирование

Метод описания архитектуры программной системы, который следует идее того, что содержимое важнее представления. Это обеспечивает простоту, понятность, достаточную точность и единообразие создаваемых моделей. Простота документа гарантирует активное участие заинтересованных сторон в моделировании артефактов. Более подробно этот подход рассматривается в книге Скотта Амблера «Гибкие технологии: экстремальное программирование и унифицированный процесс разработки» (J. Wiley, ISBN-10: 0471202827, ISBN-13: 978-0471202820; Питер, ISBN 5-94723-545-5, 0-471-20282-7).

Критика

  • При agile-подходе часто пренебрегают созданием плана («дорожной карты») развития продукта, равно как и управлением требованиями, в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации.
  • Считается, что работа в agile мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы (подход — «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжёлые к воспроизводству дефекты после реального развёртывания у клиента). Это приводит к снижению качества продукта и накоплению дефектов.

См. также

Ссылки

Примеры внедрения agile и других гибких методов в системной инженерии: