Agile — различия между версиями
Admin (обсуждение | вклад) |
Admin (обсуждение | вклад) м |
||
| (не показано 19 промежуточных версий этого же участника) | |||
| Строка 1: | Строка 1: | ||
| − | '''Agile''' (на русский обычно не переводится, хотя иногда говорят о “гибких методах”) — серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. | + | '''Agile''' (на русский обычно не переводится, хотя иногда говорят о “гибких методах”) — [[:Категория:Гибкие методологии разработки ПО|серия подходов к разработке программного обеспечения]], ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. |
| − | В системной инженерии “железных” систем методы agile пока используются мало, но в последние годы ситуация быстро меняется: разработка определения системы в существенной мере оказывается похожей на разработку программного обеспечения, и в ней для разработки моделей могут быть использованы практики, зарекомендовавшие себя при разработке ПО. | + | В [[Системная инженерия|системной инженерии]] “железных” [[система|систем]] методы agile пока используются мало, но в последние годы ситуация быстро меняется: разработка определения системы в существенной мере оказывается похожей на разработку программного обеспечения, и в ней для разработки моделей могут быть использованы практики, зарекомендовавшие себя при разработке ПО. |
| + | == Гибкое моделирование == | ||
| + | Метод описания архитектуры [[программная система|программной системы]], который следует идее того, что содержимое важнее представления. Это обеспечивает простоту, понятность, достаточную точность и единообразие создаваемых моделей. Простота документа гарантирует активное участие заинтересованных сторон в моделировании [[рабочий продукт|артефактов]]. Более подробно этот подход рассматривается в книге Скотта Амблера «Гибкие технологии: экстремальное программирование и унифицированный процесс разработки» (J. Wiley, ISBN-10: 0471202827, ISBN-13: 978-0471202820; Питер, ISBN 5-94723-545-5, 0-471-20282-7). | ||
| − | == | + | == Критика == |
| − | + | * При agile-подходе часто '''пренебрегают созданием плана''' («дорожной карты») развития продукта, равно как и '''[[Инженерия требований|управлением требованиями]]''', в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации. | |
| − | + | * Считается, что работа в agile '''мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом,''' при этом зачастую '''не обращая внимания на правильность кода с точки зрения требований нижележащей платформы''' (подход — «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжёлые к воспроизводству дефекты после реального развёртывания у клиента). Это приводит к снижению качества продукта и накоплению дефектов. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | * | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
== Ссылки == | == Ссылки == | ||
| − | Примеры внедрения agile и других гибких методов в системной инженерии: | + | Примеры внедрения agile и других гибких методов в [[Системная инженерия|системной инженерии]]: |
| − | * [ | + | * [http://sewiki.ru/images/0/00/CASE2012_2-4_Muratore_presentation.pdf организация хода разработок в компании SpaceX]. Главная там фраза — '''focus on tools not rules'''. А потом '''test rigorously and often'''. |
* производство автомобиля: [http://www.youtube.com/watch?v=x8jdx-lf2Dw видеорассказ], [http://wikispeed.org/the-car/ описание автомобиля], [http://scrumlab.scruminc.com/articles.html/_/open/extreme-manufacturing-r93 eXtreme manufacturing], [http://wikispeed.org/2013/07/tdd-for-hardware/ TDD for hardware]. Главное там было — обеспечить высокую скорость изменений, и указывались примерно те же механизмы, что и в SpaceX (обмен информацией через сеть вместо традиционных control boards, даже была оговорка, что ещё лет пять назад это было бы невозможно по причине недоразвитости сетевых сервисов, а лет десять назад всех этих сервисов вообще не существовало). | * производство автомобиля: [http://www.youtube.com/watch?v=x8jdx-lf2Dw видеорассказ], [http://wikispeed.org/the-car/ описание автомобиля], [http://scrumlab.scruminc.com/articles.html/_/open/extreme-manufacturing-r93 eXtreme manufacturing], [http://wikispeed.org/2013/07/tdd-for-hardware/ TDD for hardware]. Главное там было — обеспечить высокую скорость изменений, и указывались примерно те же механизмы, что и в SpaceX (обмен информацией через сеть вместо традиционных control boards, даже была оговорка, что ещё лет пять назад это было бы невозможно по причине недоразвитости сетевых сервисов, а лет десять назад всех этих сервисов вообще не существовало). | ||
| − | * [http://www.lean- | + | * [http://www.lean-systems-engineering.org/downloads-products/lean-enablers-for-systems-engineering/downloads-lean-enabler-for-systems-engineering/ lean systems engineering] – "[[Бережливое производство|бережливая]]" системная инженерия |
| − | * | + | * [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 серии телевизионных документальных фильмов про мастерство инженеров]). | |
| + | == См. также == | ||
| + | * [[Параллельная инженерия]] - разработка систем, по духу близкая к 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 - модель для гибких организаций