У вас что ПМа нет процесс наладить?
1. Если обычная, но не быстрая задача.
Девелопер комитит в ветку задачи. Потом мержит в test, по окончании. Мержит только если его задача идёт в текущую версию.

2. Срочная, мелкая, задача.
Девелопер комитит напрямую в test.
Когда QA версии окончен, вся ветка мержится в release.

3. Сверхсрочные комиты в релиз делаются только в исключительных ситуациях с разрешения вышестоящих ответсвтенных.

Это лишь вариант. Задача ПМа адаптировать процесс под нужды проекта. Версионность релизов вообще есть?

ОзверинGKS_Samara,

а сколько разработчиков в отделе? Есть подозрение..что овчинка выделки не стоит.
+1

GKS_Samara> У вас что ПМа нет процесс наладить?
Ну вот я этим занимаюсь.

"повезло" :)

GKS_SamaraСейчас так по сути и есть.
Когда релиз проверен- делается ветка "релиз.1.4" например.

Используйте все версии 1.4.8.231
1 - меняется при полной переделке проекта
4 - major version - меняется с каждым релизом
8 - minor version - либо каждый минорный релиз, но я считаю что это не совсем верно. Лучше использовать как QA релиз. Когда девелоперы отдают тестерам.
231 - build number - проще всего подвязать туда SVN revision. из QA ветки или транка.

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

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

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

Это тестера не касается вообще. Тестеру задача сообщить об ошибке. Девелоперы и ПМ должны быть подписаны на багтрек. В идеале девелоперы сами забирают задачи на себя. Но ПМ, так как владеет более общей информацией можен назначать задачи на конкретных девелоперов по обстоятельствам. Это всё QA вообще интересовать не должно. Девелоперов всех уволят, найдут новых. Кому будет тестер тогда адресовать баги? :)

GKS_SamaraМенеджер тестирования хочет сузить область поиска ответственного за
ошибку. Чтобы было всего два варианта "ошибка была всегда" и "ошибка
сделана А".

Что это даст? Тыкать пальцами и говорить "петя - лох, сломал проект"? Смысла в этом нет. Девелоперы сами должны обращать внимание на ошибки в трекере, а у ошибки должен быть адекватный приоритет.

GKS_SamaraТ.е. чтобы была ветка "стабильный код" и каждое задание было
отдельным ответвлением от неё.

Каждое задание должно быть ответвлением от транка, это позволит выявлять конфликты задач на более раннем этапе. ИМХО.

GKS_SamaraНо мне тогда придётся построить работу "ветка на любую задачу, кроме
орфографии", что нежелательно.

Надо смотреть на проект, команду, размеры проектов. Когда в команде 3-5 человек, то нет вообще никакой проблемы всё комитить в транк. Важно только правильно организовать процесс QA и релиза. А бранчевать только очень крупные задачи.
Это и есть Agile - подстраивать процесс под особенности проекта. Ты же, по-моему, пытаешься получить идеальны бюрократический процесс даже там где он не всегда нужен.

GKS_SamaraВот об этом и речь. Я отвечаю за процесс разработки, но есть внешние
силы, желающие его менять.

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

GKS_SamaraВ нашей группе 5.
В соседней (часть кода общая)- 4.

Ну может и не стоит.


Такие проблемы стоит решать по мере поступления. Т.е. заказчик просит улучшения в процессе и говорит какие именно. Ты ему говоришь - "обождите". Узнашь что именно его волнует. И решаешь именно проеблему, которая его волнует. Не нужно просто следовать тому что он требует, нужно решать его проблемы.

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

Стоит рассказать тестеру про smoke testing, regression testing и планировние QA под проект в целом. Опять же. Узнай что именно волнует тестера и реши его проблему, а не давай ему рулить процессом.

Alexey TominЭто хорошо, но муторно. Создать ветку. svn checkout всего кода. создать новый workspace в eclipse (переключать существующий неудобно, т.к. ветка может существовать долго и бегать туда-сюда проще перевыбирая workspace). Делать это для задания на 2-4 часа не хочется.

Какие-то ты ужасы рассказываешь. Какой нафиг проект\воркспейс? Какой нафиг check out? SVN switch в нужный бранч затягивает только разницу между бранчами. Всё.

Alexey TominНе я. Менеджер тестирования. Но ему по должности положено хотеть идеала :)

То же самое. Менеджер тестирования может хотеть чего угодно. Это его право. Но ты узнай что его волнует и реши его проблему. Не стоит курочить весь процесс только потому что кому-то так хочется. Или он про это в книжке прочитал. Пусть лучше составит план тестирования, в котором будут все фазы тестирования, а не только отдельные фичи.

GKS_Samara> Я выразился неправильно,
> условно разделены по:
> Разработчики GUI, Разработчики БД и тд.

Ближе к этому, хотя это деление по модулям.

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

ОзверинЭто пока в команде 5-10 человек, как только в команде их 30, и богатый собственный слой(gui,бд-интеграция, оптимизация и тд), то все всё знают - это трудно достижимо.
Вполне достижимо, но с оговорками.
Понятно, что когда присутствуют сложные бизнес требования в большом объеме, все их знать не могут.
Понятно что middle и junior к некоторым техническим решениям просто не готовы и их стоит удерживать от решения таких задач.
Но senior девелоперы могут решеть задачи на любом уровне, и вот их, как раз, стоит привлекать на разные задачи по всему проекту.