LINUX.ORG.RU
ФорумTalks

О трекинге задач и командной работе

 , ,


3

1

Вечер добрый.

Насущный вопрос: лоровец, а чем ты пользуешься в своём проекте для трекинга задач, а также мониторинга и взаимодействия всего и вся?

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

И как бы с одной стороны бумажный листочек и телефон остаются самыми удобными средствами, но ежу понятно, что хчется чего-то приемлимого.

Теперь конкретно о том, что я жевал в этой сфере:

  • Trello — интересно, но слишком визуально и не работает уже от 15 человек. Ну или при большой текучке
  • Google-сервисы — работа на основе календаря, табличек, списков и прочего. Работает плохо, много телодвижений
  • Teamer — не знаю, стоит ли даже упоминать, совершенно случайно доводилось юзать, штука просто невменяемая.
  • Redmine — вот тут уже интереснее. По факту, есть всё, что нужно. Но требует поддержания самой системы, и так или иначе заточено под код. И во многих случаях его исползование может выглядеть как использование мультитула в качестве открывашки.
  • Slack — очень интересная вещь, но не решает проблему трекинга совершенно.

Это основное, что вспомнил. Поясню, что кроме непосредственно сервисов я и те, кому актуально, пробовали различные варианты работы исходя из того что есть. Также сейчас тыкаю todoist — пока создаётся ощущение, что интересно, но в бесплатной версии особо ничего нельзя. А насколько полезна платная не знаю.

Теперь конкретизирую вопрос. Сразу предупрежу, что он скорее метафорический и всеобщный. Какие есть годные средства командной работы? Хочется видеть гибкость, многофункциональность и всеобщность. Ну то есть всё сразу: трекер с блок-задачами, деревьями, метками, возможностями назначения ответсвенных, наблюдателей, подтверждалок и прочего; всякие графики прогресса; хранилище материалов; возможность отслеживания проработки какого-либо материала как задачи; группы пользователей, объявления, а также клиенты с уведомлениями и прочая социальщина.

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

Ответ на: комментарий от hippi90

Допустим, а у него есть пробный период или что-то ещё? И если есть, то чем примечателен?

Dispetcher14 ★★★★★
() автор топика

Это тут уже было.

Для мелких проектов вики и треккер на битбакете или гитхабе, для проектов посерьёзней докувики и канбоард.

Вот этой штуки тебе, скорее всего, на первое время хватит:
https://kanboard.net/

Goury ★★★★★
()
Ответ на: комментарий от HeipaVai1o

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

Канбан это очень хорошая методология.
Канборд это очень хороший инструмент.

Goury ★★★★★
()

Мы сейчас юзаем JIRA+Confluence в Atlassian Cloud, на маленькую команду стоит копейки. Все работает просто замечательно.

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

alex_the_v ★★★
()
Ответ на: комментарий от alex_the_v

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Goury

А как положено делать по канбану, когда у тебя 30 открытых багов, и они все ожидают уточняющей инфы от юзеров?

Алсо посмотрел на скриншоты канборда и что-то не увидел комментов к задачам. Их там правда нет? А где тогда задачи обсуждать?

HeipaVai1o
()

Dispetcher14 ★★★  Школьник

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

Stahl ★★☆
()

Redmine требует настройки, как и любая тулза. Как-то писал плагин для малого предприятия по изготовлению металлоконструкций для трэкинга смен. ИМХО - вариантов не особо много Есть бабло - jira Нет бабла - redmine

Все остальное - куцые клоны.

ioway
()
Ответ на: комментарий от HeipaVai1o

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

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

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

Goury ★★★★★
()
Ответ на: комментарий от Iron_Bug

на эту мелочь надо отдельный сервер

https://www.atlassian.com/ondemand/signup/, дарю.

Про томкат дрюкающий сервера поржал. А зачем тебе сервера? Чтобы они стояли, а ты их веером обмахивал да пылинки сдувал? Бэкапы по полгига тебя напрягают? Лол.

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

В нашей конторе избавиться от Редмайна было не моей идеей, но я очень был рад решению перейти на Джиру, хоть Редмайн и был моим детищем.

alex_the_v ★★★
()
Ответ на: комментарий от alex_the_v

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

Iron_Bug ★★★★★
()

