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

А>Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?

Не проще. Вряд ли у тебя есть толковые программисты которые умеют писать быстрые прототипы, скорее всего у тебя обычные кодеры широкого профиля. Значит на разработку даже простейшей системы уйдет 1-2 месяца. Поскольку ты сам не очень представляешь чего хочешь, первая версия не будет работать как должно. В результате закладывай еще 2-3 месяца на вторую версию. Еще несколько месяцев займет внедрение, в результате эффект будет в лучшем случае только через год. Опыт яндекса, джетбрейнс и других контор которые писали свой тасктрекер говорит что год это крайне оптимистичная цифра. Так что можешь писать, дело твое, но я бы рекомендовал изучить дефолтный процесс джиры и работать в точности по нему. В конце концов, его не самые глупые люди делали.

Кстати, посмотри Trello. Приоритезация перетаскиванием там есть.

On 21.08.2014 14:15, alex_public wrote:
> From: *alex_public* </Users/98162.aspx>

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

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

Если вы экстремал и проводите основное время в разъездах и походах в
местах, где нет связи — это конечно да, преимущество. Но если всё это
затеяно ради того, чтобы раз в год, когда вам, летя в самолёте, придёт
охота сделать код ревью, не надо было записывать выводы в файлике — то
это по-моему overkill.

Основное на мой взгляд преимущество DVCS — лёгкость работы с бранчами,
за счёт того что всё хранилище доступно локально. Всё остальное —
агитация и пропаганда )

--
WBR,
Serge.

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

А>Эта кнопка для удобства разработчиков, а не для усиления контроля. Если разработчик разгильдяй или бездельник, с этим ничего не сделаешь, кроме увольнения.

Мои наблюдения показали, что, как правило, разработчики обновляют статус задачи раз в день (если эта задача на несколько дней), а статус бага — после сабмита фикса. Делается это не из-за разгильдяйства, а потому что так тратится меньше времени на выполнение всех формальностей. Поэтому автоматический подсчёт потраченного времени по времени изменения статуса задачи будет во многих случаях бесполезным.

А>Учитывается не только время, но и ведется лог разработки, в котором разработчик указывает, что именно он делал.

Лог по изменению статуса тикета ведётся практически любым трекером. Не вижу тут преимущества самописной системы. У того же редмайна, например, есть ещё и интеграция с svn, которая обеспечивает привязку ревизии к задаче/багу.

А>Это помогает держать контроль над ситуацией. Чтобы предсказать куда мы движемся, нужно иметь данные о том, как мы двигались в последние моменты. Чтобы экстраполировать, нужна статистика. Контроль над выполнением задач не дает разработчику "погрузиться в себя" и не сбиться с пути. Не говоря уже о статистике для последующего анализа в случае проблем.

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

Если разработчик работает над задачей, то он:

1. Разбивает её над подзадачи (если задача крупная).
2. Оценивает каждую из подзадач.
3. Начинает выполнять по очереди (в редких случаях — параллельно).
4. В конце каждого дня отмечает прогресс — сколько времени ещё осталось до завершения задачи.

Каждый день менеджер проверяет, насколько изменилось время, отведённое для выполнение задачи. Если время изменилось меньше чем на 6 часов, то это повод для вопросов. Возможно, задача попалась трудная, всплыли неизвестные трудности или же разработчик увлёкся изобретением велосипедов.

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

В общем, процессы настраиваются как-то так. И нет никакой необходимости в специальном самописном трекере.

S>>ТС говорит не про сортировку, а про выставление приоритетов. А эту операцию действительно лучше выполнять тасуя мышкой карточки, потому что приоритет конкретной задачи зависит не только от нее, а еще и от других задач.
S>А, тогда нужно что-то типа http://trac-hacks.org/wiki/QueuesPlugin

Или structure для Jira. До 10-и пользователей копейки стоит.

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

КЛ>Выглядит разумно. Судя по тому, что Вы описали, надстройка легковесная, т.е. не требует значительного кодинга.

Кстати, забыл рассказать про ещё один вариант (мы его пробовали перед написанием своего). Я когда сказал, что на рынке есть только маргинальные решения такого рода, просто как-то забыл про него. Т.е. когда мы стали искать готовый вариант под наши требования, то всё же нашли одно решение профессионального уровня (и кстати написанное отлично — автором sqlite). Это Fossil (кстати, сам сайт продукта — это просто веб-интерфейс системки) — в точности то, что мы хотели и даже чуть больше (там ещё и wiki есть, соответственно тоже распределённая). Мы были в восторге (от описания ), когда нашли его и сразу пустили в дело. Но к сожалению как-то не пошло... Причём из-за мелочей, но их было слишком много в сумме. И сам контроль версий был менее вылизан, чем Mercurial. И конфигурация управлением задачами не позволяла сделать в точности как нам удобно. И собственно сам интерфейс не очень (мало того что web, так ещё и не лучший его вариант). И варианты серверов/транспорта победнее (в сравнение с Mercurial). В общем нам полностью понравилась идея, но не понравилась реализация, так что решили сделать свой вариант. И он получился явно удобнее, за счёт использования уже вылизанных инструментов. Кстати, распределённая вики у нас тоже есть — просто редактор Zim, файлы которого опять же лежат под Mercurial. )

КЛ>Мы от диаграмм Ганта отказались. Вернее так, если менеджеру нужно, то он может ими пользоваться. Но они не являются официальным инструментом.

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

КЛ>1. Проблемы с объединением кода. Фактически коллеги установили гит, но используют его, как свн, потому что, с одной стороны, им не нужна распределённость, а, с другой стороны, если сразу не коммитить свои изменения в основной репозиторий, то потом много проблем будет с объединением. К тому же, у них проект на юнити, много бинарных файлов, которые вроде бы не меняются, но помечаются, как изменённые (возможно, потому что среда разработки вносит какие-то несущественные изменения). В общем, если коротко, то много бинарников, которые потом трудно объединить.
КЛ>2. Есть сомнения, что гит работает хорошо с большими объёмами бинарных данных. Во всяком случае, свн работает с ними плохо. Поэтому наша команда использует перфорс.

