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

[Юлиана]

У нас небольшая контора, около 20 человек, планируем развиваться.
Сейчас создаётся отдел тестирования. Чтобы не придумывать велосипед, я думаю, что надо ориентироваться на стандарты
У меня такой вопросик: на какие стандарты лучше всего ориентироваться. Или я могу выбрать какой мне больше нравятся, или можно смешивать?

[Clauster]

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

[dlg99]

20 человек?

А Вы уверены. что внедрение [на мой взгляд] достаточно тяжеловесных ISO/CMM в компании, где только "создаётся отдел тестирования" принесет пользу и получит поддержку тех самых 20 человек?

Agile processes (SCRUM/MSF/...), на мой взгляд, могли бы быть лучшей альтернативой.

Хотя сфера деятельности компании немаловажна, да и принятые практики/процессы тоже.

[Case]

Коллеги, по-моему вопрос всё-таки сформулирован верно - "на какой стандарт ориентироваться?". Не внедрять стандарт, а не что смотреть, чтобы не изобретать всё по новой.

Для работы отдела тестирования я бы всё-таки рекомендовал РУП,а не гибкие методологии (которые ещё тоже кстати надо внедрить). Большим подспорьем будут шаблоны РУПа - тот же тест план отвечает на многие вопросы, если его грамотно и вдумчиво отработать.

[Case]

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

Хотя на моей практике какой-то порядок начинался в основном из группы тестирования расти.

[Case]

Agile processes (SCRUM/MSF/...), на мой взгляд, могли бы быть лучшей альтернативой.

Позволю себе не согласиться. Зачастую из гибкости растёт хаос :) Особеннов небольших компаниях, где нет жетской руки и практика в той или иной гибкой методологии - вырождается всё в работу без документо и планов, а это как мы понимаем совсем не ХР или Скрум.

[Yury]

У нас небольшая контора, около 20 человек, планируем развиваться.
Сейчас создаётся отдел тестирования. Чтобы не придумывать велосипед, я думаю, что надо ориентироваться на стандарты
У меня такой вопросик: на какие стандарты лучше всего ориентироваться. Или я могу выбрать какой мне больше нравятся, или можно смешивать?

Юлиана,

Мы ничего не знаем о вашем рынке/клинтах, приложениях, процессе разработки, и т.п.
Также не очень понятно, в каком значении Вы используете слово "стандарт".

Без этой информации дать какой-либо содержательный совет невозможно.

Юрий

P.S. Только что обнаружил, что dlg99 уже сказал то же самое до меня :(.
Нельзя быть таким невнимательным.

[van]

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

http://www.citforum....th_per_project/
http://www.software-...really-need.htm
http://www.software-...lin/gone-if.htm

[SALar]

ISO - стандарт.
Семейство CMM - модели (не стандарт).
И есть еще много интересного: кайдзен, бережливое производство, PSP, ...

Изо всех них можно что-то брать. Внедрять целиком не советую. Прежде всего потому, что предлагаемые модели и стандарты - это прежде всего инструмент для роста компании, скажем, с трехсот до тысячи человек (если не иметь ввиду получение сертификата в рекламных целях). Использование CMM в полном объеме в малых компаниях до 100 человек, скорее всего, будет неоправданной тратой времени и денег. Работать не будет.

Сразу оговорюсь, что следует понимать сочетанине стандартов, моделей и проектных методологий и последовательность внедрения всего этого.
Так можно одновременно соответствовать ISO и CMMI. При этом для разных проектов можно использовать различные методологии.
Но например, для достижения хотя бы второго уровня CMMI необходимо, в частности:
* Управление требованиями
* Планирование проекта
* ...
третьего:
* Определение процессов организации
* Разработка требований
* Проверка продуктов на соответствие требованиям
* ...
Т.е. без внедрения методологии разработки ПО нельзя сертифицироваться на CMMI.

Соответственно, как правильно сказал Case, на данном этапе ориентируйтесь на методологию. А к ISO / CMMI вернитесь через пару лет.

Что из предлагаемого набора выбрать? Тяжеловесные (RUP, MSF) или легкие (Agile, SCRUM, XP, crystal)?
Как говорит Алистер Коберн, каждому проекту свою методологию. Если у вас проект на 10 человеколет и есть жесткие требования к качеству (ошибки ведут к серьезным потерям), то стоит задуматься об утяжелении методологии. Если есть ряд крохотных проектов (два - три человека на пару месяцев) и нет жестких требований к качеству, то лучше облегчить процесс. Если есть постоянный контакт с заказчиком, возможность организации коротких циклов и быстрого проведения бета тестирования, то можно обойтись без формализованного документа требований. Если же проект организован по принципу: "Когда все сделаете, посмотрим результат", - имеет смысл настаивать на создании ТЗ (даже для маленьких проектов).

[sunlex]

Дело совершенно не в стандартах, а в реальных условиях, существующих на вашей фирме, также в целях вашей фирмы.
На моей прошлой конторе не внедряли ни исо ни смм, но по уровню процессов они достигли что-то среднее между 3-м и 4-м левелом смм.
И им все эти лэйблы исошные и тд не нужны.
В моей текущей конторе внедрили исо (большей частью для кастомеров). Так вот оно осталось формальным, а реальные процессы представляют смесь мсф, рупа, смм и исо:)

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

