На нём используется всего три портлета:

• Time Sheet Summary на одну неделю. Позволяет оперативно видеть какими задачами и сколько времени (через Worklog) занимался сотрудник;
• Issue Calender с опцией показа крайнего срока (Due date). Позволяет определить сколько задач в ближайшее время должны быть завершены;
• Show Saved Filter With Columns с фильтром по открытым задачам на человека, показывает сколько всего задач, с каким сроком и приоритетом висят на сотруднике.

Остальные дашборды можно посмотреть тут и тут.

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

Руководителю группы или отдела, не важно, один раз в год приходится сталкиваться с вопросами о том, что было сделано важного за год, что делали его подчинённые и что планируется делать дальше. В самом простом варианте предлагается сделать документ, с перечислением предполагаемых улучшений в процессах и инструментах. Это самый не эффективный подход, потому что не каждая фирма настолько стабильна и консервативна, чтобы прогнозы сделанные в начале года оказываются точными под конец, особенно в области разработки ПО. Я с этим сталкивался несколько раз и во многом оценка исполнения своих же планов вызывала уныние. Это подтолкнуло к мысли о том, что систему планирования и прогнозирования стоит изменить, уменьшив период до адекватного размера.

Мне приглянулся период планирования длиной в три месяца. Этот срок позволил внедрить изменения, отследить их мутацию и отмирание, подготовить адекватный план развития на следующий период и быстро отреагировать на любые изменения в процессе разработки в целом. Так же это позволяет не создавать чрезмерной нагрузки на сотрудников, но позволяет держать их в тонусе. Период условный и каждый волен выбирать сам.

Улучшение тестирование планируется по трём направлениям — процессы, методики и инструментарий. Изменение процессов сложное, только если действовать революционными изменениями, если умерить пыл и проводить изменения плавно получается просто и намного тише. Инструментарий в плане внедрения намного сложнее, особенно для обеспечения процессов. Любая формализация ведения задач и отчетности вызывает скрытое сопротивление, преодолеть его хоть и не сложно, но требует времени и много внимания.

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

Общее планирование развития разумно начать с формализации и унификации существующих процессов: что тестеры делают до, во время и после релиза; как нужно вести заметки по работе; и так далее. У меня это вылилось вот в такие пункты документа по улучшениям:

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

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

В последующих планах в основном придется оперировать только этими тремя сущностями – процессы, методики и инструменты. Насколько насыщенными будут дальнейшие планы, напрямую зависит от уровня продумывания и исполнения двух первых этапов.

Систему трекинга ошибок я реализовывал на основе Jira (в силу разных обстоятельств, впрочем я в этом не одинок). Все изменения, которые потребовалось сделать не потребовали никаких доработак кода Jira (то есть при апгрейде не возникает проблем). Система не изолированная и во многом рассчитана на то, что ей будут пользоваться менеджеры и лиды команд. Естественно копаться никто долго не хочет и главный вопрос – что у нас с релизом [в плане ошибок]. Для того, чтобы сделать на основе Jira понятную структуру, которая позволила бы наглядно ответить на этот вопрос понадобилось изменить воркфлоу для проекта, хранящего ошибки. К существующим, стандартным, было добавлено несколько новых статусов:

• Открыт (Переоткрыт)
• В разработке
• Требуется дополнительная информация
• В тестировании
• Работа закончена
• Не баг
• Проверен и закрыт

Далее с помощью портлетов Show Saved Filters (можно использовать Show Saved Filters with Columns) , фильтров с учётом статуса и Pie Chart был сделан дашборд, который показывал сколько задач на каком этапе находятся. Чарт добавлен только ради большей наглядности.

(Картинка не увеличивается, и дана только чтобы показать расположение элементов)

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

Решение довольно гибкое, поскольку позволяет даже внутри одного проекта созда разный набор фильтров и дашбордов на основе практически любых полей, которые есть в Jira. Хотя тут бы я не увлекался и дальше стандартных полей не уходил.

MindMap Ежедневных митингов (кликабельно)

]]> http://alsedi.com/blog/mindmap-dlya-ezhednevnyx-mitingov/feed/ 0 http://alsedi.com/blog/ezhednevnye-mitingi/ http://alsedi.com/blog/ezhednevnye-mitingi/#comments Wed, 04 Mar 2009 16:48:17 +0000 Alex http://alsedi.com/blog/?p=305 Еще в то время, когда нам пытались привить Scrum (по ряду причин безуспешно), тема ежедневных митингов поднималась несколько раз за декаду, но так до дела и не дошло. Мы делали митинги сначала три раза в неделю, потом раз в неделю, потом раз за итерацию, потом по необходимости, потом без отрыва задниц от места.

