Hi!

paul310
Про bug tracker: организация эффективной работы поддержки - это отдельная большая тема. Могу только сказать, что
"голый" телефон - это самый омерзительный и неэффективный способ.
Расскажу, как сделано у нас.

Пользователи напрямую в багтракер не пишут. Туда вообще никто не пишет, кроме QA. Пользователи общаются с саппортом через
специальную самописную CRM-систему. Это что-то типа форума, где разные предприятия заказчики друг-друга не видят, но сотрудники
нашей конторы имеют полный доступ на чтение и запись по всем заказчикам. Телефон - самый омерзительный способ. Аська и персональная
почта - тоже плохо. Информация по всем заявкам должна документироваться в единой доступной всем базе. Заявки, соответственно,
подразделяются на "новое требование", "просто консультация", "проблема". Новые требования - к аналитику. Просто консультации - к
саппорту. Проблема - к QA. Только после того, как QA воспроизведет проблему на эталонной системе, она заносится в багтракер, в
тестплан, в тестовые скрипты (которые при запуске должны сказать FAILED). И отправляется руководителю проекта (который передает ее
нужному разработчику). После исправления идет команда на автоматическую сборку билда и запуск тестскриптов (которые должны сказать
OK). После этого QA закрывает багу.

Почему в багтракер пишет только QA. Потому, как правильно локализовать проблему и найти причину - нужна квалификация, которая есть
только у QA, кроме того, нужно следить за тестскриптами и тестпланом. Если все подряд будут менять тестскрипты, настанет хаос.

Для того, чтобы QA воспроизвел проблему на эталонной системе, есть логи. В системе предусмотрена возможность полного
протоколирования всех операций. Ее можно включить или выключить. Понятно, что протоколировать надо не только ошибки, но и все
действия которые были до этого. Соответственно, рассказы по телефону: "Я тут нажал кнопку и у меня тут что-то непонятное", - в сад.
Нужно просто попросить юзера включить логи и попробовать повторить. Потом выложить логи в CRM, где оно станет доступно и QA и
разработчикам и всем остальным сотрудникам. Часто повторить сразу не получается. С включенным журналированием юзер может работать
несколько дней. Рано или поздно проблема повторяется. Тогда появляются логи в миллионы записей. Есть специальный утиль для
автоматизированного анализа логов. Имея логи можно точно установить, что и где произошло. Эти логи и прикладываются к формулировке
проблемы в багтракере.

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

Почему QA должен проблему воспроизводить на эталонной системе. Потому, что вопросы, типа: "Я не читал документацию, но мне кажется,
что тут неправильно", "я криво что-то настроил, и у меня нифига не работает", способны остановить любую разработку, если их
передавать непосредственно разработчикам. Если у юзера что-то не работает оттого, что у него сеть криво настроена, то это еще не
бага, это просто саппорт. И только когда QA подтверждает, что проблема воспроизводится в лабораторных условиях, это считается багой.
Это сильно уменьшает вероятность патовых ситуаций, когда у юзера не работает, а у разработчика все замечательно работает. QA со
своей эталонной системой тут служит арбитром.

Чего мы добились:

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

Все 100% ошибок на данный момент отлавливаются многоуровневой системой контроля качества.

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

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

Есть только один минус. Начальству кажется, что руководитель проекта балду пинает (ведь все так просто и само собой
работает). Тестеры балду пинают (ведь ошибок же нет). Программисты нифига не делают (а чего там программировать-то,
все элементарно). Потому зарплату не повышают а народ пришел к выводу, что достигли нирваны и дальше совершенствоваться
некуда, а потому все резко захотели свалить. В стране полно проектов, где все не так шоколадно, и на их оптимизации можно
срубить немало бабла.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73

Posted via ActualForum NNTP Server 1.4

Hi!