Ну по сути это одна проблема, связанная с бинарными данными. Но я не вижу разницы в работе с ними у vcs и dvcs — в обоих случаях возможностей меньше, чем с текстом. Другое дело, что в конкретной системе могут быть реализованы какие-то мелкие подстройки, улучшающие общую негативную ситуацию с бинарными данными. Типа тех, что есть (по слухам — сам не пробовал) в Perforce или например такого http://mercurial.selenic.com/wiki/LargefilesExtension в Mercurial.

КЛ>3. Секьюрность. В перфорсе можно ограничивать доступ отдельным людям к отдельным веткам репозитория. В свн это вроде сделать нельзя. А как в гите, dcvs?

Ну вообще такие специфические вещи обычно делаются уже через всякие расширения... Я сам не пользовался, но сейчас глянул к примеру для Mercurial есть такое: http://mercurial.selenic.com/wiki/AclExtension

КЛ>4. Постоянно нужна обновлённая версия. Мы все работаем над одним продуктом, в который за цикл разработки нужно добавить несколько сотен фич. Важно, чтобы эти фичи не поломали друг друга и работали бы друг с другом хорошо.

А в чём тут проблема у dcvs?

КЛ>Да, но ведь нужна какая-то ветка, в которой лежит эталонная версия продукта. Которую смотрят тестеры и продюсеры. Конечно, можно тестировать версию, которая находится в локальном репозитории отдельного программиста или тестера, но если она не будет синхронизирована с эталонной версией, то нельзя сказать, реализована конкретная фича или нет. Точно так же — нельзя оценить её качество. Нам нет особой пользы от возможности заводить локальные репозитории. Нам важно, чтобы реализованная программистами фича, попала бы в основной репозиторий и была бы там проверена продюсерами и тестерами.

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

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

_>>Я безусловно поясню зачем она нужна и даже на примерах. Но в начале вы ответьте на один вопрос, что бы я мог понять, как правильнее пояснить: работали ли вы когда-нибудь с mercurial или git в качестве основной системы контроля версий для вашего проекта?
КЛ>Нет.

Вот я именно так и подумал. И вот почему — если заменить в ваших словах "задачи" на "файлы", то получатся почти в точности аргументы сторонников старых централизованных cvs. Причём они имеются только у тех, кто не пробовал на практики dcvs. А понимание того, что в dcvs используется совершенно другая модель, в которой нет подобных проблем, приходит только после того, как реально распробуют систему на практике.

Что касается преимуществ распределённой системы управления задачами. Наиболее чётким ответом на это является такой: при использование централизованной системы управления задачами совместно с распределённой системой контроля версий, становится невозможно полноценно использовать все преимущества последних. А преимуществ у dcvs над старыми cvs множество — отсылаю к бесконечным статьям на эту тему.

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

P.S. Кстати, dcvs могут работать как в схеме без центрального репозитория (вообще не требуются никакие серверы), так и в схеме с центральным репозиторием (тогда требуется наличие некого корпоративного сервера, на котором он будет находиться). И в обоих случаях сохраняются все преимущества dcvs, т.к. дело не в отсутствие главного сервера, а в модели работы с данными.

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

А>Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?
Если можешь одной фразой объяснить, чем твой трекер будет лучше существующих, то это повод всерьез задуматься над новом трекером.
Если сможешь продать идею здесь, на рсдн-е, то можешь начинать писать. Риск, конечно, большой, но результат может превзойти ожидания.

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

А>Эта кнопка для удобства разработчиков, а не для усиления контроля. Если разработчик разгильдяй или бездельник, с этим ничего не сделаешь, кроме увольнения.
С точки зрения разработчика эта кнопка — просто лишняя формальность, которую нужно не забыть выполнить, даже если переключаешься на полчаса на мелкий тикет. Автоматизировать проверку "забыл переключить" нельзя — получаем ещё одну вещь, которую нужно постоянно держать в голове вместо чего-либо более полезного.

А>Учитывается не только время, но и ведется лог разработки, в котором разработчик указывает, что именно он делал.
А вот это вообще садизм. У вас уже есть управление тикетами + контроль версий, т.е. эту информацию можно восстановить. Ну ок, предположим, вы обязали сотрудников составлять детальные отчёты — что вы будете с ними делать? Если вы попытаетесь следить за всем на таком уровне — потонете в деталях. Если агрегировать — зачем собирать сами мелкие детали?

Если сильно хочется — введите практику "в конце каждой недели каждый член команды пишет отчёт в 2-3 пункта", в отчёте — самые важные (для автора отчёта) задачи/проблемы. И вам не надо копаться в мелочах, и разработчику полезно — нарабатывается материал для примерной оценки сроков.

А>Это помогает держать контроль над ситуацией. Чтобы предсказать куда мы движемся, нужно иметь данные о том, как мы двигались в последние моменты. Чтобы экстраполировать, нужна статистика.
Статистику за слишком мелкие промежутки собирать не так просто. Помимо лишней работы для всей команды накапливается погрешность по каждой из задач и разброс из-за неравномерной загрузки в течении недели. Если сразу брать оценку за неделю — эта погрешность сглаживается сама собой и нет нужды копаться в микроменеджменте.

А>Контроль над выполнением задач не дает разработчику "погрузиться в себя" и не сбиться с пути. Не говоря уже о статистике для последующего анализа в случае проблем.
Неа. На практике важны не конкретные отрезки времени, а их статистически достоверные отклонения. Даже банальное коммитов/день (тикетов/день) при накопленной статистике уже даст достаточно информации для обнаружения проблемных задач. Ну а в их решении статистика уже не поможет, тут надо на конкретику смотреть.

Что до самоконтроля (если разработчика это вообще интересует) — достаточно статистики по тикетам + статистики с билд-сервера.

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

КЛ>>Не понимаю, зачем для управления проектом нужна распределённая система управления задачами. Чтобы удалённая команда работала бы над своими задачами в рамках проекта, и вы бы об этих задачах не знали или узнавали бы с опозданием?

_>Я безусловно поясню зачем она нужна и даже на примерах. Но в начале вы ответьте на один вопрос, что бы я мог понять, как правильнее пояснить: работали ли вы когда-нибудь с mercurial или git в качестве основной системы контроля версий для вашего проекта?

Встряну: я работал, и мне тоже интересен заданный Кириллом вопрос.

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

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

Я же говорю, примеры из реальности. ) Причём если в самолёте я чаще всего провожу часа 4 (что как бы не критично для выпадения из дел) и не особо часто, то на даче у подруги могу быть и более суток...

