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

Инициатива презентации вышеупомянутых практик (или Lessons Learned) исходила от менеджмента компании и решала вполне конкретные цели. Неоспорима важность извлечения уроков и для команды, и для проекта в целом. Помимо получения однозначного ответа на вопрос «чему мы научились?», нам также становятся понятны зоны роста и видение будущего проекта. Такие мероприятия важны и для всей компании, ведь внутренний обмен опытом представляет большую ценность, прежде всего из-за своей доступности. В этой статье я опишу первое подобное мероприятие в нашей компании и постараюсь подтвердить выдвинутые мною тезисы о полезности такой практики.

Итак, зафиксируем точки сравнения. На начало проекта в команду входили 2 бизнес-аналитика (они же разработчики, именуемые так ввиду особенностей инструментов разработки) и управляющий проектом; работа строилась на Kanban доске с элементами Scrum (нечеткий бэклог, нерегулярные планирования, про ретро молчу, однако работа делилась на спринты и какие-никакие демо все же проводились). Сразу отмечу, что на тот момент такая организация была отчасти оправдана, т.к. по коммерческим причинам не было четкой уверенности, и целью было как можно быстрее показать хоть что-то. Со временем, уверенность в продукте появилась, и на сегодняшний день в команду проекта входят Project manager, 3 бизнес-аналитика, 1,5 QA (проекту выделен отдельный QA-инженер, а также QA lead с частичной занятостью), .NET-разработчик; по рабочему процессу можно сказать, что проект полностью работает по методологии Scrum. В рамках нашего первого мероприятия я выделил 6 основных выученных уроков, о которых изложу ниже.

1-й урок – Внедрение Scrum poker. Это распространенная практика, позволяющая команде быть уверенной, что все оценки будут обоснованны, т.к. без консенсуса не будет принята ни одна оценка. Мы начали каждое наше планирование проводить с покером. Работая в офисе, мы использовали напечатанные карты (4 оценки в story points + 4 дополнительные: «?», «∞», «0», «☕»). Перейдя, в свете известных событий, на удаленную работу, мы начали использовать открытый онлайн ресурс PointingPoker.Com. Нам он подошел прежде всего тем, что позволяет настраивать номиналы карт вручную. Хочу отметить, что раньше планирование у нас сводилось к бесконечным обсуждениям, наши мнения часто не соответствовали друг другу, и чувствовалось «доминирование» одного мнения. В результате, мы планируемся с покером более 2-х месяцев и имеем: схождение в 90% случаев запланированных и реальных оценок; а также уверенность, что взятые в спринт задачи реализуем в срок.

2-й урок – Внутренние демо для QA. Постепенно улучшая Scrum процессы, мы искали полезный формат проведения внутренних демо, и нашли его в проведении демо для QA инженеров. Имея 2-х недельные спринты, каждый 2-й понедельник Project manager и инженер QA, закрепленный за проектом, проводят встречу, на которой происходит разбор нового и обновленного функционала. Основная цель – обновить заведенные тест-кейсы и подготовить тест-план к регрессионному тестированию. И это действительно помогло. Раньше согласования тест-кейсов были устные, и мы нередко сталкивались с несоответствием понимания задач у бизнес-аналитиков, и у QA инженеров. В совокупности это позволило нам снизить (примерно на 50%) время вхождения QA в понимание, что тестировать; а также мы перестали получать вопросы «ошибка или нет?» и пр., которые неминуемо появлялись раньше.

3-й урок – Отчеты клиентам по обновлениям. После каждого планового обновления, а они на проекте, напомню, раз в 2 недели, была заведена привычка формировать текстовый отчет и предоставлять его клиенту, с описанием новых функциональных возможностей. Таким образом, я, как PM, формирую такой отчет на основе Release notes спринта, и отправляю его клиентам после обновления. До этого показ нового функционала мы проводили только на демо, причем было это нерегулярно; а по сему мы сталкивались с вопросами «как должно работать?». Итог понятен и краток – снижен уровень недопонимания у клиента по переданному функционалу в релизе.

