Господа, по видимому, RUP — это хорошо, но всё-же каждый подстраивает его под свои нужды и выделяет из него наиболее подходящие, практичные вещи, да и видимо есть альтернативы RUP.
Вопрос вот в чём: кто какие роли использует в ходе проектов ? Понятно, что зависит от проекта, но видимо есть устоявшиеся основные роли. И по возможности процесс взаимодейстия между ними.
Т.е. например: разработчик и тестировщик. Разработчик пишет всю документацию и код, тестер пишет баги и отдаёт разработчику, внедряет отлаженный продукт. А все остальные роли — ненужное разделение труда. Или как-то ещё.
В частности очень интересует тонкий момент рабочего процесса проектирования и его связка с другими, т.е. есть ли некий архитектор, или лид-проектировщик, или ещё как-то и каким образом подобная роль взаимодействует с остальными.
Спасибо.

Здравствуйте, BalTun, Вы писали:

BT>Господа, по видимому, RUP — это хорошо, но всё-же каждый подстраивает его под свои нужды и выделяет из него наиболее подходящие, практичные вещи, да и видимо есть альтернативы RUP.
BT>Вопрос вот в чём: кто какие роли использует в ходе проектов ? Понятно, что зависит от проекта, но видимо есть устоявшиеся основные роли. И по возможности процесс взаимодейстия между ними.
BT>Т.е. например: разработчик и тестировщик. Разработчик пишет всю документацию и код, тестер пишет баги и отдаёт разработчику, внедряет отлаженный продукт. А все остальные роли — ненужное разделение труда. Или как-то ещё.
BT>В частности очень интересует тонкий момент рабочего процесса проектирования и его связка с другими, т.е. есть ли некий архитектор, или лид-проектировщик, или ещё как-то и каким образом подобная роль взаимодействует с остальными.
BT>Спасибо.

Почитайте нативную доку. Там все описано.

Здравствуйте, BalTun, Вы писали:

BT>Вопрос вот в чём: кто какие роли использует в ходе проектов ? Понятно, что зависит от проекта, но видимо есть устоявшиеся основные роли. И по возможности процесс взаимодейстия между ними.

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

S>В проекте должны использоваться все роли, но один человек может сочетать в себе несколько ролей. По RUP не помню, но практика показала, что не все роли могут сочетаться безболезненно в одном человеке. Примером может служить плохое сочетание программиста-кодера и тестировщика.
Что любопытно, в XP приветствуется написание и прогон тестов программистом-кодером

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

S>> Примером может служить плохое сочетание программиста-кодера и тестировщика.
c> Что любопытно, в XP приветствуется написание и прогон тестов программистом-кодером

Так это, извините меня, во-первых, XP, где сама разработка направляется модульными тестами (и даже начинается не с написания кода, а с написания тестов), а во-вторых, приёмочные тесты как раз должны исполнять не разработчики, а заказчики. Так что ваше замечание немного не в тему.

Здравствуйте, cvoronin, Вы писали:

S>>В проекте должны использоваться все роли, но один человек может сочетать в себе несколько ролей. По RUP не помню, но практика показала, что не все роли могут сочетаться безболезненно в одном человеке. Примером может служить плохое сочетание программиста-кодера и тестировщика.
C>Что любопытно, в XP приветствуется написание и прогон тестов программистом-кодером
Практика показывает, что человек, который написал программу, не в состоянии корректно оттестировать ее.

C>>Что любопытно, в XP приветствуется написание и прогон тестов программистом-кодером
А>Практика показывает, что человек, который написал программу, не в состоянии корректно оттестировать ее.
XP утверждает, что человек не в состоянии корректно написать программу, не имея для неё тестов

Здравствуйте, cvoronin, Вы писали:

S>>В проекте должны использоваться все роли, но один человек может сочетать в себе несколько ролей. По RUP не помню, но практика показала, что не все роли могут сочетаться безболезненно в одном человеке. Примером может служить плохое сочетание программиста-кодера и тестировщика.
C>Что любопытно, в XP приветствуется написание и прогон тестов программистом-кодером

Не надо путать юнит-тесты, с полноценным приемочным и др. функциональным тестированием.

Здравствуйте, BalTun, Вы писали:

BT>Господа, по видимому, RUP — это хорошо, но всё-же каждый подстраивает его под свои нужды и выделяет из него наиболее подходящие, практичные вещи, да и видимо есть альтернативы RUP.
BT>Вопрос вот в чём: кто какие роли использует в ходе проектов ? Понятно, что зависит от проекта, но видимо есть устоявшиеся основные роли. И по возможности процесс взаимодейстия между ними.
BT>Т.е. например: разработчик и тестировщик. Разработчик пишет всю документацию и код, тестер пишет баги и отдаёт разработчику, внедряет отлаженный продукт. А все остальные роли — ненужное разделение труда. Или как-то ещё.
BT>В частности очень интересует тонкий момент рабочего процесса проектирования и его связка с другими, т.е. есть ли некий архитектор, или лид-проектировщик, или ещё как-то и каким образом подобная роль взаимодействует с остальными.
BT>Спасибо.

Дьявол, как обычно кроется в деталях . Это какую документацию пишет разработчик??? Требования к системе? Не всякий разработчик сможет это сделать хорошо. Если речь о проектной документации (т.е. описание дизайна и архитектуры), то опять-таки смотря что вкладывать в эти понятия. Основная проблема -- волюнтаризм (или просто откровенная безграмотность???) менеджеров проектов или тех кто исполняет их роль, которые не понимают разницу например м/у системной и программной архитектурой и тем более не знают как ее правильно задокументировать. Естетственно если это необходимо для данного конкретного проекта.
Вообще -- все определется целями которыми вы перед собой ставите (использование ролей и прочия). Но разумно не изобретать велосипед, что любят делать многие отечественные менеджеры даже не имя систематизированных знаний о методологиях, а обратиться к накопленному опыту.
Посему подстраивать RUP под свои нужды -- это тоже нужно уметь. Классика, если огрубить, выделяет как минимум роли Менеджера проекта, системного аналитика (или аналитика требований), разработчика, тестера, ну еще про деплоймент можно вспомнить в качестве основных позиций. Очевидно, что фиксировать требования в каком либо виде к системе нужно, при понимании этого -- необходимость роли системного аналитика (или аналитика требований) очевидна. Проектирование ... -- это зависит от проекта. Но как минимум, особенно в отечественной практике, неоправданно большое внимание (IMHO!!!) уделяется проектированию структуры БД (правда это все статическая модель, не понятно как при таком подходе описать бизнес-логику ... но это др. вопрос), так что роль системного аналитика, тоже выходит нужна. Разработка -- ну куда без этого . Тестирование -- это тоже от проекта заваисит. Можно, например, возложить часть тестирования на заказчика. Так что необходимость не всегда очевидна. Про деплоймент молчим.
Да, естетсвенно в некоторых случаях эти рольи может выполнять и один человек (это о совмещении).
Если говорить про agile то там все по-разному. Но дизайн никто не отменяет. XP -- это отдельная песня со своими условиями. Там есть зачатки требований (user story), а недостаток дизайна как тоакового компенсируется постоянным РЕФАКТОРИНГОМ, про это не нужно забыать.

Здравствуйте, Аноним, Вы писали:

сорри, это был я ... забыл залогиниться ...

Здравствуйте, stasukas, Вы писали:

S>Примером может служить плохое сочетание программиста-кодера и тестировщика.

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

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

И выходило это — очень хорошо. Во многом — гораздо продуктивнее тестеров.

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

Но ИМХО основная причина всё же в том, что у некого "среднего" программиста квалификация (общекомпьютерная, что ли) выше, чем у некого "среднего" тестера.

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

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

Здравствуйте, trial, Вы писали:

T>Но ИМХО основная причина всё же в том, что у некого "среднего" программиста квалификация (общекомпьютерная, что ли) выше, чем у некого "среднего" тестера.

Но у пользователя, еще меньше.

С уважением, Gleb.

