redmine/track + <your favorite version control system>

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

хотя бы пост-ревью, хоть какое-нибудь

В свое время я тупо просматривал svn history, dvn diff, звал к своему рабочему месту провинившихся, и объяснял, в чем они не правы.

Едва ли процесс ускорится от того, что тебе придется давать эти объяснения в письменном виде ;) (имеется ввиду работа с полноценным code review tool)

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

человек постит вопрос, я на него отвечаю в режиме Instant Messaging, например, ссылками на вики по-быстрому составляя это самое wiki

Может, и использовать Instant Messaging, не мудрствуя лукаво? Жаббир.

s/dvn/svn/

Но чото ни один багтрекер мне категорически не нравится

Багзилла и мантис - оба хороши. Ненужные поля не заполняйте, и замедляться будет не с чего.

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

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

Есть нюансы. Например, под каждый модуль - отдельный репозиторий, а модулей 100500. Каждый новый репозиторий приходится чекаутить, если нужны исправления - перенастраивать IDE, для проверки нужно перенастроить сервер итп.

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

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

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

Может, и использовать Instant Messaging, не мудрствуя лукаво? Жаббир.

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

сейчас QA сконцентрирован в общей джаббероконференции, но из-за, опять же, большого объема и неструктурированности, польза от нее довольно сомнительная. Сейчас она на треть засрана вопросами типа «что такое JSON и как с ним работать?» и ответами со ссылками на гугл. На другую треть она засрана проектно-специфичными вещами, которые бесполезны (а иногда и вредны) для других участников. Всё это идет сплошным блоком текста и совершенно выносит мозг.

под каждый модуль - отдельный репозиторий

А зачем?

QA

Q&A automation

Сначала подумал про контроль качества

Сотни сайтов, примерно одинаковой структуры. Каждый сайт - отдельный проект, со своей собственной отчетностью, бухгалтерией, итп. Часть кода является общей - либо на уровне библиотек, либо на уровне копипасты. Один сайт пишется в течение пары часов. Написал один - пошел на следующий.

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

Моя рабочая и проверенная версия того, что делать в таких случаях:
во-первых - бьем весь «табун» на группы по 5+1 человек
во-вторых - из всех существующих задач выбираем такие, которые каждая из групп в состоянии решить за 8 часов рабочего времени
в-третьих - каждую из задач делим на количество частей, равное количеству членов группы
в-четвертых - выдаем задачи каждой из групп, путем объяснения 6-ому члену группы того, что надо сделать, рассказываем ему, как он должен поставить задачи остальным членам группы и как проконтролировать выполнение, так же рассказываем как будем контролировать выполнение задачи всей группы. Естественно, этих «шестых» членов группы надо авторизовать перед остальными участниками групп, как людей выдающих и принимающих выполненные задачи в течение, например, недели
в-пятых - в течение первого дня, пока те «шестые» будут постигать азы общения с командой, садимся и пишем понятным языком рабочие инструкции, касающиеся того, какую информацию где и как искать, какую информацию где и как фиксировать, какую информацию кому и в какой форме сообщать. (Все последующие дни - вносим коррективы в написанные рабочие инструкции, анализируем знания-умения-навыки членов команд, принимаем решения о «кадровых» перестановках, делаем свою остальную повседневную работу)
в-шестых - к концу рабочего дня приходим в каждую из групп и вместе с «шестым» контролируем выполнение задач (если «шестой» раньше никогда не выдавал/принимал задачи, то мягко просим его молчать и слушать, как это будем делать мы - демонстрируем пример для подражания). В процессе контроля выполнения корректно сообщаем как и что надо исправить и сдержанно хвалим за то что было сделано верно.
в-седьмых - ознакамливаем все группы с писаниной из пункта «в-пятых» и требуем выполнения написанных правил.

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

Что касается софта, то он, как любой инструмент вторичен - сначала надо позаботиться о рабочих процедурах, потом уделять внимание инструментам. Мне понравился mingle ThoughtWork'овский (правда, он платный).

У нас в подобном случае обычно общая репа - транк для движка и теги для кастомных настроек/перепилок. В сильно «производственно запущенных случаях» (давно в продакшене/«движок» - какая-нибудь гигантская библиотека или куча сервисов, много раз перепроданная под разными названиями, оркестрованная по масштабу на сильно разные бизнес-задачи) - у движка и сайтов отдельные репы, но в этом случае и команды их поддерживают разные (подозреваю, команды сайтов пилят у себя срочные патчи для движка, а потом сливают их в разрабам движка в транк - а потом внезапно переезжают на новые поколения движка, когда разрабы того придумают какое-то глобальное улучшение). Хотя... Возможно, тут разница в масштабах проектов. Или... Я просто «модуль» понял как «подсистема» :)

замени svn на git/hg и половину проблем отпадет сразу же.

