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

Практикум по тест-дизайну 2.0
онлайн, начало 29 ноября
Тестирование REST API
онлайн, начало 18 ноября
Автоматизатор мобильных приложений
онлайн, начало 27 ноября
Selenium WebDriver: полное руководство
онлайн, начало 15 ноября
Фотография

Парадокс современного российского софтостроения


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

#1 SALar

SALar

    Гуру

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


Отправлено 07 Январь 2010 - 13:13

Для одновременного:
  • снижения стоимости проекта,
  • уменьшения сроков
  • и увеличения качества
достаточно создание отдела технического контроля на любом участке до тестирования.

Исходя из опросов коллег и личных наблюдений могу сделать вывод, что подобная формула верна не для всех российских фирм, но для большинства. Есть и другие методы, но этот любопытен своей парадоксальностью.
  • 0

-- 

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

Блог 255 ступеней

 


#2 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 659 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 07 Январь 2010 - 14:33

А подробнее?
В моем понимании любые формы выделенного контроля скорее ухудшают ситуацию.

И тем не менее, не очень понятно, как выглядит такой отдел и чем занимается.
  • 0

#3 SALar

SALar

    Гуру

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


Отправлено 07 Январь 2010 - 17:00

В моем понимании любые формы выделенного контроля скорее ухудшают ситуацию.

Правильно. Но до понимания этого фирмам еще расти и расти. Для тех, кто смог дорасти, рекомендация будет звучать так:

достаточно введение процедуры контроля качества ПО на любом участке до тестирования.


А совсем правильным будет:

достаточно введение процедуры контроля качества ПО на любом участке до кодирования


  • 0

-- 

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

Блог 255 ступеней

 


#4 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 659 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 08 Январь 2010 - 03:54

достаточно введение процедуры контроля качества ПО на любом участке до кодирования

А как же тотальный контроль качества, Lean и другие позитивные методы?

Такая рекомендация, по-моему, не решает основную проблему - коммуникации, из-за которых (а точнее из-за их отсутствия) даже "проконтролированная" задача до кодирования будет понята неправильно и реализована плохо. Либо же я не понимаю саму идею контроля качества до кодирования.
  • 0

#5 SALar

SALar

    Гуру

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


Отправлено 08 Январь 2010 - 19:30

Есть и другие методы, но этот любопытен своей парадоксальностью.

Либо же я не понимаю саму идею контроля качества до кодирования.


1) Бутылочным горлышком должен быть самый дорогой участок
2) Достаточно часто самый дорогой участок - это кодирование
3) Один из методов увеличения пропускной способности бутылочного горлышка - выбраковка перед ним
  • 0

-- 

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

Блог 255 ступеней

 


#6 CVD

CVD

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

  • Members
  • Pip
  • 47 сообщений
  • ФИО:Сергей

Отправлено 10 Январь 2010 - 09:13

SALar, на мой взгляд, ваша идея разумна, но достаточно утопична по той причине, что далеко не всегда есть хорошее представление о том, как должна выглядеть система.
Иными словами, весьма узки рамки ее применения и хотелось бы понять хотя бы приблизительно, какой процент функционала может быть покрыт этой схемой.
Велик процент ситауций, когда "Туман войны" проясняется после кодирования или достаточно проясняется после тестирования. Что вы скажете на это? Как вы думаете, каким должен быть "процент ясности" по тому или иному функционалу, чтобы эта схема была жизненной?
  • 0

#7 DrVal

DrVal

    Постоянный участник

  • Members
  • PipPipPip
  • 230 сообщений
  • ФИО:Drozdov V. V.

Отправлено 11 Январь 2010 - 11:21

Это все верно, если участок, на котором выбраковывают, сам не становится бутылочным грлышком.

В общем, справедливо при 2-х допущенях:
1. Кодирование является бутылочным горлышком.
2. Возможно создать рентабельную процедуру, которая позволит выявлять дефекты до этапа кодирования.


Почему гибкие методологии более эффективны для определенного класса проектов?
Потому как править написанный код быстрее, чем создавать артефакты и искать в них дефекты.

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

1) Бутылочным горлышком должен быть самый дорогой участок
2) Достаточно часто самый дорогой участок - это кодирование
3) Один из методов увеличения пропускной способности бутылочного горлышка - выбраковка перед ним


  • 0

#8 Clauster

Clauster

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 11 Январь 2010 - 16:05

Почему гибкие методологии более эффективны для определенного класса проектов?
Потому как править написанный код быстрее, чем создавать артефакты и искать в них дефекты.

