[Закрываются] гибкие мифы и неправильные представления
У меня есть действительно глупый, но чрезвычайно полезный при навигации по глубоким древовидным структурам. Поместите это в .bashrc (или подобный):
alias cd6="cd ../../../../../.."
alias cd5="cd ../../../../.."
alias cd4="cd ../../../.."
alias cd3="cd ../../.."
alias cd2="cd ../.."
16 ответов
«Мы делаем Scrum - поэтому нам не нужно (пара | рефакторинг | делать TDD | ...)» Фактически основатели Scrum - Кен и Джефф были говоря, что все высокопроизводительные команды схватки реализуют полный спектр практик экстремального программирования.
Разработка через тестирование не обнаружит всех ошибок / непросто применить ко всему - поэтому мы не будем пытаться ! - Изучение TDD - это не вопрос «все или ничего», и вы научитесь лучше понимать, что тестировать и как это делать эффективно. Я занимаюсь этим уже десять лет, и все еще нахожу лучшие способы сделать это и новые вещи, которые нужно учитывать.
Я могу узнать все, что мне нужно для применения гибких методов, из книги. - Вам нужно учиться на практике, а это часто означает коучинг и встречи с другими людьми, которые могут помочь. Многие вещи идут не так, как надо, когда люди просто пытаются выучить это из книги.
Истерическое (и вполне реальное) «Кандидат должен принимать указания и поддерживать scrum-мастера» (Из спецификации вакансии, которую мне прислали на прошлой неделе ...) - Мастер схватки не должен указывать людям, что им делать . Он / она здесь, чтобы помогать, то есть помогать команде научиться решать вопросы самостоятельно. Это режим массового отказа - наличие мастера схватки, который «командует» людьми!
Говоря о «гибкой методологии» - большой показатель невежества. Во-первых, говорить об «Agile», как будто это что-то особенное, тогда как это очень расплывчатые общие термины для множества разных вещей. Во-вторых, использование «гибкой» методологии - их очень много, и множество различных способов сделать многие из них! В-третьих, многие люди в agile-сообществе столкнулись с негативной реакцией на большие, тяжелые, нагруженные UML методы девяностых годов. Эти люди не склонны использовать слово «методология» ...
Вам нужны особо талантливые люди, чтобы разрабатывать программное обеспечение гибким способом. Джефф Сазерленд говорит, что они рассматривали возможность использования модели «команды главных программистов» для управления командами в банках, но обнаружили, что у них не было достаточно «руководителей». Скрам предназначен для повышения продуктивности многих умеренно способных программистов. Фактически, удаление одного, непропорционально продуктивного члена команды, который не хочет помогать другим, может "разблокировать" посредственных членов команды и довести свою общую продуктивность до того, что с лихвой компенсируют сверхпродуктивного бывшего члена команды ... Во всяком случае, это то, что Джефф говорит ...
Есть довольно много других, связанных с XP , который мы придумали на семинаре по открытому космосу, который я недавно провел: http://xpday-london.editme.com/WhereHasXpGone
Вы совершенно правы в том, что вокруг Agile существует множество мифов, одни исходят извне, а другие - изнутри. Вот еще несколько, которые я подумал добавить в список:
«Вам больше не нужны менеджеры проектов или бизнес-аналитики»
Хотя мы не занимаемся BDUF, и команды сами управляются, как и все по-прежнему нужны люди, чья работа заключается в координации происходящего. А если у вас очень сложный бизнес-сценарий, возможно, вам понадобится кто-то, кто поможет вам разобраться в нем. IME, многие проекты, которые действительно нуждались в PM и BA, все еще нуждаются в них (а те, которым они не нужны сейчас, вероятно, никогда не нуждались в них!). Но, конечно, роли менеджеров по менеджменту и бизнес-менеджеров в мире гибкой разработки обычно различаются, и это может вызывать у людей беспокойство.
«Agile может»
Миф: Agile всегда лучше по сравнению с другими альтернативами.
Факт: в зависимости от размера проекта, требований (особенно гибкости), внешнего расписания и отношения клиентов, это не всегда может быть более продуктивным по сравнению с ортодоксальной методологией.
Самый большой миф, который я видел, заключается в том, что люди думают, что это лучше, чем другие процессы разработки.
Это обычное змеиное масло серебряной пули, которое мы наблюдаем в этой отрасли в течение многих лет.
https://stackoverflow.com/questions/301993/is-agile-development-dead/302060#302060
Миф: «Нет большого дизайна впереди» означает отсутствие дизайна.
Миф: Agile означает отсутствие документации
Факт: Программное обеспечение, работающее в Agile, ценит больше, чем исчерпывающую документацию, но это не означает отсутствие документации вообще. Документация должна быть написана вовремя и в достаточном количестве. И нет, Agile не говорит, что нужно всегда использовать пользовательские истории. Используйте их тогда и только тогда, когда они уместны!
Миф: Agile означает отсутствие плана
Факт: Agile не поддерживает разработку без планирования. Agile использует непрерывное планирование и оценку, чтобы максимизировать рентабельность инвестиций. На самом деле Agile - это управление масштабом.
Миф: Agile означает отсутствие дисциплины
Факт: Agile-разработчики должны быть более дисциплинированными для успеха.
Миф: Agile работает только для тривиальных проектов
Факт: Agile (на самом деле) Scrum здесь) был использован для
- одобрено FDA,
There's no real myths - but anything taken to an extreme will be wrong. An Agile project that does zero design in the hopes of "designing as it goes" will likely fail. A Waterfall project that designs everything down to the last semicolon will likely fail due to budget, time or changed user requirements.
Myth: using Agile development practices is a silver bullet solution to software engineering problems.
Myth: You need to carefully plan and schedule each sprint.
This leads you to do lots and lots of up-front planning so that you can fully plan each sprint.
This leads you to defeat agility and create a waterfall called "Agile".
Миф: При разработке сначала тестирование требует адекватного модульного тестирования вашего проекта.
Факт: Многие разработчики ленивы, а модульные тесты, которые они пишут перед своим кодом, часто бывают слабыми и неадекватными.
Миф: Парное программирование всегда дает лучший код.
Факт: Программисты, как правило, немного антисоциальны и имеют существенно разные мыслительные процессы друг от друга. Когда вы пишете код, кто-то дышит вам в шею, это очень неприятно, и в результате часто возникает напряженная рабочая атмосфера с ухудшением как качества, так и количества кода.
«Рабочее программное обеспечение важнее исчерпывающей документации» означает, что вам не нужна функциональная спецификация ...
Неправильно !!! Это просто означает, что вы можете итеративно сглаживать недостатки вместе с пользователями - говоря как поставщик, вам все равно нужна хорошая документация, чтобы помочь на этапах контроля качества и согласования ...
It has been repeatedly said "Agile design methods do not scale" whereas Agile development will effectively scale to any size if implemented and thought out properly.
Миф : Agile означает XP и Scrum
Факт : Существуют и другие методы, такие как OpenUP, AMDD и т. Д.
Миф: Водопад всегда терпит неудачу.
Реальность: Большая часть программного обеспечения, которое вы используете в вашем проекте Agile, был разработан с водопадом. Даже водопад BDUF, во многих случаях.
Легко узнать, что выставлять счет вашему клиенту. Для нас это всегда самые большие проблемы, потому что мы не знаем, в каком объеме мы можем дать заказчику фиксированную цену, и большинство заказчиков требуют фиксированную цену.
Миф: Agile противоречит безопасности.
Факт: Это верно только в том случае, если вы попытаетесь навязать полномасштабный SDL в стиле водопада (жизненный цикл разработки безопасности) предположительно Agile-командам. Фактически, я разработал и внедрил варианты Agile-SDL во многих организациях, и могу сказать, что включение Agile в Security действительно может обеспечить более высокий и надежный уровень безопасности. для этого просто нужно изменить мышление безопасности - с контроля на видимость и руководство .