Я уверен, что не я один участвовал в подобном процессе, мы материли “Scrum мастера” за то, что он ничего не знает, а время митинга растягивается минимум на час. Большую часть которого две трети участников спят, ковыряют столы, стулья и носы, звонят по телефону, обсуждают вчерашний футбол, сидят с хмурыми мордами лицами. После митинга никто не помнил о чем договорились, да и вообще, договорились ли?! Но ведь что то обсуждали, но что же решили? Никто не помнил. “Scrum мастер” писал письмо руководству о прогрессе в разработке, выражая его в процентах

Мы готовы к завоеванию мира на 90%!

Эта версия лучше на 45%!

Ваши ресницы будут длиннее на 63.3% если вы попали в 34 и 5 десятых процента белокожих женщин с карими глазами и родинкой на животе!

Да брехня это всё, виртуально. А мы реальны. Мы понимали, что это чушь, что нам это чуждо и не нужно. Естественно всё умерло и с каждым релизом выяснялось, что забыли что-нибудь положить в CVS, сделали изменения в зависимых модулях и забыли известить зависимых. В тестировании тоже всё было не слишком гладко, даже налаженные горизонтально-вертикально-поперечные связи давали сбои и какие то очевидные ошибки оставались незамеченными.

Так что необходимость митингов как была так и осталась. Я решил следовать довольно простой схеме. В моей команде люди разбиты по своим проектам и…

Тогда, еще два года назад, “Scrum мастер” сделал главную ошибку, которой сейчас пытаюсь избежать я – он взял всех лидов и разработчиков по всем направлениям и посадил в одну комнату с целью у каждого узнать “как дела”. Направления, хоть и представляли собой единую платформу, но всё-таки были довольно самостоятельными и по большому счёту были связаны вместе только базой. Это примерно как, если бы вы ходили каждый день в один и тот же бар и слушали бы как бармен рассказывал как сложно достать сейчас бренди, хотя вам всё равно есть бренди или нет.

…я решил митинговать с каждой командой отдельно (привет, велосипед). На каждую встречу не более 15 минут, во время митинга поднимаются только три темы: что не получилось сделать из запланированного вчера, какие проблемы мешают, что делаем сегодня. И так изо дня в день, пока эти маленькие сообщества не научатся четко говорить о проблемах и понимать свою работу, а я вместе с ними не пойму в деталях что происходит. После этого можно будет перейти к тому, чтобы митинговать со связанными командами. Делать это каждый день уже нет смысла, потому что группы нужно связывать только, когда релиз одного из компонент сильно затрагивает другие.

За разными командами тестировщиков стоят не только разные продукты или компоненты, но и разные команды разработчиков. А это люди! Каждый со своими тараканами и подходами к работе, которые могут упростить жизнь релизу или усложнить.

Был у нас очень интересный разработчик. Он разрабатывал один компонент системы…  в течение двух лет! И когда проект был на этапе завершения оказалось, что он не совместим с платформой немного (ну это ладно). В добавок после его добавления в систему дороги назад уже не было – обратной совместимости продумано не было. С одной стороны очень плохо, разработчик чудовище. С другой мы избавились от многоярусной поддержки целого семейства старого кода.

На третьем шаге собираем всех тестировщиков вместе. Это не может быть частое явление, на мой взгляд. Но почему бы не сделать так раз в месяц, для того чтобы не было вопросов кто и чем занимается. Это сыграет свою роль, обязательно. Когда это произойдёт нельзя будет сказать – “Вот он! Это потому что два месяца назад они были на митинге”, но при проблемах всегда найдется падла зараза, которая скажет “Это потому что митингов не было” и будет права.

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

Заинтересованные в релизе группы людей

Список вопросов неполный, но QA должны знать ответы хотя бы на них. Для этого, в первую очередь, потребуется отслеживать выполнение задач по разработке и тестированию. Существование трекера первый шаг к построению нормальной информационной системы.
Подойдет любая система трекинга, в которой можно реализовать такую структуру (я предпочитаю Atlassian Jira, для небольших проектов Eventum):

• Backlog – группа проектов в которой по версиям и продуктам разбиваются пожелания и требования бизнес стороны. Это не только спецификации (ТЗ), но и простые заметки, пришедшие от бизнес стороны в стиле «нужно сделать это, примерно вот так функционирует и выглядит». На основе таких «business story» можно построить спецификацию и согласовать с бизнесом.
• Development Project – Группа проектов по разработке конкретных продуктов. Основная часть задач появляется с привязкой к Backlog проекту. Это позволяет отслеживать соответствие требованиям бизнеса и начать работу QA еще до завершения разработки (что-то вроде Test Driving Development, но мягче).
• Feedback – Группа проектов для получения отзывов от клиентов и бизнес стороны по работе текущей версии и проблемам с ними связанным (но не для трекинга багов по разрабатываемой версии).
• QA – Группа проектов, привязанных к таким же проектам в Development Project. В них будет вестись трекинг задач, связанных с тестированием версии или общей работы, но не багов!
• Bugs – Группа проектов, привязанных к проектам в QA и Development Project. Здесь тестировщики создают все таски связанные с найденными ошибками и предлагают улучшения проектов.

