Перейти к содержимому

Тестирование производительности: JMeter 5
онлайн, начало 2 июля
SQL: Инструменты тестировщика
онлайн, начало 1 июля
Docker: инструменты тестировщика
онлайн, начало 1 июля
Программирование на C# для тестировщиков
онлайн, начало 25 июня
Фотография

Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 64

#61 OVA

OVA

    Опытный участник

  • Members
  • PipPipPipPip
  • 405 сообщений
  • ФИО:Высоцкий Сергей Павлович
  • Город:Новосибирск

Отправлено 02 декабря 2011 - 04:00

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

Я, возможно, опять покажусь занудой, но у меня magic numbers всегда вызывают подозрения.
"Для решения сложных задач" звучит как "среднее по больнице". Я видел команды меньше (больше, кстати, редко видел) и им всего хватало. Не назвал бы их задачи простыми. Для разных задач нужны разные наборы специализаций.
Мне в свое время довелось работать в команде, размер которой менялся от 2 до 8 человек на разных стадиях проекта. Это работало. Более того - ничего страшного в этом небыло, т.к. объемы работ менялись время от времени, а в компании производили продукты такие, что переключение с одного на другой много времени не занимало.
В достаточно больших проектах опять же приходится разбивать работы по проекту на несколько комнд.
Кстати, в командах с руководителями я не работал уже года четыре как.

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

Это для вас тестирование производительности это временная активность. Для ряда продуктов она практически непрерывная. В ряде случае оно решается проще - выделенные команды дизайнеров/администраторов/нагрузки/прочих специалистов. Часто, кстати, команда консультирует профессионала, а не наоборот.

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

ЗЫ: Кстати, в фазу тестирования я уже давно не верю. Но это отдельный разговор.
  • 0

#62 maksiq

maksiq

    Новый участник

  • Members
  • Pip
  • 24 сообщений
  • ФИО:Максим Цепков

Отправлено 09 декабря 2011 - 06:05

Дополню этот тезис статистикой Макконела. (К несчастью, этой книги нет в продаже. Если будет второе издание покупайте не думая.)

Из статистики Путнэма следует, что 7 кросфункциональных разработчиков сделают такой проект быстрее, чем 3 аналитика + 7 программистов + 4 тестировщика.


Сергей, а можно ссылку на книжку? Я у Макконнелла на русском нашел только Совершенный код (по фамилии автора), но у тебя скан чего-то другого. И хочется как-то подробнее о графике, хотя, возможно, за этим придется лезть в оригинал (судя по всему это Putnam, Myers - Five core metrics 2003). Потому что приведена статистика анализа "бизнес-проектов среднего размера", из чего не следует, что они эквивалентны. Объем кода тоже ничего особого не говорит. Так что сроки и объем вполне могут быть функцией сложности проектов.
  • 0

#63 maksiq

maksiq

    Новый участник

  • Members
  • Pip
  • 24 сообщений
  • ФИО:Максим Цепков

Отправлено 09 декабря 2011 - 06:33


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

Я, возможно, опять покажусь занудой, но у меня magic numbers всегда вызывают подозрения.
"Для решения сложных задач" звучит как "среднее по больнице". Я видел команды меньше (больше, кстати, редко видел) и им всего хватало. Не назвал бы их задачи простыми. Для разных задач нужны разные наборы специализаций.
Мне в свое время довелось работать в команде, размер которой менялся от 2 до 8 человек на разных стадиях проекта. Это работало. Более того - ничего страшного в этом небыло, т.к. объемы работ менялись время от времени, а в компании производили продукты такие, что переключение с одного на другой много времени не занимало.

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

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

Разбивать работы по проекту на несколько команд - это понятно, но в данном случае речь о том, что происходит внутри команды и каким набором активностей она обладает. Что касается руководителя, то это вопрос о терминах. Он может быть более или менее формальным, и работать разными методами. Зрелая команда не нуждается в непосредственном руководстве, но персонализация внешних интерфейсов сохраняется. Активности PM - никуда не уходят, и полностью за пределами команды быть не могут. SCRUM делит весь набор активностей между двумя людьми - PO и SM, в наших командах PM обычно более сильный, но я встречал и обратную ситуацию.


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

