Добрый день форумчане. Поделитесь опытом. Есть процесс разработки конфигурации/блоков конфигурации. Кто как ведет учет разработки: что нужно, что сделано, какие косяки, тестирование, какие вопросы остались нерешенными и т.д. Вариант ведения "на листочке" немного достал.

FreeMind

(0) интелектуальные карты знаю, но не уверен, что это хороший способ отражения, так как не на все вопросы отвечает, да и плюс не сильно отличается от варианта "на листочке".

(0) Стена из поликарбоната + фломастеры. В лучших традициях Scrum и иже с ними.

Excel

процедура РазработатьПрограммуУчетаРазработки()
    Если Не ЕстьПрограммаУчетаРазработки ТОгда
        РазработатьПрограммуУчетаРазработки();
    КонецЕсли;
КонецПроцедуры

(3) то есть лучше "листочка" ничего не придумали?

(5) ходят такие грешные мысли...

Microsoft Project мож

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

(0)содержание этой описательной системы по трудозатратам больше чем содержание самой разрабатываемой системы на 1с

(10) по большому счету может быть. но постепенно, когда перелапачиваешь кучу "листиков" возникает желание в этой системе...

Напиши свою конфу на 1с по учету разработки

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

если не своя конфа, то может у кого есть набор каких-то практик, правил? способов учета? хоть-какого-то софта? (вариант Project уже учтен)

СППР же.
http://v8.1c.ru/model/?printversion=1

(13) целое стадо тестеров на инфостарте сидят, только закинь )

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

(16) спасибо за идею

(17) может и есть, но никто пока такой не знает...

(15) спасибо. а можно это чудо где-то накопать?

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

(20) 6 тыщ всего.
http://www.1c.ru/news/info.jsp?id=16931

(21) поискал на users - не нашел.

(23) там же есть веб доступ к демо базе.

(23) на юзерсах точно есть.

(25) понял - буду искать. спасибо.

jira, redmine, mantis выбирай любой.
У тебя все равно связи задачи с исходым кодом нет.

(25) прошу прощения - есть - просто были скрыты недоступные конфигурации

(6) Если вы так расцениваете, то да, не придумали. redmine тоже наличествует, но быстрее всего поднять глаза на стену. Вдобавок ни один из топов не будет смотреть в редмайн(как показала практика), а вот на стену они смотрят волей неволей, если забредают в наш уголок.

v8: v8: методология Agile

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

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

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

(0) Своя системы учета задач. Ведется дерево объектов конфигурации, к каждой задаче привязывается объект (например, к задача по разработке отчета привязывается отчет), в итоге видно, какие задачи были по какому объекту, историю изменений и т.д. Начиналось все с простейшей конфы на основе БСП + 2 справочника + 1 перечисление, сейчас достаточно мощная система учета задач.

(34) и у вас это сейчас работает? на сколько довольны? метаданные цепляете?

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

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

(37) Структура БД для сложного механизма это схема на листике A4, а если есть время, нарисованная в visio или в спец ПО в особо запущенном случае. И чаще всего, уже устаревшая.

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

(35) Напрямую связи между разрабатываемой конфой и справочником объектов нет, заводим руками по мере необходимости, например, надо доработать справочник "Контрагенты", если его в базе еще нет - заводится руками за 30 секунд.

(39) это уже вопрос организованности

(40) но стараетесь описывать все используемые элементы конфигурации?

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

(43) а какой-то наряд на обновление конфигурации? или стоп-лист обновлений на элементы, так как они там не доработаны?

(44) Нет стоп-листов, если кому-то необходимо доработать объект, его захватывают в хранилище. По мере выполнения задач РП получает уведомления об этом и принимает решение, можно ли обновлять конфу или нет.

(45) спасибо. а система сильно отличается от упомянутого СППР?

+(45) Но с этим проблем нет, так как доработка нескольких объектов в рамках одной задачи в нашей учетке ведется в подчинении одному элементу справочника "Задачи", то есть ставится глобальная задача и декомпозируется до мелких, в разрезе одного объекта метаданных. РП отслеживает выполнение только задачи верхнего уровня, а перевести ее в статус "Выполнена" нельзя, пока нет такого статуса у всех подчиненных задач. В этот же момет, когда меняется статус задачи, кодер отпускает объекты в хранилище. Таким образом, когда РП получает уведомление о выполненной задаче, делается тестирование и если все ок, то конфа обновляется из хранилища.

(46) Не могу сказать, я не видел СППР.

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

(49) Конечно, к задаче добавляются подчиненные задачки типа "Если не указана дата отчета, то возникает ошибка блаблабла" и т.д., задача из статуса "Выполнена" снова переводится в статус "Принята к исполнению" и так по кругу, пока все не заработает.

(50) спасибо большое за удовлетворение моего любопытства.

(51) Обращайтесь

(52) а логику решения вы как-то храните или нет?