Agile — различия между версиями
Admin (обсуждение | вклад) м (→Agile-методологии) |
Admin (обсуждение | вклад) м |
||
| (не показаны 3 промежуточные версии этого же участника) | |||
| Строка 1: | Строка 1: | ||
| − | '''Agile''' (на русский обычно не переводится, хотя иногда говорят о “гибких методах”) — серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. | + | '''Agile''' (на русский обычно не переводится, хотя иногда говорят о “гибких методах”) — [[:Категория:Гибкие методологии разработки ПО|серия подходов к разработке программного обеспечения]], ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. |
В [[Системная инженерия|системной инженерии]] “железных” [[система|систем]] методы agile пока используются мало, но в последние годы ситуация быстро меняется: разработка определения системы в существенной мере оказывается похожей на разработку программного обеспечения, и в ней для разработки моделей могут быть использованы практики, зарекомендовавшие себя при разработке ПО. | В [[Системная инженерия|системной инженерии]] “железных” [[система|систем]] методы agile пока используются мало, но в последние годы ситуация быстро меняется: разработка определения системы в существенной мере оказывается похожей на разработку программного обеспечения, и в ней для разработки моделей могут быть использованы практики, зарекомендовавшие себя при разработке ПО. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Гибкое моделирование == | == Гибкое моделирование == | ||
| Строка 74: | Строка 9: | ||
* При agile-подходе часто '''пренебрегают созданием плана''' («дорожной карты») развития продукта, равно как и '''[[Инженерия требований|управлением требованиями]]''', в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации. | * При agile-подходе часто '''пренебрегают созданием плана''' («дорожной карты») развития продукта, равно как и '''[[Инженерия требований|управлением требованиями]]''', в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации. | ||
* Считается, что работа в agile '''мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом,''' при этом зачастую '''не обращая внимания на правильность кода с точки зрения требований нижележащей платформы''' (подход — «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжёлые к воспроизводству дефекты после реального развёртывания у клиента). Это приводит к снижению качества продукта и накоплению дефектов. | * Считается, что работа в agile '''мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом,''' при этом зачастую '''не обращая внимания на правильность кода с точки зрения требований нижележащей платформы''' (подход — «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжёлые к воспроизводству дефекты после реального развёртывания у клиента). Это приводит к снижению качества продукта и накоплению дефектов. | ||
| − | |||
| − | |||
| − | |||
== Ссылки == | == Ссылки == | ||
| Строка 86: | Строка 18: | ||
* [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 и других гибких методов в системной инженерии:
- организация хода разработок в компании SpaceX. Главная там фраза — focus on tools not rules. А потом test rigorously and often.
- производство автомобиля: видеорассказ, описание автомобиля, eXtreme manufacturing, TDD for hardware. Главное там было — обеспечить высокую скорость изменений, и указывались примерно те же механизмы, что и в SpaceX (обмен информацией через сеть вместо традиционных control boards, даже была оговорка, что ещё лет пять назад это было бы невозможно по причине недоразвитости сетевых сервисов, а лет десять назад всех этих сервисов вообще не существовало).
- lean systems engineering – "бережливая" системная инженерия
- «Kanban and Scrum. Making the most of both» – пример связи подходов lean и agile.
- Впечатляющий пример – как стадион разбили на 12 секторов, и пока один сектор проектировали, предыдущий строили, а пред-предыдущий отделывали (6й сезон 14й фильм из замечательной серии телевизионных документальных фильмов про мастерство инженеров).
См. также
- Параллельная инженерия - разработка систем, по духу близкая к Agile
- Business Agility - модель для гибких организаций