H>Если вы экстремал и проводите основное время в разъездах и походах в
H>местах, где нет связи — это конечно да, преимущество. Но если всё это
H>затеяно ради того, чтобы раз в год, когда вам, летя в самолёте, придёт
H>охота сделать код ревью, не надо было записывать выводы в файлике — то
H>это по-моему overkill.

Возможность работы оффлайн — это не единственное преимущество распределённых систем. Просто наиболее удобное для демонстрации принципов.

H>Основное на мой взгляд преимущество DVCS — лёгкость работы с бранчами,
H>за счёт того что всё хранилище доступно локально. Всё остальное —
H>агитация и пропаганда )

Это просто ещё одно следствие из используемой модели работы с данными. Из модели локальных коммитов следует сразу всё. И возможность оффлайновой работы и продвинутая работа с ветками и функции правки локальных ревизий и например возможность работы без центрального сервера вообще (вполне удобно в команде из двух человек) и т.п.

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

КЛ>Я не высказывал никаких аргументов как "за", так и "против" — просто спросил, т.к. вопрос мне кажется интересным. Видите ли, у меня сложилось такое мнение, что на текущий момент достаточно инструментов для управления проектами. Например, мне хватало outlook'а, redmine'а и excel'я. Вот и было интересно узнать, для чего пришлось создавать собственный таск трекер.

Мы как раз использовали Redmine до написания своей системы.

Вообще если делать всё "по честному" и разрабатывать полноценную систему, то наверное игра не стоит свеч — проще смириться с некоторыми минусами централизованных. Но мы сделали некий хитрый ход — использовали в качестве основы системы управления задачами нашу же dcvs (у нас это Mercurial). Таким образом мы сразу получили "на халяву" весь низкий уровень (база данных, транспорт, авторизации, разруливание конфликтов и т.п.), причём очень продвинутый и вылизанный. Осталось только продумать правильный формат данных для задач (чтобы гарантированно никогда не было слияний) и собственно написать gui к этому формату. С использованием редактора форм и такого эффективного языка как Питон, вся разработка нового трекера завершилась за несколько дней. При таком раскладе результат уже явно стоил потраченных сил.

Кстати, бонусом к такой схеме получился полноценный системный GUI, а не html'ое недоразумение.

Сейчас используем только эту нашу систему (ну и плюс я использую Planner с его диаграммами Ганта для своих прикидок) и полностью довольны.

КЛ>Тем не менее, распределённая система контроля кода/задач вносит свои проблемы. Как раз сегодня обсуждал их со своим коллегой, работающим в другой команде и с другим заказчиком. Но, понятно, обсуждение этих вещей выходит за пределы данной темы.

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

КЛ>Вы ревьюите код коллег после его коммита в основной репозиторий?

Хы, вот как раз с dcvs это всё вообще не вопрос. Подход в виде одного репозитория и ветвлений (автоматических) по каждому чиху реализуется там очень удобно.

КЛ>Вы самостоятельно правите код Ваших коллег? Не лучше ли в ревью написать замечание, а вносить правку будет тот человек, который писал данный код?

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

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

А>Убедите меня, что не стоит этого делать.

А>Я пересмотрел кучу средств управления задачами, и был потрясен, насколько они все далеки от удовлетворения моих элементарных нужд в управлении проектами.

А>При этом вроде бы как трекер задач — это приложение-то примитивное совсем. Сами задачи — это просто тупо одна таблица в базе, причем с записями и делать-то ничего особенно не надо, буквально просто хранить и некоторые запросы делать.

они все так думали...

А>не проще уж написать самостоятельно?

валяй

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

А> Когда он начинает работу (нажимая на какую-нибудь кнопку), автоматически отмечается время начала работы, когда заканчивает — время окончания и затраченное время.

Предположим, разработчик обновил состояние бага/задачи после сабмита, а не тогда, когда начал над ней работать. В результате, автоматически подсчитанное время равно 0. Что из этого воспоследует?

Предположим, разработчик научился обновлять статус задачи вовремя, и время, потраченное на задачу, считается автоматически правильно. Как это помогает Вам лучше управлять проектом? Например, добиваться того, чтобы проект был закончен к определённой дате?

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

А>Я пересмотрел кучу средств управления задачами, и был потрясен, насколько они все далеки от удовлетворения моих элементарных нужд в управлении проектами.

По-моему, в этом мире остро не хватает платформы Универсального Интерфейса к СУБД (сокращенно, УИСУБД). Все, что вы описали, не есть характерная часть системы управления задачами. Это нужно во многих областях.

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

Drag-n-drop записей, привязанный к параметру записи X, пригодился бы в плейлистах. Чем выше положение в плейлисте, тем выше текущий рейтинг. Если речь идет о drag-n-drop в группы (то есть, параметр X не количественный, а задан множеством типа {Высокий; Средний; Низкий} и каждый член ассоциирован с группой, при перетаскивании в группу происходит установка значения параметра X), то это вообще часто нужно для тегирования. Хотя бы жанры песням задать. Или контакты раскидать по {Работа; Родственники; Друзья}. Или проставить теги записям в блоге, только тут обратный инструмент нужен — перетаскивание группы на запись, а не записи на группу.

>Еще чтобы в зависимости от роли пользователя (тестер, разработчик, ПМ) был разный интерфейс. Потому что тестер, репортящий баг, не должен иметь возможность сделать что-то лишнее, например, назначить баг какому-то девелоперу. Или хотелось бы, чтобы разработчик видел вообще только свои задачи. Когда он начинает работу (нажимая на какую-нибудь кнопку), автоматически отмечается время начала работы, когда заканчивает — время окончания и затраченное время.

Ровно то же самое нужно ВЕЗДЕ в бухгалтерии и финансах. Директор, управляющий операторами, хочет видеть все заказы, но чтоб операционист видел только те записи в таблице заказов, которые сам же и создал. Или чтоб операционисту кнопка «Удалить запись» (то есть, в данном случае, «Отменить заказ») была видна только на его заказах. Или чтоб стоимость заказа (одно поле в записи) показывалась только тому оператору, который его создал. Или не оператору, а сейлсмену.

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

А>Все системы, которые я видел, либо совсем примитивны, либо наоборот напоминают конструктор, но при этом и те и другие заточены на какой-то непонятный мне процесс разработки.

