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

[LeshaL]

Представьте ситуацию, что у вас задача организовать процесс разработки. И у вас есть карт-бланш для организации такого процесса (или как вариант только процесса тестирования) с нуля.
Т.е. вы можете организовать все - документооборот, дефект-трэкинг, набор policies и rules ну и так далее.
Какие бы вы выбрали инструменты для этого? Интересуют как коммерческий так и бесплатный варианты. Мощность не имеет значения - хоть для 10 человек, хоть для 10 тыс. людей - кому что нравится.
Начну для затравки
1. Система контроля версий
- subversion (svn).
2. Task tracker (так же можно использовать, как help\service desk или AI tracker)
- request tracker (rt).
3. Defect-tracker
- Bugzilla
....

PS: Комплексные решения - тоже интересны, конечно же.
PРS: Инструменты автоматизированного тестирования - не интересны, т.к. это другая тема.
РPРS: Обсуждения достоинств и недостатков того или иного тула - тож не интересны. Только названия, область применения ну и ссылка не помешает :)
Заранее спасибо.

[saezar]

Ну что ж... Именно так дела обстояли у меня примерно год назад.
1. Система контроля версий, конечно же SVN. У меня то всё плохо в этом плане. До сих пор стоит CVS, пользуются им люди нерегулярно, обязательный характер его использование не носит. До сих пор так и не внедрили серьёзный учёт версий. У меня - некому заниматься, у программистов - никакого желания. Как не было релиз-инженера, так и нет. Обещают в начале апреля принять одного сотрудника, которого я и планирую в этом качестве использовать.
Вообще, с нумерацией версий возникает парадоксальная ситуация. Никто, ни один человек, включая разработчика не может точно сказать, что значат эти четыре странные цифры в номере программы. Я решение конечно выработал, но пока о нём умолчу.

2. и сразу 3. Я долго метался по JIRAм, TestLinkам, QTrackам, и прочим бесплатным радостям. Пробовал поставить MQC. В последенем случае просто не срослось, в том числе и изза overprice (эта печальная история похоронена тут на форуме). И в конце концов, я остановился на платной системе - SpiraTest. Оно собирает в себе полный цикл разработки - RT, TT, BT и плюс в зачаточном состоянии Versioning. Мы её купили, поставили, работаем. Не без недостатков, разумеется, но саппорт у америкосов организован на высшем уровне.

3. Документооборот. Это П%#$#%ц с большой буквы. Его просто нет. Уже год мы не можем выбить из начальства согласие на внедрение. Если у кого то есть на примете "бесплатная" система....

4. Управление. Project само собой. Правда есть и своя доморощенная система, но сделана она мягко скажем... никак и пользуются ей только потому, что на неё ориентируется начальство. Реального контроля за ситуацией она не даёт.

[greesha]

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

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

Коротко о том, что используется у нас.

Система контроля версий - MS Visual Source Safe (так сложилось исторически). Для маленькой команды вполне достаточно. Существует жёсткое правило: передача исходников от одного человека к другому - только через VSS. Нужно протестировать релиз - тестировщик не имеет права брать скомпилированный файл у программиста (у которого, как известно, всегда "всё работает"), а должен запустить специальную процедуру сборки (простой .bat-файл), которая достанет и соберёт нужную версию из VSS.

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


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


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

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


А вот сбор статистики затрат по проектам - удобная вещь. Но требует дисциплины, естественно. Сейчас это делается так: каждое утро мы проводим "пятиминутку" по примеру daily SCRUM meeting, во время которой я опрашиваю каждого и учитываю время, потраченное днём раньше на каждый проект. При этот структура базы примитивнейшая - одна-единственная таблица, из которой с помощью элементарных view можно извлечь готовое распределение времени по проектам, клиентам, приложениям, видам работ и исполнителям.

[maximkr]

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

По этому поводу есть сейчас 2 противоположных мнения:

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

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

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

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

Naumen несколько лет назад пыталась сделать продукт для автоматизации процессов на основе нескольких open source проектов, потом проект закрыли, вот выводы одного из разработчиков:
===
1. Причины остановки проекта
Прекращение внешнего финансирования только одна из причин. В конце концов проект могли развивать и "для себя"...
Дело в том, что "подспудной идеей" проекта была мысль: "Давайте возьмем все лучшие фриварные средства управления проектами и поинтегрируем в одну систему... должно получиться круто."
С большим или меньшим гемороем, задача была решена. Но! Выяснилось, что все эти "лучшие средства" имеют очень четко выраженные _иделогии_ и методологии (если хотите — свой собственный "миф" о том что такое есть "разработка софта"). И разумеется, эти "мифы" — разные.
Таким образом, сумма хороших инструментов... не оказалась удобным инструментом (ибо не понятно, по какой методике вести в ней разработку).
===

[greesha]

Кстати, сообщество аналитиков совместно с Agile Russia в прошлом году проводило семинар на тему "Альтернативные системы поддержки процесса разработки ПО". Ссылка на материалы семинара здесь:

http://www.uml2.ru/i...o...9&Itemid=56

[Oldman]

Кстати, сообщество аналитиков совместно с Agile Russia в прошлом году проводило семинар на тему "Альтернативные системы поддержки процесса разработки ПО". Ссылка на материалы семинара здесь:

http://www.uml2.ru/i...o...9&Itemid=56

Был там
1. Интеграция Open Source-систем для управления разработкой ПО. - неплох (из серии как сделано у нас)
2. Альтернативные средства управления требованиями. - нууу (я лучше промолчу)
3. Luxoft LUXProject: Поддержка вашей распределенной разработке ПО. - много рекламы и обещаний как все будет

[belonesox]

Кстати, сообщество аналитиков совместно с Agile Russia в прошлом году проводило семинар на тему "Альтернативные системы поддержки процесса разработки ПО". Ссылка на материалы семинара здесь:

http://www.uml2.ru/i...o...9&Itemid=56

Был там
1. Интеграция Open Source-систем для управления разработкой ПО. - неплох (из серии как сделано у нас)

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

[Lloret]

Использую open-source решения:

1. Контроль версий - svn. Удобство, понятный интерфейс, распостраненность
2. Tasktracker - NetOffice. Web-based система контроля производственного процесса, удобна, бесплатна
3. Bagtracker - Mantis. Ничем не хуже и не лучше других багтракеров.