Проблемные команды надо делать хорошими постепенно, а для этого надо знать к чему стремиться. О «сферическом коне в вакууме» никто не говорит. Вполне себе реальные проекты. И таких вам могу не один десяток назвать только в Украине.
Мы с вами разговариваем на разных языках. Представьте, что я бы пытался вас научить бегать, а вы бы постоянно задавали мне вопрос: «хорошо, но как ваши советы заработают, если у меня не будет одной ноги? а двух?».
TDD не может в принципе являться инструментом контроля качества, потому что это стиль разработки (если вы конечно знаете о чем я, а не просто читали пару статей на эту тему). Про покрытие 100% в комментариях по соседству вы тоже можете найти мое мнение. А вот по поводу бюджета и оценки факторов я с вами соглашусь. Об этом писал в комментариях к вот этой статье.
Епрст, так я и предлагаю на каждом этапе в статье делать, а не только на завершающем. В этом и смысл. Модульные тесты, правильное планирование, TDD, прототипы и другие практики направлены на то, чтобы устранить ошибку на ранних этапах, а не ждать пока отдадут на тестирование. И теперь вы пришли к тому же…
Вот поэтому я вам не зря про прошлое написал. А подсчет брака никто не делает. Останавливают, исправляют проблему и дальше поехали. Почитайте про Тойота систему производства хотя бы пару книг. «Цель» Голдратта тоже прочтите для расширения кругозора, там много про качество и заботу о нем. После этого вернемся к разговору. А википедию завязывайте читать и учебники универские выкиньте с начала века.
По поводу ваших сомнений в существовании таких компаний — поверьте, за мой опыт консультирования и проведения тренингов я таких видел и очень много.
А по поводу ответственности всей команды я с вами совершенно согласен. Вот только как билд инженер мог повлиять на качество кода, который писали другие? Орать на них или морально давить?
Из моих знакомых, которые строили себе дома, только те построили классные и как хотелось, кто был очень сильно вовлечен. Те, кто просто платил и полагался на результат, до сих пор жалеют. Пример с ремонтом не на ровном месте…
Применяя подход из статьи, сначала стоит обсудить все детали болванки, потом выпустить одну и показать заказчику. Если это то, что ему нравится, то закрепить ее в качестве стандарта (приемочного теста) и автоматизировать проверку. Маню уволить. После этого выпускать точно такие же, показывая каждую сотую, чтобы вдруг не оказалось, что рынок поменялся.
А в вашем подходе с кучей метрик и отделов качества вся эта братия, «имеемая анально» под главенством Мани, будет по прежнему производить никому не нужный хлам. Да оставайтесь же вы в прошлом, в которое не хочется возвращаться!
Я больше вел речь не о производстве, а просто о заказных услугах по осуществлению каких-то работ. Вот заказали вы ремонт в квартире, пояснили как хотите чтобы он выглядел, нарисовали на бумажке, команду наняли толковую и дорогую. Смотрите в смету, а там графа «специалисты по контролю качества». А можете ли вы тем же людям доверить проверять качество и почему это отдельные люди? Что изначально есть риск получить некачественную работу, если этим специалистам не заплатить денег. Да и в чем им интерес своих же работников «подставлять»? Для вас качество будет соответствовать вашему пониманию + мнению независимых специалистов. Но вот независимые специалисты помогут вам с КОНТРОЛЕМ КАЧЕСТВА, а ваша вовлеченность в ремонт (просмотр ранних результатов, подстраивание и корректировка планов, общение с бригадой) поможет с ОБЕСПЕЧЕНИЕМ КАЧЕСТВА.
По поводу дефекта у меня есть определенное разделение, я о нем уже писал не раз. Про документацию речи в статье не шло, потому что разработчики ее и не пишут. Это не их труд.
Вы как призрак из прошлого века. И вдобавок все время норовите подчеркнуть весомость своего мнения за счет грубостей: бред, бредовой, буллшит. Но ладно, вернемся к вопросу.
Смотрите, все очень просто. Я постараюсь объяснить как бабушке. Есть человек А, который делает основную работу. Есть человек Б, которого наняли с целью контроля качества работы А. Конечной задачей Б является недопущение некачественной работы со стороны А. У человека Б есть два варианта:
— Дождаться пока А сделает работу. Проверить, описать проблемы и отослать обратно к А. Потом принять исправления, проверить и повторить операцию. При этом на само качество работы А и причины его деградации Б не влияет. В итоге такой же цикл будет повторяться постоянно и на нем будут тратить время и А и Б.
— Сделать все возможное на самых ранних этапах, чтобы А сделал работу заведомо качественно. Для этого он может прояснять требования, помогать А готовить тестовые примеры, проверять ранние незавершенные результаты его работы, искать причины проблем в работе А и помогать устранять их. В этом случае процесс разработки постоянно улучшается и качество вместе с ним.
Поэтому, загляните, пожалуйста, хотя бы в википедию, чтобы мы с вами говорили все-таки на одном языке.
Оно и видно, что вы в нее пересмотрели.
Если вы полностью автоматизировали процесс КОНТРОЛЯ (хотя я не сильно в это верю), то это не значит, что ваши разработчики им занимаются.
Мы автоматизировали процесс контроля регрессии собственной работы. Это помогает нам разрабатывать быстрее, потому что нет необходимости кучу усилий тратить на поддержание работоспособности старого функционала. Мы спокойно делаем рефакторинг, развиваем архитектуру и дизайн, пишем новый код и т.д.
Когда-то давно ОТК отделили от прочих инженерных подразделений по одной очень простой причине — когда сверху давят (типичнейшая заказная разработка), то инженеры склонны «не замечать» и недооценивать дефекты. Поэтому перенос на них ответственности по контролю (еще раз — именно контролю) — очень плохая идея.
Что-то недооценить или не заметить помешают вам заказчик и конечные пользователи продукта. Ваша задача искать причины пропуска и их устранять на будущее. Вот и все.
Текущий проект, над которым мы работаем, уже живет больше трех лет. Уверенно вышел в мир после нескольких месяцев разработки и зарабатывает деньги заказчикам. Релизы постоянные и частые (раз в 1-2 недели). В 2011 году вошел в топ 100 самых успешных стартапов года. У нас ни одного тестировщика и примеры из статьи во многом взяты из этого проекта. Все чисто на автоматизации и приемке заказчика, а также обратной связи от пользователей. Мы любим свою работу и делаем ее качественно.
И да, первый раз скриншоты надо будет просмотреть. Думаю разработчикам под силу с такой непростой задачей совладать…
В принципе, если эти отделы спрятаны от заказчика и вы просто не способны по-другому делать ПО, то это допустимо. Благодаря этому стоимость ваших услуг возрастет и вы будете неконкурентны на рынке. Пока это не так, но к этому идет. Знаю много компаний, в которых отделы тестирования расформировывают, а тестировщиков интегрируют в команды разработки. Чтобы ВКЛАДЫВАТЬ КАЧЕСТВО, а не контролировать, когда поделать уже ничего нельзя.
Если вы так хотите перейти на личности, то у меня два технических образования. Одно отечественное, второе немецкое. Как это повлияло на наш диалог о качестве?
Из своей практики, предположим разрабатываете вы систему управления для загрузчика ядерного топлива в АЭС.
Я с вами на 100% согласен, что в таких критических проектах надо на порядок больше внимания уделить процессу тестирования, даже стоит отдельную стороннюю команду тестирования нанять, а может и больше. Ведь цена ошибки колоссальна. Мы все такие проекты пишем? У всех такой риск ошибки?
Так же вы описали коня в вакууме, НЕ БЫВАЕТ команды на 100% из супер профессионалов, невозможно им сразу родится, и конкуренция на рынке всегда есть, сегодня у вас их 10 а завтра уже 8, и вы берете 2 мидлов, которые могут допустить ошибки.
Многие компании предпочитают делать небольшие команды, чтобы поддерживать культуру качества. Если набрать одних студентов, то понятное дело так работать не будет. А команд, в которых вся команда отвечает за качество и прилагает максимум усилий, чтобы не допускать понижения его уровня, я знаю много.
И действительно тут правильно указали, время разработчика дороже, нежели тестера. И это так же нужно учитывать.
Это обезьяньего тестера. Хороший специалист по тестированию стоит немало, а за границей даже больше в некоторых случаях разработчика.
Автоматизация никогда не покроет 100% возможных кейсов.
100% — абсолют. Он недостижим. Но приблизится к нему на безопасное расстояние с приемлемыми затратами можно.
Так же добавлю, любой профи человек, с девушкой поссорился, вчера перепил на свадьбе, гриппует, сидит с температурой +40. И тут хоть какой вы супер менеджер, но человек может допустить ошибку, и уйти на больничный. И что вы предлагаете? Взять второго ( у которого загрузка 100%) и попросить его проверить, что вчера Вася налабал с жутким похмельем? И на завтра у вас -1 профессионал.
Ваши мысли непонятны. У нас, к примеру, весь код обязательно проходит ревью и на него будут смотреть другие разработчики. Так что ваш плохой код по личностным проблемам не пролезет. А 100% загрузка и стремление к ней — еще одно большое зло в IT.
Качество надо не контролировать, а внедрять. Нельзя исправить некачественный продукт без дополнительных затрат. На заводе сначала много тестируют, а потом запускают в разработку.
Я написал по поводу узкой специализации и ее проблем чуть выше. С таким подходом разработка должна быть далеко не интеллектуальным трудом. Один придумывает все, описывает детально на достаточном уровне, чтобы другие сели и банально закодили. Ничего не напоминает? Процессы конца прошлого — начала этого века. Современная разработка от этого уходит и семимильными шагами.
TDD не может в принципе являться инструментом контроля качества, потому что это стиль разработки (если вы конечно знаете о чем я, а не просто читали пару статей на эту тему). Про покрытие 100% в комментариях по соседству вы тоже можете найти мое мнение. А вот по поводу бюджета и оценки факторов я с вами соглашусь. Об этом писал в комментариях к вот этой статье.
А по поводу ответственности всей команды я с вами совершенно согласен. Вот только как билд инженер мог повлиять на качество кода, который писали другие? Орать на них или морально давить?
А в вашем подходе с кучей метрик и отделов качества вся эта братия, «имеемая анально» под главенством Мани, будет по прежнему производить никому не нужный хлам. Да оставайтесь же вы в прошлом, в которое не хочется возвращаться!
По поводу дефекта у меня есть определенное разделение, я о нем уже писал не раз. Про документацию речи в статье не шло, потому что разработчики ее и не пишут. Это не их труд.
Смотрите, все очень просто. Я постараюсь объяснить как бабушке. Есть человек А, который делает основную работу. Есть человек Б, которого наняли с целью контроля качества работы А. Конечной задачей Б является недопущение некачественной работы со стороны А. У человека Б есть два варианта:
— Дождаться пока А сделает работу. Проверить, описать проблемы и отослать обратно к А. Потом принять исправления, проверить и повторить операцию. При этом на само качество работы А и причины его деградации Б не влияет. В итоге такой же цикл будет повторяться постоянно и на нем будут тратить время и А и Б.
— Сделать все возможное на самых ранних этапах, чтобы А сделал работу заведомо качественно. Для этого он может прояснять требования, помогать А готовить тестовые примеры, проверять ранние незавершенные результаты его работы, искать причины проблем в работе А и помогать устранять их. В этом случае процесс разработки постоянно улучшается и качество вместе с ним.
Оно и видно, что вы в нее пересмотрели.
Мы автоматизировали процесс контроля регрессии собственной работы. Это помогает нам разрабатывать быстрее, потому что нет необходимости кучу усилий тратить на поддержание работоспособности старого функционала. Мы спокойно делаем рефакторинг, развиваем архитектуру и дизайн, пишем новый код и т.д.
Что-то недооценить или не заметить помешают вам заказчик и конечные пользователи продукта. Ваша задача искать причины пропуска и их устранять на будущее. Вот и все.
И да, первый раз скриншоты надо будет просмотреть. Думаю разработчикам под силу с такой непростой задачей совладать…
Я с вами на 100% согласен, что в таких критических проектах надо на порядок больше внимания уделить процессу тестирования, даже стоит отдельную стороннюю команду тестирования нанять, а может и больше. Ведь цена ошибки колоссальна. Мы все такие проекты пишем? У всех такой риск ошибки?
Многие компании предпочитают делать небольшие команды, чтобы поддерживать культуру качества. Если набрать одних студентов, то понятное дело так работать не будет. А команд, в которых вся команда отвечает за качество и прилагает максимум усилий, чтобы не допускать понижения его уровня, я знаю много.
Это обезьяньего тестера. Хороший специалист по тестированию стоит немало, а за границей даже больше в некоторых случаях разработчика.
100% — абсолют. Он недостижим. Но приблизится к нему на безопасное расстояние с приемлемыми затратами можно.
Ваши мысли непонятны. У нас, к примеру, весь код обязательно проходит ревью и на него будут смотреть другие разработчики. Так что ваш плохой код по личностным проблемам не пролезет. А 100% загрузка и стремление к ней — еще одно большое зло в IT.