А я видел систему, которая реализует УИСУБД. Это MS SharePoint. К сожалению, она не очень У, и в ней нет и половины того, что нужно в И. А кроме того, MS ее с 2007 года развивает в совершенно непонятном направлении. В общем, я бы именно этого продукта избегал, но вообще, это показатель, что такие платформы (а) возможны, (б) удобны, (в) могут быть коммерчески состоятельными.

А>При этом вроде бы как трекер задач — это приложение-то примитивное совсем. Сами задачи — это просто тупо одна таблица в базе, причем с записями и делать-то ничего особенно не надо, буквально просто хранить и некоторые запросы делать.

А юзеров хранить в той же таблице? А проекты? Короче, это типичная реляционная задача, но запросов-то дохерища (а не «некоторые»).

А>Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?

Тут вы лукавите. Если у вас такие типичные задачи, почему вас Jira не устраивает? Значит, задачи нетипичные, то есть, неизбежно брать платформу и настраивать под себя. Но это вовсе не муки, если у вас есть адекватные средства настройки. Например, в SharePoint можно (не разбираясь в SQL, HTML, программировании) из кубиков собрать баг-трекер за день и получить при этом море fun'а. Но он, еще раз, не У и не шибко богат инструментом.

Кроме того, для платформы можно организовать рынок кастомных настроек, получив, как щас говорят «экосистему». Типа, пусть авторы багтрекеров и бухгалтерий, Рабочих Мест операторов такси и РМ риэлторов, соревнуются в дизайне и продуманности операций, а юзер может скачать готовый пакет. Может быть, даже не зная о платформе, но имея все возможности улучшить и немного подточить под себя.

А>Убедите меня, что не стоит этого делать.

По-моему, не стоит делать очередной багтрекер. Фокус — главный бизнес-фокус. Стоит делать такой УИСУБД. Но не вам, а молодым энергичным стартаперам, которые хотят выпустить world-class product и продаться за миллиарды.

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

КЛ>>4. Постоянно нужна обновлённая версия. Мы все работаем над одним продуктом, в который за цикл разработки нужно добавить несколько сотен фич. Важно, чтобы эти фичи не поломали друг друга и работали бы друг с другом хорошо.
_>А в чём тут проблема у dcvs?

Тут, наверное, проблем нет. Тут, скорее, другое — отсутствие необходимости в распределённой системе контроля кода/задач. Просто сама специфика проекта не требует этого.

_>Когда я говорил об отдельных ветках, то это было как раз не о заводимых лично каждым программистом и потом поддерживаемых ими, а наоборот об автоматически генерируемых системой при каждом коммите/синхронизации. А далее подразумевается, что эти ветки сливаются с основной. Причём это может делать как сам программист, так и другое лицо (ревьюер например или ещё кто-то).

Не совсем понятно, зачем генерировать ветки при каждом коммите. Ещё понятно, когда на отдельную задачу создаётся бранч, или, скажем, бранч для альфа/бета версии. Также понятно, зачем девелоперу иметь свой девелоперский бранч. Но не ясно, зачем создавать бранч при каждом коммите. Не могли бы Вы пояснить?

Убедите меня, что не стоит этого делать.

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

Например, мне бы хотелось, чтобы задачи приоритизировались перетаскиванием, то есть чтобы я просто мог рассортировать их руками. Еще чтобы в зависимости от роли пользователя (тестер, разработчик, ПМ) был разный интерфейс. Потому что тестер, репортящий баг, не должен иметь возможность сделать что-то лишнее, например, назначить баг какому-то девелоперу. Или хотелось бы, чтобы разработчик видел вообще только свои задачи. Когда он начинает работу (нажимая на какую-нибудь кнопку), автоматически отмечается время начала работы, когда заканчивает — время окончания и затраченное время.

Все системы, которые я видел, либо совсем примитивны, либо наоборот напоминают конструктор, но при этом и те и другие заточены на какой-то непонятный мне процесс разработки.

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

Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?

А>Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?

Если вам достаточно существующих систем и загвоздка только в интерфейсе — нет, не проще.

Если же вам надо что-то особенное (например, поддержку ScrumBut tuned by Vasissualiy Pupkin), можете попробовать озаботиться.

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

А>>При этом вроде бы как трекер задач — это приложение-то примитивное совсем. Сами задачи — это просто тупо одна таблица в базе, причем с записями и делать-то ничего особенно не надо, буквально просто хранить и некоторые запросы делать.

S>они все так думали...

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

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

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

Из опыта — лучше всего работает сочетание двух представлений:
1. Задачи, которые разработчик (менеджер, тестер) забрал себе. Группируются по этапу разработки (итерации), внутри каждой группы сортируются по приоритету и дате изменения.

2. "Общий вид" — все задачи по проекту, сгруппированные по состоянию (очередь разработки, разработка,очередь тестирования, тестирование...), внутри каждой группы сортировка по приоритету + дате изменения.

В траке (в основном работал с ним) это делается очень просто — создаём произвольный запрос, добавляем url в закладки.

А>Еще чтобы в зависимости от роли пользователя (тестер, разработчик, ПМ) был разный интерфейс. Потому что тестер, репортящий баг, не должен иметь возможность сделать что-то лишнее, например, назначить баг какому-то девелоперу.
Как минимум в траке настраивается точно.

А>Или хотелось бы, чтобы разработчик видел вообще только свои задачи. Когда он начинает работу (нажимая на какую-нибудь кнопку), автоматически отмечается время начала работы, когда заканчивает — время окончания и затраченное время.
А>чтобы разработчик видел вообще только свои задачи
Это неправильно. Должен быть общий пул (очередь разработки), из которого разработчики сами забирают себе задачи. Более того, очень часто разработчики берут себе один длинный таск и одновременно закрывают кучу мелких багов — просто потому что большая задача выносит мозг и надо на время переключиться на что-то попроще. Так что даже если учёт времени и есть (в траке записывается время перевода задачи из одного состояния в другое) — это скорее оценка сверху, причём с очень большим запасом.

Если ставить задачу точного учёта времени — надо заводить ещё одно состояние ("Разработка — отложен") и заставлять разработчиков переводить отложенные тикеты в это состояние. На практике в небольших командах это очень неудобно и никто этим не заморачивается.

