Обсуждение

Эээ, непонятно зачем запускть perforce поверх confluence/wiki, ибо вики хранит ревизии всех версий документа и поверх этого в документах можно вставлять доп. таги хоть version.major.minor.build

1. Я не говорю о запуске Perforce поверх confluence. Ибо perforce работает с файлами, а не с документами. А в confluence странички-документы, а не файлы. Поэтому ничего из систем версионирования "поверх" запустить нельзя. 2. Вики хранит версии отдельных страниц. Системы управления версионированием отслеживают не столько версии каждого отдельного текста, сколько обеспечивают связь между изменениями отдельных документов (билды). В вики нет вообще понятия "билда" (совокупности страничек с согласованными изменениями), нет "бранчей" и т.д.

Мой ответ был на цитату: "Можно ли запустить Perforce прямо над страничками Confluence -- вот в чем вопрос!". С issue tracking/wiki/versioning systems/rm (о последнем в самом низу) работаю много лет и описанная проблема знакома. Сперва немного разверну тему и прокомментирую ваш ответ. Выбор JIRA от Atlassian разумен, ибо является стандартом де-факто. Существует ещё и FogBugz от FogCreek, который позиционируется "более agile", однако не предоставляет native sidekick solution аля wiki и к нему нет такой тонны extensions. Поскольку _реальной_ нативной интеграции между JIRA и Confluence НЕТ -- одни шалости, вроде возможности отображения issue listа по фильтру на странице -- причём это не попадает под versioning, так как является тагом. Итак, поскольку реального benefit использовать confluence вместе с JIRA нет, то со спокойной душой можно ставить любой другой wiki. Если очень хочется, сторонний versioning system можно запустить поверх wiki, работающего на файловой системе - такие имеются, но описаная проблема ведь глубже. Для Wiki я в первом своём комментарии предложил ставить versioning tag внутри групп документов, когда хочется сделать "build" группы документов с определённым тагом. После этого можно делать поиск групп документов внутри архива по версии и это работает... только вот приучить к вики+тагам сотню людей невозможно. Итак, смысла городить такую чепуху нет, потому что проблема ваша называется... (барабанная дробь) Проблема менеджмента требований. http://www.jiludwig.com/Requirements_Management_Tools.html То, что вы называете "Симултрек" зовётся RM. Если я не правильно вас понял, было бы интересно почитать мысли по этому поводу.

1. Нет, симултрек у меня -- набор информационных моделей деятельности организации, а не "требования". В симултрек входят прикладные модели (зависящие от предметной области деятельности -- модель картошки в поле, самолета в небе и т.д.) и организационные модели (структура, процессы, финансы, люди и т.д.). В подтверждение того факта, что я знаю о существовании управления требованиями (даже не по отношению к софтверным проектам), я приведу свой старый пост по управлению реформами -- там оно прописано явно: http://ailev.livejournal.com/398953.html 2. Поэтому требования (на входе), работы (в процессе) а также конфигурации (на выходе) вместе с их "управлениями" являются составными частями для симултрека. И это в том случае, когда на выходе -- именно "конфигурации" (продукты), а не сервисы! Скажем, JIRA вполне может управлять issues в сервисных организациях (где issues могут пониматься как запросы на сервис, например). 3. Нет такого продукта, который хорошо бы делал управление требованиями, работами и конфигурациями (сейчас это три разных класса продуктов). 4. предполагаю, что управление требованиями и конфигурациями можно было бы сделать вокруг управления работами (в варианте JIRA, когда работы возникают вокруг issues -- в отличие от классического управления проектами, где работы возникают псевдостатически в виде WBS) и моя гипотеза была в том, что как управление требованиями, так и часть самой конфигурации (а именно -- файлы документов) можно было бы реализовать на wiki. 4. Понятно, что в мире хватает разных попыток объединить неообъединяемое, или приспособить неприспосабливаемое. Вот, например, http://www.codeproject.com/aspnet/OpenCollective.asp Мне бы хотелось предпринять какое-то более системное усилие, не на уровне "просто кодирования". Меня заботит методологическая сторона вопроса. 5. И важно еще отметить, что у меня в голове прежде всего несофтверные проекты, ибо для чисто софтверных проектов существуют и разные другие решения (основанные на том, что результат работ -- это набор файлов программ и тестов). 6. А чтобы еще запутать дело, сообщу, что в голове у меня даже не столько проекты, сколько программы -- совокупности проектов, выполняющиеся одновременно на одном и том же множестве ресурсов.

