Каморка

Jou-Jou писал(а):

Stanislav писал(а):соотношение программеров:тестеров стало 1:1+

Интереса ради, а какое соотношение ты считаешь примерно правильным?

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

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

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

А как тестеры могут проверить хорош ли продукт для конечных пользователей?
Для этого тестер должен быть специалистом в предметной области.

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

Хм... ну если на стадии тестирования выяснилось, что дизайн/архитектура/требования к продукту неправильные, то это ИМХО означает только одно - полный провал, впустую потраченные деньги и надо начинать все сначала...

Stanislav писал(а):

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

А как тестеры могут проверить хорош ли продукт для конечных пользователей?
Для этого тестер должен быть специалистом в предметной области.

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

Stanislav писал(а):

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

Хм... ну если на стадии тестирования выяснилось, что дизайн/архитектура/требования к продукту неправильные, то это ИМХО означает только одно - полный провал, впустую потраченные деньги и надо начинать все сначала...

Отстало мыслите - отрасль уже давно начала переход от вотерфола (где действительно, если была допущена ошибка на предыдущей стадии разработки, то на последующих ее не исправить в этой версии) к аджайлу. Ну и всё-таки, нечасто бывает, чтобы дизайн/архитектура/требования были неправильны на 100%...

Meadie писал(а):

Stanislav писал(а):

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

А как тестеры могут проверить хорош ли продукт для конечных пользователей?
Для этого тестер должен быть специалистом в предметной области.

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

Ну вот такого тестера достаточно одного-двух, это не сильно изменит соотношение девел:тест

Meadie писал(а):

Stanislav писал(а):

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

Хм... ну если на стадии тестирования выяснилось, что дизайн/архитектура/требования к продукту неправильные, то это ИМХО означает только одно - полный провал, впустую потраченные деньги и надо начинать все сначала...

Отстало мыслите - отрасль уже давно начала переход от вотерфола (где действительно, если была допущена ошибка на предыдущей стадии разработки, то на последующих ее не исправить в этой версии) к аджайлу. Ну и всё-таки, нечасто бывает, чтобы дизайн/архитектура/требования были неправильны на 100%...

Ага! Вот что такой аджайл!
Это когда за мои деньги отпиливается оттуда и приклеивается сюда (см. известную картинко про разработку программ), а потом меня убеждают, что так и должно быть!

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

johndoe писал(а): вообще то дизайном и должны заниматься люди, понимающие в этом.

Exactly.

johndoe писал(а): В девелопменте соответственно девелоперы.

А не логичнее чтобы дизайном занимались дизайнеры? Ну а код по разработанному дизайну писали девелоперы.

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

Чем позже в SDLC находишь ошибки, тем дороже стоит их исправление. Непонятно как может быть "экономически целесообразно" находить неправильности на стадии тестирования? Ведь в таком случае надо возвращаться к архитектуре и дизайну, переделывать их, переписывать код и потом опять тестинг. Где тут экономическая целесообразность?

Stanislav писал(а):

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

Хм... ну если на стадии тестирования выяснилось, что дизайн/архитектура/требования к продукту неправильные, то это ИМХО означает только одно - полный провал, впустую потраченные деньги и надо начинать все сначала...

+100. Ответила до того как прочла Stanislav-а

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

Чё-то у Вас как-то Agile не совсем верно озвучен, в смысле что он нужен для исправления ошибок сделанных в предыдущих версиях

Jou-Jou писал(а):Чем позже в SDLC находишь ошибки, тем дороже стоит их исправление. Непонятно как может быть "экономически целесообразно" находить неправильности на стадии тестирования? Ведь в таком случае надо возвращаться к архитектуре и дизайну, переделывать их, переписывать код и потом опять тестинг. Где тут экономическая целесообразность?

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

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

Jou-Jou писал(а):

johndoe писал(а): вообще то дизайном и должны заниматься люди, понимающие в этом.

Exactly.

johndoe писал(а): В девелопменте соответственно девелоперы.

А не логичнее чтобы дизайном занимались дизайнеры? Ну а код по разработанному дизайну писали девелоперы.

"Девелоперы", пишущие код по разработанному кем-то дизайну, называются кодерами, а не девелоперами. В software development нет дизайнеров per se, да и понятие "дизайн" (не UI!) в SD - это все-таки <софтвер> (или <аппликейшн>) дизайн, и этим-таки занимаются (в том числе) Девелоперы ( не кодеры). Именно Девелоперы - это те люди, которые "понимают в дизайне" софта. Архитекторы решают другие вопросы ...

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

Gadi писал(а):Кстати, часто бывает, что архитекторы еще и девелоперы, а девелоперы в большинстве случаев еще и кодеры. Вот чистых кодеров держать часто бывает экономически нецелесообразно.

+100500

Gadi писал(а):

Jou-Jou писал(а):

johndoe писал(а): вообще то дизайном и должны заниматься люди, понимающие в этом.

Exactly.

johndoe писал(а): В девелопменте соответственно девелоперы.

А не логичнее чтобы дизайном занимались дизайнеры? Ну а код по разработанному дизайну писали девелоперы.

"Девелоперы", пишущие код по разработанному кем-то дизайну, называются кодерами, а не девелоперами. В software development нет дизайнеров per se, да и понятие "дизайн" (не UI!) в SD - это все-таки <софтвер> (или <аппликейшн>) дизайн, и этим-таки занимаются (в том числе) Девелоперы ( не кодеры). Именно Девелоперы - это те люди, которые "понимают в дизайне" софта. Архитекторы решают другие вопросы ...

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

По последнему утверждению. В небольших компаниях и под небольшие аппликейшены - да, согласна.

Я писала о крупных разработках, my bad что не оговорила это сразу. Тут для разработки внутреннего дизайна аппликейшена (не внешнего вида UI-а, а именно внутреннего дизайна системы, дизайна отдельных модулей, дизайна интеграции этих модулей etc) используются люди с особыми мозгами и другими знаниями, чем "кодеры". Названия для них встречала разные - Systems Integration Design, Internal Development Design, Technical Design. A "кодеры" чаще всего называются Development. Отсюда и конфьюжн.

Meadie писал(а):

Jou-Jou писал(а):Чем позже в SDLC находишь ошибки, тем дороже стоит их исправление. Непонятно как может быть "экономически целесообразно" находить неправильности на стадии тестирования? Ведь в таком случае надо возвращаться к архитектуре и дизайну, переделывать их, переписывать код и потом опять тестинг. Где тут экономическая целесообразность?

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

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

Спасибо за описание Agile, я вообще-то в нём четыре года назад уже работала, так что представление имею.

Ответа, однако, на поставленный вопрос -

как может быть "экономически целесообразно" находить неправильности на стадии тестирования

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

Несколько десятков миллионов долларов на проект и коллектив в 400 человек может считаться не мелкой разработкой?