Тестирование как сервис, предоставляющий услуги всем группам разработк

В продолжение семинара 14 апреля статья о производственных потоках: http://habrahabr.ru/post/139194/

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

угу--сс....
много информации для "подумать".

хм.. ощущение огромного личного опыта )).
А где можно найти расписание семинаров, Вами проводимых?

Более интересный тюнинг доски был предложен Олегом (не указал фамилии) в статье «Канбан в IT (Kanban Development)» (http://habrahabr.ru/...elopment/64997/ ).

Федоров

В продолжение семинара 14 апреля статья о производственных потоках: http://habrahabr.ru/post/139194/

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

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

А где можно найти расписание семинаров, Вами проводимых?

Ближайшие:

• 25-26 мая 2012 года в Минске «Analyst Days» - доклад об анализе производственных потоков. Будет являться дополнением к статье и семинару "Канбан в SWD - это миф".
• 9 июня, Москва, devconf http://devconf.ru/of...d_tracking=1339 "Параллельная разработка альтернатив как третий способ спасения горящего проекта" - рассказ об одной из практик нацеленных на полноценное использование ограничения системы. Тематики таже - TOC, просто другой аспект.
• 23-24 июня, Иваново третий Летний Аналитический Фестиваль (ЛАФ'12) - видимо на второй день возьмусь вести семинар по принципу "От завтрака до упора". Тематика объемная и что либо понять можно только после 2-4 часов.

Суммарно объем готового материала с примерами, задачами, играми на симоляторах производства - порядка двух дней.

Попытались бы вы решить проблемы, оставляя обязательно каждому проекту свою команду тестирования?

В частности и сейчас пытаемся. Да, это довольно сложно.

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

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