ИМХО не стоит воротить всё это дело вокруг десятка разных чужих тулз, а стоит построить чёткие спеки того, как выглядит "свой" моделе-документо-работо-итп-оборот и пойти к большим дядькам (SAP-оподобные) на поклон для построения custom системы, ибо универсальную создать всё равно нельзя.

А вот с SAP и подобными -- там принципиальная разница. Они же воплощают best practices, а не дают инструментарий. Причем делают это совершенно неоправданно задорого. А у меня свой набор best practices, и нет никакого желания идти куда-то на поклон за большие деньги. Я уверен, что в конце не будет десятка "чужих тулз". Мне кажется, что все может быть много проще -- и я намерен поработать в этом направлении.

Выбор JIRA от Atlassian разумен, ибо является стандартом де-факто. Существует ещё и FogBugz от FogCreek, который позиционируется "более agile", однако не предоставляет native sidekick solution аля wiki и к нему нет такой тонны extensions. Поскольку _реальной_ нативной интеграции между JIRA и Confluence НЕТ -- одни шалости, вроде возможности отображения issue listа по фильтру на странице -- причём это не попадает под versioning, так как является тагом. Итак, поскольку реального benefit использовать confluence вместе с JIRA нет, то со спокойной душой можно ставить любой другой wiki.

Позволю себе встрять в обсуждение :-) JIRA - оно, конечно, стандарт, но Вы реально пробовали кастомайзить там что-то более сложное, чем багтрекинг в софтовом проекте ? При попытке сделать шаг влево-вправо от опенсорсно-софтового проекта (не хочется клиентам все поля показывать, хочется _совсем_ другие workflow, хочется иерархию задач в несколько уровней) там все начинает трещать по швам и никакими плагинами оно не лечится. А вот это вообще перл, от разработчиков Confluence: http://fishbowl.pastiche.org/2005/09/28/the_wall_of_death Еще момент - а зачем знания хранить отдельно от багов ? И у того, и у другого есть workflow, они кем-то вносятся, кем-то изменяются, кто-то должен получать notification-ы, кто-то должен настраивать права ? Зачем все делать дважды в 2-х системах, а потом заниматься их интегрированием ? Думаю, путем интегрирования вышеописанных продуктов проблему не решить, развалится оно все. Надо либо что-то свое писать, либо смотреть в сторону более гибких систем, типа IBM ClearQuest, TrackStudio Enterprise, Serena TeamTrack.

Очень правильные замечания! Я тоже много над этим думаю: совершенно непонятно, почему "работа над issue" так отличается от "работы над документом" (тем более, что issue может быть как раз по поводу документа!). Тут не обойтись без какой-то подлежащей теории, правильных метафор. У меня была мысль, что JIRA и Confluence много более связаны, чем оказывается. В любом случае, это выглядит как очень простое решение для начала работы (простое -- значит которое имеет шанс прижиться). Писать самому -- это проще повеситься. Легче найти что-то уже работающее и поддерживаемое. На "более гибкие системы" по вашему списку нужно еще смотреть: за универсальность, как известно, можно неожиданно много заплатить сложностью и невнедряемостью. И вам хорошо бы зарегистрироваться в ЖЖ: тогда ответы на ваши комменты будут приходить к вам по почте, а мы не будем путать разных других анонимов с вами.