Это ошибочное мнение что тестировщик менее квалифицированный и низкооплачиеваемый нежли программист -- хороший тестировщик, более образован и развит ибо он должен свободно ориентироваться в чужом коде, устанавливать причины, писать тесты и прочее, речь не идёт о простом тыкании кнопок, речь идёт о функциональном тестировании и прочем подобном. Т.к. у вас вероятно оно не проводится, а тестирование сводится к тупой проверке работы с интерфейсом, то и тестировщики у вас соответвующие...
В качестве тестировщика безусловно можно использовать и самих программистов, но не разумно ибо они за частую во время написания кода должны были отладить всё что смогли увидеть, другое дало если они были загнаны как лошади темпом разработки так что не успевали подумать между своими задачами о законченности пройденного... только в этом случае имеет смысл подобное тестирование — дабы дать программистам закончить, то что они не успели сделать из-за того что PM не удачно спланировал проект.
В любом случае опытом многих и своим доказано что тестирование собственно созданной функциональности мало эффективно. Более эффективно даже обменяться двум программистам функционалом для тестирования.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, trial, Вы писали:

T>>Но ИМХО основная причина всё же в том, что у некого "среднего" программиста квалификация (общекомпьютерная, что ли) выше, чем у некого "среднего" тестера.

GZ>Но у пользователя, еще меньше.

Связи не понял

Здравствуйте, nixite, Вы писали:

N>Это ошибочное мнение что тестировщик менее квалифицированный и низкооплачиеваемый нежли программист -- хороший тестировщик, более образован и развит ибо он должен свободно ориентироваться в чужом коде, устанавливать причины, писать тесты и прочее, речь не идёт о простом тыкании кнопок, речь идёт о функциональном тестировании и прочем подобном.

А такое бывает??? Это не подколка, ни в коем случае!! Мне в самом деле интерестно. Просто за 6 лет вращения в IT я такого не встречал, к сожалению. Всё что я видел — это тестеров-бывших(будущих) администраторов и тестеров-неудавшихся(будущих) программистов. Или просто случайных людей. Говорить о том, что квалификация у них выше — естественно не приходится. И з/п тоже.

N>Т.к. у вас вероятно оно не проводится, а тестирование сводится к тупой проверке работы с интерфейсом, то и тестировщики у вас соответвующие...

Нет, это не так. У нас, преимущественно, серверные проложения — поэтому про интерфейс там особо говорить не приходится — хотя, его конечно тоже проверяют. И тестирование, по большей части сводится к анализу логов по итогам различных действий. И вот тут — программисты оказываются впереди. Я даже больше скажу — когда "в нормально режиме" тестируют тестеры — зачастую логи приходится разбирать всё равно разработчикам — только они, как авторы досконально знающие свой код могут это сделать (по крайней мере быстрее).
И, честно говоря, я не представляю себе тестировщика который будет на голову выше программиста (может свободно ориентироваться в чужом коде и т.д.). Почему же он остаётся тестировщиком при такой крутизне? З/п? Вряд ли. Тестирование, всё таки, достаточно занудное занятие — обычный программер долго не выдержит (ИМХО). Тут, в соседней ветке как раз обсуждают психологию управления программерами.

N>В качестве тестировщика безусловно можно использовать и самих программистов, но не разумно ибо они за частую во время написания кода должны были отладить всё что смогли увидеть, другое дало если они были загнаны как лошади темпом разработки так что не успевали подумать между своими задачами о законченности пройденного... только в этом случае имеет смысл подобное тестирование — дабы дать программистам закончить, то что они не успели сделать из-за того что PM не удачно спланировал проект.

Нет, нет и ещё раз нет. Программа — понятие растяжимое. И если речь едёт о достаточно крупной программе, в которой много модулей, то ни один человек (ИМНО) не в состоянии написать так, что бы всё разаботало на раз-два. А если этой программе ещё и нужно взаимодействовать с чем-то внешним, что работает само по себе (AD, Exchange, MIIS — да мало ли ещё что) — то ИМХО не возможно с первого раза охватить все тест-кейзы. Бывают такие случаи, что даже в голову не приходят. А они бывают

N>В любом случае опытом многих и своим доказано что тестирование собственно созданной функциональности мало эффективно. Более эффективно даже обменяться двум программистам функционалом для тестирования.

Тоже спорно. Видел множество обратных примеров. Если есть вменяемый тест-план — то может оказаться очень даже нормально. Хотя обменяться функциональностью — тоже полезно, конечно же.

И ещё раз повотрюсь: я не за такой подход. Я лишь против его отвергания. Иногда тестирование силами программистов очень эффективно.

Это был я.

Почему то разлогинился.

n>Это ошибочное мнение что тестировщик менее квалифицированный и низкооплачиеваемый нежли программист -- хороший тестировщик, более образован и развит ибо он должен свободно ориентироваться в чужом коде, устанавливать причины, писать тесты и прочее, речь не идёт о простом тыкании кнопок, речь идёт о функциональном тестировании и прочем подобном.

