Гибкие мифы и заблуждения
Какие мифы или заблуждения связаны с Agile?
Существует множество заблуждений, связанных с Agile, в которые может впасть средний новичок. Каковы неправильные представления в Agile мире и как вы обосновываете, что это действительно неправильное представление?
Обновление: краткое изложение гибких мифов
- Agile не позволяет документацию
- Гибкие методы не масштабируются
- Agile означает отсутствие плана
- TDD покрывает все потребности модульного тестирования
- Парное программирование всегда приводит к лучшему коду
- Agile - это решение для разработки программного обеспечения с помощью серебряной пули (есть решение с использованием серебряной пули)
- Agile не требует предварительного дизайна
- Мы занимаемся скрамом, поэтому нам не нужно заниматься TDD, рефакторингом парного программирования и т. Д.
- Изучить Agile можно из книги
- Agile работает только для тривиальных проектов
- Agile всегда использует "Истории пользователей"
Прочитайте следующие ответы для получения дополнительной информации о вышеупомянутых мифах и для большего количества мифов.
18 ответов
"Мы занимаемся Scrum - поэтому нам не нужно (пара | рефакторинг | делать TDD | ...)" На самом деле основатели Scrum - Кен и Джефф говорят, что все высокопроизводительные команды разработчиков Scrum реализуют весь спектр экстремальных практик программирования.
Разработка через тестирование не найдет всех ошибок / не легко применить ко всему - поэтому мы не собираемся пробовать! - Обучение TDD - это не "все или ничего", и вы становитесь лучше в оценке того, что тестировать и как делать это эффективно. Я делаю это уже десять лет, и я все еще нахожу лучшие способы сделать это и новые вещи, чтобы рассмотреть.
Я могу узнать все, что мне нужно, чтобы применить гибкие методы из книги. - Вы должны учиться на практике, а это часто означает тренировку и знакомство с другими людьми, которые могут помочь. Многие вещи идут не так, когда люди просто пытаются узнать это из книги.
Истеричный (и вполне реальный) "Кандидат должен принять руководство и поддержать мастера схватки" (Из спецификации работы, которую мне прислали на прошлой неделе...) - Мастер схватки не должен говорить людям, что делать. Он / она здесь для того, чтобы помогать - то есть помогать команде учиться самим разбираться. Это огромный провал - наличие мастера схватки, который "командует" людьми!
Разговор о "гибкой методологии" - большой показатель невежества. Во-первых, говорить о "гибкой", как будто это специфическая вещь, тогда как это очень расплывчатые зонтичные термины для многих разных вещей. Во-вторых, использование "гибкой" методологии - их множество, и множество разных способов их выполнения! В-третьих, многие люди в гибком сообществе попали сюда в ответ на большие, тяжелые UML-методы девяностых. Эти люди не склонны использовать слово "методология"...
Вам нужны особенно талантливые люди для разработки программного обеспечения гибким способом. Джефф Сазерленд говорит, что они рассматривали возможность использования модели "команда главного программиста" для управления командами в банках, но обнаружили, что у них не было достаточно "начальников". Scrum разработан для того, чтобы добиться максимальной производительности от множества программистов со средними способностями. Фактически удаление одного, непропорционально продуктивного члена команды, который не хочет помогать другим, может "разблокировать" посредственных членов команды и довести их совокупную производительность до более чем компенсации сверхпродуктивного бывшего члена команды... Вот что Джефф все равно говорит...
Есть довольно много других, связанных с XP, которые мы придумали на семинаре по открытому пространству, который я недавно провел: http://xpday-london.editme.com/WhereHasXpGone
"Работа программного обеспечения над всеобъемлющей документацией" означает, что вам не нужны функциональные спецификации...
Неправильно!!! Это просто означает, что вы можете итеративно сгладить морщины с пользователями - выступая в качестве поставщика, вам все еще нужна хорошая документация, чтобы помочь с фазами QA и выхода из системы...
Миф: использование Agile-разработок - это решение для разработки программного обеспечения.
Миф: разработка в первую очередь вынуждает ваш проект пройти адекватное модульное тестирование.
Факт: многие разработчики ленивы, и модульные тесты, которые они пишут перед написанием своего кода, часто бывают слабыми и неадекватными.
Миф: парное программирование всегда приводит к лучшему коду.
Факт: программисты, как правило, слегка антисоциальны и имеют значительно отличающиеся мыслительные процессы друг от друга. Когда кто-то дышит вам в шею, когда вы пишете код, это очень неприятно, и результатом этого часто является напряженная рабочая атмосфера со снижением как качества, так и количества кода.
Миф: Agile означает отсутствие документации
Факт: гибкое работающее программное обеспечение - это больше, чем полная документация, но это вовсе не означает отсутствие документации. Документация должна быть написана как раз вовремя и достаточно. И нет, Agile не говорит, что нужно всегда использовать пользовательские истории. Используйте их тогда и только тогда, когда они уместны!
Миф: Agile означает отсутствие плана
Факт: Agile не поддерживает разработку без планирования. Agile использует непрерывное планирование и оценку, чтобы максимизировать рентабельность инвестиций. На самом деле Agile - это управление областью действия.
Миф: проворный означает отсутствие дисциплины
Факт: Agile разработчики должны быть более дисциплинированными для достижения успеха.
Миф: Agile работает только для тривиальных проектов
Факт: Agile (на самом деле Scrum здесь) использовался для
- FDA-утвержденное, жизненно важное программное обеспечение для рентгеновских и МРТ-исследований,
- Финансовые платежные приложения,
- 24x7 с требованиями к времени безотказной работы 99,9999%,
- Многотерабайтные приложения базы данных,
- так далее
Миф: Agile не масштабируется
Факт: Сазерленд использовал Scrum в группах по 500+, Кон использовал Scrum в группах по 100+
Миф: "Нет большого дизайна впереди" означает отсутствие дизайна.
Миф: Водопад всегда терпит неудачу.
Реальность: Большая часть программного обеспечения, которое вы используете в своем гибком проекте, была разработана с использованием Waterfall. Даже BDUF водопад, во многих случаях.
Там нет настоящих мифов - но все, что доведено до крайности будет неправильно. Agile-проект, который не разрабатывает дизайн в надежде на "проектирование как есть", скорее всего потерпит неудачу. Проект "Водопад", который проектирует все до последней точки с запятой, скорее всего потерпит неудачу из-за бюджета, времени или изменившихся требований пользователя.
Неоднократно говорилось, что "Agile-методы проектирования не масштабируются", тогда как Agile-разработка эффективно масштабируется до любого размера, если она реализована и продумана должным образом.
Самый большой миф, который я видел, состоит в том, что люди думают, что это лучше, чем другие процессы разработки.
Это обычное змеиное масло с серебряной пулей, которое мы наблюдаем в этой отрасли в течение многих лет.
https://stackru.com/questions/301993/is-agile-development-dead/302060
Миф: Вы должны тщательно планировать и планировать каждый спринт.
Это заставляет вас делать много заблаговременного планирования, чтобы вы могли полностью спланировать каждый спринт.
Это приводит вас к победе над ловкостью и созданию водопада под названием "Ловкий".
Отличная тема. Хотя я не предлагаю ничего нового в своем блоге, я иллюстрирую две главные причины, по которым Agile терпит неудачу, когда она терпит неудачу. 1) Отсутствие предварительных требований (доведение "начинающего кодирования с неполными требованиями" до крайности) и 2) Отсутствие адекватных модульных тестов (потому что произойдет ИЗМЕНЕНИЕ - и модульные тесты - это самый быстрый способ отловить все критические точки, возникающие в результате МЕНЯТЬ).
http://www.anujvarma.com/BlogEngine.net/post/2010/11/03/Agile-versus-Flat-Footed-development.aspx
Миф: Agile означает XP и Scrum
Факт: существуют другие практики, такие как OpenUP, AMDD и т. Д.
Легко узнать, что взимать с вашего клиента. Это всегда самые большие проблемы для нас, потому что мы не знаем масштабов проекта, мы не можем дать клиенту фиксированную цену, и большинство клиентов требует фиксированную цену.
Миф: Agile всегда лучший вариант по сравнению с другими альтернативами.
Факт: в зависимости от размера проекта, требований (особенно гибкости такого), внешнего графика и отношения с клиентом, он не всегда может быть более продуктивным по сравнению с ортодоксальной методологией.
Если вы не показываете реальную ценность с Agile, он потерпит неудачу. И потерпеть неудачу с треском, как с банкротом. Если вы будете проворны из-за того, что это "проворно", вы будете выглядеть глупо, как ИТ-директор в этом видео:
http://www.youtube.com/watch?v=nvks70PD0Rs
Джон
Миф: Agile противоречит безопасности.
Факт: Это верно только в том случае, если вы попытаетесь навязать полномасштабный SDL в стиле водопада (жизненный цикл разработки безопасности) предположительно гибким командам. На самом деле, я разработал и внедрил варианты Agile-SDL во многих организациях, и я могу сказать, что включение Agile в Security может обеспечить более высокий и надежный уровень безопасности. это просто меняет мышление безопасности - от контроля до видимости и руководства.
Вы совершенно правы, что вокруг Agile существует множество мифов, некоторые приходят извне, а другие - изнутри. Вот еще несколько идей, которые я хотел бы добавить в список:
"Вам больше не нужны руководители проектов или бизнес-аналитики"
Хотя мы не занимаемся BDUF, а команды руководствуются сами собой, поскольку по мере роста масштабов все еще существует потребность в людях, чья работа координирует происходящее. И если у вас очень сложный бизнес-сценарий, вам может понадобиться кто-то, кто поможет вам разобраться в этом. IME, многие проекты, которые действительно нуждались в PM и BA, все еще нуждаются в них (а те, которые не нуждаются в них сейчас, вероятно, никогда не нуждались в них!). Но, конечно же, роли менеджеров и менеджеров в Agile-мире, как правило, различны, и это может вызывать беспокойство у людей.
"Agile нельзя использовать для проектов с фиксированной ценой"
Может, но это немного сложнее. Тем более, что мы все знаем, что "фиксированная цена" действительно означает "фиксированная цена, объем и время"...
"Мы не делаем BDUF, мы делаем все по ходу дела"
Единственный способ работать - это JEDUF (Just Enough Design Up Front). Иногда вам нужно больше, иногда вы можете обойтись меньшим, но в этот момент вы не делаете больше, чем нужно.