4-й урок – Понятная работа с требованиями. Ввиду особенностей работы на проекте требования от заказчиков поступают постоянно, и мы этому рады. В рамках этого пункта была выстроена понятная схема работы с запрошенным функционалом. Изначально PM фиксирует требования совместно с менеджерами клиента; после – РМ подготавливает концепцию реализации функциональности; концепция просматривается менеджерами клиента и отправляется функциональным заказчикам на рассмотрение; после этого происходит аналитика, расчет трудозатрат, реализация. До этого требования мы и получали, и обрабатывали хаотично. Присутствовали долгие обсуждения без конкретики, и в последний момент (когда бэклог становился пустым) резко активизировалась работа и проходили срочные согласования. В результате, на сегодня мы имеем согласованный функционал и понятный план проекта более чем на 2 месяца, а также ведем активные согласования большого III-го этапа разработки (используя эту самую схему).

5-й урок – Критерии Ready to release. Наш проект (на ряду с еще одним проектом в компании) начал работать с критериями готовности к релизу, которые обеспечивают QA инженеры. После каждого регрессионного тестирования они формируют отчет по нему, куда включают соответствующие критерии. Отчет также направляется и клиенту. До принятия критериев релиз происходит по моей субъективной оценке, причем полной уверенности в релизе не было (т.к. отсутствовали параметры оценки). Теперь можно сказать, что мы имеем единое (на 100%) понимание готовности к релизу и у нас, и у клиента; также повысилась вовлеченность клиента в процессы разработки и уверенность в продукте.

6-й урок – Учет «подушки» при планировании. Речь идет об учете 20% запаса трудозатрат при планировании спринта, на случай непредвиденных затрат (блокеры, хотфиксы и пр.). Так, при планировании спринта мы на каждого исполнителя набираем трудозатрат на 20% меньше, чем брали ранее, т.е. от рассчитанного количества (расчет производится по количеству рабочих дней). Ранее мы часто сталкивались с несоответствием фактических и планируемых трудозатрат, в результате появлялись просроченные трудозатраты. На сегодняшний день можно сказать, что на 75% уменьшены опоздания к деплоям на тест (перед началом регрессионного тестирования), а также сведен к 0 риск несвоевременного релиза клиенту.

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

Инициатива презентации вышеупомянутых практик (или Lessons Learned) исходила от менеджмента компании и решала вполне конкретные цели. Неоспорима важность извлечения уроков и для команды, и для проекта в целом. Помимо получения однозначного ответа на вопрос «чему мы научились?», нам также становятся понятны зоны роста и видение будущего проекта. Такие мероприятия важны и для всей компании, ведь внутренний обмен опытом представляет большую ценность, прежде всего из-за своей доступности. В этой статье я опишу первое подобное мероприятие в нашей компании и постараюсь подтвердить выдвинутые мною тезисы о полезности такой практики.

Итак, зафиксируем точки сравнения. На начало проекта в команду входили 2 бизнес-аналитика (они же разработчики, именуемые так ввиду особенностей инструментов разработки) и управляющий проектом; работа строилась на Kanban доске с элементами Scrum (нечеткий бэклог, нерегулярные планирования, про ретро молчу, однако работа делилась на спринты и какие-никакие демо все же проводились). Сразу отмечу, что на тот момент такая организация была отчасти оправдана, т.к. по коммерческим причинам не было четкой уверенности, и целью было как можно быстрее показать хоть что-то. Со временем, уверенность в продукте появилась, и на сегодняшний день в команду проекта входят Project manager, 3 бизнес-аналитика, 1,5 QA (проекту выделен отдельный QA-инженер, а также QA lead с частичной занятостью), .NET-разработчик; по рабочему процессу можно сказать, что проект полностью работает по методологии Scrum. В рамках нашего первого мероприятия я выделил 6 основных выученных уроков, о которых изложу ниже.