Это для вас тестирование производительности это временная активность. Для ряда продуктов она практически непрерывная. В ряде случае оно решается проще - выделенные команды дизайнеров/администраторов/нагрузки/прочих специалистов. Часто, кстати, команда консультирует профессионала, а не наоборот.

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

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

Это можно перефразировать как "я не люблю учебники, потому что они бессмысленны сами по себе. Это просто знания, теория в лучшем случае шаблоны решения каких-то умозрительных задач. Они ничего не гарантируют в реальной жизни. Для каждой задачи все равно приходится искать свой метод решения."
  • 0

#64 SALar

SALar

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 09 декабря 2011 - 07:43


Дополню этот тезис статистикой Макконела. (К несчастью, этой книги нет в продаже. Если будет второе издание покупайте не думая.)

Из статистики Путнэма следует, что 7 кросфункциональных разработчиков сделают такой проект быстрее, чем 3 аналитика + 7 программистов + 4 тестировщика.


Сергей, а можно ссылку на книжку? Я у Макконнелла на русском нашел только Совершенный код (по фамилии автора), но у тебя скан чего-то другого. И хочется как-то подробнее о графике, хотя, возможно, за этим придется лезть в оригинал (судя по всему это Putnam, Myers - Five core metrics 2003). Потому что приведена статистика анализа "бизнес-проектов среднего размера", из чего не следует, что они эквивалентны. Объем кода тоже ничего особого не говорит. Так что сроки и объем вполне могут быть функцией сложности проектов.

"Сколько стоит программный проект" http://www.livelib.ru/book/1000217546
Ключевая книга для оценивания проектов. Я ее поставил в топ-7. из тех, которые должен прочитать IT-шник.
В первоисточник лезть все равно надо. Я этот график рассматриваю, как повод задуматься. Т.е. можно задавать вопросы, можно спорить, отмахнуться нельзя.

PS. Немного оффтопа.
Предположим у нас проект как раз такого размера (1000 функциональных точек). Есть команда в 5 человек. Понимаем, что есть риск не успеть. Добавляем еще 15 человек.
Похоже, что наилучшей стратегией будет создание 4 маленьких команд и работа в параллель. Вдруг кто успеет. У Тойоты подобный подход называют выбор альтернатив. Кстати, в разработке софта тоже так иногда так делают. Запускают 30 проектов, точно зная, что выпускать будут только 3.
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#65 OVA

OVA

    Опытный участник

  • Members
  • PipPipPipPip
  • 405 сообщений
  • ФИО:Высоцкий Сергей Павлович
  • Город:Новосибирск

Отправлено 14 декабря 2011 - 05:44

Зрелая команда не нуждается в непосредственном руководстве, но персонализация внешних интерфейсов сохраняется.

Не вижу причин почему внешние интерфейсы должны быть зациклены на одну персону.

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

Я вполне нормально отношусь к agile. Я плохо отношусь к продаже silver bullets, неосмысленным ритуалам и к тому когда выдают желаемое за действительное, даже если они очень похожи.
Ну и еще раз - я всю жизнь работаю в "продуктовых лавках", где одноразовых проектов практически не существует. Т.е. с моей точки зрения тестирование как было постоянной активностью, так ей и осталось и "заслуг" agile тут в принципе нет.
Да и в целом тесторование всегда было настолько постоянным насколько вам хотелось. Не более и не менее

Это можно перефразировать как "я не люблю учебники, потому что они бессмысленны сами по себе. Это просто знания, теория в лучшем случае шаблоны решения каких-то умозрительных задач. Они ничего не гарантируют в реальной жизни. Для каждой задачи все равно приходится искать свой метод решения."

Слишком вольная метафора. Тренд это просто тенденция. Много agile это тренд. Рост популярности соцсетей это тренд. Угги у девочек на ногах это тренд. Но в большинстве своем IT-контора это не модная девочка и для нее следование трендам далеко не всегда не самоцель.
  • 0


Инструменты тестировщика: Командная строка
онлайн
Практикум по тест-дизайну 2.0
онлайн
Программирование на Phyton для тестировщиков
онлайн
Тестирование производительности (JMeter)
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале