Comments 14
а как может быть «Testing» — «Met», на основании чего такое предположение, скорее всего предположение :), может быть сделано?
и что значит «Feature Bugs» — «Met», в одной из предыдущих статьях был критерий «All bugs are fixed», и что прям все-все баги фиксаются? а те которые не фиксаются или не успеваются пофиксаться?
почему для «Code Coverage» туту же не показывается количественное значение, чему оно «Met»?
почему для «Code Coverage» туту же не показывается количественное значение, чему оно «Met»?
Визуализация — это сила!
Давненько я не думал в сторону requirement management.
Спасибо.
Давненько я не думал в сторону requirement management.
Спасибо.
У нас руководство как-то заинтересовалось этой штукой. Это же офигенская новая штука от МС для совместной разработки проектов. Потом увидели ценник и сказали что svn им будет выше крыши.
Интересные закголовки у элементов на картинках, типа: Nulla non trotor a dui semper posuere.
По виду — латынь :) Сходил в google translate. Так и есть: «Перевод этой языковой пары (латынь > русский) пока не поддерживается»
Шифруетесь? :)
По виду — латынь :) Сходил в google translate. Так и есть: «Перевод этой языковой пары (латынь > русский) пока не поддерживается»
Шифруетесь? :)
Это Lorem ipsum
А мне почему-то TFS всегда казался чем-то классически отстающим, второстепенным продуктом.
Это не значит что он плох, это достаточно мощный инструмент, но в умелых «натруженных» руках задр… настройщиков.
По сравнению с тем же YouTrack он очень жестко впаян в без того тяжеловесный интерфейс VS.
Посмотрите на форму Quality Gates: 33 поля выбора + 11 вкладок + 6 полей ввода.
Отчеты либо с плоскими графиками, либо текстовые. Строки в отчетах ни о чем не говорят, действительно ли «Critical», и все ли «Complete» невозможно понять пробежавшись взглядом, приходится вчитываться.
И с этим монстром приходится работать людям каждый день. бррр…
Это не значит что он плох, это достаточно мощный инструмент, но в умелых «натруженных» руках задр… настройщиков.
По сравнению с тем же YouTrack он очень жестко впаян в без того тяжеловесный интерфейс VS.
Посмотрите на форму Quality Gates: 33 поля выбора + 11 вкладок + 6 полей ввода.
Отчеты либо с плоскими графиками, либо текстовые. Строки в отчетах ни о чем не говорят, действительно ли «Critical», и все ли «Complete» невозможно понять пробежавшись взглядом, приходится вчитываться.
И с этим монстром приходится работать людям каждый день. бррр…
Действительно – долгое время отставал. Однако искренне уверяю вас, что 2010-я – существенный шаг вперед. Разумеется, в отдельных направлениях есть вещи и посильнее, однако не стоит забывать, что TFS – продукт универсальный: система контроля версий + сервис автоматической сборки + тестирование + жизненный цикл.
По поводу сложности формы Quality Gates: она кастомизирована под конкретный проект. Если точнее – по умолчанию ее вообще нет. В чем прелесть TFS: он дает базовые формы, а дальше вы сами можете добавлять то, что вам нужно в конкретном проекте. То же самое касается полей на существующих формах и логики.
Привязка к VS конечно есть, что и понятно, однако есть и не-VS инструменты, включая кросс-платформенные, а так же – плагин к Эклипсу.
К тому же установщик существенно переработан, конфигуратор – полностью визуальный.
По поводу сложности формы Quality Gates: она кастомизирована под конкретный проект. Если точнее – по умолчанию ее вообще нет. В чем прелесть TFS: он дает базовые формы, а дальше вы сами можете добавлять то, что вам нужно в конкретном проекте. То же самое касается полей на существующих формах и логики.
Привязка к VS конечно есть, что и понятно, однако есть и не-VS инструменты, включая кросс-платформенные, а так же – плагин к Эклипсу.
К тому же установщик существенно переработан, конфигуратор – полностью визуальный.
Меня как-то удивило, что все отметки и их корректность доверялось ставить самим разработчикам. Посчитал, что тут багов нет и все критерии выполнены — и закрыл задачу. У нас вот на фирме баг закрывается только после проверки программистом, системой автоматического тестирования и тестером. А иногда (для критеческих вещей) еще и ПМом или другим программистом. А тут — «мы людям доверяем». Хм.
Так оно и есть: предположим я нашел баг и открыл work item и отправил его тимлиду. Тимлид, зная своих людей, по характеру бага закрепляет его за исполнителем. После исправления, исполнитель отправляет баг обратно лиду, тот проверяет и, если все нормально, отправляет его мне. Затем я проверяю и закрываю его, если все нормально. И это – тоже в простейшем случае. В сложных – подход индивидуальный.
Кроме человека, который открыл баг, закрыть его никто не может.
В статье имелись в виду обобщенные критерии. Т.е. менеджер может изменить quality gate только, если условия удовлетворяют требуемым. Пример: quality gate = не должно быть багов с приоритетом больше 2. Соответственно он может поставить “met” только, если у него нет багов с высоким приоритетом.
Если же он смухлюет, и это обнаружат… Ну вы сами понимаете :)
Кроме человека, который открыл баг, закрыть его никто не может.
В статье имелись в виду обобщенные критерии. Т.е. менеджер может изменить quality gate только, если условия удовлетворяют требуемым. Пример: quality gate = не должно быть багов с приоритетом больше 2. Соответственно он может поставить “met” только, если у него нет багов с высоким приоритетом.
Если же он смухлюет, и это обнаружат… Ну вы сами понимаете :)
Sign up to leave a comment.
Как Microsoft DevDiv использует TFS – части 8 и 9