Если вы не хотите экономить деньги фирмы и строить все сами - я бы посоветовал:
1 - постараться найти консультанта (знакомый QA manager с хорошей фирмы), и потиху настраивать работу.
2 - из "стандартов" мое личное предпочтение на стороне MSF. Опять же, как уже отмечали ребята на форуме - главное не стандарт:)

[Юлиана]

Спасибо всем за советы. В общем ваш взгляд на ситуацию я поняла.
Хочу разъяснить, что никакого стандарта мы пока внедрять не собираемся, на данном этапе этого пока и не нужно. Но мне бы всё-таки хотелось, чтобы перед глазами был "образец" ( если можно так выразится), на который можно ориентироваться и понимать к чему стремиться. Но в то же время не пытаться скопировать, а выбирать из стандартов то, что подходит нам. А то когда ничего нет так и выбирать не из чего. А самим выдумывать- это лишняя работа.
Спасибо Van за ссылки,


"Поправлю сам себя - смотрите не методологию, а не на стандарт. РУП например просто Библиотека хороших практик, из которых нужно набрать себе полезностей на все случаи жизни"
спасибо Case, наверно в нашем случае всё-таки првильнее будет использовать методологии.
Будем работать

[van]

Юлиана,

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

Осмелюсь предложить Вам в кратком виде то, что у меня получилось:
http://www.software-...ive-success.htm

[SALar]

На моей прошлой конторе не внедряли ни исо ни смм, но по уровню процессов они достигли что-то среднее между 3-м и 4-м левелом смм.

Не верю. Нет, не так. НЕ ВЕРЮ!!!

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

[Clauster]

Не верю. Нет, не так. НЕ ВЕРЮ!!!

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

Не, ну на второй тянут некоторые. Я работал в одной, там даже метрики собирали (типа на четвертый уровень).

[sunlex]

На моей прошлой конторе не внедряли ни исо ни смм, но по уровню процессов они достигли что-то среднее между 3-м и 4-м левелом смм.

Не верю. Нет, не так. НЕ ВЕРЮ!!!

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

Отчего же не верим?:)
Не знаю как в РФ, я работаю в РБ. Думаю что принципиальной разницы нет.

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

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

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

Конечно, смми 3-4 формально эта контора не получит. Финтифлюшки какой-нибудь не хватит. Но по мощности процессов она кое-где и на 5 потянет. Особенно в области постоянного импрува.

[Case]

Что из предлагаемого набора выбрать? Тяжеловесные (RUP, MSF) или легкие (Agile, SCRUM, XP, crystal)?

Коллеги, не являясь адептом РУП-а скажу только, что его незаслуженно относят к тяжёлым методологиям (что такое чёрт возьми "тяжелая" методология?!). Есть например РУП для малых команд :)

РУП - библиотека практик подкреплённая соотв.артефактами + есть рекомендации по внедрению РУП-а в проектах разного размера - что построить из РУП-а зависит от конкретных условий проекта/группы/компании. Что есть у РУП-а и чего нет (как мне кажется) у ХР и других "Скрумов" - масштабируемость для проектов разного размера. Не секрет, что небольшие проекты иногда вырастают в совершенно промышленных монстров. Что в таком случае будут делать адепты ХР, когда количество требований перемахнёт скажем 1000?

Я категорически против самого подхода, который "проповедуют" так называемые "гибкие методологии" сознательно противопоставляя себя мнимым гигантам в лице РУП-а. Основное что подкупает разработчиков и менеджеров в гибких методиках это "отсутствие документации" - ни более, ни менее. Зная нежелание писать что либо кроме кода, адепты "гибкости" первым делом выставляют эту, скажем так, особенность методологии. Что ещё полезного и удобного есть у Скрума, например? Итеративность? Митинги? Открытая коммуникация? Кто сказал что в "жестком" РУП-е этого нет? Есть – не надо изобретать велосипед, есть это всё :)

[Case]

Не, ну на второй тянут некоторые. Я работал в одной, там даже метрики собирали (типа на четвертый уровень).

Чего дальше с ними делали? :)

[я даже сяду поудобнее с блокнотом и ручкой]

[Case]

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

Согласшусь. Я выступал несколько раз в такой роли - созданные группы тестирования работают до сих пор и ведут за собой направление "порядка" в компаниях.

[Yury]

Для того чтобы держать производительность на высшем уровне ввелось отслеживание кучи метрик
.....................
Конечно, смми 3-4 формально эта контора не получит. Финтифлюшки какой-нибудь не хватит. Но по мощности процессов она кое-где и на 5 потянет.

Очень интересно Вы пишите.
Правильно ли я понял, что "мощность процесса" является одной из ваших метрик?
Не могли бя Вы написать немного поподробнее, я то я первый раз с такой метрикой сталкиваюсь.

Юрий

[Clauster]

Не, ну на второй тянут некоторые. Я работал в одной, там даже метрики собирали (типа на четвертый уровень).

Чего дальше с ними делали? :)

[я даже сяду поудобнее с блокнотом и ручкой]

Без понятия. Я там недолго задержался. У них свой департамент СМК и они там че-то рулят, я не вникал.
PS А смайлик это к чему? Типа не реально чтоли?