А>Все системы, которые я видел, либо совсем примитивны, либо наоборот напоминают конструктор, но при этом и те и другие заточены на какой-то непонятный мне процесс разработки.
Они не заточены ни под один из процессов (даже TFS предлагает разные профили). Подгонка остаётся за вами.

А>При этом вроде бы как трекер задач — это приложение-то примитивное совсем. Сами задачи — это просто тупо одна таблица в базе, причем с записями и делать-то ничего особенно не надо, буквально просто хранить и некоторые запросы делать.
А>Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?
Оптимизм никто не запрещал, но я бы потратил время на что-то более полезное

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

А>При этом вроде бы как трекер задач — это приложение-то примитивное совсем. Сами задачи — это просто тупо одна таблица в базе, причем с записями и делать-то ничего особенно не надо, буквально просто хранить и некоторые запросы делать.

А>Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?

Пишите.
Знаю компании/отделы, которые написали для себя, либо сильно допилили jira или что-то подобное.

На практике на "простую" систему типа того, что вы описываете — уходят человеко-месяцы (в примере с допиливанием jira в результате был нанят специальный человек на фулайм, который уже больше года только её и занимается).

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

А>Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?

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

А вообще еще не видел не одного проекта, который был бы завален из-за неудобного тула для микроменеджмента,
ценность которого все равно весьма сомнительна.
Та же проблема с тестерами очень проста.
Просто скажите ему что не надо назначать девелоперов.
Делов то... И так во всем. А строить систему управления,
устойчивую к целенаправленному саботажу (тестер ради развлечения меняющий статус багов) — это реально детский сад.
Ну а не понимающего слов тестера можно просто уволить.
Дешевле чем писать свою собственную систему.

Но в целом делайте что хотите

А>Все системы, которые я видел, либо совсем примитивны, либо наоборот напоминают конструктор, но при этом и те и другие заточены на какой-то непонятный мне процесс разработки.

Из личного опыта — два раза писал свою систему управления задачами (оба раза до конца и с внедрением), после чего наконец вкурил как устроен процесс в Jira и перешел на нее. О том, что именно я курил можно послушать вот в этом докладе:

http://www.youtube.com/watch?v=hdTpLLby-dQ

А>Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?

Не проще, увы. Вторую версию я три месяца писал, при том что я в целом не самый бесталанный разработчик. Много мелких нюансов, особенно с разрешением конфликтов.

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

M>На практике на "простую" систему типа того, что вы описываете — уходят человеко-месяцы (в примере с допиливанием jira в результате был нанят специальный человек на фулайм, который уже больше года только её и занимается).

Это от неправильного выбора инструмента, перфекционизма и общего рукожопия. На Ruby On Rails то что хочет топикстартер делается за 2 недели одним опытным рубистом и одним яваскиптером. Там всего-то пара моделей и три вьюхи, и то 99% фич можно взять готовыми.

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

M>>На практике на "простую" систему типа того, что вы описываете — уходят человеко-месяцы (в примере с допиливанием jira в результате был нанят специальный человек на фулайм, который уже больше года только её и занимается).

S>Это от неправильного выбора инструмента, перфекционизма и общего рукожопия. На Ruby On Rails то что хочет топикстартер делается за 2 недели одним опытным рубистом и одним яваскиптером. Там всего-то пара моделей и три вьюхи, и то 99% фич можно взять готовыми.

Там проблема не в том, на чём делается, хотя даже вы показываете человеко-месяц (на каком-нибудь 1С оно пишется ещё быстрее, например),
а в том, что в ходе написания и начала работы с системой вылезает "Много мелких нюансов, особенно с разрешением конфликтов", как уже отметил Eye of Hell, которые влекут существенные изменения, усложенния и кучу переработок.
А дальше начинаются хотелки типа отчетов, кто сколько за месяц отгрузил и т.п.

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

S>Это не совсем правильно — задачи должны сортироваться сами, без вашего вмешательства.

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

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

M>Там проблема не в том, на чём делается, хотя даже вы показываете человеко-месяц (на каком-нибудь 1С оно пишется ещё быстрее, например),

На 1С этим невозможно будет пользоваться.

M>а в том, что в ходе написания и начала работы с системой вылезает "Много мелких нюансов, особенно с разрешением конфликтов", как уже отметил Eye of Hell, которые влекут существенные изменения, усложенния и кучу переработок.

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

M>А дальше начинаются хотелки типа отчетов, кто сколько за месяц отгрузил и т.п.

В одной из контор мы как-то написали себе CRM. Сейлзы сразу же начали просить всякие фишечки и отчетики. Хорошо мы догадались прикрутить CRM к экселю в качестве провайдера данных и добились моратория на дальнейшие изменения без ТЭО. Работает до сих пор, всех устраивает.

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

S>ТС говорит не про сортировку, а про выставление приоритетов. А эту операцию действительно лучше выполнять тасуя мышкой карточки, потому что приоритет конкретной задачи зависит не только от нее, а еще и от других задач.
А, тогда нужно что-то типа http://trac-hacks.org/wiki/QueuesPlugin

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

EOH>Или structure для Jira. До 10-и пользователей копейки стоит.

А для 11 уже $600, это известная разводка. При том что за следующую версию придется заплатить столько же.

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

EOH>>Или structure для Jira. До 10-и пользователей копейки стоит.

S>А для 11 уже $600, это известная разводка.
В чем разводка-то? На странице цен об этом написано...

Больше 10 человек на продукте — это уже что-то довольно большое, для которого 600 баксов не слишком много

S>При том что за следующую версию придется заплатить столько же.
Вроде 50% за апгрейд. К тому ж можно сидеть на старой версии и не апгрейдиться

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

А>Убедите меня, что не стоит этого делать.

А>Я пересмотрел кучу средств управления задачами, и был потрясен, насколько они все далеки от удовлетворения моих элементарных нужд в управлении проектами.

А>Например, мне бы хотелось, чтобы задачи приоритизировались перетаскиванием, то есть чтобы я просто мог рассортировать их руками. Еще чтобы в зависимости от роли пользователя (тестер, разработчик, ПМ) был разный интерфейс. Потому что тестер, репортящий баг, не должен иметь возможность сделать что-то лишнее, например, назначить баг какому-то девелоперу. Или хотелось бы, чтобы разработчик видел вообще только свои задачи. Когда он начинает работу (нажимая на какую-нибудь кнопку), автоматически отмечается время начала работы, когда заканчивает — время окончания и затраченное время.

