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

м
 
Строка 9: Строка 9:
 
* При agile-подходе часто '''пренебрегают созданием плана''' («дорожной карты») развития продукта, равно как и '''[[Инженерия требований|управлением требованиями]]''', в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации.
 
* При agile-подходе часто '''пренебрегают созданием плана''' («дорожной карты») развития продукта, равно как и '''[[Инженерия требований|управлением требованиями]]''', в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации.
 
* Считается, что работа в agile '''мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом,''' при этом зачастую '''не обращая внимания на правильность кода с точки зрения требований нижележащей платформы''' (подход — «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжёлые к воспроизводству дефекты после реального развёртывания у клиента). Это приводит к снижению качества продукта и накоплению дефектов.
 
* Считается, что работа в agile '''мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом,''' при этом зачастую '''не обращая внимания на правильность кода с точки зрения требований нижележащей платформы''' (подход — «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжёлые к воспроизводству дефекты после реального развёртывания у клиента). Это приводит к снижению качества продукта и накоплению дефектов.
 
== См. также ==
 
* [[Параллельная инженерия]] - разработка систем, по духу близкая к Agile
 
* [[Business Agility]] - модель для гибких организаций
 
  
 
== Ссылки ==
 
== Ссылки ==
Строка 21: Строка 17:
 
* [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 серии телевизионных документальных фильмов про мастерство инженеров]).
 +
 +
== См. также ==
 +
* [[Параллельная инженерия]] - разработка систем, по духу близкая к Agile
 +
* [[Business Agility]] - модель для гибких организаций
  
 
[[Категория:Подходы]]
 
[[Категория:Подходы]]
 
[[Категория:Модели ЖЦ]]
 
[[Категория:Модели ЖЦ]]

Текущая версия на 02:40, 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 и других гибких методов в системной инженерии:

См. также