Комментарии 32
Меня всегда «убивали» комментарии, в духе: «Спасибо, огромное! Как раз собирались начать использование <сабж поста>!». Но вот это случилось и со мной — и сказать-то больше нечего. В общем, спасибо огромное! Как раз рассматриваем перспективу работы на Редмайн, и данный пост очень кстати.
Рад, что статья оказалась полезной. Когда писал, то терзался мыслью, что многие и без меня все это знают.
Как правило если человек занимается созидательной деятельностью, через некоторое время оказывается что он может научить чему-то полезному того, кто это не знает. На этом весь хабр держится имхо. Ведь дают же в тестах ответ типа «ваш результат лучше чем у 65% участников» — значит эти 65% могут почерпнуть от вас что-то новое.
У Вас просто замечательная реализация. Доработками редмайн сами занимались или использовали готовые плагины?
Мы все сами делаем. Мы занимаемся разработкой корпоративной среды на базе Redmine. Отказались практически от всех сторонних плагинов. Исключение DMSF.
То есть «простому» пользователю не добиться такого функционала методом «ставим redmine, настраиваем через web-интерфейс и подключаем общедоступные плагины»? Или все-таки что-то из описанного в статье сделать можно?
Почти все можно настроить и в стандартном Redmine, но будет не так удобно настраивать и конечному пользователю тоже будет не очень удобно, не будет кнопок и многих других элементов интерфейса. Но суть статьи в принципах трекания задачки. Какие поля на какой стадии просить заполнять и т.д.
В Redmine для редактирования задачи есть одна ссылочка «обновить», после ее нажатия открывается форма редактирования задачи. Можно задать права на обновление определенных полей, но акцентированного действия настроить не получится.
В Redmine для редактирования задачи есть одна ссылочка «обновить», после ее нажатия открывается форма редактирования задачи. Можно задать права на обновление определенных полей, но акцентированного действия настроить не получится.
Перепробовав несколько платных и бесплатных систем управления проектами в нашей маленькой компании, остановились на Redmine. Используем стандартные плагины, все довольны.
Если у вас в компании такие же сложные связи задач и людей, то, в конечном итоге, можно будет дописать самим под свои требования, но для старта и успешного использования «из коробки» фукнционала хватит.
Если у вас в компании такие же сложные связи задач и людей, то, в конечном итоге, можно будет дописать самим под свои требования, но для старта и успешного использования «из коробки» фукнционала хватит.
Кстати дополню, что возможно достаточно быстро установить замечательную систему Redmine на win, linux, osx с помощью Bitnami Redmine Installers
Про установку писал в своей первой статье habrahabr.ru/company/monandco/blog/198496/
Как вы заставляете заказчика внятно формулировать «Цель»?
Как вы заставляете заказчика оценить работу и написать осмысленный отзыв? Он для каждой мелкой задачи должен это делать? А если не сделает?
Как вы заставляете заказчика оценить работу и написать осмысленный отзыв? Он для каждой мелкой задачи должен это делать? А если не сделает?
С этим проблемы и тут опять же все зависит от адекватности заказчика, но не только.
Во-первых, у нас административно это закреплено. В правилах использования Redmine,
Во-вторых, технически, если заказчик вообще не поставит оценок, то он сам ЗП не получит и система проинформирует его руководителя в момент закрытия его ЗП о том, что подчиненный не выставил оценок исполнителям и его ЗП нельзя закрыть. Такая мера очень помогла в свое время.
Сложнее с адекватностью пояснений к оценке было. Народ просто ставил Плохо и пробел в пояснении. Это побороли административно, добавили такой пункт в правила:
Строго запрещено:
— проставлять оценки не вникая в суть и смысл показателей, по которым ставятся оценки;
— ставить оценки отличные от «хорошо», не давая подробного пояснения причин снижения или повышения оценки
Плюс, у нас действует сквозная система жалоб и похвалы. Каждый может пожаловаться на любого за несоблюдения правил использования Redmine, например, или других приказов. Руководитель, сотрудника на которого жалуются, получает эти сообщения в момент расчета ЗП и может принять их во внимание, снизить оценку.
Он для каждой мелкой задачи должен это делать?
Да. Для каждой в которой он заказчик. Но он может ставить оценку «Хорошо», не давая пояснений
Цель в задаче указывает не заказчик, а руководитель проекта. Заказчик у нас как правило пишет заявку в которой, как может, указывает свои хотелки. Потом руководитель на основе заявки создает задачу, при этом заявка связана с задачей и исполнитель всегда может посмотреть исходную заявку.
Как руководитель определяет цель? Это во многом от заказчика зависит. Есть адекватные активные заказчики, которые знают чего хотят и могут изложить это доступным языком. Есть неадекватные.
Во втором случае, я иду к заказчику лично и прошу его объяснить мне на пальцах чего ему не хватает. Прошу что бы он рассказывал мне не то, что нужно сделать в redmine, а то чего сделать сейчас не может и почему? Если это не помогает, то прошу его в Redmine начать что-либо делать и прошу сказать когда не удобно будет.
На этой стадии некоторые задачки самоликвидируются. Если нет, то я своими словами говорю как я его понял и спрашиваю правильно или нет? Пото сразу фиксирую все это в задаче.
С объемными задачами, в которых несколько ключевых заказчиков все сложнее.
Как руководитель определяет цель? Это во многом от заказчика зависит. Есть адекватные активные заказчики, которые знают чего хотят и могут изложить это доступным языком. Есть неадекватные.
Во втором случае, я иду к заказчику лично и прошу его объяснить мне на пальцах чего ему не хватает. Прошу что бы он рассказывал мне не то, что нужно сделать в redmine, а то чего сделать сейчас не может и почему? Если это не помогает, то прошу его в Redmine начать что-либо делать и прошу сказать когда не удобно будет.
На этой стадии некоторые задачки самоликвидируются. Если нет, то я своими словами говорю как я его понял и спрашиваю правильно или нет? Пото сразу фиксирую все это в задаче.
С объемными задачами, в которых несколько ключевых заказчиков все сложнее.
У вас процесс-центричный подход. Переходы в очередной статус возможны только пройдя все предыдущие. В моей практике, было гораздо удобнее сделать роле-центричный, когда можно было за одно действие перевести задачу в любой доступный статус, если у тебя есть на это права.
Например, пошла у вас задача в работу, и решено ее закрыть. Как это сделать? Идти обратно по всем стадиям? Неудобно. То же самое, если нужно сделать доработки по результатам тестирования.
Это же касается и количества статусов. Они разрастаются, а смысла реального не дают.
Для отдела из 30 человек вполне достаточно следующего:
1. Новая
2. Готово к работе
3. Разработка
4. Тестирование
5. Закрыто
Статусы — накопители типа «проверена» являются вредными. Тестировщик может в него скидывать задачи, но они там будут отмокать любое время прежде чем пойти в продакшен. Иногда такая задержка может достигать месяца и более. Нет, после тестирования задача должна идти в разработку на общих основаниях, и как можно раньше. Разработчик ее и увидит сразу и не будет терять контекст за счет длительного ожидания. Особенно хорошо сюда ложится канбан, когда есть лимит задач в определенном статусе по каждому исполнителю.
Например, пошла у вас задача в работу, и решено ее закрыть. Как это сделать? Идти обратно по всем стадиям? Неудобно. То же самое, если нужно сделать доработки по результатам тестирования.
Это же касается и количества статусов. Они разрастаются, а смысла реального не дают.
Для отдела из 30 человек вполне достаточно следующего:
1. Новая
2. Готово к работе
3. Разработка
4. Тестирование
5. Закрыто
Статусы — накопители типа «проверена» являются вредными. Тестировщик может в него скидывать задачи, но они там будут отмокать любое время прежде чем пойти в продакшен. Иногда такая задержка может достигать месяца и более. Нет, после тестирования задача должна идти в разработку на общих основаниях, и как можно раньше. Разработчик ее и увидит сразу и не будет терять контекст за счет длительного ожидания. Особенно хорошо сюда ложится канбан, когда есть лимит задач в определенном статусе по каждому исполнителю.
У вас процесс-центричный подход. Переходы в очередной статус возможны только пройдя все предыдущие. В моей практике, было гораздо удобнее сделать роле-центричный, когда можно было за одно действие перевести задачу в любой доступный статус, если у тебя есть на это права.
Нет! У нас конечно можно прыгать между статусами. Просто я в статье описал общую картинку движения задачи. Если на схемку взглянете из статьи то увидите, что там переходов больше чем описано в статье. Это как раз и есть скачки между статусами. В основном они есть у руководителя, но и у тестеровщика тоже могут быть.
Если бы я все переходы показал, то картинка была бы такой :)
Про количество статусов, я частично разделяю ваше мнение. Но с другой стороны наши статусы появились не просто так. Думаю, конкретно для нашей среды, в них все таки есть смысл.
По поводу скачков понятно.
А вот по количеству оценить просто. Введите метрику — среднее время исполнения задачи, от взятия в работу до выкладки на бой. Обычно это довольно хороший показатель забюрократизированности процесса, если отнормировать по трудоемкости. И потом проведите эксперимент с разными воркфлоу. С точки зрения теории, любые излишние элементы системы будут снижать ее КПД и повышать бюрократическое трение. С точки зрения моей практики это подтверждается (я добивался повышения скорости прохождения задач с месяца до недели исключительно с помощью оптимизации рабочего процесса).
А вот по количеству оценить просто. Введите метрику — среднее время исполнения задачи, от взятия в работу до выкладки на бой. Обычно это довольно хороший показатель забюрократизированности процесса, если отнормировать по трудоемкости. И потом проведите эксперимент с разными воркфлоу. С точки зрения теории, любые излишние элементы системы будут снижать ее КПД и повышать бюрократическое трение. С точки зрения моей практики это подтверждается (я добивался повышения скорости прохождения задач с месяца до недели исключительно с помощью оптимизации рабочего процесса).
По поводу скачков понятно.
А вот по количеству оценить просто. Введите метрику — среднее время исполнения задачи, от взятия в работу до выкладки на бой. Обычно это довольно хороший показатель забюрократизированности процесса, если отнормировать по трудоемкости. И потом проведите эксперимент с разными воркфлоу. С точки зрения теории, любые излишние элементы системы будут снижать ее КПД и повышать бюрократическое трение. С точки зрения моей практики это подтверждается (я добивался повышения скорости прохождения задач с месяца до недели исключительно с помощью оптимизации рабочего процесса).
Благодарю за совет. Планировали сделать метрики, но немного по другому. Сколько и в каком статусе и на ком проживает задача, что бы можно было отчеты строить: на ком скапливаются задачи и в каком статусе скапливаются задачи. Что бы в любом жизненном цикле (у нас их много) можно было анализировать узкие места.
Интересная и познавательная статья. Мы тоже используем у себя связку redmine+gitlab, но несколько с другим подходом. Кому интересно, подробнее можно прочитать вот тут: blog.ksdaemon.ru/2014/02/v-poiskakh-optimalnykh-sredstv-soprovozhdeniya-razrabotki-chast-tretya-schaste-blizko/
Понравилась идея с «Как проверить». Но у нас основополагающий документ — это ТЗ. И соответственно, тестировщики проверяют продукт на соответствие ТЗ. И если это не так — то или правится ТЗ под существующие реалии, либо правится софт, чтобы соответствовал ТЗ. Кстати, именно по ТЗ, тестировщики пишут тест-кейсы, которые так же фигурируют в задачах/багах.
Понравилась идея с «Как проверить». Но у нас основополагающий документ — это ТЗ. И соответственно, тестировщики проверяют продукт на соответствие ТЗ. И если это не так — то или правится ТЗ под существующие реалии, либо правится софт, чтобы соответствовал ТЗ. Кстати, именно по ТЗ, тестировщики пишут тест-кейсы, которые так же фигурируют в задачах/багах.
Кстати, вопрос: как вы учитываете вопрос временных трудозатрат? Одно дело, это оценка времени выполнения задачи постановщиком (менеджером, или ведущим разработчиком), другое — что скажет конечный исполнитель? И опять же, очень хочется понимать, сколько реально времени тратится на те или иные задачи, чтобы накапливать статистику и в дальнейшем иметь возможность пользоваться ей для более точных (адекватных) прогнозов. Есть возможность указывать временные трудозатраты прям в коммит-сообщениях, но даже это программисты нифига не делают. Да, можно требовать принудительно проставления, но это тоже не всегда верно/нужно…
С логированием времени у нас ситуация следующая. Программист должен логировать время в задаче. К концу месяца руководитель проводит анализ соответствия плановых часов залогированным программиста и на свое усмотрение может изменить или нет плановые часы. Плановые часы напрямую влияют на ЗП программиста (вот такой вот flexible price).
Во время планирования задач мы проводим обсуждение и коллегиально решаем сколько в часах стоит та или иная задача. В последний раз проводили Planning pocker. Планируем делать это и в будущем.
У нас кнопка настроена для быстрого логирования времени. Проблем с логированием нет поскольку это напрямую влияет на ЗП программиста.
Во время планирования задач мы проводим обсуждение и коллегиально решаем сколько в часах стоит та или иная задача. В последний раз проводили Planning pocker. Планируем делать это и в будущем.
Есть возможность указывать временные трудозатраты прям в коммит-сообщениях, но даже это программисты нифига не делают. Да, можно требовать принудительно проставления, но это тоже не всегда верно/нужно…
У нас кнопка настроена для быстрого логирования времени. Проблем с логированием нет поскольку это напрямую влияет на ЗП программиста.
Хороший пример и антипример одновременно. Редмайн очень ценю, в свое время активно продвигал его использование на прошлой работе.
Выделение отдельных полей под специфику бизнеса можно только приветствовать, автоматизация основных шагов — типичная и абсолютно правильная доработка редмайна.
Теперь о дегте: самое плохое — задача с заголовком «Доработки» не должна существовать в принципе.
Причины:
1. Заголовок должен отражать цель задачи (насколько это возможно в одной строке)
2. Задача должна отвечать критерию завершимости
3. Результат выполнения задачи должен содержаться в ее статусе
«Доработки» в этом смысле никуда не годятся. Целью они не являются, могут не завершаться годами. Так можно назвать большой, динамически изменяемый набор задач, что и произошло: в описании указано несколько слабо связанных друг с другом подпунктов, которые де-факто являются отдельными задачами. Только их статус уже нельзя отследить из списка задач в редмайне — все похоронено в недрах задачи «Доработки». И боже упаси, если по ходу выполнения список будет меняться.
Граф переходов велик и страшен — если нужна скорость, то можно сделать автоматический переход по статусам (с соответствующей записью в историю), а вот ввод прямых переходов куда угодно — костыль.
Статусы «В очереди» и «Назначена» не имеют смысла — это не статусы самой задачи, а привязка ее к конкретной итерации и исполнителю. «Обратная связь» — не статус, а независимый флаг, показывающий, что задача заморожена в текущем статусе из-за недостатка информации.
Также может помочь выделение подстатусов со своими графами переходов.
Приоритеты в свое время переименовал вот так:
1. Немедленно — исполнитель должен буквально бросить все и делать прямо сейчас.
2. Срочно — делается в указанной итерации в первую очередь
3. Обязательно — должно быть сделано в указанной итерации
4. Желательно — хорошо бы сделать в текущей итерации, но предполагается возможность переноса на следующую
Других градаций не нужно — если ниже «желательно», то просто переносится в другую итерацию и ставится приоритет уже для нее. Названия приоритетов говорящие.
Исполнительно из списка задач берет максимально приоритетную.
Поля затрат времени желательно заполнять автоматически с возможность корректировки сотрудником.
«Плановые часы напрямую влияют на ЗП программиста»
А вот это плохо — стимулирует фальсификацию, да и наказывают рублем отнюдь не планирующего.
Выделение отдельных полей под специфику бизнеса можно только приветствовать, автоматизация основных шагов — типичная и абсолютно правильная доработка редмайна.
Теперь о дегте: самое плохое — задача с заголовком «Доработки» не должна существовать в принципе.
Причины:
1. Заголовок должен отражать цель задачи (насколько это возможно в одной строке)
2. Задача должна отвечать критерию завершимости
3. Результат выполнения задачи должен содержаться в ее статусе
«Доработки» в этом смысле никуда не годятся. Целью они не являются, могут не завершаться годами. Так можно назвать большой, динамически изменяемый набор задач, что и произошло: в описании указано несколько слабо связанных друг с другом подпунктов, которые де-факто являются отдельными задачами. Только их статус уже нельзя отследить из списка задач в редмайне — все похоронено в недрах задачи «Доработки». И боже упаси, если по ходу выполнения список будет меняться.
Граф переходов велик и страшен — если нужна скорость, то можно сделать автоматический переход по статусам (с соответствующей записью в историю), а вот ввод прямых переходов куда угодно — костыль.
Статусы «В очереди» и «Назначена» не имеют смысла — это не статусы самой задачи, а привязка ее к конкретной итерации и исполнителю. «Обратная связь» — не статус, а независимый флаг, показывающий, что задача заморожена в текущем статусе из-за недостатка информации.
Также может помочь выделение подстатусов со своими графами переходов.
Приоритеты в свое время переименовал вот так:
1. Немедленно — исполнитель должен буквально бросить все и делать прямо сейчас.
2. Срочно — делается в указанной итерации в первую очередь
3. Обязательно — должно быть сделано в указанной итерации
4. Желательно — хорошо бы сделать в текущей итерации, но предполагается возможность переноса на следующую
Других градаций не нужно — если ниже «желательно», то просто переносится в другую итерацию и ставится приоритет уже для нее. Названия приоритетов говорящие.
Исполнительно из списка задач берет максимально приоритетную.
Поля затрат времени желательно заполнять автоматически с возможность корректировки сотрудником.
«Плановые часы напрямую влияют на ЗП программиста»
А вот это плохо — стимулирует фальсификацию, да и наказывают рублем отнюдь не планирующего.
Теперь о дегте: самое плохое — задача с заголовком «Доработки» не должна существовать в принципе.
Соглашусь на 80% процентов. Большого количества таких задач быть конечно не должно. У нас для этого даже пункт в правилах есть:
Заголовки в сущностях (задачах, заявках и т.д.) должны отражать краткую суть проблемы, описанной в содержании сущности.
Заголовок должен быть кратким, но информативным. Например: “Проблема с расчетом ЗП. Фактические часы не соответствуют действительности в сводном отчете о ЗП”.
У нас некоторые задачи формируются из заявок сотрудников. Сотрудники скопом указывают кучку мелких доделок. Не всегда правильно с точки зрения экономии собственного времени бить хотелки сотрудников на задачи.
Граф переходов велик и страшен — если нужна скорость, то можно сделать автоматический переход по статусам (с соответствующей записью в историю), а вот ввод прямых переходов куда угодно — костыль.
Прямые переходы, есть в основном у руководителей подразделений. Это иногда спасает. Почему считаете что это костыль? К каким плохим последствиям это может привести?
Статусы «В очереди» и «Назначена» не имеют смысла — это не статусы самой задачи, а привязка ее к конкретной итерации и исполнителю. «Обратная связь» — не статус, а независимый флаг, показывающий, что задача заморожена в текущем статусе из-за недостатка информации.
На мой взгляд, это вопрос достаточно философский. У нас почти в каждом состоянии есть сотрудник ответственный за задачу. Когда задача уходит в запрос информации, например, то она меняет свой статус и значение поля «Назначено». В этот момент, ответственность за исполнение задачи лежит на сотруднике у которого информацию запрашивают. Выделение такого статуса помогает с фильтрацией и др.
Приоритеты в свое время переименовал вот так:
1. Немедленно — исполнитель должен буквально бросить все и делать прямо сейчас.
2. Срочно — делается в указанной итерации в первую очередь
3. Обязательно — должно быть сделано в указанной итерации
4. Желательно — хорошо бы сделать в текущей итерации, но предполагается возможность переноса на следующую
У нас немного по другому, но тоже имеет право на жизнь, мне кажется:
Срок решения заявки зависит от приоритета. Автор заявки обязан максимально точно определить ее приоритет. Для определения приоритета необходимо пользоваться следующим набором правил:
- Заявка со срочным приоритетом требует решения в течение суток.
- Заявка с высоким приоритетом выполняются в течение текущего месяца.
- Заявка с нормальным приоритетом выполняется в порядке очереди после высоких.
- Заявка с низким приоритетом выполняется в порядке очереди после нормальных.
«Плановые часы напрямую влияют на ЗП программиста»
А вот это плохо — стимулирует фальсификацию, да и наказывают рублем отнюдь не планирующего.
Про наши схемы денежной мотивации планирую написать в следующей статье. Это вопрос сложный и не однозначный, не имеющий правильного решения, на мой взгляд. Одно могу сказать, эффект от влияния плановых часов на работу программиста есть! Как положительный, так и отрицательны!
В целом, спасибо за отзыв. Он был очень полезным.
Благодаря вашим комментариям и заметкам убедился, что redmine гораздо эффективнее с административными правилами, которые формируют нужный workflow. Мне было бы интересно развитие этой темы в дальнейших статьях. Спасибо за изложение своего опыта!
У тестировщика есть свой тестовый сервер для проверки задач, но прежде чем скидывать задачу на проверку программист должен выложить ее в рабочем состоянии на тестовый сервер.
Каким образом программист узнает, свободен ли этот тестовый сервер, и не тестирует ли на нем сейчас кто-то свои задачи? Постоянно спрашивает у тестировщика? Просто у нас были постоянные проблемы с этим: программистов несколько, а тестировщик один. В результате в общем чате постоянные вопросы типа «Стейджинг свободен?! Занимаю!» и т.п. А если тестировщик в данный момент занят, то вообще непонятно что: программист переходит к следующему таску, а данный таск «подвисает» в неком статусе «ожидает тестирования»… В общем, как-то нам это сложно показалось. У вас с этим как?
Если рабочее окружение не слишком громоздкое можно развернуть несколько серверов для тестирования.
У меня в отделе 1 тестировщик и два программиста (мы стараемся не разращивать штат :) ).
Тестовых сервера у нас два, один общий, там мы проводим интеграционные тесты, которые пишут программисты (т.е. тестируем всю версию перед выкладкой)
У тестировщика есть свой сервер где он прогоняет UI-тесты, тестирует в том числе и бизнес логику, но на преднастроенном окружении (без зачистки БД и т.д.)
У нас проблем с доступом к тестовому серверу нет, как вы понимаете :)
Тестовых сервера у нас два, один общий, там мы проводим интеграционные тесты, которые пишут программисты (т.е. тестируем всю версию перед выкладкой)
У тестировщика есть свой сервер где он прогоняет UI-тесты, тестирует в том числе и бизнес логику, но на преднастроенном окружении (без зачистки БД и т.д.)
У нас проблем с доступом к тестовому серверу нет, как вы понимаете :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Жизненный цикл задач в Redmine для небольшой группы разработки. Наш опыт и полезные советы