Категории

Scrum: история Agile-команды, часть 3

Опубликовано: 06.10.2018

«Я хочу видеть, что вы сделали за прошедший спринт» — так можно подытожить слова нашего scrum master, который в тот момент был ещё и product owner'ом. Незадолго до завершения сппринта он просил нас показать, что мы успели сделать. Мы подготавливали демо — рабочую версию приложения, работавшую в тестовом окружении.

Scrum предлагает проводить демо в конце каждого спринта непосредственно перед ретроспективой. команда должна подготовить работающую версию, на которой инвесторам и product owner'у можно показать, какие из запланированных функций реализованы и то, что они работают.

Agile Scrum Training Part 3 - Backlog Refinement Meeting

Вы можете справедливо спросить меня, а почему всё-таки тестовое окружение, ведь после каждого спринта продукт должен быть готов к использованию в продакшне? Скажем так, продукт должен быть готов к продакшну настолько, насколько это возможно, однако реализация отдельных элементов функциональности может занять больше времени, чем один спринт, таким образом они не будут готовы. При этом, продукт стабильно работает, но всё ещё обладает запланированной функциональностью в полном объёме. Тем не менее, заказчик желает увидеть то, что уже реально работает, и чтобы иметь возможность показать это, в подобных случаях продукт нуждается в специальном окружении для своей работы.

#3 JIRA Tutorial for beginner-jira scrum tutorial | SCRUM Project Part 1

Кроме того, после проведения демо product owner может решить, что какой-то большой кусок функциональности уже достаточно готов, чтобы представить его пользователям в следующей версии. Очень часто подобный подход позволяет на ранних этапах оценить важность новой функциональности, основываясь на отклике от пользователей, и таким образом скорректировать путь развития продукта наилучшим образом, чтобы удовлетворить как можно большее количество пользователей.

Что ж, всё это выглядит достаточно простым. Вы являетесь гибкой командой, у вас все тесты всегда «зелёные» и ваш продукт всегда готов к использованию. Разве сложно подготовить демо? Это намного сложнее. чем вы можете себе представить!

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

Мы по-прежнему нуждаемся в руководстве

Это был момент, когда наш scrum master предложил проводить совещания ежедневно. Да! Ежедневно, каждое утро, в одно и то же время!

Я нахожу это очень полезной затеей для новых команд, где люди ещё не притёрлись друг к другу или не полностью погрузились в проект. Такие ежедневные собрания, которые называются Daily Scrum , проводятся командой ежедневно в точно определённое время. Они должны проводится обязательно до того, как будет сделана какая-либо работа за соответствующий день. В нашей команде мы решили собираться в 10 утра, что было трудновато выполнять, но тем не менее, это было хорошим решением.

Daily scrum — это простые и короткие совещания, длящиеся не более 15 минут. Целью таких совещаний является помощь команде быть в курсе того, кто и чем занят, какие имеются проблемы и узкие места в работе.

Чтобы такие собрания были действительно короткими и не растягивались, мы используем одну хитрость: мы их проводим стоя на ногах. После 15 минут стояния на ногах люди обычно начинают уставать, что как раз на руку! Если вы видите, как ваши коллеги ищут глазами место, куда бы примостить задницу, это сигнал к тому, что ваше собрание затянулось и пора сворачиваться.

На daily scrum каждый участник команды должен ответить на три вопроса.

Что было сделано вчера? Короткий ответ. 2-3- минуты максимум. Чем он собирается заниматься сегодня? Тоже очень коротко. Типа: «сегодня я работаю над историей N». Есть ли проблемы? Если есть, то что делать? Можно ли их быстро решить? Ответ должен быть коротким, освещающим суть проблемы и способа решения, если таковое имеется на данный момент. Нельзя допускать никаких подробных обсуждений проблем на этом собрании. Scrum master должен отметить для себя, что есть такая-то проблема и приступить к её решению только после окончания собрания.

Решение проблем и устранение различного рода препятствий должны иметь наивысший приоритет в работе команды, поскольку в противном случае процесс разработки будет постоянно прерываться. Часто тому, кто столкнулся с проблемой, её решение — это всего лишь вопрос времени. В некоторых случаях для устранения препятствия требуется помощь команды. А иной раз случаются вещи, которые парализуют работу всей команды целиком.

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

Большинство наших проектов написаны на PHP. В какой-то момент нам потребовалось связывать наши приложения с VMWare. Мы посмотрели, что из официальных библиотек есть для доступа к VMWare API. Были версии для Java и Perl, а также был найден неофициальный вариант для Ruby. Мы были уверены, что у нас не возникнет проблем с использованием найденных решений и всё ограничится простыми вызовами exec () и разбором возвращаемого значения. Ну и, как нам казалось, всё это будет проще пареной репы.

В реальности же оказалось, что эта затея находится где-то на грани невозможного. Ни одна из библиотек не работала так, как мы того неё ожидали. Некоторые из них были либо незаконченными, либо вообще заброшенными, при этом анализировать их вывод было практически нереально. В итоге нам пришлось делать то, чего до нас ещё никто не сделал: создавать библиотеку для доступа к VMWare API на PHP. К сожалению. другого способа на тот момент мы просто не нашли.

Проблема оказалась просто огромной и отбросила сроки на недели! Конечно же. мы тут же поставили в известность product owner и совместно с ним мы разрабатывали новый график, писали новые истории, в которых отражали создание создание новой API-библиотеки.

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

Итоги

Вот мы и подобрались к концу. Я рассказал вам о том, как мы начинали. Некоторые концепции были очень полезными, некоторые — менее. Некоторые идеи оказались полезными лишь ненадолго, в то время как другие стали чуть ли не религией в команде.

Главное, что я могу вам посоветовать: пробуйте Agile-техники и Scrum в частности. Пробуйте и формируйте своё мнение. Уверен, вы найдёте множество полезных моментов и сможете их внедрить в работу своей команды. Будьте гибкими, берите то, что вам подходит и пробуйте это в работе и в жизни. Не бойтесь добавлять что-то от себя. помните, что Agile — это прежде всего гибкость, а не слепое следование правилам.

Часть 1

Часть 2

Источник: Nettuts+