Очень правильные замечания! Я тоже много над этим думаю: совершенно непонятно, почему "работа над issue" так отличается от "работы над документом" (тем более, что issue может быть как раз по поводу документа!). Тут не обойтись без какой-то подлежащей теории, правильных метафор. У меня была мысль, что JIRA и Confluence много более связаны, чем оказывается. В любом случае, это выглядит как очень простое решение для начала работы (простое -- значит которое имеет шанс прижиться).

По поводу простоты - согласен :-) Но я уже встречал комментарии от пользователей, которые хотят jirafluence :-) Мое ИМХО по этому поводу - Atlassian решила делать Confluence отдельным продуктом т.к. сейчас развивать JIRA очень сложно, доделки из most popular issues висят годами и постоянно переносятся. Это был первый продукт компании, который построен на изрядно устаревших на данный момент инструментах (типа OfBiz или Velocity), отказаться от них уже нельзя. Ну а Confluence - это исправление ошибок молодости, он сделан гораздо лучше чем JIRA и куда быстрее развивается. Осталось только убедить пользователей, что им нужно 2 продукта :-)

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

Да, есть такой момент. Мне кажется что прогресс в софтостроении идет в странном направления - из нескольких направлений выживает самое простое, которое потом начинает усложняться до совершенно неразумного уровня. Пара примеров: web-интерфейс стал популярен во-многом как более _простая_ замена Win32 API и всяким там Motif. Но сейчас со всеми этими DHTML, CSS, JavaScript, AJAX, версиями браузеров он стал сложнее в разработке чем desktop UI, причем победить его изначальную кривизну получается с трудом. Другой пример - JIRA. Нынешняя система прав (с группами, project roles-ами, issue level security) переплюнет по сложности и нелогичности почти все системы из моего списка :-), при этом в JIRA до сих пор нет field level security и вообще непонятно как его туда прикручивать будут. Но за счет простоты первых версий она обошла конкурентов, и теперь их эта сложность не очень волнует, многие будут выбирать JIRA просто потому что это стандарт и все так делают. Я для себя такой вывод сделал - если заранее видно что гибкости системы (размеров машины, мощности дрели) не хватает чтоб там реализовать штатными средствами _все_ то, что нужно уже сейчас, даже если этом разовые задачи, то лучше поискать что-то по-возможности более гибкое (большое, мощное). Потому что когда требования начнут расти - менять может быть уже поздно.

И вам хорошо бы зарегистрироваться в ЖЖ: тогда ответы на ваши комменты будут приходить к вам по почте, а мы не будем путать разных других анонимов с вами.

Да, зарегистрируюсь, спасибо. Но это все еще я :-)

Недавно глиффи оценил, но про связку с Вики не думал даже Изображение «Веб2.007» — открыть источник

Не знаю про "потоки работ" (это что?), но в центре должна быть тулза, поддерживающая само понятие task -- и позволяющая делать programming by example из этих элементарных операций (например, по agile-процессу выполнить какую-то цепочку работ, а потом объявить ее бизнес-процессом "задним числом"). Или накидать какую-то группу операций, и грубо оценить их общее время выполнения на заданном множестве ресурсов (это уже проектная метафора). Поэтому про интеграционную платформу мне не так важно, как про модель представления тасков/операций. Мы будем в ближайшее время сами писать прототипы такого софта на Крокете-сквике, мы почти совсем уже созрели. Ищем системного архитектора для этого (у меня был про это пост пару недель назад).

кстати забавно, вот же он "TrackStudio Enterprise" - уже 1.01.2007 упомянут :>

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

Нет, не попадалась. Если нужно общение по-русски, ставьте TrackStudio, они из Смоленска.

Добрый день, Анатолий. Из Вашей статьи я поняла только, что Вы разбираетесь в jira. Очень срочно нужна помощь. Не за спасибо конечно. Если есть возможность напишите мне пожалуйста на почту: illusionvik@mail.ru. С уважением, Ирина.

Вы неправильно поняли. Я не разбираюсь в jira. Я, конечно, знаю, что это такое, но явно не специалист по этому софту.