1-й урок – Внедрение Scrum poker. Это распространенная практика, позволяющая команде быть уверенной, что все оценки будут обоснованны, т.к. без консенсуса не будет принята ни одна оценка. Мы начали каждое наше планирование проводить с покером. Работая в офисе, мы использовали напечатанные карты (4 оценки в story points + 4 дополнительные: «?», «∞», «0», «☕»). Перейдя, в свете известных событий, на удаленную работу, мы начали использовать открытый онлайн ресурс PointingPoker.Com. Нам он подошел прежде всего тем, что позволяет настраивать номиналы карт вручную. Хочу отметить, что раньше планирование у нас сводилось к бесконечным обсуждениям, наши мнения часто не соответствовали друг другу, и чувствовалось «доминирование» одного мнения. В результате, мы планируемся с покером более 2-х месяцев и имеем: схождение в 90% случаев запланированных и реальных оценок; а также уверенность, что взятые в спринт задачи реализуем в срок.

2-й урок – Внутренние демо для QA. Постепенно улучшая Scrum процессы, мы искали полезный формат проведения внутренних демо, и нашли его в проведении демо для QA инженеров. Имея 2-х недельные спринты, каждый 2-й понедельник Project manager и инженер QA, закрепленный за проектом, проводят встречу, на которой происходит разбор нового и обновленного функционала. Основная цель – обновить заведенные тест-кейсы и подготовить тест-план к регрессионному тестированию. И это действительно помогло. Раньше согласования тест-кейсов были устные, и мы нередко сталкивались с несоответствием понимания задач у бизнес-аналитиков, и у QA инженеров. В совокупности это позволило нам снизить (примерно на 50%) время вхождения QA в понимание, что тестировать; а также мы перестали получать вопросы «ошибка или нет?» и пр., которые неминуемо появлялись раньше.

3-й урок – Отчеты клиентам по обновлениям. После каждого планового обновления, а они на проекте, напомню, раз в 2 недели, была заведена привычка формировать текстовый отчет и предоставлять его клиенту, с описанием новых функциональных возможностей. Таким образом, я, как PM, формирую такой отчет на основе Release notes спринта, и отправляю его клиентам после обновления. До этого показ нового функционала мы проводили только на демо, причем было это нерегулярно; а по сему мы сталкивались с вопросами «как должно работать?». Итог понятен и краток – снижен уровень недопонимания у клиента по переданному функционалу в релизе.

4-й урок – Понятная работа с требованиями. Ввиду особенностей работы на проекте требования от заказчиков поступают постоянно, и мы этому рады. В рамках этого пункта была выстроена понятная схема работы с запрошенным функционалом. Изначально PM фиксирует требования совместно с менеджерами клиента; после – РМ подготавливает концепцию реализации функциональности; концепция просматривается менеджерами клиента и отправляется функциональным заказчикам на рассмотрение; после этого происходит аналитика, расчет трудозатрат, реализация. До этого требования мы и получали, и обрабатывали хаотично. Присутствовали долгие обсуждения без конкретики, и в последний момент (когда бэклог становился пустым) резко активизировалась работа и проходили срочные согласования. В результате, на сегодня мы имеем согласованный функционал и понятный план проекта более чем на 2 месяца, а также ведем активные согласования большого III-го этапа разработки (используя эту самую схему).

5-й урок – Критерии Ready to release. Наш проект (на ряду с еще одним проектом в компании) начал работать с критериями готовности к релизу, которые обеспечивают QA инженеры. После каждого регрессионного тестирования они формируют отчет по нему, куда включают соответствующие критерии. Отчет также направляется и клиенту. До принятия критериев релиз происходит по моей субъективной оценке, причем полной уверенности в релизе не было (т.к. отсутствовали параметры оценки). Теперь можно сказать, что мы имеем единое (на 100%) понимание готовности к релизу и у нас, и у клиента; также повысилась вовлеченность клиента в процессы разработки и уверенность в продукте.

6-й урок – Учет «подушки» при планировании. Речь идет об учете 20% запаса трудозатрат при планировании спринта, на случай непредвиденных затрат (блокеры, хотфиксы и пр.). Так, при планировании спринта мы на каждого исполнителя набираем трудозатрат на 20% меньше, чем брали ранее, т.е. от рассчитанного количества (расчет производится по количеству рабочих дней). Ранее мы часто сталкивались с несоответствием фактических и планируемых трудозатрат, в результате появлялись просроченные трудозатраты. На сегодняшний день можно сказать, что на 75% уменьшены опоздания к деплоям на тест (перед началом регрессионного тестирования), а также сведен к 0 риск несвоевременного релиза клиенту.

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