Сообщений в теме: 42

[SALar]

Для одновременного:

• снижения стоимости проекта,
• уменьшения сроков
• и увеличения качества

достаточно создание отдела технического контроля на любом участке до тестирования.

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

[rlabs]

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

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

[SALar]

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

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

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

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

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

[rlabs]

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

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

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

[SALar]

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

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

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

[CVD]

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

[DrVal]

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

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


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

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

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

[Clauster]

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

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

[greesha]

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

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

:)

[rlabs]

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

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

[SALar]

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

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

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

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

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

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

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

[Clauster]

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

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

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

[rlabs]

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

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

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

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

[DrVal]

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

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

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

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

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

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

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

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

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

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

[Clauster]

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

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

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

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

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

[DrVal]

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

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

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

[rlabs]

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

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

[SALar]

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

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

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

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

[DrVal]

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

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

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

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

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

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

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

[Alfa]

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

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

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