Вас послушать — тестировщик просто Ленин какой-то получается.

n>Т.к. у вас вероятно оно не проводится, а тестирование сводится к тупой проверке работы с интерфейсом, то и тестировщики у вас соответвующие...

Хотелось бы понять, в чём, по вашему мнению, разница между «функциональным тестированием» и «тупой проверкой работы с интерфейсом».

Действительность же такова, что хороших тестировщиков очень мало. В разы — в десятки раз! — меньше, чем хороших программистов. Для «плохих» тестировщиков действует правило «up or out», зачастую используемое в практике консалтинговых компаний: «плохой» тестировщик либо стремится стать программистом, либо будет уволен.

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

Слово «качество» здесь — ключевое. Вот, что вы пишете:

n>В качестве тестировщика безусловно можно использовать и самих программистов, но не разумно ибо они за частую во время написания кода должны были отладить всё что смогли увидеть, другое дало если они были загнаны как лошади темпом разработки так что не успевали подумать между своими задачами о законченности пройденного... только в этом случае имеет смысл подобное тестирование — дабы дать программистам закончить, то что они не успели сделать из-за того что PM не удачно спланировал проект.

Получается, что у программистов есть некие загадочные «свои» задачи, и качество среди этих задач занимает почему-то далеко не лидирующие позиции. Увы, в подавляющем большинстве случаев это именно так: гони на гора строки кода, главное — сроки (успел — премия, не успел — PM виноват). И в первую очередь поэтому неэффективно использование программистов для тестирования продукта.

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

n>В любом случае опытом многих и своим доказано что тестирование собственно созданной функциональности мало эффективно. Более эффективно даже обменяться двум программистам функционалом для тестирования.

Вторая причина неэффективности программиста как тестировщика, на мой взгяд, в том, что программист при тестировании будет стараться «сыграть результат». Это такой театральный термин, означающий, что актёр реагирует на событие ещё до того, как оно воспринято зрителем (потому что актёр знает, что это событие обязательно произойдёт и именно в этот момент, и он заранее готов к нему). Программист знает, что делает его код, поэтому играет best case scenario, и, убедившись в его работоспособности, рапортует о том, что тестирование завершено успешно.

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

Здравствуйте, Аноним, Вы писали:

GZ>>Но у пользователя, еще меньше.

А>Связи не понял
Проясню, вчера не было времени дописать.
1. Возьму пример из жизни. При ошибке коннекта через DCOM, пользователю выводится ошибка: "Произошла системная ошибка в процедуре CoCreateInstanceEx". Для любого программиста, это вполне достаточная и главное понятная информация. Однако приходит тестировщик, и говорит что это является ошибкой. Для него, как для пользователя, данная информация не понятна. Программист возражает: "А если я выведу другую ошибку, то я не пойму что произошло". Безусловно, что в данном случае, тестировщик прав, потому что он оценивает ситуацию со стороны потребителя. Это наиболее явный пример.
2. Тестировщик ничего не знает об архитектуре. На моей практике, ошибку выдавало даже переименование окна в ресурсах. Программист, так как знает, что это не должно выдавать ошибку, даже проверять не станет. Для тестировщика эту информацию всегда нужно проверять.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Проясню, вчера не было времени дописать.
GZ>1. Возьму пример из жизни. При ошибке коннекта через DCOM, пользователю выводится ошибка: "Произошла системная ошибка в процедуре CoCreateInstanceEx". Для любого программиста, это вполне достаточная и главное понятная информация. Однако приходит тестировщик, и говорит что это является ошибкой. Для него, как для пользователя, данная информация не понятна. Программист возражает: "А если я выведу другую ошибку, то я не пойму что произошло". Безусловно, что в данном случае, тестировщик прав, потому что он оценивает ситуацию со стороны потребителя. Это наиболее явный пример.

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

GZ>2. Тестировщик ничего не знает об архитектуре. На моей практике, ошибку выдавало даже переименование окна в ресурсах. Программист, так как знает, что это не должно выдавать ошибку, даже проверять не станет. Для тестировщика эту информацию всегда нужно проверять.

Если есть тест-план — то проверит в лучшем виде.