А что, orts никто не юзает? Приходилось использовать в паре контор именно как трекер задач, вполне подходит. Да, в нем нет свистоперделок и красивых менюшек, но как средство управления и мониторинга на небольшую контору он вполне ОК. У себя возможно тоже внедрю. Пока обходимся встроенными задачами в zimbra.

tmp_do
()
Ответ на: комментарий от Iron_Bug

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

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

alex_the_v ★★★
()
Последнее исправление: alex_the_v (всего исправлений: 1)

раз

https://github.com/taigaio

и два

youtrack

Использовал второе в открытом режиме, вот где действительно аналитика, вот это я понимаю.

До этого смотрел redmine: очень хотел, чтобы оно мне понравилось, но не понравилось. Впрочем, даже если и не хочется его поддерживать, то берешь у do преднастроенную и оно крутится. Потом через какое-то время переносишь задачи в новую такую же преднастроенную. Поддерживать не надо,разбираться с настройками — тоже. Удобно.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 5)

бумажный листочек и телефон остаются самыми удобными средствами

Часто на ЛОРе встречал упоминания о бумажных листках и карандаше, всё не мог поверить, что это так. Наверное, это какие-то гуру канбана.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от alex_the_v

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

всё, что нужно программисту...

Очень упрощённое видение ситуации. В agile-тиме «потрясание мудями», всякие скрам-борды, графики-бантики, нормальные нотификации, нормальная интеграция с GIT и с CI (джира нативно интегрируется с Stash и Bamboo) - это очень важные вещи, и в Редмайне все эти процессы весьма куцые. А так-то да, проекты-тикеты есть, чё еще надо, так можно и жаббером проектами управлять.

не могу сказать, что это был какой-то героизм

Да я его за 15 минут поднял из докера и все тоже сразу заработало, плюс ещё 15 минут сконнектить аутентификацию с Google OAuth. Редмайн действительно сразу ставится и работает, но не в этом дело. А в том, что чтобы от него получить какой-то толк, надо месяцами потом ходить вокруг него с напильником. Там, блин, плагин поставить-снести надо заходить по SSH и размахивать граблями (rake, в смысле), причем снести плагин иногда бывает нетривиально.

alex_the_v ★★★
()
Ответ на: комментарий от alex_the_v

Очень упрощённое видение ситуации. В agile-тиме «потрясание мудями», всякие скрам-борды, графики-бантики, нормальные нотификации, нормальная интеграция с GIT и с CI (джира нативно интегрируется с Stash и Bamboo) - это очень важные вещи

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

Iron_Bug ★★★★★
()

что-то, где есть вообще всё, причём с блекджеком и трёхцветное. Нечто, что может применяться в любой командной работе

Боюсь, что ничего нет. Десять лет назад IBM соловьём разливалась на тему collaboration. Говорила, что Quickplace в интеграции с Sametime - это будущее командной работы. В итоге всё свелось к корпоративным социалочкам и блоггингу.

Xellos ★★★★★
()

Тут ещё какое дело. «Командная работа» - это buzzwords. Абстрактный класс, предельно абстрактный причём. Нужно искать софт (информационную систему) для конкретной методики командной работы. Вот про канбан уже упомянули, но канбаном жизнь не ограничивается, как бы это ни было противно свидетелям канбана.

Xellos ★★★★★
()
Ответ на: комментарий от Iron_Bug

Некомпетентность опасна на любой позиции, в том числе и на менеджерской. Грамотный проджект-менеджер или деливери-менеджер реально решают, особенно когда в тиме 1 дизайнер, 1 UX, 2 фронтеда, 4 джависта, 2 девопса, 1 секопс, а сроков осталась неделя с выходными. Хорошие инструменты решают тоже.

alex_the_v ★★★
()
Ответ на: комментарий от alex_the_v

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

в разработке на срок выполнения проектов влияет только опыт разработчиков и мотивация в виде зарплаты

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

Goury ★★★★★
()
Последнее исправление: Goury (всего исправлений: 1)
Ответ на: комментарий от Xellos

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

Goury ★★★★★
()
Ответ на: комментарий от Iron_Bug

Зря вы так.
Сотрудники бывают разные и задача руководства (именно руководства, а не менеджера) — рулить так, чтобы команда не разосралась, но дружно пилила общий велосипед на пути к светлому будущему.

Возможно тут имеет место расхождение терминов.
Проджект-менеджер это не менеджер в классическом понмании, но что-то ближе к тимлиду, занимающимуся принятием технических решений и взаимодействующему со всей командой от продажников до директора.

