Сообщений в теме: 55

[tolyy]

Немного истории.
Я пришел в компанию 4 недели назад,как Senior QA Engineer.
Не было ни багтрекинговой системы ,ни системы управления требованиями. Требования были сформулированны лишь устно.

Сейчас есть и уже работает 3 недели багтрекинг\Requirement Managment от Microsoft - Team Fundation Server. Налажена работа с багами, после создания бага ,его смотрит тимлидер девелоперов ,выставяет приоритет и ассайнит на девелопера. Проведена большая работа по изменению существующих форм и шаблонов для багов и требований.(список изменений - 3 страницы в Ворде) Так же в систему занесены порядка 50 требований. Этим требованиям выставлены приоритеты ,увы не совсем удачно. В основном вся инициатива по написанию требований и наладки багтрекинга происходила от меня. Да и по установке сервера тоже.

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

Есть два предложения:
1) Сейчас все требования имеют три приоритета А, В, С.
50% - А
40% - В
10% - С

Я хочу ,чтобы все приоритеты были пересмотрены.
А - необходимая функциональность ,которая ДОЛЖНА быть реализованна ,протестированна и работать СТАБИЛЬНО через месяц. Без неё демонстрация не состоиться.
В - Если останеться время ,то реализуем и доведем до стабильности часть или все эти требования
С - Если случиться ЧУДО ,то займемся этим.

Распредлением я предлагаю следующие:
А - 30-35%
В - 30-35%
С - 30-35%
Т.е. все категории примерно по ровну.

2) У нас очень часто бывало ,что неожиданное добавление новой функциональности или что еще хуже изменение уже реализованной приводило к тому,что ломались другие компоненты.

Поэтому Я предлагаю назначить дату, примерно 10-14 дней до предпологаемого мини-релиза. К этой дате должны быть УЖЕ реализованны как минимум все требования с приоритетом А.
После этой даты добавление новой функциональности будет приостановлено до релиза. Будет производиться исскючительно тестирование, багфикс ,стабилизация. Таким образом мне кажеться реальным представить руководству стабильный, рабочий релиз.

Вопросы ,комментарии ? Не слишком ли круто?

[Case]

Размер команды?
Объём проекта?
Источник цифр для того как хочется сделать (А, В, С)?

PS
Ресурсы на всё это есть или как в том анекдоте (попробуем теперь взлетть со всем этим добром на борту)?

[DrVal]

Поэтому Я предлагаю назначить дату, примерно 10-14 дней до предпологаемого мини-релиза. К этой дате должны быть УЖЕ реализованны как минимум все требования с приоритетом А.
После этой даты добавление новой функциональности будет приостановлено до релиза. Будет производиться исскючительно тестирование, багфикс ,стабилизация. Таким образом мне кажеться реальным представить руководству стабильный, рабочий релиз.

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

[Azart]

А почему бы не совместить первое и второе предложение, но с доработками?

1. Разбить на два приоритета.
А - необходимая функциональность ,которая ДОЛЖНА быть реализованна, протестированна и работать СТАБИЛЬНО через месяц. Без неё демонстрация не состоиться.
В - Вся остальная функциональность, реализация которой может быть отложена.

2. Необходимо чётко разграничивать релизы в которых работает всё и те в которых добавление НОВОЙ функциональности внесло сбой в работу ПО. Естественно демонстрировать начальству необходимо последний 100%-ый рабочий релиз(возможно без какого либо функционала).

[DrVal]

2. Необходимо чётко разграничивать релизы в которых работает всё и те в которых добавление НОВОЙ функциональности внесло сбой в работу ПО. Естественно демонстрировать начальству необходимо последний 100%-ый рабочий релиз(возможно без какого либо функционала).

Если проект большой и участников много, то получение билда, удовлетворяющего определенным критериям, - это отдельная задача.
Пока фиксят одно, ломают другое, и невозможно выбрать "100%-ый рабочий релиз(возможно без какого либо функционала)".

[Azart]

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

[DrVal]

Azart, а у вас есть опыт участия в проектах, в которые вовлечены несколько команд общей численностью больше 100 человек?

[Izaboo]

Добрый день всем!

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

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

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

[barancev]

Я думаю в данной ситуации багам нужно ставить приоритеты исходя из их серьезности вообще для программы в целом, а не для релизной версии.

Как фокус внимания смещается... В оригинальном сообщении речь шла про приоритеты требований.

[Izaboo]

Да, barancev, спасибо что поправили и я приношу извинения за неточности. Хотя своего мнения не меняю, в посте понятие требования прозвучали в контексте требований к программе, или я не права снова и это были требования к процессу?
Проясните для меня пожалуйста, кто понял :)

Видимо придется идти в школу и учиться читать....

[tolyy]

Ага ,вот и понедельник все подтянулись на работу ,а уж решил что все вымерли :)

2 Azart
Потому что из 3 выбирать интереснее чем из 2. Мы уже это проходили,побили все требования фактически на 2 группы. Одна критичные - 75% ,другая 25%. Что получилось я уже написал. Принялись за все сразу и ничего не сделали.

2 Izaboo
Про баги не было ни одного слова.
А вы кем работаете?:) Если тестером ,то мне кажеться ,вы можете пропустить много багов ,раз даже не имеет привычки тестировать перед постингом своё сообщение

2 DrVal
Вообще в проекте вместе с тимлидером и мной всего 10 человек..


2 ALL
Я внес предложение и его вроде одобрили. Тока оно слегка изменилось , теперь в основе распределения лежит удельная сложность:

