Категория:Гибкие методологии разработки ПО — различия между версиями
Admin (обсуждение | вклад) (Новая страница: «''Основная статья: Agile'' Категория:Методологии разработки ПО») |
Admin (обсуждение | вклад) м (→Agile-методологии) |
||
(не показана одна промежуточная версия этого же участника) | |||
Строка 1: | Строка 1: | ||
− | '' | + | |
+ | == 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, экстремальное программирование). | ||
+ | * '''[[TDD]]''' (Test-driven development, разработка через тестирование). | ||
+ | * '''[[BDD]]''' (Behavior-driven development, разработка через поведение) - ответвление от TDD. | ||
+ | * '''[[DevOps]]''' (development & operations) — методология активного взаимодействия специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга для обеспечения качества продукта. | ||
+ | |||
+ | == См. также == | ||
+ | [[Agile]] | ||
[[Категория:Методологии разработки ПО]] | [[Категория:Методологии разработки ПО]] |
Текущая версия на 02:45, 27 августа 2019
Содержание
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, экстремальное программирование).
- TDD (Test-driven development, разработка через тестирование).
- BDD (Behavior-driven development, разработка через поведение) - ответвление от TDD.
- DevOps (development & operations) — методология активного взаимодействия специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга для обеспечения качества продукта.