Введение в гибкие ценности

Чтобы узнать о ценностях гибкого программного обеспечения, нам нужно сначала узнать, что такое гибкое программное обеспечение и необходимость его разработки. Гибкая методология подразумевает, что программное обеспечение является инкрементным, оно увеличивается за счет регулярного добавления. Этот подход предлагает новую версию или подход в короткие промежутки времени.

Этот гибкий процесс отличается от другого традиционного подхода к разработке программного обеспечения, когда потребности и требования пользователей компилируются, а затем, в конце концов, программное обеспечение создается сразу.

Agile Manifesto - это декларация, в которой четко говорится о ключевых ценностях и принципах, которым должны следовать разработчики программного обеспечения для руководства своей работой. Это основа гибкого движения. Это четыре ценности и двенадцать принципов в качестве руководства.

4 Agile Values ​​OF Agile Manifesto

Ниже приведены 4 значения Agile Manifesto:

1. Команда и коммуникация выбраны из-за процедуры и инструментов

Первое значение делает больший упор на командную работу и общение. Поскольку все мы знаем, что для создания программного обеспечения требуется команда людей, а не инструменты. Человек может иметь сложный набор инструментов, но для разработки программного обеспечения ему необходимо эффективно работать с командой с продуктивными взаимодействиями.

Инструменты и процессы, безусловно, являются ключом к разработке программного обеспечения, но они должны быть в руках квалифицированной команды, чтобы получить результат, а не наоборот.

2. Работа программного обеспечения над всеобъемлющей документацией

Много времени было потрачено на документацию разработки продукта, такую ​​как техническая спецификация, технические требования, планы испытаний, проектная документация и утверждение, требуемое для каждого. Вид документации, созданной для них, был очень подробным, и многие из них даже не упоминались во время процесса проекта. Команда хотела, чтобы готовый продукт соответствовал спецификации, поэтому документы были ориентированы на многое. Но конечный продукт все равно будет другим, поскольку актуальность будет потеряна.

Agile оптимизирует эти документы в такой форме, которая дает разработчику только то, что необходимо для выполнения работы, не отвлекаясь на мелкие детали. Agile не говорит, что документация не нужна. Все это говорит о том, что клиенты предпочитают работающее программное обеспечение, а не документ, который, возможно, также не будет рассматриваться. Всякий раз, когда возникает необходимость в изменениях, гибкая команда с готовностью принимает их и вносит постоянные изменения.

3. Общение с клиентом, предпочитающим подписанные соглашения

Успешные команды разработчиков работают в тесном контакте со своими клиентами и регулярно общаются с ними. Как только вы услышите мнение своих клиентов, вы получите обратную связь, и вы поймете, чего именно они хотят от вашего продукта.

Будет чрезвычайно полезно, если правовые отношения с клиентом могут быть отделены от личных отношений. Это будет стимулировать общение, а знание их мыслей, мнений и предпочтений приведет к получению более удовлетворительного продукта.

Коммуникация также помогает клиенту улучшить свое видение и пересмотреть свои требования, если это необходимо в ходе проекта.

В традиционной разработке программного обеспечения после определения требований продукт можно увидеть только тогда, когда он будет готов. Но Agile бросает вызов этому, позволяя клиенту участвовать во всей процедуре.

4. С готовностью принимать изменения, а не следовать строгому плану

Считается, что изменения являются дорогостоящими и трудоемкими, и их следует избегать любой ценой. Это так, потому что мы уделяем ненужное внимание документации и разрабатываем планы доставки. Мы склонны придерживаться сроков и спецификаций продукта больше, чем требуется.

Важно понимать, что изменения неизбежны. Будет чрезвычайно полезно принять изменения и спланировать их. Всегда должно быть место для изменений, иначе план скоро устареет.

Согласно Agile, изменения - это не затраты, а необходимая обратная связь, которая приводит к улучшению проекта. Изменения, инициированные обратной связью, повышают ценность проекта.

Гибкие методологии позволяют гибкой команде изменять процесс в процессе работы и делать его пригодным для команды, а не наоборот. Таким образом, первый принцип общения со всей командой должен быть упомянут здесь. Разработчики команды должны быть в курсе изменений.

Всегда следует помнить о конечной цели вашего проекта, и если есть какие-либо препятствия, команда должна быть осведомлена об этом и напоминать об этих 4 ценностях.

Двенадцать принципов гибкой разработки

Эти принципы являются тестом, чтобы определить, гибки ли вы:

  1. Удовлетворение клиентов благодаря своевременной и постоянной доставке ценной работы. Клиенты счастливее, если они получают работающее программное обеспечение через регулярные промежутки времени, а не ждут длительных интервалов между выпусками.
  2. Принять изменение в течение всего процесса: всякий раз, когда требуется изменить требование или функцию, это должно быть сделано с готовностью.
  3. Часто выпускайте эффективное программное обеспечение: поскольку команда работает в области спринтов, она обеспечивает регулярную поставку рабочего программного обеспечения.
  4. Сотрудничество между заинтересованными сторонами и разработчиками: лучшие решения принимаются, когда деловая и техническая команда работают вместе.
  5. Мотивация , поддержка и доверие . Мотивация команды - вот ключ. Всякий раз, когда проект начинается, полная поддержка команды, ободряющая атмосфера и вера в команду будут поддерживать их.
  6. Обсуждения один на один . Самый важный метод передачи любой информации всей команде - это проведение обсуждений один на один.
  7. Программное обеспечение работает: прогресс может быть измерен только программным обеспечением, которое успешно работает в то время.
  8. Гибкие процедуры способствуют непрерывному развитию: промоутеры, планировщики и клиенты должны быть в состоянии прогрессировать.
  9. Важность для техники: правильные навыки и хороший дизайн обеспечивают постоянное улучшение продукта, поддерживая темп и поддерживая изменения.
  10. Сохраняйте это простым: развивайтесь достаточно, чтобы выполнить работу, которая сейчас выполняется,
  11. Самоорганизующиеся команды. Самоорганизующиеся команды - это место, где появляются лучшая архитектура, требования и дизайн.
  12. Регулярные размышления о том, как стать более эффективными: команда должна продолжать работать над тем, чтобы стать более продуктивной и соответственно адаптироваться.

Рекомендуемые статьи

Это было руководство по гибким ценностям. Здесь мы обсудили Концепцию, 4 главных ценности и Двенадцать Принципов Agile Development. Вы также можете просмотреть наши другие Предлагаемые статьи, чтобы узнать больше -

  1. Что такое Agile?
  2. Что такое гибкое управление проектами?
  3. Microsoft Project Management
  4. Вопросы по управлению проектами
  5. 8 Важная задача написать шаблон плана тестирования