Да, тут разница в масштабах. Чуваки решили «масштабировать так масштабировать» и отмасштабировали всё, включая репозитории. Мы на это повлиять никак не можем. Лично я юзаю git svn, но оно пока недостаточно готово чтобы работать в нашем случае.

QA and code review tool (комментарий)

Ну, может быть, умный инструментарий сможет научить нас правильному рабочему процессу, и каким-то образом enforce it :)

Помедетирую над твоим каментом, отвечу чуть позже...

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

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

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

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

Чего только люди не сделают чтобы лично не общаться....

Моё мнение тебе не важно и не интересно

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

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

Да-да, сначала плавать научись, а потом мы тебе и воду нальем.

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

http://www.lolwithme.org/?p=159

CI (jenkins, cruise control), чекеры для coding standard's, юнит тесты.

Всякие практики из agile методологий, типа pair programming, митинги и самостоятельные комманды. Та же Jira вполне себе нормальное средство для Scrum.

[грязно выругался]
QA != Q&A
QA automation != Q&A automation

Да-да, сначала плавать научись, а потом мы тебе и воду нальем.

Есть и такая методика, применительно к плаванию.

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

http://www.lolwithme.org/?p=159

Беспомощный управленец детектед.

Слив защитан, спасибо за дискуссию.

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

Да-да, сначала плавать научись, а потом мы тебе и воду нальем.

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

Беспомощный управленец детектед.

В моей команде никто вроде не жалуется.

Слив защитан, спасибо за дискуссию.

Терпи-терпи своих беспомощных управленцев, ходи скули об этом по форумам, таково твое предначертание, ничего не поделаешь :D

А ещё можно понаблюдать за уже работающими тимлидами.

Если бы ты больше знал про Олега, то был бы в курсе, что он и так достаточно интересуется чужим опытом. Практику такие наблюдения заменить не могут, причем роль практики еще более выраженная, чем в случае с плаванием.

мне интересно, как можно сначала научиться управлять, а потом только начать управлять?
так не бывает.

мне интересно, как можно сначала научиться управлять, а потом только начать управлять?

мне вот тоже не понятно:
как это можно сначала научиться лечить людей, а потом только начать их лечить?

так не бывает.

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

мне вот тоже не понятно: как это можно сначала научиться лечить людей, а потом только начать их лечить?

man интернатура

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

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

посоветуйте конструкцию офисного помещения

Тир, 35 метров с пулеуловителем.

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

Ты обрёл просветление.

anonymous, ты медик? если да, то прикасайся к пациентам.
нельзя научиться лечить не леча. если бы было можно, то не было бы интернатуры.

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

все в редмайн. вопросы тебе пусть тикетами бросают либо на статус «не знаю что делать». потом это все в секицю вики FAQ и посылать туда если дубли вопросов.

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

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

man интернатура

возьму из wiki, чтобы далеко не ходить (все подчеркивания мои):
Интернату́ра (лат. internus — внутренний) — первичная последипломная специализация выпускников медицинских институтов по одной из врачебных профессий, проводимая после сдачи государственных экзаменов, на базе лечебно-профилактических учреждений под наблюдением и руководством соответствующей кафедры ВУЗа.

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

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

я правильно понял?

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

вычитать из зарплаты студентов? может им сразу бесплатно работать?

Ты обрёл просветление.

думаешь он осилит понять, что ТС со своим «I need help» здесь, это и есть тот самый троечник? :)

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

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

возьму из wiki, чтобы далеко не ходить

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

думаешь он осилит понять, что ТС со своим «I need help» здесь, это и есть тот самый троечник? :)

ТС активно ищет, не вижу здесь проблемы. Собаки лают, караван идёт :)

а на кой там в принципе скил больше студенческого? на таком потоке любой новичек после тройки-четверки сайтов превращается в полноценную ноду и работает на общих основаниях

и заставь прокачать скил

вот это - отдельный вопрос, «как качать скилл». Групповым образом, то есть. У тебя есть истории успеха?

http://www.youtube.com/watch?v=pngVqaIJank

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

я бы давал список ссылок для ознакомления и тестовые задания на выполнение. напр запилить типовой сайт и соблюсти требования 1,2...n

еще в какойнить мудле провести тестирование по теории.

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

я понял иначе - студенты уже клепают по 3-4 сайта в день которые уже идут в продакшн

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

у меня не было такой теории; есть теория, что интерны постепенно приобретают опыт под руководством опытного доктора, причем в самом начале они не несут никакой ответственности, а пациенты получают лечение, назначенное интерном только после одобрения старшего; здесь ключевое слово «постепенно»;

а что мы видим здесь?
глав. врач больницы (гениальный менеджер ТС'а) назначает интерна (самого ТС) зав. хирургическим отделением, со штатом в десяток медсестер (студенты-новички), и дает план - пять операций в день («Мне как тимлиду нужно сделать так, чтобы команда производила что-нибудь полезное»)