Есть одна проблема — программисты не любят писать отчеты. Также иногда много времени уходит на понимание того, что пора кому-то просто задать вопрос а не тратить часы на бессмысленную медитацию. Есть современный подход, который позволяет отлично справляться с такими проблемами. Это микроблог. Примером сервиса микроблогов является Twitter. Представьте себе онлайн инструмент в котором программист может зайти в свою задачу и написать короткий пост вроде: «С задачей я немного застрял, придется поменять тип связи между двумя сущностями в модели: User и Training. А еще в кулере вода закончилась. Полный бардак. Процент выполнения задачи — 47».
Кроме прозрачности работы и активности программиста такой подход дает и адекватную макро картинку: какой статус и прогресс отдельной задачи, таск-группы и проекта в целом, какова динамика развития проекта (насколько быстро мы идем и нет ли отставания). В результате несложной операции данные о процентах прогресса, сообщаемые программистами в реальном времени, можно отражать на burn-down диаграмме.
Кроме прозрачности работы и активности программиста такой подход дает и адекватную макро картинку: какой статус и прогресс отдельной задачи, таск-группы и проекта в целом, какова динамика развития проекта (насколько быстро мы идем и нет ли отставания). В результате несложной операции данные о процентах прогресса, сообщаемые программистами в реальном времени, можно отражать на burn-down диаграмме.
Незатейливые микропосты и их частота намного больше говорят о работе программиста чем формальный дневной отчет.
Посмотрим как мы можем можем использовать Twitter для сбора таких микро-отчетов. Во превых нужно решить проблему секьюрити. Кому нужен репортинг, который транслируется на весь мир?! К счастью в Twitter все необходимые опции для создания секретных микроблогов уже есть - это закрытый аккаунт и закрытый список.
Давайте проделаем все по-порядку...
Сначала разберемся с аккаунтами программистов и инженеров по качеству - тех, кто собственно будет отчитываться. В половине случаев у членов Вашей команды уже есть аккаунт на Twitter где они делятся житейскими событиями и анекдотами со своими друзьями. Эти аккаунты нам не подходят. Самый лучший способ - создать отдельный "деловой" аккаунт для работы над проектами. В нашей команде мы все делаем по такой схеме: Иван Иванов, или, для пущего веселья - Гомер Симпсон - создает новый Gmail аккаунт homer.simpson.in.ganttzilla@gmail.com, где ganttzilla - это имя Twitter -аккаунта который собирает отчеты (для этого вы можете использоать любой имеющийся у Вас аккаунт, причем он не обязательно должен быть приватным). Далее он регистрирует в Twitter новый аккаунт с данным email и именем hsimpson4pm (приходится использовать сокращенную форму, посколько Twitter не разрешает "длинные" аккаунты).
При этом в настройках аккаунта обязательно выставляется галочка приватности для твиттов:
Посмотрим как мы можем можем использовать Twitter для сбора таких микро-отчетов. Во превых нужно решить проблему секьюрити. Кому нужен репортинг, который транслируется на весь мир?! К счастью в Twitter все необходимые опции для создания секретных микроблогов уже есть - это закрытый аккаунт и закрытый список.
Давайте проделаем все по-порядку...
Сначала разберемся с аккаунтами программистов и инженеров по качеству - тех, кто собственно будет отчитываться. В половине случаев у членов Вашей команды уже есть аккаунт на Twitter где они делятся житейскими событиями и анекдотами со своими друзьями. Эти аккаунты нам не подходят. Самый лучший способ - создать отдельный "деловой" аккаунт для работы над проектами. В нашей команде мы все делаем по такой схеме: Иван Иванов, или, для пущего веселья - Гомер Симпсон - создает новый Gmail аккаунт homer.simpson.in.ganttzilla@gmail.com, где ganttzilla - это имя Twitter -аккаунта который собирает отчеты (для этого вы можете использоать любой имеющийся у Вас аккаунт, причем он не обязательно должен быть приватным). Далее он регистрирует в Twitter новый аккаунт с данным email и именем hsimpson4pm (приходится использовать сокращенную форму, посколько Twitter не разрешает "длинные" аккаунты).
При этом в настройках аккаунта обязательно выставляется галочка приватности для твиттов:
В результате включения такой настройки hsimpson4pm получает нотификацию:
А вот так выглядит для внешнего мира приватный аккаунт Гомера:
Далее Гомер через поиск людей в Twitter находит аккаунт, на который он будет транслировать репорты - ganttzilla и фолловит его. Ganttzilla в ответ - фолловит hsimpson4pm. Почему не наоборот (искать и фолловить hsimpson4pm из ganttzilla)? Дело в том что Twitter - это мега стар, которому нужно около 2х дней чтобы новый аккаунт начал показываться в результатах поиска.
В результате hsimpson4pm получает запрос на подтверждение права ganttzilla видеть его твитты:
Гомер нажимет кнопку Accept и может начинать писать отчеты.
Со стороны собирающего аккаунта ganttzilla удобно создать list для сбора отчетов. Этот лист имеет смысл создать как приватный, чтобы никто из внешнего мира не узнал даже его название. Первый отчет пришедший от Гомера нужно добавить в этот список. Все последующие отчеты будут туда попадать автоматически:
Со стороны собирающего аккаунта ganttzilla удобно создать list для сбора отчетов. Этот лист имеет смысл создать как приватный, чтобы никто из внешнего мира не узнал даже его название. Первый отчет пришедший от Гомера нужно добавить в этот список. Все последующие отчеты будут туда попадать автоматически:
На этом мы заканчиваем нехитрый сюжет как Twitter можно использовать в качестве дружественного инструмента для репортов.
Теперь поговорим о том, чем полезен данный подход.
У нас долго не получалось сдавать фазы и проекты в срок в приемлемом качестве. Основной проблемой были «хвосты» у функциональных задач в виде нудного списка багов.
Внешне выглядело так что вроде бы весь скоп выполнен, но отдавать в таком качестве проект нельзя, поскольку шаг вправо или влево от пути презентации ведет к прикрытым или неприкрытым бородам exceptions.
Стоит также добавить что оценки по задачам у нас изначально поступают от разработчиков, поэтому эффектом прессинга эта ситуация не являлась.
На самом деле проблема заключалась в разном понимании ситуации «фича сделана» у программистов и QA-щиков. Из-за коротких итераций тестирование проводилось уже после интеграции всех недоделанных фич на последней неделе. И кошмар наступал. Это был праздник Хаоса.
Как проблема решилась? Мы ввели правило — 100% по своей задаче программист ставить не имел право. Его последний микропост должен был выглядеть примерно так: «я все сделал. Слышите? ВСЕ! Прогресс — 99%». Дальше шел микропост тим лида или менеджера: «ай молодец! Проверяет Женя. Прогресс — 99%». Женя — это QA-щик. Он в большинстве случаев находил 1-2 бага имплементации, 1-2 потерянных участков из Test Case, 1-2 юзабилити огреха и писал под задачей такой пост: «есть баги [тут идет их список со ссылками на баг-трекер]. Прогресс — 60%». Дальше идет доработка задачи…
Эти 100% — 60% = 40% и есть хвост задачи. Описанным подходом мы научились его обрубать.
Не стоит думать что таким способом мы загнали все баги в фичи. Остаются еще ошибки интеграции, логические ошибки в спеках, архитектурные ограничения и многое другое. Эти баги попадают в беклог, приоритезируются, оцениваются, включаются-исключаются из итерации и ремонтируются.
С Twitter Вы можете использовать этот подход уже сейчас. Если Вас интересут более интегральное решение - скоро мы выдаем новый релиз нашей он-лайн системы управления проектами, где подход к репортингу в виде микропостов будет интегрирован с Гантт и метриками. Сейчас этот функционал мы усиленно тестируем.
Выживания и удачи!
Теперь поговорим о том, чем полезен данный подход.
У нас долго не получалось сдавать фазы и проекты в срок в приемлемом качестве. Основной проблемой были «хвосты» у функциональных задач в виде нудного списка багов.
Внешне выглядело так что вроде бы весь скоп выполнен, но отдавать в таком качестве проект нельзя, поскольку шаг вправо или влево от пути презентации ведет к прикрытым или неприкрытым бородам exceptions.
Стоит также добавить что оценки по задачам у нас изначально поступают от разработчиков, поэтому эффектом прессинга эта ситуация не являлась.
На самом деле проблема заключалась в разном понимании ситуации «фича сделана» у программистов и QA-щиков. Из-за коротких итераций тестирование проводилось уже после интеграции всех недоделанных фич на последней неделе. И кошмар наступал. Это был праздник Хаоса.
Как проблема решилась? Мы ввели правило — 100% по своей задаче программист ставить не имел право. Его последний микропост должен был выглядеть примерно так: «я все сделал. Слышите? ВСЕ! Прогресс — 99%». Дальше шел микропост тим лида или менеджера: «ай молодец! Проверяет Женя. Прогресс — 99%». Женя — это QA-щик. Он в большинстве случаев находил 1-2 бага имплементации, 1-2 потерянных участков из Test Case, 1-2 юзабилити огреха и писал под задачей такой пост: «есть баги [тут идет их список со ссылками на баг-трекер]. Прогресс — 60%». Дальше идет доработка задачи…
Эти 100% — 60% = 40% и есть хвост задачи. Описанным подходом мы научились его обрубать.
Не стоит думать что таким способом мы загнали все баги в фичи. Остаются еще ошибки интеграции, логические ошибки в спеках, архитектурные ограничения и многое другое. Эти баги попадают в беклог, приоритезируются, оцениваются, включаются-исключаются из итерации и ремонтируются.
С Twitter Вы можете использовать этот подход уже сейчас. Если Вас интересут более интегральное решение - скоро мы выдаем новый релиз нашей он-лайн системы управления проектами, где подход к репортингу в виде микропостов будет интегрирован с Гантт и метриками. Сейчас этот функционал мы усиленно тестируем.
Выживания и удачи!
