Может ли кто-нибудь объяснить гибкую методологию простыми предложениями?
development-process
agile
Чанки патхак
источник
источник
Ответы:
Agile - это много вещей и практик, но я думаю, что ядро всего лишь итеративная разработка.
Итеративный: Подумайте о кучке очень маленьких водопадов. То есть метод водопада (требования-> спецификации-> код-> тест), но вместо того, чтобы делать это в течение года или около того, вы делаете это в течение нескольких недель для получения управляемой части общего объема. проект. В конце итерации / спринта / приращения у вас есть небольшой, но полный и проверенный набор дополнительных функций.
Это позволяет вам быстро изменить ход проекта, если выясняется, что то, что вы делаете, - это не то, что хочет клиент, или потребности бизнеса, или что-то еще. Отсюда и термин «проворный».
источник
Я думаю, что ничто не ставит это лучше, чем сам Agile Manifesto:
Мы раскрываем лучшие способы разработки
программного обеспечения, делая это и помогая другим делать это.
Благодаря этой работе мы пришли к оценке:
Лица и взаимодействие над процессами и инструменты
Работой программного обеспечения более комплексной документация
совместно с клиентами над контрактными переговорами
Реакцией на изменения в течение следующего плана
То есть, хотя в элементах
справа есть ценность, мы слева оцениваем элементы больше.
с http://agilemanifesto.org/
источник
Для меня самая важная идея заключается в следующем:
Изменения в требованиях произойдут, потому что мы вынуждены разрабатывать программное обеспечение в условиях, необходимых для понимания того, что необходимо (начало проекта), а требования станут яснее только в ходе проекта.
Традиционные (водопадные) подходы пытаются смягчить это изменение, заключив всех в контракт в начале проекта, заставив их подписать всеобъемлющие спецификации. Это может работать как CYA, но это не делает никого счастливым, чтобы доставить что-то, что не отвечает потребностям пользователей, особенно если их возражения встречаются с "Хорошо, вы подписали это!"
Гибкие методы предназначены для того, чтобы принять неизбежные изменения, а не оградить их от команды разработчиков. Это делается несколькими способами, главными из которых являются итеративное развитие и постоянное участие заинтересованных сторон в процессе. По моему опыту, в конце концов, все участвующие становятся счастливее, хотя это может быть более неудобно для некоторых типов менеджеров, которые жестко планируют.
источник
В одном предложении это выглядит так:
Это происходит из определения Википедии, и мне это очень нравится. Я выделил основные принципы.
источник
Я хотел бы просто добавить, что Agile НЕ является. Есть много магазинов, которые утверждают, что они Agile, но в некотором смысле это означает, что они не заинтересованы в планировании своих проектов и ожидают, что что-то будет сделано в неоправданно короткий период времени.
Agile! = Нет плана проекта. Трудно обращаться с людьми, которые неявно думают, что утверждение ложно, потому что они, как правило, являются типами управления и не всегда легко противоречат.
источник
Энди уже связался с Agile Manifesto, который, я думаю, чуть ли не охватывает его.
Я думаю, что полезно посмотреть, откуда появился Agile Manifesto. Существовал ряд методологий, которые имели некоторые общие элементы и множество схожих мотивов: экстремальное программирование (XP), Scrum, DSDM, адаптивная разработка программного обеспечения, Crystal, функционально-ориентированная разработка, прагматическое программирование (список из Alistair Cockburn ). Люди, предлагающие эти методологии, решили придумать термин маркетинга, чтобы охватить общие для них вещи, чтобы усилить силу того, что они говорили.
Интересно (в соответствии с тем, что мне сказали) в шорт-листе было несколько имен, которые можно было выбрать вместо «Agile», одно из которых было «Adaptive». Я лично считаю, что одним словом, которое лучше подводит итог, что Agile на самом деле лучше, чем "Agile"!
источник
Использование гибкой методологии сводится к тому, чтобы акцентировать внимание на предоставлении качественных продуктов по сравнению с другими аспектами разработки продуктов, и осознавать, что обратная связь от сообщества пользователей является жизненно важной частью создания качественных продуктов.
Сравните это с традиционным подходом к разработке с использованием «водопада», в котором основное внимание уделяется предварительному проектированию, документированию и определению интерфейса при одновременном снижении акцента на реализации и переходе продукта от разработки к выпуску.
По моему мнению, есть внутреннее качество, которое команда может встроить в продукт, и я вижу это в форме подтверждения того, что продукт функционирует так, как задумал команда разработчиков, и может разумно приспособиться к ожидаемым улучшениям. Есть также качественные факторы, основанные исключительно на восприятии, которые измеряют, насколько продукт отвечает потребностям его пользователей.
Гибкие подходы имеют тенденцию предоставлять продукты итеративно , включая обратную связь с пользователем и обратную связь с разработчиком в каждую итерацию, и способствуют предоставлению каждого приращения функциональности, когда он достигает минимальной жизнеспособности, в качестве функции принуждения для получения частой обратной связи с пользователем и противодействия тенденции действий разработки для длительные периоды времени без обратной связи с его пользователями. На мой взгляд, другие аспекты гибких подходов имеют тенденцию поддерживать эти ключевые принципы.
источник