Введение в Scrum

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

Начну издалека. Про большой взрыв, я вам конечно рассказывать не буду... Но когда компьютеры были большими, а программы маленькими, чтобы не изобретать велосипед из промышленности была взята методика, которая получила название водопад (waterfall):

 На первом этапе, да и для сложных систем, для которых только написание ТЗ занимает пол года и больше, все оказалось хорошо (если кто не верит, то может найти статью Джоэла Спольски "Моя первая проверка Биллом Г" и посмотреть, что на разработку спецификации VB for Excel у него ушло время с 17 июля 1991 года по 30 июня 1992 года. Ссылку на статью не выкладываю, т.к. сайт Джоэла с переведенными статьями что-то недоступен, а другие ресурсы рекламировать не хочу).
Но очень быстро, заказчики и разработчики поняли, что Soft в отличии от Hard можно менять в процессе пути. Т.е. заказать курятник, а потом попросить к нему пару крыльев и реактивный двигатель с Hard не прокатывает, а с Soft иногда и выходит. И началось... А что началось, если вы писали хоть раз программу на заказ, вы представляете. Поэтому стали искать, что же делать. И тут пригодилась еще одна особенность ПО, а именно, то что его можно внедрять ЧАСТЯМИ! Вы можете представить, чтобы вам продали автомобиль без колес, двигателя? Нет, колеса и двигатель вам тоже привезут, но позже. Двигатель через месяц, а колеса через два. Сможете сразу после покупки корпуса получить выгоду от покупки? А с ПО эта схема неожиданно выстрелила. Вы покупаете систему управления производством. На перовм этапе вам поставили кадровый учет, потом бухгалтерию, потом складской учет (э... прошу не счесть за рекламу).
И на смену водопаду, пришел итеративный подход:

Заказчик не получает готового решения после первого витка, но он получает набор функций, который облегчает его жизнь (в некоторых случаях, после первого витка получается не первая полезность, а, например, интерфейс основной части системы, в котором вся обработка заменена заглушками).
Такая идея была предложена в 1988 году Барри Боэмом. А в 2001 году был принят Манифест гибкой разработки ПО (Agile Manifesto). О! Наконец то появилось можное слово Agile. Что жэ это такое?
Agile - это группа подходов к разработке объединенных не общими практиками, а общими ценностями объявленными в указанном выше манифесте. Собственно разработчики этих методологий и поставили свои подписи под этим документом. Их было достаточно много: Extreme programming, Scrum, DSDM, Adaptive Software Development, Crystal Clear, Feature-Driven Development, Pragmatic Programming.
Хм, читатель, ты еще здесь? Странно, я думал рассказываю прописные истины и ты уже закрыл эту страницу... Ну раз этого не произошло, то позволь я еще немного понудю и приведу перевод того, что ты уже конечно почитал по ссылке чуть выше.
Итак, манифест состоит из 4 основных идей:

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

И еще 12 принципов, которые поясняют эти идеи:

• удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО;
• приветствие изменений требований, даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
• частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще);
• тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
• проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
• рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
• работающее ПО — лучший измеритель прогресса;
• спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок;
• постоянное внимание на улучшение технического мастерства и удобный дизайн;
• простота — искусство НЕ делать лишней работы;
• лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
• постоянная адаптация к изменяющимся обстоятельствам.

Как видим, ни в идеях, ни в принципах нет "серебрянной пули"... Нет инструкции, как идти из пункта А и приходить в пункт Б за время t несмотря на погоду, перекопанную дорогу и т.д.

Но тогда, возникает вопрос, а как же этим пользоваться? А вот за инструменты и отвечают всякие XP, Scrum, Kanban и т.д. Именно они содержат директивы (инструкции) о том, что и как делать, чтобы получить программный продукт. Наверно, из названия понятно, что остальные статьи будут посвещены в основном Scrum, но здесь, я бы просто на пальцах хотел показать разницу между этими методиками и методиками принятыми в водопаде. На следующем графике показано количество директив, которым надо следовать в 4 методологиях. Первая, RUP - из мира водопадов, остальные XP (eXtrime Programming), Scrum и Kanban из мира Agile:

Собственно, даже из этого графика очень наглядно видно, почему RUP - это написание программ управления ядерными реакторами, а Agile - сегодня я хочу это, а завтра то.
Ну и собственно в заключении,перед тем как в следующих частях рассказывать про 9 "догм" из мира Scrum, я хотел бы озвучить следующую мысль:
Если у вас классная команда, адекватный заказчик и замечательная методология, то... у вас весьма неплохие шансы на успех. Но только шансы! С ухудщением команды, заказчика и методологии у вас по прежнему остаются шансы сделать продукт, просто их будет все меньше и меньше. Или совсем коротко: можно с великолепным инструментом завалить проект, а можно несмотря на паршивый инструмент выпустить вполне себе продукт.

P.s. Ну вот, раз дал обещание писать, то теперь точно не будет отмазов: "сегодня некогда, лучше завтра или вообще никогда".