Как разобраться во всем этом Agile?
Agile, Scrum, XP, парное программирование, Lean. Если вы слышали какие-то из этих новомодных слов, но в вашей голове никак не вырисовывается общая картина — вам сюда.
На самом деле, все это не так сложно.
Проблема в том, что почему-то никто не хочет писать об этом просто. Из статьи в Википедии вы узнаете, что
Agile — это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения.
Ух ты.
По Agile , Scrum и всем остальным новым словам пишется множество книг, продаются колоды карт, разная атрибутика, проводятся тренинги и семинары. Можно даже пройти сертификацию.
Но, это, правда, не так сложно. По-моему проблема многих авторов книг о гибких методологиях разработки — это то, что они фокусируются на частном, вместо того, чтобы просто объяснить суть и дать читателю возможность найти частное в своем конкретном случае.
Давайте попробуем разобраться.
Как бывает обычно
Вот вам такая ситуация. Приходит, значит, к вам заказчик и говорит: «Мне нужно сделать такой-то программный продукт. Оцени-ка мне сроки и стоимость.».
Увещевать, что оценка будет очень неточной, бесполезно — никто вас не поймет. Клиента можно понять — ему ведь тоже нужны какие-то ориентиры. Да и принято так.
И тогда, устав спорить, вы говорите: «А напишите мне все, что вы хотите, чтобы в этом программном продукте было». Надо же на чем-то оценку делать.
Дальше составляется Документ. ТЗ, спецификация, как угодно. Клиент вписывает туда все,что может придумать. Производится оценка. Как в анекдоте: «Обещанный срок сдачи — это аккуратно рассчитанная дата окончания проекта плюс шесть месяцев.».
Начинается разработка.
Когда половина пути пройдена, клиент понимает, что одна часть требований была ошибочной, а другая просто устарела. Попытки внести изменения обычно не приводят ни к чему хорошему.
Вы ведь не горите желанием ничего менять — вы уже оценили стоимость, любая дополнительная работа забирает у вас деньги. Да еще код менять. Скрепя зубами, вы вносите те изменения, которые не требуют серьезных правок, и отсекаете остальное («Это очень сложно сделать»).
И вот, через какое-то время после дедлайна, проект наконец готов. Вы и с горем пополам сдаете его клиенту, получаете деньги и теперь можете забыть об этом.
Звучит знакомо?
В больших компаниях ситуация может усугубляться тем, что оценку стоимости и сроков будут производить одни люди (например, руководство), потом это задание свалится на проектировщиков и программистов. Последние выплюнут продукт тестировщикам. Бюрократия, отсутствие обмена информацией и все такое прочее.
Что нового?
Описанная схема — очень плохая реализация так называемой каскадной модели. Каскадная модель — самая, что ни на есть классическая методология разработки. Несложно представить, откуда она появилась. Кхм 
Государственные учреждения и большие корпорации только так и могут работать (написали требования — оценили — выделили деньги — работаем). Кроме того, разработка ПО как дисциплина изначально была тесно связана с инженерными науками, где внесение изменений в спецификацию невозможно после того, как проект начался. Вы же не будете менять чертежи моста после того, как построены опоры.
Но теперь после Интернета, SaaS и Ускорения некоторые считают, что такой процесс разработки неэффективен.
Было разработано несколько практических методик того, как надо разрабатывать ПО по-другому.
Scrum, XP и множество других — это и есть эти практические методологии. Они конкретно расскажут вам, что нужно делать и как построить работу. Scrum — самая популярная из таких методологий, XP или eXtreme Programming известна своими интересными практиками, например, парным программированием или разработкой через тестирование.
Agile или гибкая методология — это просто обобщение, декларация ценностей, так сказать. Agile сама по себе не содержит практических советов. Хотите практики — Scrum, XP и иже с ними вам в помощь. На самом деле весть Agile — это вот эти четыре утверждения.
Еще стоит сказать о Lean Software Development. (ака Бережливая разработка). Это не совсем методология, скорее тоже набор идей о том, на что следует обращать внимание, организовывая процесс разработки. Обратите внимание, я не сказал «о том, как следует организовывать».
Это в книгах по Scrum вы найдете утверждения, мол следует организовать 15-ти минутные собрания в начале рабочего дня. В книгах по бережливой разработке будут перечислены лишь общие советы, например о том, как важно упростить общение между членами коллектива.
Так все-таки как?
Вот простой способ понять, как делать agile-way.
Можно относится к разрабатываемому продукту как к чему-то такому, что будет сделано, оплачено и сдано.
А можно относится к продукту как к своему ребенку — ожидать, что он будет расти, развиваться и изменяться. И заботиться о нем.
Поэтому в Agile поощряется внесение изменений в спецификацию и после начала разработки. Не обязательно писать жесткую спецификацию до начала работы — она все равно будет меняться. Поощряется общение между всеми участниками разработки. Программист не пишет код, складирует его, а затем отдает в другой отдел для тестирования — «Пусть разбираются, мы же платим им деньги». Все работают вместе. Клиент получает готовый продукт как можно раньше и как можно чаще. Разработчики получают обратную связь в виде отзывов.
Это несложно представить, если считать, что ваша команда производит не готовый продукт, а предоставляет клиенту услугу по разработке программного обеспечения.