А>Все системы, которые я видел, либо совсем примитивны, либо наоборот напоминают конструктор, но при этом и те и другие заточены на какой-то непонятный мне процесс разработки.

А>При этом вроде бы как трекер задач — это приложение-то примитивное совсем. Сами задачи — это просто тупо одна таблица в базе, причем с записями и делать-то ничего особенно не надо, буквально просто хранить и некоторые запросы делать.

А>Найти подходящую систему и настроить ее под себя — это адские муки, не проще уж написать самостоятельно?

Мне нравится ChiliProject, это форк RedMine.

Хотя с другой стороны можно было бы писать девлоги и прочее, использовать гит, а документировать доксигеном в *.dox файлах.

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

E>В чем разводка-то? На странице цен об этом написано...

Что-то я не видел чтобы там было написано что заблокированный пользователь считается как настоящий.

E>Больше 10 человек на продукте — это уже что-то довольно большое, для которого 600 баксов не слишком много

Давай посчитаем: 1 служебный пользователь для интеграции с VCS и CI, 1 ПМ, 1 сисадмин, 2 фронтендщика, 2 бэкендщика, 2 тестера, 1 дизайнер. Это очень-очень небольшой вебный проект. Если таких проектов больше одного или мы хотим включить в команду контенщика шансов уложиться в 10 пользователей нет никакого.

А>Я пересмотрел кучу средств управления задачами, и был потрясен, насколько они все далеки от удовлетворения моих элементарных нужд в управлении проектами.
Идеального софта не бывает, но насчет "насколько далеки от удовлетворения элементарных нужд", мне кажется, вы преувеличиваете.

А>Например, мне бы хотелось, чтобы задачи приоритизировались перетаскиванием, то есть чтобы я просто мог рассортировать их руками.
JIRA + JIRA Agile (бывший Greenhopper).

А>Еще чтобы в зависимости от роли пользователя (тестер, разработчик, ПМ) был разный интерфейс. Потому что тестер, репортящий баг, не должен иметь возможность сделать что-то лишнее, например, назначить баг какому-то девелоперу.
У нас в компании процесс большой и сложный, но JIRA вполне справляется с подобной кастомизацией. Redmine с плагинами, пожалуй, тоже. Рекомендую.

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

A>Когда он начинает работу (нажимая на какую-нибудь кнопку), автоматически отмечается время начала работы, когда заканчивает — время окончания и затраченное время.
Насчет "из коробки" не знаю, где такое есть, но в JIRA и Redmine наверняка есть плагины на эту тему.

А>Все системы, которые я видел, либо совсем примитивны, либо наоборот напоминают конструктор, но при этом и те и другие заточены на какой-то непонятный мне процесс разработки.
Если ваш процесс большой и сложный, вы потратите на реализацию специального трекера времени больше, чем на сам проект. Научитесь жить с компромиссами.
Если ваш процесс маленький и простой, под него наверняка можно адаптировать практически любой трекер.

А>При этом вроде бы как трекер задач — это приложение-то примитивное совсем. Сами задачи — это просто тупо одна таблица в базе, причем с записями и делать-то ничего особенно не надо, буквально просто хранить и некоторые запросы делать.
Вы выше уже перечислили больше фич, чем на одну таблицу.

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

КЛ>Предположим, разработчик обновил состояние бага/задачи после сабмита, а не тогда, когда начал над ней работать. В результате, автоматически подсчитанное время равно 0. Что из этого воспоследует?

Эта кнопка для удобства разработчиков, а не для усиления контроля. Если разработчик разгильдяй или бездельник, с этим ничего не сделаешь, кроме увольнения.

КЛ>Предположим, разработчик научился обновлять статус задачи вовремя, и время, потраченное на задачу, считается автоматически правильно. Как это помогает Вам лучше управлять проектом? Например, добиваться того, чтобы проект был закончен к определённой дате?

Учитывается не только время, но и ведется лог разработки, в котором разработчик указывает, что именно он делал.

Это помогает держать контроль над ситуацией. Чтобы предсказать куда мы движемся, нужно иметь данные о том, как мы двигались в последние моменты. Чтобы экстраполировать, нужна статистика. Контроль над выполнением задач не дает разработчику "погрузиться в себя" и не сбиться с пути. Не говоря уже о статистике для последующего анализа в случае проблем.

А>Убедите меня, что не стоит этого делать.

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

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

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

E>>В чем разводка-то? На странице цен об этом написано...

S>Что-то я не видел чтобы там было написано что заблокированный пользователь считается как настоящий.

Настоящие — это все, кто в jira-users и jira-administrator. Заблокированных надо просто выкинуть из этих групп. Лично проверял — работает.

E>>Больше 10 человек на продукте — это уже что-то довольно большое, для которого 600 баксов не слишком много

S>Давай посчитаем: 1 служебный пользователь для интеграции с VCS и CI, 1 ПМ, 1 сисадмин, 2 фронтендщика, 2 бэкендщика, 2 тестера, 1 дизайнер. Это очень-очень небольшой вебный проект. Если таких проектов больше одного или мы хотим включить в команду контенщика шансов уложиться в 10 пользователей нет никакого.

Смысла в служебном пользователе не вижу, его можно совместить с одним из реальных. Накой в жире сисадмин?
да даже если он там нужен — ты имеешь команду из 10 человек, т.е. минимум 600 тыр в месяц тратишь на чистую зп + налоги + аренда. Что для тебя 1200+600 баксов в год? Копейки...

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

MVK>Если можешь одной фразой объяснить, чем твой трекер будет лучше существующих, то это повод всерьез задуматься над новом трекером.
MVK>Если сможешь продать идею здесь, на рсдн-е, то можешь начинать писать. Риск, конечно, большой, но результат может превзойти ожидания.

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

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

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

А>Речь была о том, чтобы написать сугубо для себя, а не на продажу. При этом предполагается, что это несравнимо проще, поскольку конкретные требования будут реализовываться в конкретном коде, и никакая настройка не требуется.

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

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

Отговариваю: жизнь слишком коротка чтобы тратить её на создание еще одного велосипеда.
не надо искать идеальный инструмент — достаточно хорошего.

