Гибкая разработка [закрывается]

Гибкая разработка не является методологией сама по себе, это общий термин, описывающий несколько гибких методологий (все они относятся к Итеративным и Постепенное развитие - IID - семейство).

alt text http://img62.imageshack.us/img62/6374/dd997578teamprojagileum.png

При подписании Agile Manifesto в 2001 году были представлены следующие методологии: eXtreme Programming ( XP), Scrum, DSDM, адаптивная разработка программного обеспечения (ASD), Crystal, функционально-ориентированная разработка (FDD), прагматическое программирование. Каждый из них разделяет основные ценности Agile Manifesto, но реализует их с немного другим подходом.

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

Scrum и XP (используемые вместе) являются наиболее часто используемыми в настоящее время.

Похоже, вы действительно хотите знать, что люди на самом деле используют в реальном мире. Существует множество сайтов о том, что входит в практику / методологию Agile, а что нет.

Итак, мой опыт работы на моих последних (последние 5 лет) должностях:

1. Никто не использовал парное программирование, за исключением ситуаций паники (исправление серьезной ошибки за нулевое время), менеджеры до сих пор просто не верят этой идее в все - и я говорю ВООБЩЕ, что жаль, поскольку мне это очень нравится.
2. Истории пользователей и пользователи, выбирающие колоду для следующего выпуска - на самом деле не работает, если пользователи действительно не купятся, чего я еще не видел. Пользователи в моем районе всегда говорят, что все имеет первостепенное значение, они не могут жить без всего этого. Лично я просто перефразирую «в каком порядке, по вашему мнению, мне лично следует работать над этими задачами?».
3. Разработка, управляемая тестами - это происходит очень редко, но многие модульные тесты пишутся (правда, уже после того, как код работает), так что почти промахивается imho
4. Непрерывная интеграция - это сильно зависит от команды, в последнюю очередь В течение 5 лет он был у всех моих команд, но часто он терял (сломанная сборка) на несколько дней / недель, прежде чем привлек внимание. Многие люди до сих пор не верят в это.
5. Часто рефакторинг - это на самом деле серьезная поддержка. Рефакторинг - это навык, который, если у вас его нет, может стать серьезной проблемой.
6. Небольшие релизы - это (в моей работе) в любом случае обычно является нормой, хотя, вероятно, выполняется.
7. Стандарты кодирования - да
8. Коллективное владение кодом - все еще довольно часто обвиняют в этом "плохой" модуль на самом деле никогда не исправляется, потому что кодировщик, который его создал, просто исправляет и исправляет, пока он не «заработает».
9. Никаких сверхурочных - почти, но сильно зависит от руководителя группы - я видел худшие вещи (марши смерти), происходящие в нескольких футах от моей команды ...
10. Сначала тесты, когда находят ошибки - это случается по моему опыту. Это очень хорошо.

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

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

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

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

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

Некоторые предложения Agile Software Development легче использовать по сравнению с некоторыми другими. Хотя парное программирование может не иметь реального успеха на практике или даже на ежедневных встречах по схватке, но, по моему опыту, успехом является начало программирования, как только мы получаем достаточно точный набросок программного обеспечения, его требований и функций, никогда забыть о приоритетах, данных самим покупателем. Затем обновление анализа UML при разработке для итерации.

Итерации программного обеспечения, по моему опыту, начинают набирать обороты.

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

Некоторые недавние эмпирические данные о практиках, используемых в промышленности:

Я только что наткнулся на Результаты опроса Agile Practices: июль 2009 г. . Это довольно небольшой набор образцов (123), но он предлагает интересную перспективу. Например, 10 самых эффективных agile-практик (по данным респондентов) были следующими:

1. Непрерывная интеграция
2. Ежедневное встречное совещание
3. TDD для разработчиков
4. Планирование итераций
5. Рефакторинг кода
6. Ретроспективы
7. Парное программирование
8. Активное участие заинтересованных сторон
9. Программное обеспечение с возможностью поставки
10. Отслеживание загрузки

Также есть диаграммы для 10 лучших гибких практик, которые:

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

Практики - не главное

Мы выполняем практики не ради практик. Практики гибкой разработки основаны на следовании принципам гибкости , как описано на веб-сайте манифеста . Наивысший принцип Agile: «удовлетворять клиента за счет своевременной и непрерывной поставки ценного программного обеспечения». Ключевые слова здесь Ранний , Continous и valueable . Если команда не понимает, как принципы управляют практиками, тогда они рискуют стать, как сказал @Guildencrantz, культом карго, не добившись ожидаемого успеха волшебной пули, объявив Agile провалом и отказавшись от этого. Это.

Легче быть Agile в новом проекте, чем преобразовать проект в Agile:

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

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

В нашей команде мы применяем ежедневные стендапы и командное программирование (примерно в половине случаев - зависит от задачи). Однако мы не претендуем на гибкость.

Thoughtworks - одна из компаний, в которых действует гибкая разработка. Узнайте больше об Agile-разработке прямо на веб-сайте Мартина Фаулера .

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

У нас были очень регулярные встречи, которые назывались «стендапами» (что-то вроде agile-термина).

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

Это зависит от компании к компании. Я работаю в компании, которая делает все TDD, все пары, все CI, все время. Команда не боится позвонить вам, если вы отправите код, но не отправили тесты unit / FitNesse, и менее чем через минуту после отправки кода сервер CI запускает весь набор тестов, и если ваш код нарушает сборку, или Эми из тестов терпит неудачу, индикаторы гаснут, и вы помечаете себя как тот, кто нарушил сборку.

Это не самая распространенная ситуация, но есть компаний, которые действительно практикуют Agile.

• Scrum очень популярен (хотя это просто техника управления, а не техническая дисциплина).
• Экстремальное программирование намного менее популярно, хотя применяемый. (Я реализовал множество коммерческих проектов XP - хотя трудно найти команды, которые хотели бы заняться XP.
• Разработка через тестирование (TDD) является частью XP, хотя многие люди этим занимаются (и многие другие говорят, что что они делают ...)

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

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

Гибкая методология - это основа для гибкой разработки.

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

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