Cinimex и Agile наш подход.

Прошло 2 месяца как мы играем в Scrum.

История.

Шел девятый месяц разработки релиза, который должен был быть выпущен шесть месяцев назад.

 Количество новых задач росло с каждым днем, количество непроверенных доработок так же не отставало. Становилось понятно, что если не сказать стоп, то релиз выпущен не будет никогда. Параллельно шли постоянные жалобы со стороны разработчиков на тестеровщиков, со стороны тестеровщиков на администраторов и аналитиков, администраторов на железо, аналитиков на заказчиков…. Попахивало замкнутым кругом где каждый работал на 120% но завалы не разгребались да и проблемы не решались.

 Из сухих цифр выполненных 237 задач, не проверенно 160 задач. Поставка просто огромна. Когда будет выпущена, не известно.

Попытка перемен.

Для тех, кто не использует Scrum как инструмент разработки ПО могу сказать так, идя Scrum должна быть продана всем участникам проекта. Scrum – инструмент которым показывает проблемы в проекте, но их решение предстоит найти вам. Коллеги должны понимать зачем прилагать усилия и пытаться следовать достаточно жестким рамкам. У коллег должно появиться желание и согласие. Насаждением сверху или снизу этого процесса, не сработает. У коллег, работающих над одним ПО, должна появиться общая цель и фокус восприятия должен сместиться с личного достижения на достижение команды.

И вот было принято решение, необходимо что-то менять. Но что и как. Нам на помощь пришла методология Agile и её инструмент Scrum. 

Прочитав документацию:

• http://ru.wikipedia.org/wiki/Scrum
• http://scrumtrek.ru/scrum/Sprint-planning-meeting
• http://smartsourcing.ru/blogs/teoriya_metodiki_i_standarty/772
• http://scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-trenches-rus-final.pdf
• http://blog.crisp.se/author/henrikkniberg

Родилось представление о том, как попытаться внедрить это к нам.

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

Считаю, что данный документ сыграл ключевую роль во внедрении Scrum, поскольку не все будут читать статьи и книги о Agile и Scrum.

После ознакомления с документом была проведена встреча всех участников проекта, с обсуждением данного подхода. Команда сказала, что идея здравая и можно попробовать. В процессе будем решать проблемы.

Ограничения, которые мы применили для себя:

• Команда 11 человек.
• Команда полностью покрываются все этапы от Аналитики до Внедрения.
• Ежедневные встречи в 12 дня (15 минут).
• Длина итерации 1 месяц = 22 дня.
• Аналитика задач идет с опережением итерации.

Итерация 0

Цель: выпустить новый релиз

Напомню, что к моменту принятия решения о внедрении Scrum в проекте был кризис всего сделано 237 задач, не проверенно 160 задач. И круговое перекладывание ответственности за ошибки, неработающие стенды …

Этапы внедрения.

• Все новые требования начали падать в очередь, и не шли сразу в разработку.
• Все незавершенные задачи разработчики закрыли.
• Провели планирование следующего релиза.
• Аналитики и разработчики начали работать над новой версии.
• Тестировщики обещали подтянуть хвосты и закрыть огромный релиз.
• Тестировщики обещали проверять новые задачи.

Уже через несколько дней процесс нормализовался. 

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

Постепенно задачи из раздела TO-DO и Work In Progress (WIP) переместились в Test и здесь появилась новая проблема. За прошедшие 2 недели в столбце Test стало порядка 26 задач и они не сдвигались в столбец Done.

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

Все тестеровщики подтягивали хвост и не уделяли внимания новым задачам. Вскрылась ошибка, на ежедневных встречах НУЖНО говорить о проблемах.

Обнаруженная проблема требует решения. Команда решила, взяться за тестирование всем коллективом. Из списка задач были выбраны те, которые могут быть проверены разработчиками. Счастья в этом не много, но нам важно решить общую проблему.

Как итог через месяц мы имеем проваленную итерацию 0. 

Результат:

TODO	24
In Progress	10
To Test	21
Closed	19

Из положительного, в огромном релизе осталось только 50 задач. 

Из отрицательного, появилось 21 не проверенная задача из нового релиза.

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

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

Итерация 1. Техническая

Цель: Убрать долг тестирования

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

На текущий момент осталось 8 рабочих дней итерации. По тестированию остался долг в 41 задачу. Для решения дальнейших проблем будим применять подход Kanban с введением ограничений на взятие новых задач и критериями выполнения задачи.

Эксперимент продолжается….