Не хочется вступать в дискуссию, но по моему мнению, тут вы не правы.
  • 0

#9 greesha

greesha

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

  • Members
  • PipPipPipPip
  • 363 сообщений
  • ФИО:Печёнкин Григорий Михайлович
  • Город:Мытищи

Отправлено 11 Январь 2010 - 16:20

Не хочется вступать в дискуссию, но по моему мнению, тут вы не правы.


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

:)
  • 0
Григорий Печёнкин
greesha.ru
жежешечка

#10 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 659 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 11 Январь 2010 - 17:17

Не хочется вступать в дискуссию, но по моему мнению, тут вы не правы.

В существующем коде действительно быстрее и проще искать дефекты, чем в специально для этого написанной документации. Ну, на вкус и цет, конечно.
  • 0

#11 SALar

SALar

    Гуру

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


Отправлено 11 Январь 2010 - 17:48

В общем, справедливо при 2-х допущенях:
...
2. Возможно создать рентабельную процедуру, которая позволит выявлять дефекты до этапа кодирования.

А в чем проблема, кроме низкой квалификации персонала? По большей части эта процедура совершено бесплатна. "Бэз воздмэздно. То есть да'ом"

Почему гибкие методологии более эффективны для определенного класса проектов?
Потому как править написанный код быстрее, чем создавать артефакты и искать в них дефекты.

Справедливо при низкой квалификации персонала в области системного анализа (очень распространенная ситуация). А гибкие методологии эффективны потому, что там работают универсалы. Вместо аналитиков, техписов, кодеров и тестировщиков там работают разработчики. Смотри задачу про заборостроителей http://blog.shumoos.com/archives/183 .

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

Неверно по нескольким пунктам.
1) При проектной организации разработки софта стоимость проекта прямо пропорциональна времени. При производственной организации, как это ни странно, увеличение пропускной способности в 2.5 раза также приводит к уменьшению среднего времени проектов. Дай бог памяти... в 3-4 раза. Я не виноват, это статистика.

2) сроки проекта определяются не длинной критического пути, а длиной критической цепи. Критический путь - это вырожденная критическая цепь в условии отсутствия конфликта по загрузке сотрудников и/или ресурсов.
  • 0

-- 

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

Блог 255 ступеней

 


#12 Clauster

Clauster

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 11 Январь 2010 - 19:57

Не хочется вступать в дискуссию, но по моему мнению, тут вы не правы.

В существующем коде действительно быстрее и проще искать дефекты, чем в специально для этого написанной документации. Ну, на вкус и цет, конечно.

Наверное, если наша цель - поиск дефектов. Только причем тут гибкие методологии я не понял.
  • 0

#13 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 659 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 12 Январь 2010 - 05:27

В существующем коде действительно быстрее и проще искать дефекты, чем в специально для этого написанной документации. Ну, на вкус и цет, конечно.

Наверное, если наша цель - поиск дефектов. Только причем тут гибкие методологии я не понял.

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

В других ситуациях, возможно, эффективнее идти по V-процессу и осуществлять специальный контроль на каждой стадии.
  • 0

#14 DrVal

DrVal

    Постоянный участник

  • Members
  • PipPipPip
  • 230 сообщений
  • ФИО:Drozdov V. V.

Отправлено 12 Январь 2010 - 07:49

В общем, справедливо при 2-х допущенях:
...
2. Возможно создать рентабельную процедуру, которая позволит выявлять дефекты до этапа кодирования.

А в чем проблема, кроме низкой квалификации персонала? По большей части эта процедура совершено бесплатна. "Бэз воздмэздно. То есть да'ом"


Процедура далеко небесплатна, как минимм для этого требуется:
- артефакты, в которых можно искать дефекты
- дополнительные квалифицированные ресурсы
- время

В конечном этоге эти расходы могут и окупиться, но они есть.

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

Просто возьмите одну конкретную компанию и посчитайте, во что им обойдется создание такой точки контроля.

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

Неверно по нескольким пунктам.
1) При проектной организации разработки софта стоимость проекта прямо пропорциональна времени. При производственной организации, как это ни странно, увеличение пропускной способности в 2.5 раза также приводит к уменьшению среднего времени проектов. Дай бог памяти... в 3-4 раза. Я не виноват, это статистика.

2) сроки проекта определяются не длинной критического пути, а длиной критической цепи. Критический путь - это вырожденная критическая цепь в условии отсутствия конфликта по загрузке сотрудников и/или ресурсов.


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

#15 Clauster