NikolayK
Вопрос был о планировании новой разработки.
А это имеет непосредственное отношение к планированию. Планирование, всего лишь часть управления
проектом, а не существует само по себе. Есть работы вероятностного характера, и они
не поддаются планированию. А есть вполне предопределенные. Допустим, дают программисту задание
реализовать фичу, срок - 40 часов. Он начинает работу, в этот момент звонит юзер и говорит, что у него
ошибка и надо исправить, потом еще кто-то чего-то спросил, потом еще. Итог - работа в срок не сделана,
по этой причине задержано начало других работ, в итоге полетел план-график всего проекта. Вся фигня
в том, что программист работает по заданию и календарному графику, а у саппорта нет графика,
он реагирует на события. И нельзя смешивать эти работы в одну кучу. Саппорт - процесс параллельный
и независимый от разработки.

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

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

У нас нет ТЗ и такой документ вообще отсутствует. Есть спецификации требований. Заказчик
присылает некую "хотелку". Иногда сразу понятно, что надо делать и сколько времени это
займет, иногда нужно довольно длительное обсуждение и это занимает месяцы. Требования
регистрируются в специальной базе данных. Далее идет процесс обсуждения. Разработчики,
тестеры и т.д. его читают (им в почтовый ящик валится), просто чтобы быть в курсе. Они
вполне могут вмешаться и задать уточняющий вопрос. Это не обязательно и не должно их
сильно отвлекать от текущей работы, но просто рекомендуется, т.к. сильно сократит время
"въезжания в тему" в будущем. Как только мне становится понятно, что примерно
надо делать и есть хоть какая-то обоснованная оценка сроков, требование получает статус
"согласовано". У требований, понятно, есть приоритеты. Примерно 10% должно иметь
"высокий", примерно 20% - "низкий", остальные - "средний". По каким критериям
расставляются приоритеты - отдельная тема и не техническая.

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

И вот после релиза предыдущей версии наступает сабж для следующей. В этот момент
мы уже имеем список требований, их приоритетов и оценку сроков, а также протокол
обсуждения с заказчиком этих требований, причем все участники проекта заранее в курсе
дела. Все планирование заключается в том, чтобы набрать из списка требований с учетом
приоритета такое их количество, чтобы в сумме получилась длительность следующей
итерации. Например, начальство может сказать: "Хотим релиз к выставке. Такая-то дата."
Нет проблем.

Далее объявляется (для руководства) список требований, которые будут реализованы,
делается предварительный календарный план-график всех работ. Собственно, вот
и все планирование. После этого для каждого требования составляется более детальная
спецификация. Это этап проектирования. Собственно, в спецификации может быть несколько
частей. Функциональную часть согласовывают с заказчиком. Особенности реализации
согласовывают с разработчиками. Спецификацию должна утвердить команда и заказчик.
И в этот момент уже имеется достаточно точная оценка сроков и рисков по данному
требованию, а также уточненный календарный план. Когда все спецификации по всем
требованиям утверждены, можно начинать программировать.

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

Так что все очень просто. Главное понять, что надо навсегда забыть
подход: "Зачем личность должна изобретать велосипед если в мире существуют
сдандарты для постановок задач вот только ВОПРОС в наборе используемых
инструментов."

В мире нет стандартов. Есть практики. Удачные и неудачные в конкретных
условиях применения. И те и другие надо знать и изучать. В конкретных
условиях используются те или иные методы. Есть RUP, MSF, Agile, XP,
PMBOK, SWEBOK и много других слов. Даже в моем сумбурном
описании можно найти сразу элементы нескольких разных подходов.
Если я буду работать в другой конторе и над другим проектом,
то там буду делать все по-другому, в зависимости от специфики.

NikolayK
Интересно разработкой какой системы Вы занимаетесь
http://www.solidworks.ru/products/data_management/

NikolayK
и количество программеров, тестеров, саппортов можно в % отношении.
В разное время было разным. Во время активного развития было три разработчика
(включая меня, т.к. я тоже разрабатываю), три тестера, один саппорт.

Соотношение % сильно зависит от проекта. Глупо стараться делать 1:3 только
потому, что "так делает Microsoft при разработке винды". Вы работаете в конторе,
аналогичной Microsoft, над разработкой операционной системы? Если нет, то к чему
аналогии?
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73

Posted via ActualForum NNTP Server 1.4