По сути, основных рабочих инструментов у меня сейчас три: e-mail, календарь и записная книжка. Ну еще и браузер сюда можно добавить, поскольку плотно приходится работать с корпоративным Confluence. Бывает, что я за целый день ни разу не запускаю Far. Ну а в gVim вообще могу неделями не заходить :(
За время работы в Интервэйл пережил две попытки внедрения в процесс работы MS Project-а. Обе неудачные. Имхо, результат вполне закономерный. Ну не такой это процесс – разработка ПО – который хорошо ложится на управление посредством MSP. Особенно в нашей компании, которая еще не переросла из стартапа в бюрократизированную солидную структуру.
Единственным работающим методом (по крайней мере для моего отдела) оказался метод “списков ожидания” (wish-list-ов). Т.е. все, что нужно сделать не планируется заранее на конкретных людей и конкретные даты, а фиксируется в списке. Причем хотелки там сортируются в порядке убывания приоритета (т.е. на самом верху всегда самые важные). Когда какой-то человек завершает свою текущую задачу, списки ожидания просматриваются и ему выделяется самая важная из тех, с которыми он в состоянии справится.
Списков, обычно, несколько, по одному на каждый разрабатываемый отделом продукт/проект.
Списки ожидания в наших условиях работают хорошо. Но у них есть недостаток. Они показывают объем работы, который висит на отделе (команде), но не дают наглядного представления о том, как все это может растянуться во времени.
Картину распределения времени по задачам/людям хорошо дают диаграммы Ганта. И, когда мне захотелось создать такую картинку текущих работ своего отдела, сразу вспомнился MS Project :(
Поскольку с MSP связываться не хотелось, то поискал в Интернете его легковесные аналоги. Их есть :) Но немного. Из живых, похоже, остался разве что GanttProject.
Скачал, поставил, попробовал. Вроде нормально. Очень хорошо иллюстрирует кто чем занят и когда освободится.
Но сразу захотелось большего :) Туда бы еще отдельной фичей добавить wish-list-ы с потенциальной привязкой к людям. Причем так, чтобы задачу из wish-list-а можно было назначить сразу нескольким исполнителям (кто первый освободится, тот ее и получит). И чтобы на диаграмме Ганта другими цветами обозначались потенциальные задачи для людей. Вот тогда было бы интересно поэкспериментировать с этим инструментом.
Могу еще OmniPlan порекомендовать, если вы конечно на OS X. Удобней и красивей GanttProject.
ОтветитьУдалить@YoungSkiper:
ОтветитьУдалитьНе, я виндузятник :)
К тому же искал бесплатный инструмент. Наверняка под Windows есть платные аналоги Project-а приличного внешнего вида.
@dulanov:
ОтветитьУдалитьПро канбан наслышан, но пока не решился связываться. Да и не от меня сие зависит.
а когда кто-то делает коммит, он *автоматически* начинает отображаться на соответствующей полоске диаграммы ганта? а ткнув мышью по коммиту на полоске, можно посмотреть его код (в смысле дифф)?
ОтветитьУдалитьэто я так (повторно) намекаю, что своя тулза поудобнее будет, да и затраты на ее изготовление близки к нулю (разве что надо требовать ее написания на чистом РНР+JS+SQL без всяких там персистентных объектов и тем более без использования CMS -- вам же потом будет на порядки легче понять этот код и уже *самим* подтачивать его под себя)
з.ы. РНР потому, что такого программера легче найти, да и заточено оно хорошо под *наколеночные* поделки
@имя:
ОтветитьУдалитьКоммиты тут вообще не причем. Промежуточная активность разработчика не имеет тесной корреляции с прогрессом по конкретной задаче. Поэтому в инструменте для планирования лично я не вижу смысла обращаться к низкоуровневым деталям, вроде коммитов, процентов покрытия кода тестами и пр.
если у тебя по началом 50 программистов и их *все* задачи отображаются на диаграмме ганта, то соглашусь с тем, что детали типа кода коммитов излишни для большей части твоей деятельности -- но информация лишней не бывает, *если* ее отображение можно легко включить и отключить
ОтветитьУдалитьпроцент покрытия кода тестами тоже был бы полезен как способ оценить, как сделана работа -- наскоро или качественно и основательно
а еще полезна цикломатическая сложность, чтобы прикинуть, насколько была трудна работа и даже "сколько времени ему осталось"
если разработчик покрыл половину кода тестами за 1 день, то за сколько дней он покроет тестами вторую половину кода? ответ: зависит от цикломатической сложности (грубо, если первая половина половина кода это мешанина if-ов и for-ов, а вторая -- длинная линейная портянка без единого if-а или for-а, или наоборот -- то время явно разное)
s/как способ оценить/как способ прикинуть/
ОтветитьУдалить@имя:
ОтветитьУдалитьБез обид, но в том, что ты пишешь, имхо, проявляется проблема перехода инженера в менеджеры. А именно, попытка слишком жесткого контроля за происходящим.
Менеджера, под которым 50 программистов, вообще не должны интересовать такие вещи, как коммиты. По хорошему, он вообще должен о таких вещях забыть. Коммиты, процент покрытия тестами и пр. технические детали могут быть важны тимлиду, может нач.отдела. А менеджеру нужны качественные оценки -- сделано или не сделано, достаточное качество для перевода в бой или не достаточное, укладываемся в срок или нет.
Все вышесказанное имхо, возможно, я ошибаюсь.
в целом да
ОтветитьУдалитьабсолютно без обид -- со мной можно гораздо жестче разговаривать и сохранять дружеские отношения (обратная сторона этого в том, что с людьми общаюсь так же жестко, и недоумеваю, чего они *вдруг* начинают пищать или огрызаться? :-)
тут три момента
1. я, хотя и был проинформирован о том, что ты перешел в менеджеры, как-бы не поверил; т.е. интуитивно я все же предполагал что-то вроде очень большого проекта, с некой общей идеей, который нельзя разбить на 100% независимые части, и который нуждается в том, чтобы иногда самому смотреть даже отдельные коммиты (типа ядра линукса)
2. я продолжаю считать, что на менеджера, которому нет нужды смотреть коммиты, можно и нужно брать девочку с соответствующей зарплатой (хотя все же девочку с мозгами; девочка без мозгов -- это секретарь-машинистка); у этого менеджера нет никакой ответственности, кроме исполнения формальной программы, данной ему в виде должностных обязанностей, а существенные решения (типа "пойти на уступки заказчику или нет?") принимает все равно не он (да, кстати, ты их принимаешь? тогда это меняет дело)
вот даже ты проговорился, что существенные решения типа "перейти на канбан" принимаешь не ты (хотя, конечно, ты можешь сильно повлиять; если говорить про канбан -- я бы кстати, как и ты, поосторожничал)
я не исключаю, что ты решил немного отдохнуть от борьбы с с++, не?
3. если б я была царицей... то все равно потребовал бы фичу "посмотреть коммиты", даже если мне это не нужно по работе
есть одна ответственная роль -- оценщик времени на разрботку; я специально говорю не должность, а роль, т.к. ее можно цеплять на разные должности
ОтветитьУдалитьдля этой роли инфа о прошлых проектах (дабы поискать аналогичные) в виде диаграммы ганта с проставленными цикломатической сложностью и т.п. была бы полезна, не?
еще одна ответственная роль -- понять, что хочет заказчик (а-ля твоя задачка про лицензию не в начале файла); тут и правда можно на тексты коммитов не смотреть, но я категорически отказываюсь называть человека, исполняющую эту роль, "менеджером"
ОтветитьУдалитьs/исполняющую/исполняющего/
ОтветитьУдалить@имя
ОтветитьУдалитьПонятие менеджер - это слишном расплывчатое понятие. Например, менеджер проекта - это одна роль. Начальник отдела - совсем другая. Хотя это две менеджерские должности. Я не управляющий конкретными проектами, а пытаюсь навести порядок в оркестре из нескольких подразделений, работающих над разными проектами. Одна из задач при этом - это сохранение некоторой генеральной линии развития имеющихся у нас продуктов. Если этого не делать, то ПМы быстренько раздербанят имеющуюся кодовую базу не кучу несовместимых между собой кастомных решений. С такой ролью никакая хорошо полученная методам планирования и управления проектами девочка не справится. Тут опыт проектирования и разработки за спиной нужен.
Недавно мне рассказали историю про молоденькую девушку ПМа, которая в компании по внедрению, если не ошибаюсь, систем хранения данных, управляла двухстами проектами одновременно! Именно потому, что управление заключалось в засечке контрольных точек и инициировании дальнейших стандартных шагов при их достижении.
ОтветитьУдалить> Если этого не делать, то ПМы быстренько раздербанят имеющуюся кодовую базу не кучу несовместимых между собой кастомных решений.
ОтветитьУдалитьага!!! я че-то такое подозревал