Зачем нужно три проекта для QA? Для того, чтобы не создавать мусорной кучи. Feedback доступен не только тестировщикам (которые, по идее, знают о разрабатываемых продуктах больше остальных), но и бизнес стороне. Люди со стороны бизнеса имеют полное право не знать о том, что существует множество версий и множество компонент внутри продуктов, но должны иметь возможность сообщить о проблеме при работе. Для этого им нужно знать только что они делали и версию продукта, с которым они работали (а не всю систему), когда появилась проблема.

Причем, не важен тип решения (а пользователь может и не знать что там еще стоит за окном в которое он смотрит), разрабатываемого компанией:

• самостоятельное приложение;
• серверное приложение с доступом из стороннего (Web сервис, XML/HMTL сервер);
• клиентское приложение с доступом к стороннему (Debuggers, разнообразные сетевые клиенты);
• клиент-серверное приложение, с собственным сервером и клиентом (платформы с удаленным доступом);

Разобраться где конкретно ошибка и ошибка ли дело QA и разработчиков. Часто разработчики могут сделать это быстрее.

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

Группа проектов QA позволяет отделить работу по тестированию от результатов. Для каждого релиза создается свой набор обязательных задач для проверки. В зависимости от проекта и версии список может меняться, адаптируясь под условия. Вместе с рутинными задачами в эти проекты могут быть добавлены задачи относящиеся к процессу тестирования. Например, автоматизация тестов, исследования программ и методик для тестирования.

Принципиальная схема процесса при такой структуре проектов выглядит так:

Потоки информации между проектами

При использовании этой схемы Backlog объединяет в себе первичные требования бизнеса, общее обсуждение технической реализации или ТЗ (в зависимости от возможностей), проблемы из Feedback и Bugs, которые требуют много времени на исправление или переработки бизнес логики. Основные задачи в Backlog описывают большие куски работы, разбиение которых делается через сабтаски. Далее эта информация клонируется (или разбивается на части и клонируется) в проекты по разработке и добавляется в задачи по подготовки к тестированию в QA проектах (написание тесткейсов, переработка существующих тестов, автоматизация и так далее). После релиза в соответствующем проекте QA создаётся общая задача на тестирование, а конкретная работа выделяется в сабтаски. При нахождении ошибок при тестировании они описываются в соответствующем проекте Bugs и либо клонируются в Development Project, либо заносятся в Backlog для позднего исправления. Процесс запускается по новой… в идеале.

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

Когда я пришел в компанию, у меня был довольно большой опыт в ведении тестирования (как части QA) и разработки программ. Опыта управления процессом, в котором задействовано много людей и разные команды, практически не было. Фактически, на тот момент «картина мира» для меня выглядела так.

Мифическая организация разработки

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

В большой компании, выпускающей крупные продукты, с разделенными географически офисами (сюда можно включить оффшорные компании и местные (domestic) филиалы компании), эта схема разбивается вдребезги. Всё оказалось намного сложнее. Бизнес сторона не всегда может что-либо спланировать или четко сказать, что нужно сделать. Изолированность оффисов приводит к недостатку коммуникаций и не пониманию реальной ситуации и потребностей. А о технической документации вообще задумываются редко, особенно когда речь заходит о взаимодействии связанных, но разных частей системы (лучший пример клиент-серверная архитектура). А помимо пресловутого треугольника существует еще множество разнообразных служб и подразделений: Application Management, Системные администраторы, Backoffice, поддержка клиентов и пользователей и бог знает кто еще. И все, даже новенькая уборщица, имеют свой собственный взгляд на то, каким должен быть финальный продукт. Шутки шутками, но в реалиях действительно существует множество людей, прямо или косвенно использующих финальный продукт, имеющих разные взгляды на разработку и качество продукта. В результате всего этого, при отсутствии продуманного менеджмента, через некоторое время, возникает хаос. Часто, в этот момент владельцы или топ-менеджеры задумываются о тестировании и Quality Assurance.

В зависимости от мировоззрений руководства роль QA может сильно отличатся в разных компаниях. Соответственно и возможности менеджмента ограничены только этим. В любом случае, сначала придется работать в тех условиях, которые есть, с прицелом на то, чтобы получить больше возможностей для проведения улучшений, а для того чтобы это происходило легче нужно избегать ошибок в работе. Наиболее частные ошибки… ага, так очень любят писать, хотя откуда такие данные никому не известно. А мои ошибки были такие:

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

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

Частично своим умом, частично после советов коллег и «шпилек» от начальства, я смог определить план исправления ситуации. Начал я с построения общей информационной системы, позволившей упорядочить процесс тестирования и репортинг, при этом не сильно нагружая тест менеджеров.