S>Кстати, посмотри Trello. Приоритезация перетаскиванием там есть.
перешли с trello на платный аккаунт в assembla.

Основной минус trello — крупный шрифт и только канбан доска.
Из-за крупного шрифта канбан доска сразу переполнилась.

В тикетах assembla есть и нормальный вид с фильтруемым списком задач/багов,
milestones для версий или итераций и канбан доска.

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

MVK>Если трекинг задач, это то, на чем вы зарабатываете деньги — то тогда, это имеет смысл. В противном случае, лучше подстроить себя и свои процессы под существующий трекер и сфокусироваться на своем основном бизнесе.

Попробую я "продать", у меня тоже в дальних планах такая фигня имеется. Аргументы:

1. Юзать я люблю trac: он прост и туп. А вот устанавливать/настраивать я его не люблю. Так же как и munin, например, и всё остальное, что цепляется через fcgi дикими плясками вокруг конфигов, которые если и дают результат, то никогда не догадаешься "а что я такого сделал, что оно заработало?". Про настройку апача по инету шутки ходят; у меня ровно один раз в жизни (с год назад) по какому-то наитию получилось настроить его в точности как мне надо и конфиги выглядели прямолинейно и понятно, но второй раз этот трюк я, боюсь, повторить не сумею. Поэтому я хочу сделать трекер частью приложения, пусть крутится на том же сервере и той же базе, что и сам сервис.

2. В shareware товарищ писал, что форум проекта — рулёз. Опять же, я не хочу утяжелять площадку ни php, ни питона, ни перла, не хочу этого секса с интеграцией. А хочу я, чтобы у меня и трекер проекта, и система техподдержки, и форум, и faq были интегрированы в одну систему, чтобы я мог, например, перебрасывать неприватные вопросы из ТП на форум, давать людям с форума голосовать за новые фичи, автоматом копировать ответы в ТП и форум из faq и т.д.

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

Да, даже упрощённая неконфигурируемая система "под себя" займёт 3-6 месяцев чистого времени (обычно я почему-то умножаю сроки на 2 вместо положенных 3, так что надо бы эту цифру скорректировать в 1.5 раза). Ну и чёрт с ней, может мне нравится кодить.

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

_>А мы написали свою системку (причём почти не потратив ресурсов), но только потому, что не нашли ни одной полноценной реализации, удовлетворяющей нашим требованиям. Причём речь была не о мелочах, а о принципах. )

О каких принципах идёт речь? Будет интересно, если конкретизируете.

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

КЛ>О каких принципах идёт речь? Будет интересно, если конкретизируете.

Всё просто: хотели полноценную распределённую систему. А все приличные решения на рынке централизованные и не позволяют многие фичи, привычные нам по использованию DCVS.

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

_>Всё просто: хотели полноценную распределённую систему. А все приличные решения на рынке централизованные и не позволяют многие фичи, привычные нам по использованию DCVS.

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

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

КЛ>Не понимаю, зачем для управления проектом нужна распределённая система управления задачами. Чтобы удалённая команда работала бы над своими задачами в рамках проекта, и вы бы об этих задачах не знали или узнавали бы с опозданием?

Я безусловно поясню зачем она нужна и даже на примерах. Но в начале вы ответьте на один вопрос, что бы я мог понять, как правильнее пояснить: работали ли вы когда-нибудь с mercurial или git в качестве основной системы контроля версий для вашего проекта?

On 19.08.2014 14:10, dimgel wrote:

> _>Я безусловно поясню зачем она нужна и даже на примерах. Но в начале вы
> ответьте на один вопрос, что бы я мог понять, как правильнее пояснить:
> работали ли вы когда-нибудь с mercurial или git в качестве основной
> системы контроля версий для вашего проекта?
>
> Встряну: я работал, и мне тоже интересен заданный Кириллом вопрос.

И мне (работаю с DVCS довольно давно).

--
WBR,
Serge.

Здравствуйте,

тоже интересуюсь. С DVCS работаю.

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

_>Я безусловно поясню зачем она нужна и даже на примерах. Но в начале вы ответьте на один вопрос, что бы я мог понять, как правильнее пояснить: работали ли вы когда-нибудь с mercurial или git в качестве основной системы контроля версий для вашего проекта?

Нет.

_>Вот я именно так и подумал. И вот почему — если заменить в ваших словах "задачи" на "файлы", то получатся почти в точности аргументы сторонников старых централизованных cvs.

Я не высказывал никаких аргументов как "за", так и "против" — просто спросил, т.к. вопрос мне кажется интересным. Видите ли, у меня сложилось такое мнение, что на текущий момент достаточно инструментов для управления проектами. Например, мне хватало outlook'а, redmine'а и excel'я. Вот и было интересно узнать, для чего пришлось создавать собственный таск трекер.

_>Причём они имеются только у тех, кто не пробовал на практики dcvs. А понимание того, что в dcvs используется совершенно другая модель, в которой нет подобных проблем, приходит только после того, как реально распробуют систему на практике.

Тем не менее, распределённая система контроля кода/задач вносит свои проблемы. Как раз сегодня обсуждал их со своим коллегой, работающим в другой команде и с другим заказчиком. Но, понятно, обсуждение этих вещей выходит за пределы данной темы.

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

Вы ревьюите код коллег после его коммита в основной репозиторий?

_>Как это будет выглядеть? В начале я просматриваю/правлю код в редакторе. Далее делаю коммит (вот в этой точке централизованные системы контроля версий уже не подходят) с исправлениями и делаю соответствующие отметки в задачах (и здесь опять же централизованные системы управления задачами не подходят).

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

P.S.: Спасибо за пример. Достаточно наглядно.

On 21.08.2014 19:40, alex_public wrote:

> Осталось только продумать
> правильный формат данных для задач (чтобы гарантированно никогда не было
> слияний)

Это, если не секрет, как? И что делать, если всё же конфликт?

--
WBR,
Serge.

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

_>Вообще если делать всё "по честному" и разрабатывать полноценную систему, то наверное игра не стоит свеч — проще смириться с некоторыми минусами централизованных. Но мы сделали некий хитрый ход — использовали в качестве основы системы управления задачами нашу же dcvs (у нас это Mercurial). Таким образом мы сразу получили "на халяву" весь низкий уровень (база данных, транспорт, авторизации, разруливание конфликтов и т.п.), причём очень продвинутый и вылизанный.

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

