Рефакторинг фирмы, специализирующейся на тестировании

Описанное ниже, вряд ли подойдёт аджайл-проектам.
Когда встречаю объявления типа: "В связи с расширением штата сотрудников, требуется..", "Молодая развивающаяся компания ищет.. " и подобные им, сразу представляю, как маленькое село вырастает в пгт, оно, в свою очередь, в город, а тот – в мегаполис.

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

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

Такое себе – нагрузочное тестирование. Может стоит для анализа проблем фирмы нанимать перформанс инженеров? Почему бы и нет.. Интересно, были прецеденты?

Подробнее...

> Разделение труда является причиной повышения общей производительности труда организованной группы специалистов (синергетический эффект) за счет:
Не соответствует действительности. Есть эффекты, которые понижают производительность при разделении труда.

> b. Сокращения времени, затрачиваемого на переход между различными операциями
И увеличение времени на передачу работы на другой участок.



Детская болезнь таких фирм в другом. На маленьких проектах кодирование занимает много времени. По Макконелу до 86%. На проектах побольше процент трудозатрат на кодирование падает и растет процент на анализ и проектирование. Вместо того, чтобы выделить эти фазы фирма, страдающая детскими болезнями, реализует модель КУТ (кодирование-управление-тестирование). Модель убогая и дико неэффективная.

Вывод: внедрение тестирования в этой фирме было выбрасыванием денег на ветер. Требуется грамотный управленец, для внедрения фаз анализа и проектирования.


Модель SQA-MQA-JQA на первый взгляд выглядит красиво: "вторая дивизия налево, пятая направо и танки по центру". Это заставляет задуматься о ее жизнеспособности. Такие стройные теории хорошо смотрятся в каком-нибудь теоретическом труде. На практике они не работают.

Привет, SALar!

Не соответствует действительности. Есть эффекты, которые понижают производительность при разделении труда.

Можешь привести парочку примеров таких эффектов для отдела тестирования (про него ж сейчас говорим), учесть на будущее

> b. Сокращения времени, затрачиваемого на переход между различными операциями
И увеличение времени на передачу работы на другой участок.

В тестировании, или вообще?

Детская болезнь таких фирм в другом. На маленьких проектах кодирование занимает много времени. По Макконелу до 86%. На проектах побольше процент трудозатрат на кодирование падает и растет процент на анализ и проектирование. Вместо того, чтобы выделить эти фазы фирма, страдающая детскими болезнями, реализует модель КУТ (кодирование-управление-тестирование). Модель убогая и дико неэффективная.

Вывод: внедрение тестирования в этой фирме было выбрасыванием денег на ветер. Требуется грамотный управленец, для внедрения фаз анализа и проектирования.

На проектах побольше без тестирования ну вообще никак.. или я что-то упускаю?
Для программистов надо составить другую модель, сия только для отдела тестирования.

Модель SQA-MQA-JQA на первый взгляд выглядит красиво: "вторая дивизия налево, пятая направо и танки по центру". Это заставляет задуматься о ее жизнеспособности. Такие стройные теории хорошо смотрятся в каком-нибудь теоретическом труде. На практике они не работают.

Не применял на практике пока что, посему затрудняюсь подтвердить работает или нет :)
Но и утверждать, что если "красиво" , то на практике не заработает.. не возьмусь

Привет, SALar!

Не соответствует действительности. Есть эффекты, которые понижают производительность при разделении труда.

Можешь привести парочку примеров таких эффектов для отдела тестирования (про него ж сейчас говорим), учесть на будущее

Ключом к пониманию может служить вот эта задача: http://blog.shumoos.com/archives/183 . К сожалению, задача оказалась несколько сложновата. Что удивительно, чем больше у человека лет в трудовой написано "менеджер", тем хуже он решает эту задачу. Инженеры решают несколько лучше. В любом случае, не пожалейте времени, разберите эту задачу подробно.

Дополнительный материал: http://blog.shumoos.com/archives/186


К вопросу о рефакторинге фирмы: http://blog.shumoos.com/archives/194 . Готов вести диалог по каждому пункту по отдельности или по всем вместе.

Ключом к пониманию может служить вот эта задача: http://blog.shumoos.com/archives/183. К сожалению, задача оказалась несколько сложновата. Что удивительно, чем больше у человека лет в трудовой написано "менеджер", тем хуже он решает эту задачу. Инженеры решают несколько лучше. В любом случае, не пожалейте времени, разберите эту задачу подробно.

Дополнительный материал: http://blog.shumoos.com/archives/186


К вопросу о рефакторинге фирмы: http://blog.shumoos.com/archives/194. Готов вести диалог по каждому пункту по отдельности или по всем вместе.

С удовольствием! )
Перемещаюсь в этот блог, для продолжения беседы

Начать искать ошибки после написания кода это как начать делать бекапы после поломки винта. В принципе полезно, но несколько поздновато.

Начать искать ошибки после написания кода это как начать делать бекапы после поломки винта. В принципе полезно, но несколько поздновато.

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

Модель SQA-MQA-JQA на первый взгляд выглядит красиво: "вторая дивизия налево, пятая направо и танки по центру". Это заставляет задуматься о ее жизнеспособности. Такие стройные теории хорошо смотрятся в каком-нибудь теоретическом труде. На практике они не работают.

Я лично участвовал в проекте, где это работало. Правда, модель была не трёхуровневая, а двух. И мега-пацан был не один, а двое.
Данные проекта:
Израиль, Банк Леуми.
Название, извините, "Хермеш" (управление залогами и залоговыми процессами).
Длительность проекта - около 5-ти лет (проект продолжает жить).