Agile мифы и заблуждения [закрыто]

какие мифы или заблуждения связаны с Agile?

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


обновление: резюме Agile мифов

  • Agile не позволяет документацию
  • гибкие методы не шкалы
  • Agile-это не план
  • TDD покрывает все потребности модульного тестирования
  • парное программирование всегда приводит к улучшению кода
  • Agile-это решение silver bullet для проблем разработки программного обеспечения (есть решение silver bullet)
  • Agile не нужен передний дизайн
  • мы делаем scrum, поэтому нам не нужно делать TDD, рефакторинг парного программирования и т. д.
  • можно узнать Agile из книги
  • Agile работает только для тривиальных проекты
  • Agile всегда использует "истории пользователей"

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

18 ответов


  1. " мы делаем Scrum-поэтому нам не нужно (pair / refactor | do TDD/...)" на самом деле основатели Scrum - Кен и Джефф говорили, что все высокопроизводительные команды scrum реализуют полный спектр экстремальных методов программирования.

  2. Test-driven development не найдет все ошибки / нелегко применить ко всему - поэтому мы не будем пытаться! - изучение TDD не является "все или ничего", и вы получаете лучше судить, что тестировать и как это делать эффективно. Я делаю это уже десять лет, и я все еще нахожу лучшие способы сделать это и новые вещи для рассмотрения.

  3. Я могу узнать все, что мне нужно для применения гибких методов из книги. - вам нужно учиться делать, и это часто означает коучинг и встречи с другими людьми, которые могут помочь. Многие вещи идут не так, когда люди просто пытаются узнать это из книги.

  4. истерика (и довольно real)"кандидат должен взять направление и поддержать scrum master "(из спецификации задания, которую я отправил на прошлой неделе...) - scrum master не должен говорить людям, что делать. Он / она там, чтобы облегчить - то есть помочь команде научиться разбираться в себе. Это массовый режим отказа-наличие мастера scrum, который "командует" людьми!

  5. говоря о "гибкой методологии" - большой индикатор cluelessness. Во-первых, говорить о "agile", как о конкретной вещи, тогда как это очень расплывчатые зонтичные термины для многих разных вещей. Во-вторых, использование "гибкой" методологии-их множество, и множество различных способов их выполнения! В-третьих, многие люди в сообществе agile попали сюда в ответ на большие, тяжелые UML-методы девяностых годов. Эти люди не склонны использовать слово "методология"...

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

здесь довольно много других связанных с XP что мы придумали в мастерской открытого пространства, которую я недавно вел:http://xpday-london.editme.com/WhereHasXpGone


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

неправильно!!! Это просто означает, что вы можете сгладить морщины итеративно с пользователями - говоря как поставщик, вам все еще нужна хорошая документация, чтобы помочь с фазами QA и sign-off...


миф: использование гибких методов разработки-это решение проблемы разработки программного обеспечения.


миф: тест-первая разработка заставляет ваш проект иметь адекватное модульное тестирование.

факт: многие разработчики ленятся, и модульные тесты, которые они пишут перед своим кодом, часто слабы и неадекватны.

миф: парное программирование всегда приводит к улучшению кода.

факт: программисты, как правило, немного антисоциальны и имеют значительно отличающиеся мыслительные процессы друг от друга. Когда кто-то дышит тебе в затылок, когда ты кодируешь, это очень важно. неприятно, а результатом зачастую является напряженная рабочая атмосфера со снижением как качества кода, так и его количества.


миф: Agile означает отсутствие документации

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

миф: Agile означает отсутствие плана

факт: Agile не поддерживает разработку без планирования. Проворный использует непрерывное планирование и оценку для максимизации ROI. На самом деле, Agile-это управление областью.

миф: Agile означает отсутствие дисциплины

факт: Agile разработчики должны быть более дисциплинированными для успеха.

миф: Agile работает только для тривиальных проектов

факт: Agile (на самом деле Scrum здесь) использовался для

  • одобренное FDA, жизненно важное программное обеспечение для рентгеновских лучей и МРТ,
  • финансовое оплаты приложения
  • 24x7 с 99.99999% требований к uptime,
  • мульти-терабайтные приложения базы данных,
  • etc

миф: Agile не масштабируется

факт: Сазерленд использовал Scrum в группах по 500+, Кон использовал Scrum в группах по 100+


Миф: "нет большого дизайна спереди" означает отсутствие дизайна.


миф: водопад всегда терпит неудачу.

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


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


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


миф: вам нужно тщательно планировать и планировать каждый спринт.

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

Это приводит вас к поражению ловкости и созданию водопада под названием "Agile".


самый большой миф я видел, что люди думают, что это лучше, чем другие процессы развития.

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

https://stackoverflow.com/questions/301993/is-agile-development-dead/302060#302060


миф: Agile всегда является лучшим вариантом по сравнению с другими альтернативами.

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


миф: Agile означает XP и Scrum

факт: есть и другие практики, такие как OpenUP, AMDD и т. д.


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


большой поток. Хотя я не предлагаю ничего нового в своем соответствующем блоге, я иллюстрирую две главные причины, почему Agile терпит неудачу, когда она терпит неудачу. 1) отсутствие предварительных требований (принятие "начать кодирование с неполными требованиями" до крайности) и 2) отсутствие адекватных модульных тестов (потому что изменение произойдет - и модульные тесты являются самым быстрым способом улавливания всех точек разрыва в результате ИЗМЕНЕНИЕ.)

http://www.anujvarma.com/BlogEngine.net/post/2010/11/03/Agile-versus-Flat-Footed-development.aspx


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

"вам больше не нужны руководители проектов или бизнес-аналитики"

хотя мы не делаем BDUF и команды к саморуководству, поскольку все данные там по-прежнему необходимо для людей, чья работа состоит в координации, что происходит. И если у вас очень сложный бизнес-сценарий, вы вполне можете нужен кто-то, кто поможет тебе разобраться в этом. IME, многие проекты, которые действительно нуждались в PMs и BAs, все еще нуждаются в них (и те, которые не нуждаются в них сейчас, вероятно, никогда не нуждались в них!). Но, конечно, роли ПМС и бас, как правило, различны в гибком мире, и это может заставить людей чувствовать себя неловко.

"Agile не может использоваться для проектов с фиксированной ценой"

Это может, но это совсем немного сложнее. Тем более, что мы все знаем, что" фиксированная цена "действительно означает" фиксированная цена, объем и время"...

"мы не делаем BDUF, мы делаем все это, как мы идем"

единственный способ работы-JEDUF (достаточно дизайна спереди). Иногда вам нужно больше, иногда вы можете обойтись меньшим, но вы не делаете больше, чем вам нужно в этот момент.


миф: живчик является анти-thetical безопасности.

факт: Это верно только в том случае, если вы пытаетесь заставить полномасштабный SDL в стиле водопада (жизненный цикл разработки безопасности) на предположительно гибкие команды. На самом деле, я разработал и реализовал варианты Agile-SDL во многих организациях, и я могу сказать, что ставлю Agile на безопасность, на самом деле может позволить себе более высокий, более высокий уровень безопасности. это просто требует изменения безопасности мышление-от управления to видимость и руководством.


Если вы не покажете реальную ценность с agile, он потерпит неудачу. И обанкротиться так же, как обанкротить компанию. Переход к agile только потому, что это "agile" заставляет вас выглядеть так же глупо, как CIO в этом видео:

http://www.youtube.com/watch?v=nvks70PD0Rs

Джон