_>Сейчас используем только эту нашу систему (ну и плюс я использую Planner с его диаграммами Ганта для своих прикидок) и полностью довольны.

Мы от диаграмм Ганта отказались. Вернее так, если менеджеру нужно, то он может ими пользоваться. Но они не являются официальным инструментом.

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

Тут аргументы "против", в принципе, стандартные:

1. Проблемы с объединением кода. Фактически коллеги установили гит, но используют его, как свн, потому что, с одной стороны, им не нужна распределённость, а, с другой стороны, если сразу не коммитить свои изменения в основной репозиторий, то потом много проблем будет с объединением. К тому же, у них проект на юнити, много бинарных файлов, которые вроде бы не меняются, но помечаются, как изменённые (возможно, потому что среда разработки вносит какие-то несущественные изменения). В общем, если коротко, то много бинарников, которые потом трудно объединить.
2. Есть сомнения, что гит работает хорошо с большими объёмами бинарных данных. Во всяком случае, свн работает с ними плохо. Поэтому наша команда использует перфорс.
3. Секьюрность. В перфорсе можно ограничивать доступ отдельным людям к отдельным веткам репозитория. В свн это вроде сделать нельзя. А как в гите, dcvs?
4. Постоянно нужна обновлённая версия. Мы все работаем над одним продуктом, в который за цикл разработки нужно добавить несколько сотен фич. Важно, чтобы эти фичи не поломали друг друга и работали бы друг с другом хорошо.

_>Хы, вот как раз с dcvs это всё вообще не вопрос. Подход в виде одного репозитория и ветвлений (автоматических) по каждому чиху реализуется там очень удобно.

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

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

>> Осталось только продумать
>> правильный формат данных для задач (чтобы гарантированно никогда не было
>> слияний)

H>Это, если не секрет, как? И что делать, если всё же конфликт?

Так очень просто: каждое изменение задачи — это отдельный файл (а там обычный json) с уникальным id. Так что слияний не может быть в принципе.

Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Предположим, разработчик обновил состояние бага/задачи после сабмита, а не тогда, когда начал над ней работать. В результате, автоматически подсчитанное время равно 0. Что из этого воспоследует?

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

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

КЛ>Не совсем понятно, зачем генерировать ветки при каждом коммите. Ещё понятно, когда на отдельную задачу создаётся бранч, или, скажем, бранч для альфа/бета версии. Также понятно, зачем девелоперу иметь свой девелоперский бранч. Но не ясно, зачем создавать бранч при каждом коммите. Не могли бы Вы пояснить?

Там не на коммит, а скорее на синхронизацию. Ну вот например, допустим над проектом работает 10 человек и в данный момент в репозитории есть одна ветка. Значит все 10 синхронизировались (скачали себе последнюю ревизию) и ушли в оффлайн. Потом каждый у себя делает коммиты (сколько угодно) и они как бы выстраиваются в продолжение той главной ветки. А потом они все делают синхронизацию и в репозитории автоматически оказывается 10 веток. Однако потом (увидев такую картину после синхронизации) их естественно снова сливают в одну ветку.

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

_>Кстати, распределённая вики у нас тоже есть — просто редактор Zim, файлы которого опять же лежат под Mercurial. )
У меня похоже.

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

_>А потом они все делают синхронизацию и в репозитории автоматически оказывается 10 веток. Однако потом (увидев такую картину после синхронизации) их естественно снова сливают в одну ветку.

Понятно. Спасибо! А много времени занимает такая синхронизация? Часто ли приходится разрешать конфликты?

У нас от такой практики отказались. Поначалу заказчик хотел, чтобы мы, как аутсорсер, работали в своей ветке проекта, а один из ведущих инженеров эти ветки бы синхронизировал. Однако это вылилось в то, что на синхронизацию приходилось тратить уйму времени. Где-то 2-3 человека/дня в неделю. И это было время одного из ведущих инженеров.

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

_>>А потом они все делают синхронизацию и в репозитории автоматически оказывается 10 веток. Однако потом (увидев такую картину после синхронизации) их естественно снова сливают в одну ветку.

КЛ>Понятно. Спасибо! А много времени занимает такая синхронизация? Часто ли приходится разрешать конфликты?

Так это зависит от используемой тактики — сама система контроля версий поддерживает любые. Например, если мы возьмём вариант в стиле "каждый просто делает push, а потом приходит некий главный ревьюер, который просматривает все эти ветки и сливает нормальные в главную", то наверное будет долго, т.к. скажем в вышеописанном примере ему придётся заниматься слиянием 10 веток (пусть даже большинство и автоматом сработает). А можно взять другой вариант (мы предпочитаем его, но с некоторым поправками типа стажёров и т.п.) — если после синхронизации разработчик видит раздвоение, то он должен сделать слияние своего кода с текущим. Соответственно возвращаясь к нашему примеру: больше всего повезёт тому разработчику из нашего десятка, который первым выполнит синхронизацию (ему не надо будет ничего дополнительного делать), а всем остальным придётся сделать слияние со всеми предыдущими изменениями (но они для них отображаются уже как одна ветка).

КЛ>У нас от такой практики отказались. Поначалу заказчик хотел, чтобы мы, как аутсорсер, работали в своей ветке проекта, а один из ведущих инженеров эти ветки бы синхронизировал. Однако это вылилось в то, что на синхронизацию приходилось тратить уйму времени. Где-то 2-3 человека/дня в неделю. И это было время одного из ведущих инженеров.

Постоянная отдельная ветка — это немного другой расклад. Он тоже частенько применяется, но совсем для других задач. Ну и конкретно у нас он не особо популярен. А вот в мире open source подобное на каждом шагу. Ну и git/mercurial тут безусловно тоже очень удобны.

EOH>Из личного опыта — два раза писал свою систему управления задачами (оба раза до конца и с внедрением), после чего наконец вкурил как устроен процесс в Jira и перешел на нее. О том, что именно я курил можно послушать вот в этом докладе:

а что этот доклад делал?
у них есть еще какие-нибудь материалы по этой теме?

E>а что этот доклад делал?
E>у них есть еще какие-нибудь материалы по этой теме?

Доклад делал я. Именно по управлению проектами с помощью issue tracking есть еще статья на хабре: http://habrahabr.ru/post/126104/