Архив рубрики 'Управление большим числом задач'

Багтрэкинг, работа с ним или без него

Понедельник, Декабрь 22nd, 2014

Не исключительно мое мнение:
Основное назначение трекера - дать возможность руководителю работ управлять реестром работ по проекту. Реестр задач на исправление багов,  подмножество реестра работ по проекту.”

Рекомендуемая последовательность:

  1. Внедряем процесс ведения реестра.
  2. Внедряем процесс управления реестром.
  3. Внедряем процессы создания развернутых описаний элементов реестра.

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

“Если руководитель на регулярной основе не занимается управлением реестра, то с управлением проблемы”. И, очень вероятно, бактрекер не нужен. Если вы не собираетесь делать шаг “2″, то зачем вам шаг “1″!?
Кстати. “Внедрение процесса управления реестром” дает огромный эффект. Вполне может получиться, проект по разработке системы удастся сделать в 1.5 - 2 (это не только моя оценка) раза быстрее.

Пример требований к системе. Часть 1.

Четверг, Апрель 10th, 2008

UPD от 2018 года.  А сейчас я использую этот документ на тренинге по написанию и верификации юзкейсов. И мои ученики уверенно находят в этом документе ошибки.

——————————————-
В связи с огромным количеством вопросов: «А где можно найти образец написания требований к системе?» - и стандартным ответом: «В рунете - маловероятно», - выкладываю вариант описания требований к системе.

В целом эта документация базируется на руповском шаблоне SRS. Это не плохо и не хорошо. Для некоторых команд было бы удобней видеть не варианты использования, а пользовательские истории. И совсем не видеть функциональных требований в виде «Система должна» ;-) . А описание объектов можно делать и более удобным способом. Но так писать тоже можно. В конце концов, если бы на проектах была такая документация, жить как программисту, так и тестировщику было бы значительно проще.

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

Дисклаймер. Авторские права да данный материал полностью принадлежат мне. При публикации не пострадали интересы ни одной фирмы.

(more…)