Goury ★★★★★
()
Ответ на: комментарий от Goury

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

Xellos ★★★★★
()
Ответ на: комментарий от Goury

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Stahl

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

Dispetcher14 ★★★★★
() автор топика
Ответ на: комментарий от Xellos

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

Dispetcher14 ★★★★★
() автор топика
Последнее исправление: Dispetcher14 (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

Окай, обсуждаем.

команду надо набирать

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

разношерстные люди

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

есть много других, более важных задач

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

некоторые менеджеры имеют свойство не понимать это и отвлекать программиста от работы с глупыми вопросами

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

от этих вопросов работа не ускоряется ничуть

Менеджеров с такими вопросами — гнать

от писания отчётов

А вот отчёты нужны не столько менеджерам, сколько для организации и самоорганизации.
И чтобы эти отчёты писать было легко и приятно — есть канбан.
Закончил задачу — передвинул карточку из колонки «делаем» в колонку «насяльника, проверяй» — вот и весь отчёт.
Всё остальное инструмент посчитал сам на основе двигания этой карточки по колонкам (приехало, оценено, запланировано, в работе, ящик для откладывания, готово, закрыто) и доскам (у разных групп свои доски, у отдельных сотрудников тоже могут быть свои доски). Все отчёты не требуют никаких интеллектуальных вложений и занимают секунды.
Зато потом можно легко понять кому в команде какие задачи давать и кого на какие курсы отправить. И ещё много полезных мелочей от которых в результате можно выиграть в несколько раз.

болтологии на всяких совещаниях

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

сотрясание воздуха и объём ненужной макулатуры надо сокращать и создавать условия для нормальной, спокойной и сосредоточненной работы

Да, именно для этого нужны инструменты.
Ибо не всю макулатуру можно исключить за ненадобностью.
Некоторая макулатура нужна и надо автоматизировать процесс её выработки.

обкладывают всякой управленческой фигнёй - тем меньше у него времени на программирование

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

Goury ★★★★★
()
Ответ на: комментарий от Dispetcher14

Ещё раз повторяю. Автоматизация совместной работы должна идти после понимания этой самой работы.

Xellos ★★★★★
()
Ответ на: комментарий от Goury

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

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

И если управленческую фигню можно автоматизировать управленцем, то организационную без участия организовываемого разработчика — никак.

организация программиста только у него в голове. всё остальное ненужно по определению. чем меньше программиста дёргают - тем эффективнее он работает.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 5)

Трелло, да. Еще видел самописное трелло. Канбан короче во все поля.

unt1tled ★★★★
()
Ответ на: комментарий от Iron_Bug

Вы точно разработчик? Иногда мне кажется что вы тонкий тролль.

Ну понятно же что разработчик не один в команде и по факту становления разработчиком он не становится телепатом.
И держать в голове сразу весь проект каждому разработчику и при этом помнить кто и в каком порядке что разрабатывает — глупость.

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

Держать всё в голове и не пользоваться ничем можно только если ты совсем зелёный кодер и кодишь очень простую феньку в одиночку. И даже в этом случае инструменты всё-равно упрощают разработку.

Goury ★★★★★
()
Ответ на: комментарий от Goury

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)

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

Deleted
()
Ответ на: комментарий от Deleted

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

Dispetcher14 ★★★★★
() автор топика
Ответ на: комментарий от Iron_Bug

в случае совсем тяжёлых проектов есть redmine
а всяческий учёт - это синдром вахтёра у слабых мозгом

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

эта паранойя существенно мешает

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

не тратить драгоценное время

. И не в коем случае не потратить день на изучение новых практик и инструментов.

Один умный персонаж когда-то давно ещё сказал:

Лучше сейчас день потерять, но зато потом за пять минут долететь.

Goury ★★★★★
()
Ответ на: комментарий от Dispetcher14

Я верю в самоорганизацию процесса, когда участники общаются и договариваются между собой: простые конвенции, быстрые обсуждения аля «хватай стул — иди сюда», а не долгие запланированные за две недели ППР без смысла. Хотя для самоорганизации нужен профессионализм участников, терпение и дисциплина. Трекер тут играет роль коллаборативного блокнота, где одна обезьяна сообщает другой на каком дереве висит вкусный фрукт.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.