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

[Undi]

Какое соотношение разработчиков (программистов), тестировщиков, аналитиков можно считать работоспособным (оптимальным)?

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

Например, компания из 10 программистов, 1 тестировщика, 1 аналитика. Или должен быть 1 тестировщик на каждые 4 программиста?

[Dimon]

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

Как показывает практика удобней всего на 2х-3х активных девелоперов 1-2 тестировщика.
Активных девелоперов я подразумеваю тестирование именно их работы, то что они напрограммировали. Т.е. Случай 3д-1т скорей всего удобней или на этапе проетирования или перед сдачей проекта. Случай 2д-2т применим когда продукт целиком нужно тестировать и все написанное создано внутренними программистами.

Если держаться где-то такого уровня, то это позволит нормально тестировать как внутренние проекты, так и проекты сугубо на тестирование.

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

Что касательно аналитиков (в них я не очень силен :)), то в зависимости от их роли (я сталкивался с разными аналитиками и как следствие с разными обязанностями). Если подразумевается аналитик который привлекается на стадии эстимейта и/или проектирования. То сдесь уверенно хватает вот-так 2 аналитика-эстимейтов на 20-40 проектов. А хасательно постраения архитектуру, то где-то 10 архитектур на одного аналитика. Я счетаю где то из расчета на месяц, проекты средних велечин (300-400 часов).

[Case]

Есть более формальные рекомендации в книге "Автоматизированное тестирование", зависимость количества тестировщиков от типа проекта.
Поищу сейчас на форуме, это уже пробегало.

[Case]

Dimon, а на чём основаны ваши цифры?
Просто уж очень лихо вы набросали цифры, не указывая какой тип проекта. По-моему если приложение не критическое - то есть можно себе позволить исправлять ошибки после внедрения - то можно и 10:1 себе позволить, а если это система жизнеобеспечения, то и 1:1 мало будет.

[Case]

Опять таки - играться с этим соотношением в зависимости от этапа проекта, конечно, можно - только вот ситуация - разрабатывается один проект. Так что делать тестерам? Сначала уволим, потом доберём, потом снова уволим?

[Guriy]

А теперь в тон сообщению от Case:

Проект активно разрабатывался лет 5-ть. После этого оставляем для сопровождения проекта и разработки новой функциональности 4-е разработчика. Проект важный с точки зрения жизнеобеспечения сотрудников (это в смысле за него деньги платят ;) )
Теперь вопрос - сколько нужно тестировщиков?
а если в проекте очень сильные межмодульные части?
а если внесение хоть одной маленькой функциональности затрагивает критичные функции?

ИМХО соотношение должно быть индивидуальным для каждого отдельно взятого проекта.

[Dimon]

Dimon, а на чём основаны ваши цифры?
Просто уж очень лихо вы набросали цифры, не указывая какой тип проекта. По-моему если приложение не критическое - то есть можно себе позволить исправлять ошибки после внедрения - то можно и 10:1 себе позволить, а если это система жизнеобеспечения, то и 1:1 мало будет.

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

Опять таки - играться с этим соотношением в зависимости от этапа проекта, конечно, можно - только вот ситуация - разрабатывается один проект. Так что делать тестерам? Сначала уволим, потом доберём, потом снова уволим?

Данные усредненны. Т.е. много проектов. Большое количество людей. Можно вообще нарисовать график (x=количество программистов, y=количество тестеров). И считать по средним проектам (2 программиста работают 2 месяца). При желании нарисовать ось z=количество проектов. Так будет точнее всего. И заполнить график статистическими данными.

Но как мне кажеться такое отношение наиболее приемлемо. Т.к. оказываеться всегда ряд второстипенных задач, которые не всегда вообще делаються, но заказчик готов с радостью их финансировать. :D

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

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

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

[Undi]

извините, если предыдущий пост был не точным.
Речь идет о соотношении программеров/тестеров для фирмы вцелом.
Например:
Есть вэб-отдел, есть отдел системных разработок и отдельный проект по java. Какое количество тестировщиков должно быть на фирме? Разумеется, в зависимости от нагрузок их можно "переключать" между работами. Но хотелось бы чтобы количество работников на фирме оставалось стабильным:)

[Case]

Данные усредненны. Т.е. много проектов. Большое количество людей. Можно вообще нарисовать график (x=количество программистов, y=количество тестеров). И считать по средним проектам (2 программиста работают 2 месяца). При желании нарисовать ось z=количество проектов. Так будет точнее всего. И заполнить график статистическими данными.

Если не сложно - попробуйте отобразить в виде графика.

Я всё время как ведущий сервера пекусь "об его приросте" :) Статью на данную тему не думаете написать? Я так вижу что опыт есть?

[Олешка]

Undi, могу кинуть статью на английском языке:

S.Kaner, Elisabeth Hendrickson and Jennifer Smith-Brock "Managing the proportion of testers to developers"

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

[Undi]

Undi, могу кинуть статью на английском языке:

S.Kaner, Elisabeth Hendrickson and Jennifer Smith-Brock "Managing the proportion of testers to developers"

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

Буду очень благодарна.

[Олешка]

Тогда плиз - пришли е-майл адрес приватом, или в аську скинь.

[SALar]

Отношение кол-во девелоперов / тестеров зависит от многих причин.
1) Необходимое качество проектов
2) Стадия проекта
3) Тип продукта

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

Стадией проекта пренебрежем. Будем считать, что фирма ведет несколько проетов, люди перебрасываются с проекта на проект.

По необходимому качеству:
1) "Коленочное" качество. За полгода обещали, за год сделали, и год-два отлаживали. 3/1 и больше.
2) Среднее качество. Нормальное качество продукта, т.к. возможна потеря денег при нарекании покупателя. 3/1 - 1/1. Если сроки не поджимают - оптимально 5-6/3.
3) Высокое качество. Системы высокой устойчивости или если необходимо максимально ужать срок. Банковские системы и тому подобное. Случай, когда тестирование ведется "с запасом". Т.е. по одним и тем же тест кейсам одновременно проходит несколько человек, введено автоматическое тестирование и т.д и т.п. 1/1 и меньше.

При управлении одним менеджером может быть например такая картина: Руководитель проекта, он же архитектор, 4-5 программистов, 3 тестера. Достаточно оптимальная команда для проекта на 10 - 100 человеко-месяцев.

[Undi]

SALar, спасибо за цифры!