Clauster

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 12 Январь 2010 - 12:39

В существующем коде действительно быстрее и проще искать дефекты, чем в специально для этого написанной документации. Ну, на вкус и цет, конечно.

Наверное, если наша цель - поиск дефектов. Только причем тут гибкие методологии я не понял.

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

В других ситуациях, возможно, эффективнее идти по V-процессу и осуществлять специальный контроль на каждой стадии.

Ключевые слова working и comprehensive
"править написанный код быстрее, чем создавать артефакты и искать в них дефекты" - больше похоже на некий индусский принцип разработки, чем на обоснование эффективности Agile. То, что искать дефекты в написанном коде проще - понятно, но вряд ли это эффективно. Если бы это было так, то мы вряд ли знали бы про такие вещи как XP, TDD и т.п. (конечно же, при Agile и правят написанный код, и создают артефакты, и ищут дефекты в артефактах).
По-моему, эффективность Agile в том, что мы без серьезных потерь, можем перестраиваться под меняющуюся ситуацию на рынке. С г..нокодом, который будет постоянно правиться тоже можно, конечно, но мне кажется коллапс тут неизбежен.
  • 0

#16 DrVal

DrVal

    Постоянный участник

  • Members
  • PipPipPip
  • 230 сообщений
  • ФИО:Drozdov V. V.

Отправлено 12 Январь 2010 - 14:01

Я же не утверждал, что это относится ко всем проектам. Да и Agile не упоминал.

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

Ключевые слова working и comprehensive
"править написанный код быстрее, чем создавать артефакты и искать в них дефекты" - больше похоже на некий индусский принцип разработки, чем на обоснование эффективности Agile.


  • 0

#17 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 659 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 12 Январь 2010 - 14:13

Если бы это было так, то мы вряд ли знали бы про такие вещи как XP, TDD и т.п. (конечно же, при Agile и правят написанный код, и создают артефакты, и ищут дефекты в артефактах).

Ритм TDD "red/green/refactor" как раз является неплохим примером этого принципа.
  • 0

#18 SALar

SALar

    Гуру

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


Отправлено 12 Январь 2010 - 20:15

Процедура далеко небесплатна, как минимм для этого требуется:
- артефакты, в которых можно искать дефекты
- дополнительные квалифицированные ресурсы
- время

Вы предлагаете нанять дополнительных людей? Если нет, то откуда возьмутся дополнительные расходы?

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

Вот не надо придумывать за меня то, что я не говорил. Профайл таких компаний совершенно другой. Для существования данного парадокса достаточно, чтобы в проекте были выделенные роли. Аналитики требования пишут, кодеры код, техписы руководство пользователя, тестировщики ошибки.
  • 0

-- 

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

Блог 255 ступеней

 


#19 DrVal

DrVal

    Постоянный участник

  • Members
  • PipPipPip
  • 230 сообщений
  • ФИО:Drozdov V. V.

Отправлено 13 Январь 2010 - 06:52

Процедура далеко небесплатна, как минимм для этого требуется:
- артефакты, в которых можно искать дефекты
- дополнительные квалифицированные ресурсы
- время

Вы предлагаете нанять дополнительных людей? Если нет, то откуда возьмутся дополнительные расходы?


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

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

Вот не надо придумывать за меня то, что я не говорил. Профайл таких компаний совершенно другой. Для существования данного парадокса достаточно, чтобы в проекте были выделенные роли. Аналитики требования пишут, кодеры код, техписы руководство пользователя, тестировщики ошибки.

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

Я не говорю, что утверждение неверно, оно просто неуниверсально :-)
  • 0

#20 Alfa

Alfa

    Специалист

  • Members
  • PipPipPipPipPip
  • 553 сообщений
  • Город:Moscow

Отправлено 14 Январь 2010 - 09:40

А гибкие методологии эффективны потому, что там работают универсалы. Вместо аналитиков, техписов, кодеров и тестировщиков там работают разработчики. Смотри задачу про заборостроителей http://blog.shumoos.com/archives/183 .

А откуда тогда эффективность тех команд, которые перешли на гибкие методологии, но не достигли кроссфункциональности? Судя по постоянно возникающим обсуждениям в духе «у нас нет кроссфункциональности, как нам жить?» и «как достичь кроссфункциональности?» таких команд хватает. Кроме того, не все гибкие методологии предписывают кроссфункциональность, в MSF for agile, например, есть выделенные роли.

И еще такой вопрос: а если в водопад набрать универсалов, тоже заработает эффективно?
  • 0

Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.





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

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

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