Периодически, время от времени, задумываюсь - достаточно ли информации я даю своим менеджерам. для принятия решения. Не много ли? Не мало ли? Просто и доходчиво? Правдиво ли?
Кратко и емко - как в двух словах рассказать почему мы прое..м сроки? Или не в двух словах, а в двух предложениях. Или абзацах. Как сегодня охватить ретроспективно весь релиз, чтобы было понятно - как мы пришли к тому, к чему пришли? Цифры конечно помогают, но ведь не все можно выразить цифрами. Lesson 198. There’s nothing more dangerous than a vice-president with statistics
Бывает, что за день ничего не случается. А бывает туева куча вещей из-за которых тестирование стояло. Разные вещи в разное же время, но стояли весь день. Тут тонкая грань - как рассказать и не начать оправдываться!
Для ответа на такие вопросы нужно что-то более осязаемое, чем слова на митинге, чат или разговор у кофеварки.
Нужен механизм донесения до окружающих информации, который бы мог хранить ответы или помочь ответить на вопросы:
Что делали за день?
Где мы сейчас (сколько осталось)?
Какие проблемы у нас были, есть и потенциально будут?
Если проблемы были, есть и будут - мы все еще успеваем к намеченной дате закончить тестирование?
Если мы не успеваем к намеченной дате - какие у нас есть варианты, чтобы успеть.
Какая помощь нам нужна?
В наших проектах специально для таких случаев есть практика ежедневного отчета - Daily Status Report. Отчет рассылаемый электронной почтой (и затем складируемый в SharePoint), где в копии письма указаны все те, кто может хоть когда-нибудь произнести "Почему...".
Структура отчета
Структура, изначально, была одна для многих проектов (ее элементы до сих пор присутствуют в моем отчете), но многочисленные обсуждения с менеджерам (отдельно взятых проектов) привели к тому, что мой отчет превратился в менее формальный живой (изменяющийся) документ. В других проектах отчеты также живут своей жизнью. Связано это прежде всего с тем, что они ориентированы на "клиенов": менеджеров, PM, разработчиков.В настоящее время я выделяю в своем отчете следующие части:
EXECUTION
Day Summary
Progress
- Function testing
- Regression Testing
- Non function testing (performance testing, load testing etc)
STATUSES/MILESTONES
Release
Function testing
Regression testing
Non function testing
DOWNTIMES/SHOWSTOPPERS
QA RISKS
RELEASE LOG
ISSUES FOUND SUMMARY
REFERENCIES
-Release wiki
-Daily Status Reports
- Release Delivery Schedules
Теперь несколько предложений и примеров по каждому пункту.
EXECUTION
Первый раздел - это вчерашняя ретроспектива. Что было и где мы есть. Краткость сестра таланта, но не переборщите - если проблемы - заявите о них правильно. Если есть достижения - заявите о них скромно но с достоинством )).Day Summary (суммарное состояние дел на дату составления отчета)
Расскажите своему клиенту - что вчера было. Это сродни письму "на деревню дедушке", но с той интонацией, что все под контролем.
Если не под контролем?
Тогда три W: Who (кто занимается), What (что собирается сделать), When (срок когда должны быть результаты или отчет).
Если из-за внешних проблем (вне команды тестировщиков) тестирование простаивает - обязательно укажите сколько времени вы потеряли.
Если вдруг выяснилось, что вы ошиблись с оценкой трудоемкости и она может повлиять на работу - лучше сразу предупредить, что оценка изменилась. Ошибиться на час в релизе со стоимостью 2 человеко-месяца простительно, более того, если вы с точностью до 1 часа умеете предсказать окончание тестирования - я преклоняю перед вами колени.
Далее небольшой пример.
1. Релиз в стадии функционального тестирования.
2. Случилось, что тестовое окружение было не готово с утра и до обеда - общие потери времени для команды составили 12 человеко-часов. Проблемы решены. Тестирование продолжено.
3. Спецификация по главной фиче до сих пор на согласовании с заказчиком и находится в доработке. Если к четвергу этой недели фича не будет выдана в тестирование мы можем не успеть к запланированной дате закончить тестирование. Спецификация на согласовании с заказчиком уже 2 недели. Согласовывает - менеджер. Предварительно ответ от заказчиков прозвучит завтра с утра.
4. Найдено 4 бага. Баги ожидают приоритизации с клиентами (владелец - менеджер проекта, когда сделает не знаем - To Be Discussed/To Be Clarified). Если все баги будут включены в релиз, то их проверка займет 36 человеко-часов (6 человеко-дней).
Если вдруг выяснилось, что вы ошиблись с оценкой трудоемкости и она может повлиять на работу - лучше сразу предупредить, что оценка изменилась. Ошибиться на час в релизе со стоимостью 2 человеко-месяца простительно, более того, если вы с точностью до 1 часа умеете предсказать окончание тестирования - я преклоняю перед вами колени.
Далее небольшой пример.
1. Релиз в стадии функционального тестирования.
2. Случилось, что тестовое окружение было не готово с утра и до обеда - общие потери времени для команды составили 12 человеко-часов. Проблемы решены. Тестирование продолжено.
3. Спецификация по главной фиче до сих пор на согласовании с заказчиком и находится в доработке. Если к четвергу этой недели фича не будет выдана в тестирование мы можем не успеть к запланированной дате закончить тестирование. Спецификация на согласовании с заказчиком уже 2 недели. Согласовывает - менеджер. Предварительно ответ от заказчиков прозвучит завтра с утра.
4. Найдено 4 бага. Баги ожидают приоритизации с клиентами (владелец - менеджер проекта, когда сделает не знаем - To Be Discussed/To Be Clarified). Если все баги будут включены в релиз, то их проверка займет 36 человеко-часов (6 человеко-дней).
Progress
Здесь мы обычно пишем: где мы есть в тестировании. Сколько закончено (по времени) и сколько осталось.
Здесь мы обычно пишем: где мы есть в тестировании. Сколько закончено (по времени) и сколько осталось.
Testing Progress: 10% - completed
Feature 1 - completed
Feature 2 - 50%
Feature 3 - not started
Feature 4 - in clarification (not ready for testing)
Regression Testing
Component 1 - not started
Component 2 - not started
Component 3 - not started
Non function testing (performance testing, stress testing):
Approach 1: not started
Approach 2: not started
Почему функциональное, регрессионное и нефункциональное тестирование у нас разделены? Потому что мы можем не закончить функциональное тестирование и уже начать регрессионное. Можем закончить регрессионное но вот с тестированием производительности задержаться. Менеджер должен знать, чем он рискует.
Статусы у нас имеют три цвета: GREEN AMBER RED. Статусы показывают только то - на сколько мы (тестировщики) успеваем к дате окончания тестирования и если мы не успеваем - как сильно это влияет на конечную дату релиза.
Ежедневные отчеты о статусе релиза, конечно же, замечательная практика, но скорее всего только для коротких циклов в 1-3 месяца. В случае если у вас более длинные циклы ,то лучше посылать еженедельные отчеты. Я так думаю. Но все зависит от того, как ваш PM любит знать - что, где и как происходит постоянно.
Если у вас отсутствует практика сбора информации на ежедневной основе, то мягко говоря, вы будете тратить на отчет много времени.
Если в отчете отсутствует важная для менеджеров информация, наверно, такой отчет тоже никому не будет нужен - просто очередной корпоративный спам удаляемый без прочтения. Отчет это как качество - value for someone.
Feature 1 - completed
Feature 2 - 50%
Feature 3 - not started
Feature 4 - in clarification (not ready for testing)
Regression Testing
Component 1 - not started
Component 2 - not started
Component 3 - not started
Non function testing (performance testing, stress testing):
Approach 1: not started
Approach 2: not started
STATUSES/MILESTONES
Данный раздел содержит статусы и дни окончания функционального тестирования, регрессионного тестирования, не функционального тестирования (в нашем проекте тестирование производительности). Также мы указываем день окончания релиза и его статус.Почему функциональное, регрессионное и нефункциональное тестирование у нас разделены? Потому что мы можем не закончить функциональное тестирование и уже начать регрессионное. Можем закончить регрессионное но вот с тестированием производительности задержаться. Менеджер должен знать, чем он рискует.
Статусы у нас имеют три цвета: GREEN AMBER RED. Статусы показывают только то - на сколько мы (тестировщики) успеваем к дате окончания тестирования и если мы не успеваем - как сильно это влияет на конечную дату релиза.
QA RISKS
Список рисков которые могут повлиять на проект, их статусы и сколько времени мы можем потерять если они сыграют.RELEASE LOG
ISSUES FOUND SUMMARY
Собственно история багов, комментарии к ним, их статусы.REFERENCIES
Всегда присутствует справочная информация, которую в отчет, вроде бы, вставлять не нужно (большой объем, не критично), но ссылку на хранение нужно бы добавить.Замечания и предложения по использованию отчета
И несколько моих замечаний, если вдруг кто-то побежит кричать "эврика - нам не хватало только ежедневного отчета до кучи!"Ежедневные отчеты о статусе релиза, конечно же, замечательная практика, но скорее всего только для коротких циклов в 1-3 месяца. В случае если у вас более длинные циклы ,то лучше посылать еженедельные отчеты. Я так думаю. Но все зависит от того, как ваш PM любит знать - что, где и как происходит постоянно.
Если у вас отсутствует практика сбора информации на ежедневной основе, то мягко говоря, вы будете тратить на отчет много времени.
Если в отчете отсутствует важная для менеджеров информация, наверно, такой отчет тоже никому не будет нужен - просто очередной корпоративный спам удаляемый без прочтения. Отчет это как качество - value for someone.
Несколько слов про scrum standup meetings. Сторонники Agile конечно же вспомнят про ежедневные встречи команд, на которых заслушиваются "чтояделал-какиепроблемы-чтобудуделать". Эти митинги не для того, чтобы рассказывать, как у нас вообще идут дела. И тем более не для того, чтобы озвучивать где и как мы просели. И такие митинги ретроспективу за несколько дней не показывают.Они для сплочения команды, а не для сигнального огня менеджерам.
На самом деле чтобы донести до сознания окружающих (не только начальства), что все хорошо или что все очень плохо - одного отчета в день мало. Если у вас двух-трех месячный цикл разработки/тестирования все (в основной массе) замечают только статусы отчета: RED AMBER GREEN. Поэтому проблемы, когда у отчета был статус GREEN даже не вспоминаются. Именно поэтому, когда приходит время спросить - а почему все таки тестировщики не успевают - нужно уметь скрыть вздох сожаления (они опять ничего не помнят), а дать ответ с хладнокровным выражением лица, которому позавидует и сфинкс, сославшись на количество потерянного времени тестировщиками и список, где все проблемы складировались.
Именно поэтому, когда есть проблемы - нужно не только писать о них в отчете, но и еще озвучить при личной встрече. А если человек живет на другом континенте "случайно" спросить в коммуникаторе - понимает ли он всю суть всего происходящего. Я на этом обжигался, и даже, иногда, обжигаюсь сейчас - личные коммуникации отчетами, даже ежедневными, не заменишь.
Поэтому сохраняя непроницаемое лицо пишем отчет, посылаем отчет, пишем в коммуникатор, что отчет послан и неплохо бы подумать о том, что произошло, а вечером контрольный в голову - кратенькое письмо в нескольких приложениях, что проблема еще не решена... Ну как то так.
Еще одно замечание. Конечно же этим отчетом мы прикрываем свою попу, в случае если мы не виноваты и конечно же наказание ждет нас, если мы в репортах обещали одно, а в жизни стало другое. Но этим ежедневный отчет и хорош - ты каждый день обдумываешь, что и как может пойти по другому и следовательно это дополнительный пендель думать и работать быстрее.
Собственно ежедневный отчет - очередная практика, которая может быть и полезна и бесполезна - зависит кто и как ее использует. Ежедневно тратить по полчаса в день, чтобы собрать информацию о вчерашней работе команды, конечно же затратно, но затем вся эта информация будет полезна на "разборах" и вполне очевидно для планирования будущих релизов.
Ваш отчет будет выглядеть живенько если вы добавите немного графики. Например общий прогресс и прогресс типов тестирования (на картинке функционального).
И последнее замечание (звучало раньше, но обычно лучше всего запоминают последнее ;)). Отчет живой - он изменяется под нужды клиентов. В нашем случае клиенты все те, кто его может прочитать, и если что-то клиенту не понятно, нужно информацию предоставить.
Еще одно замечание. Конечно же этим отчетом мы прикрываем свою попу, в случае если мы не виноваты и конечно же наказание ждет нас, если мы в репортах обещали одно, а в жизни стало другое. Но этим ежедневный отчет и хорош - ты каждый день обдумываешь, что и как может пойти по другому и следовательно это дополнительный пендель думать и работать быстрее.
Собственно ежедневный отчет - очередная практика, которая может быть и полезна и бесполезна - зависит кто и как ее использует. Ежедневно тратить по полчаса в день, чтобы собрать информацию о вчерашней работе команды, конечно же затратно, но затем вся эта информация будет полезна на "разборах" и вполне очевидно для планирования будущих релизов.
Ваш отчет будет выглядеть живенько если вы добавите немного графики. Например общий прогресс и прогресс типов тестирования (на картинке функционального).
И последнее замечание (звучало раньше, но обычно лучше всего запоминают последнее ;)). Отчет живой - он изменяется под нужды клиентов. В нашем случае клиенты все те, кто его может прочитать, и если что-то клиенту не понятно, нужно информацию предоставить.
Комментариев нет:
Отправить комментарий