Что такое гибкая методология? [закрыто]

27

Может ли кто-нибудь объяснить гибкую методологию простыми предложениями?

Чанки патхак
источник
3
по словам моего преподавателя CompSci в колледже, «метод водопада, просто быстрее»
Malfist
11
@Malfist будем надеяться, что он / она останется в академической среде, где ущерб ограничен мозгами ;-)
Стивен А. Лоу
@ Стивен А. Лоу, печально то, что третья глава нашего учебника - «Гибкая разработка программного обеспечения», и он до сих пор не знает, что это такое.
Malfist
2
@Malfist В середине 1990-х я случайно оказался в большом студенческом городке в крупном городе и побрел поговорить с деканом CS. Он оказался в и в болтливом настроении, поэтому мы немного поговорили о состоянии дел и о том, как это отразилось на учебной программе колледжа. Он сказал мне, что «объектно-ориентированное программирование - просто прихоть, мы его здесь не учим». Очень грустный.
Стивен А. Лоу
1
Гибкая методология похожа на китайский язык - вы не получите его, пока не изучите его;)
Работа

Ответы:

22

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

Итеративный: Подумайте о кучке очень маленьких водопадов. То есть метод водопада (требования-> спецификации-> код-> тест), но вместо того, чтобы делать это в течение года или около того, вы делаете это в течение нескольких недель для получения управляемой части общего объема. проект. В конце итерации / спринта / приращения у вас есть небольшой, но полный и проверенный набор дополнительных функций.

Это позволяет вам быстро изменить ход проекта, если выясняется, что то, что вы делаете, - это не то, что хочет клиент, или потребности бизнеса, или что-то еще. Отсюда и термин «проворный».

Fishtoaster
источник
Это действительно не правильный ответ. Agile - это не методология, это философия.
Рибальд Эдди
32

Я думаю, что ничто не ставит это лучше, чем сам Agile Manifesto:

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

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

То есть, хотя в элементах
справа есть ценность, мы слева оцениваем элементы больше.

с http://agilemanifesto.org/

Энди Лоури
источник
1
Единственный недостаток в том, что, если вы не видели плохой процесс, манифест просто не оправдывает себя. Чтобы понять, что говорит манифест, нужно сравнить с плохим. Тем не менее, +1, потому что слишком много людей путают Agile и Scrum в эти дни. И даже тогда они путают SCRUM со Scrum + XP.
МВД
2
Однако Agile иногда может противоречить самому себе. По сути, «мы ценим гибкость, но мы обесцениваем инструменты и процессы, необходимые для достижения этой гибкости». Хорошие, гибкие инструменты абсолютно необходимы для реагирования на изменения. например, миграции Ruby-on-Rails против чьей-то самодельной полуобжаренной системы ORM, для которой может потребоваться неделя, чтобы внести простое изменение в модель данных.
user8865
2
Просто интересно, как «отдельные лица и взаимодействия» могут заменить «процессы и инструменты» или как «работающее программное обеспечение может противоречить всеобъемлющей документации»? Все это разные вещи ... Неважно, я не влюбился в Agile, и я думаю, что я не буду.
NoChance
13

Для меня самая важная идея заключается в следующем:

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

Традиционные (водопадные) подходы пытаются смягчить это изменение, заключив всех в контракт в начале проекта, заставив их подписать всеобъемлющие спецификации. Это может работать как CYA, но это не делает никого счастливым, чтобы доставить что-то, что не отвечает потребностям пользователей, особенно если их возражения встречаются с "Хорошо, вы подписали это!"

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

JohnFx
источник
6

В одном предложении это выглядит так:

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

Это происходит из определения Википедии, и мне это очень нравится. Я выделил основные принципы.


источник
3

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

Agile! = Нет плана проекта. Трудно обращаться с людьми, которые неявно думают, что утверждение ложно, потому что они, как правило, являются типами управления и не всегда легко противоречат.

Q303
источник
С тех пор, как я задал вопрос до даты, я был частью некоторых из таких компаний, и я согласен с вами.
Чанки Патхак
Согласовано. Многие люди гибкие - это просто дешевый способ делать вещи.
SmallChess
2

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

Я думаю, что полезно посмотреть, откуда появился Agile Manifesto. Существовал ряд методологий, которые имели некоторые общие элементы и множество схожих мотивов: экстремальное программирование (XP), Scrum, DSDM, адаптивная разработка программного обеспечения, Crystal, функционально-ориентированная разработка, прагматическое программирование (список из Alistair Cockburn ). Люди, предлагающие эти методологии, решили придумать термин маркетинга, чтобы охватить общие для них вещи, чтобы усилить силу того, что они говорили.

Интересно (в соответствии с тем, что мне сказали) в шорт-листе было несколько имен, которые можно было выбрать вместо «Agile», одно из которых было «Adaptive». Я лично считаю, что одним словом, которое лучше подводит итог, что Agile на самом деле лучше, чем "Agile"!

FinnNk
источник
2

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

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

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

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

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