В Agile и Lean, для организации используется доска задач и бумажки с тасками, которые на неё крепятся. Доска разбивается на несколько колонок или секторов, упрощая — «входящие», «в процессе», «сделано» и «завершено». Во «входящие» ставятся все задачи, приходящие из вне. Дальше задачи с учетом приоритетов и загруженности команды переносятся в колонку «в процессе» и закрепляются за кем то. В зависимости от команды задачи могут идти в общем пуле, либо раскидываться по конретным людям сразу, что довольно рискованно. Когда задача сделана — она переносится либо в «сделано», либо в «завершено» в зависимости от того требуется ли подтверждение или нет. Например, при успешной проверке, дополнительное подтверждение не требуется, мы ведь доверяем тестировщику? Но при разработке тестового сценария неплохо бы посмотреть нескольким людям на результат. После этого на следующий день, после релиза или любой другой выбранной точки бумажка с таской выбрасывается.

Использование доски и бумажек позволяет физически видеть загрузку, что в целом может мотивировать команду, до тех пор пока на доске не окажется вся пачка офисной бумаги. А в QA это очень быстро происходит, если учитывать задачи на тестирование, тест кейсы и внутреннюю разработку. Использование Jira и вообще трекеров задачу не решает. Там происходит точно такая же свалка задач за которой перестают следить, только намного проще и быстрее.

Для того, чтобы этого не происходило все участники команды должны уметь работать с задачами. Тут есть несколько моментов, которые этому мешают – отсутствие такой практики вообще, отсутствие системы для трекинга, нежелание тратить время на написание комментариев (в открытую объясняемое нелюбовью к бюрократии, а в подсознании боязнью наказаний за обнаруженные недочеты), неумение выражать свои мысли, непонимание смысла и ценности такой работы.

Технические проблемы легко решить – установить любую систему – dotProject, Eventum, Jira. В целом не имеет значения, но с психологическими стопорами так легко может и не получится. Что же тогда делать?

Контроль — это решение. Логично, есть люди как ресурс, которые что то делают. Что, как и когда делать им говорят. Зачем разбираться в первопричинах отказа говорить о своей работе? Процесс регистрируется в задачах, записи контролируются. Но в результате время будет тратиться только на контроль, да и психологически это будет только давить, в худшем случае работа будет незаметно саботироваться, в обычном выполняться формально. Требовать от наемных рабочих горячей любви к компании за зарплату бесполезно (корреляции между деньгами и лояльностью чаще всего нет), программы мотивации работают, но они не нацелены на конкретного работника и в среднем по больнице температура то нормальная, но…

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

• «прозрачность работы», «контролируемость» является пустым звуком в большинстве случаев. Ведь это ничего не приносит тому, кто описывает свою работу. И лучшим аргументом становится часто то, что от того, как описана задача зависит работа всех участников. Потому что в случае отпуска (неприятные события лучше не упоминать, мне кажется). Описание в задаче будет единственной помощью для остальных.
• Показать на своём примере как можно работать с задачами, и пример должен быть не один. Кому то может не понравится писать много текста о работе, кому то напротив захочется записать много данных. Разные вариации описания своей работы позволяют остальным выбрать наиболее близкий, понятный и приятный стиль.

Швабера вообще стоит читать, если есть интерес к применению Scrum, потому что, во-первых, он один из основателей Agile Alliance, а во-вторых один из двух авторов теоретики по процессу Scrum. То есть, он знает о чём говорит и то, что он говорит это не секонд хенд, а сведения из первоисточника.

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

Книга разбита на девять слабо связанных частей, а каждой рассматривается по несколько случаев, которые, по идее, должны дать общее представление об основных проблемах, методах их решения и о том, как вообще не допускать описанных ситуаций. Сами случаи показаны так, как видел их сам Кен и обычно разбиты на три части: исходная ситуация до введения Scrum, либо в самом начале его применения; описание появившейся проблемы; описание вынесенных уроков из ситуации и необходимые решения для устранения проблем (Lessons Learned). Очень хорошо и подробно описана работа в условиях одной команды, причем как в случае, когда начинался новый проект, так и при переводе существующего проекта на Scrum. Применение Scrum в случае, когда задействовано много команда (Scaling Scrum) описано явно недостаточно. При этом Кем в явном виде указывает на то, что расширение Scrum на несколько групп вполне осуществимо, но при это придётся сделать финт ушами.

В конце книги Кен поместил список правил, которым стоит следовать при работе в условиях Scrum. Если же не следовать этому компактному списку правил, то на правильно работающий процесс рассчитывать не стоит.

Я не противнки итерационных методов, но и не считаю возможным их применение в широком спектре случаев. Впрочем я и не настолько хорошо знаю Agile, как Асхат Урузбаев. Зато точно знаю, что Agile будет жить в компании только в том случае, если этого хочет её хозяин. А захочет он этого только если всё будет спокойно в бизнесе и станет интересно за что наёмные рабочие получают зарпалату, либо если бизнес планируется сделать публичным (читать приятным для инвесторов и заказчиков) или продать. В других случаях итерационный процесс всегда привязан к Business Needs и заканчивается и начинается именно с них.