Новая модель.
Теперь мы будем использовать новую модель ,которая с большим успехом применяеться в других сложных и дорогих системах Requirement Managment.

Теперь подразумееваеться ,что все требования предпологаеться выполнить к релизу. Т.е. инными словами мы хотим,чтобы все требования будут реализованны ,протестированны и стабилизированны.

Однако для каждого требования вводится новый параметр – Difficulty.

Кроме того приоритеты теперь иммеют тока три значения:

А - необходимая функциональность ,которая ДОЛЖНА быть реализованна ,протестированна и работать СТАБИЛЬНО через месяц. Без неё демонстрация не состоиться.

В - Если останеться время ,то реализуем и доведем до стабильности часть или все эти требования

С - Если случиться ЧУДО ,то займемся этим.

Новый параметр Difficulty иммеет 4 значения: 1,2,3,4.

Основная идея : в первую очередь реализуется,тестируются и стабилизируеются наиболее критичные и простые требования.

Предпологаеться ,что внедрить два требования с сложностью 1 примерно соответсвует одному требованию с сложность два.

Еще на стадии планирования будет автоматически вычислена удельная сложность все требований A , B , C. Вы меняете величины и тут же видите график удельной сложности.

Удельная сложность вычисляеться путем сложения сложностей требований.

Распределение на графике удельной сложности к которому следует стремиться

А - 30-35%

В - 30-35%

С - 30-35%
Т.е. все категории примерно по ровну.

Ну конечно все работает через Team Foundation Server.

Что думаете?

[DrVal]

Что думаете?

Думаем, что тим-лида надо уволить.

С моей точки зрения, полсотни требований - это не так много, с ними вполне можно работать напрямую.

[tolyy]

2 DrVal
С моей точки зрения, полсотни требований - это не так много, с ними вполне можно работать напрямую.


Чего то я не понял,что значит напрямую

[Mila]

Основная идея : в первую очередь реализуется,тестируются и стабилизируеются наиболее критичные и простые требования.

В итоге можно получить приложение, в котором ни один процесс не будет доведен до логического конца... а так... кусками... доводка же может быть менее критичной, но более сложной

Но это все зависит от задачи: продемонстрировать осмысленное работающее приложение, или показать отчет, в котором возле большинства требований поставлены галочки


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

[tolyy]

2 Mila
Оффициально проект должен быть готов где-то к 01.2007 года.
А это промежуточная демонстрация. Требования написаны в рамках промежуточной демонстрации. Оказалось ,как я уже писал,если взяться сейчас за все сразу ,то не успеть вообще ничего! В конечный релиз почти наверняка попадут все требования. Однако уже сейчас ситуация складывается неблагоприятным для проекта образом. И если через месяц опять будет нечего демонстрировать ,то проект может быть просто свернут. Моя задача сделать так,чтобы через месяц получить стабильный промежуточный билд и чтобы в нем была хотябы частично обещанная функциональность.
Покупателей и менеджеров по продажам просто нет. Продукт предназначен будет только для внутреннего использования и это совсем не значит ,что на качество можно забить.

[Green]

tolyy,
Ваш подход совершенно верен. Слона нужно есть по частям.

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

Главная задача любого программного продукта - решать определенную бизнес задачу. Если решает - то продукт годится, если нет, то не зависимо от того, что он умеет Вам за него не заплатят ни копейки. Собственно, этот постулат и должен лежать в основе распределения задач во времени.

В первую очередь должно быть создано ядро системы, т.е. функции, ради которых создается приложение (скелет). Затем те, которые расширяют минимально необходимую функциональность, другими словами, которые необходимо реализовать, что бы продукт выглядел закончено (мышцы). И уже в конце приступать к всяким украшательствам и "вкусностям".

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

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

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

[DrVal]

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

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

Остальные требования (вот она и B) просто сортируются по приоритету. Если ресурсы высвобождаются и им нельзя назначить таски из А, то они берут таски с максимальным приоритетом из B. Все, что не успели автоматом попадает в C.

Обсуждать же здесь проценты бесполезно, оно очень зависит от специфики проекта.

[Azart]

Azart, а у вас есть опыт участия в проектах, в которые вовлечены несколько команд общей численностью больше 100 человек?

Нет.

В таком случае я бы сосредоточился только на А.

Об этом я и писал раньше...

[Mila]

To tolyy

А это промежуточная демонстрация.... Продукт предназначен будет только для внутреннего использования и это совсем не значит ,что на качество можно забить.

Вот на Качество (с большой буквы) как раз таки и можно забить Чтобы провести демонстрацию, достаточно, чтобы проходили наиболее простые случаи (никто не будет ждать, пока вы создадите мега-сложный объект или проведете сложнейшие многочасовые операции с сотней тысяч объектов) + красивое GUI. Заказчик все равно не будет пользоваться данным билдом. Набор тестов, на которой стоит гонять - это сама демонстрация.

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

[tolyy]

2 Green
Вы знаете ,бывает так что многие требования так и не доживают до релиза. Умирают своей смертью ,т.к. оказываються ненужными и сложнореализуемыми. Вот я и надеюсь что некоторые сложные требования могут так и умереть

2 Mila
Вообщем я наверное не упомянул ,что сразу после демонстрации руководству планируеться разослать мини-рилиз в несколько офисов по всему миру и ждать фидбэков. Будет странно ,если оттуда придут фидбэки ,по типу - шаг всторону от продеманстрированных возможностей - КРЕШ
Если я правильно понял ,то на всякие красивости и удобства пока лучше всего будет подзабить?