Agile, Scrum, waterfall

— Итак, я хочу рассказать тебе про Agile и Scrum.

В начале 21 века представление о программировании перевернулось.

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

— Это как же?

— А вот так.

Был придуман максимально гибкий подход к управлению работой.

Основные концепции гибкой разработки:

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

Принципы быстрой разработки:

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

Основной проблемой разработки программы было признано то, что никто из участников ни на одном этапе не обладает всей полнотой информации о том, что делать.

Заказчик может рассказать, как он видит программу, но что-то он упускает, что-то считает самим собой разумеющимся.

Менеджер вообще должен переводить требования с языка программистов на язык заказчика и обратно.

Слишком много неопределённости.

Часто требования заказчика выглядят так: сделаете как-нибудь, потом покажите мне, если мне не понравится – переделайте.

— М-да. Как все запущено.

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

— А в чем разница?

— Ну смотри, допустим, раньше на разработку программы уходил год. И только через первых полгода было уже на что посмотреть. Это как строить большой дом: сначала котлован, потом фундамент, стены, крыша, отделка и т.д.

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

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

Допустим, хочет заказчик большой охотничий домик.

Построили ему маленький, он в нем пожил зиму и решил, что дом из дерева ему не нравится. Будем делать из кирпича в 4 слоя.

Пожил рядом с озером летом, а его комары заели. Он где-то слышал, что озеро – это круто, вот и хотел. А теперь ему озеро не надо. Так ведь и дом строить легче: нет озера – нет угрозы паводков, вот и можно строить дом не на сваях, а на земле, а это на 25% быстрее.

— Интересная аналогия. Неужто заказчик так часто меняет свои требования?

— Да дело тут не в заказчике.

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

А во-вторых, разве требования заказчика – не главное? Ведь смысл всей этой работы – это сделать именно то, что заказчику нужно, а не то, что он сказал в самом начале делать.

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

Если в нем нет чего-то, что очень нужно заказчику, но про что забыли, никто это что-то делать не будет.

— Ясно. Работать по плану легче, но не все можно сделать по плану!

— Именно.

Поэтому были придуманы методики гибкой разработки.

И о самой популярно из них – Scrum — я тебе сегодня расскажу.

Основная фишка скрама – это разбиение разработки проекта на небольшие итерации – обычно 2-4 недели. Такая итерация называется «спринт».

Вначале спринта проводится «планирование спринта» — совещание часа на 3-4.

В конце проводится «демо» — демонстрация всех полностью завершенных задач.

Вот как обычно все происходит:

Перед самым первым спринтом, заказчик (или его представитель), формирует список требований – набор того, что должна уметь программа. Такие требования обычно называют «user story», а заказчика – «product owner».

Product owner переводится как владелец продукта, т.к. продукт пишется для него и он и только он определяет список требований – что надо, когда и в каком порядке.

Кроме того, product owner обычно еще назначает задачам приоритет. Сначала будут реализовываться задачи с самым высоким приоритетом. Весь список требований еще называют «product backlog» или «резерв продукта».

Когда начинается спринт, то все собираются на совещание. Ведет его обычно scrum-master: как правило это кто-то из команды. Цель совещания – отобрать задачи (user story) на текущий спринт (итерацию разработки).

Сначала каждой задаче дается коллективная приблизительная оценка в «абстрактных человеко-днях», их еще называют «story point». Затем команда решает, сколько задач она успеет сделать за этот спринт.

При этом команда сама решает, сколько задач она успеет сделать за спринт.

Допустим, product owner ожидал, что команда отберет 7 первых задач, а она отобрала всего 5, то задачи 6 и 7 переносятся на следующий спринт. Если product owner это не устраивает, он может повысить приоритет 6 и 7 задачи, чтобы их точно отобрали, но тогда из спринта выпадут какие-то другие задачи.

Также scrum master может предложить разбить часть задач на более мелкие и расставить им различные приоритеты, чтобы product owner оказался максимально довольным.

В этом и есть смысл совещания – задачи можно менять и разбивать, можно менять им приоритеты и т.д. Это именно та работа, которая не была видна в самом начале, но которая приносит очень много пользы.

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

— Да, как-то так.

Список задач, отобранных для спринта, называют sprint backlog или резерв спринта.

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

— Командная работа. Уважаю!

— Для лучшей наглядности, обычно предлагают отображать текущее состояние спринта на специальной доске:

Обрати внимание на три колонки слева.

На стикерах пишутся краткие названия задач. А стикеры переклеиваются в другую колонку в зависимости от статуса (В планах, В процессе, Готово)

Справа ты видишь «диаграмму сгорания». Там по дням отображается список несделанных задач. В идеале за время спринта количество неготовых задач падает до нуля.

Когда спринт завершается, scrum-master проводит demo, на котором демонстрируется список всего, что полностью сделано.

Затем проводится «разбор полетов» — совещание тоже на пару часов. На нем обычно пытаются выяснить, что было сделано хорошо, а что (и как) можно было сделать лучше.

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

В середине спринта, иногда еще проводят «вычесывание» — совещание посвященное планированию следующего спринта. На нем обычно уточняют приоритеты задач, а так же можно разбить некоторые задачи на части и/или добавить новые задачи в product backlog – резерв продукта.

В принципе у меня все – это обзорная лекция, и на пальцах ее не объяснить, но вот тут ты можешь почитать пару хороших статей на эту тему:

http://scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-trenches-rus-final.pdf

http://ru.wikipedia.org/wiki/SCRUM