Жизненный цикл задач в Redmine для небольшой группы разработки. Наш опыт и полезные советы



    Думаю, эта статья должна помочь людям, которые впервые решили автоматизировать процесс трекания задач на базе Redmine в группе разработки программного обеспечения. В статье я расскажу о том, как этот процесс устроен у нас, какие новые поля для задачи мы завели и какие проблемы решают эти поля. Думаю, статья будет полезна широкому кругу лиц, на мой взгляд, настройка жизненного цикла задач эта работа под лозунгом «Очевидное — не очевидно».

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

    Начнем.

    Все начинается с того, что в один прекрасный момент появляется задача и после своего появления, задача логично должна упасть на автора. Почему?! Потому что у задачи всегда должен быть сотрудник, который отвечает за дальнейшее ее исполнение, тот, кто в данный момент тормозит задачу, тот на чей стороне «мячик», и он должен этот мячик «передать другому», сделать что-то вроде футбольного паса. Иногда этого человека быть не должно. Например, когда больше нет необходимости выполнять действия по задаче, когда она закрыта.

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

    Ну понятно, это тип задания, заголовок и описание, но еще:

    • «Заказчик» – тот сотрудник который заинтересован в данной задаче и запросил ее исполнения. Он же будет впоследствии проверять результат работ, и оценивать исполнение.
    • «Цель» – конечная цель, которую должна решить задача. До этого поля мы не сразу дошли. С одной стороны, зачем нужна цель, если есть подробное описание, в котором написано, что сделать?! Но если подумать, то цель это совсем другое. Описание задачи говорит о том, что нужно сделать, чтобы достигнуть цели и если цель не фиксировать, то в процессе выполнения задачи, цель может потеряться, и сделается не совсем то и не совсем так, как нужно.



    Например, цель может быть такой:
    «Реализовать возможность расчёта базовой части ЗП на основе произвольной математической формулы».

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

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

    Куда может отправиться новая задача?

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

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

    Если задача отправляется в план, то мы обязательно просим заполнить у нее следующие поля:

    • «Оценка времени» – сколько, по мнению руководителя разработки, данная задача займет чистого времени работы программиста. Практически никогда нельзя точно определить это значение. Но нужно определять примерно. Потому что это время — на самом деле цена вопроса, т.е. это не время, это деньги, за которые заказчик покупает исполнение этой задачи у группы разработки.
    • Дату начала и дату выполнения. Тут вроде все логично. Еще у нас, когда программист необоснованно просаживает задачку по срокам, то у него это влияет на ЗП.
    • «Этап» – тот же план или версия или спринт, в который планируется выполнить задачу. У нас этапы совпадают с месяцами. По этапам и исполнителям мы контролируем ход выполнения работ.
    • «На ком» – сотрудник ответственный за исполнение задания.



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

    А если в очередь, то полей меньше:
    • «Приоритет», что бы потом из очереди первыми вытягивать более приоритетные задачи.
    • «Оценка времени», что бы можно было определиться, что влезет в будущий план, а что нет.

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

    Что исполнитель может сделать с задачей?

    Две спорные, но имеющие право на жизнь функции: «приступить» и «приостановить», которые соответственно меняют статус задачи из «Назначено» в «В работе» и наоборот. В малых группах эта функция не особо прижилась, а в некоторых больших прижилась. Если программистов много и они помечают задачи, которые исполняют в текущий момент, то можно строить срез по тем задачам, которые в текущий момент в работе у исполнителей (своего рода «Work in Progress»).

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

    Конечно главная функция для исполнителя это возможность отправки задачи на проверку и одноимённая кнопка «На проверку». Кнопка отправляет задачу тестировщику, что должен заполнить программист:

    • Поле «Как проверить» – удивительно простая и полезная вещь. Про это поле я впервые прочел в какой-то книжке по «Scrum». Программист, сдавая задачу на проверку, должен написать тестировщику и конечному заказчику, что нужно сделать, что бы воспользоваться новыми возможностями: какую ветку из репозитория взять, какие настройки сделать, куда пойти в интерфейсе и что потыкать. В результате, уходит масса ненужных вопросов у тестировщика, заказчика и руководителя группы.
    • Поле «Что сделано». Программист не всегда делает то, что первоначально написано в описании к задаче. Иногда делает что-то дополнительно, иногда программисту дается свобода действий в исполнении. Через это поле программист сообщает руководителю, заказчику и тестировщику, что конкретно он сделал в результате выполнения. Помимо прочего, у нас внедрена денежная мотивация на основе оценок задач заказчиком и в этом поле программист может обратить дополнительное внимание заказчика на особенности выполнения задачи, которые могут привести к повышенной оценке.
    • Поле «На ком» – тестировщик, который будет проверять задачу.
    • Галочка «Я выложил задачу на тестовый сервер». Без заполнения этого поля нельзя отправить задачку на проверку. У тестировщика есть свой тестовый сервер для проверки задач, но прежде чем скидывать задачу на проверку программист должен выложить ее в рабочем состоянии на тестовый сервер. Прежде всего, для того что бы руководитель смог оценить качество исполнения задачи и ему не приходилось лишний раз просить выложить задачу на тестовый сервер или делать это самому.



    После отправки задачи на проверку, ее статус логично изменяется на «На проверке». Теперь за дальнейшее исполнение задачи отвечает тестировщик.

    Что тестировщик может сделать с задачей?

    Ну, понятно: отправить задачку на доработку (кнопка «Вернуть обратно») или пропустить дальше на production-сервер (кнопка «Проверено»).

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

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

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

    • «Оценка проверки» и «Пояснение к оценке проверке». Оценку может ставить тестеровщик или руководитель. Эта оценка позволяет влиять на ЗП программиста, в том числе.
    • «Желаемая дата выкладки». Когда было бы здорово выложить задачку на production-сервер (за выкладку в нашей группе отвечает отдельный человек).
    • «Требует оповещения». Требуется ли оповещать сотрудников о доступности нового функционала или чем-то еще. Если требуется, то тестеровщик обязан сделать это перед выкладкой.
    • «Презентация». Когда задача будет презентована заказчикам (эта интересная процедура, но о ней в другой статье расскажу).



    Еще есть куча галочек для проверки перед отправкой задачи в рабочую среду. Перечислю их, вдруг кому-то будет полезно:
    • Я проверила отсутствие рекурсивных и циклических SQL-запросов через RaсkMiniProfiler.
    • Я проверила верстку на различных разрешениях браузера.
    • Я проверила верстку и работоспособность в различных браузерах последних версий (Chrome, Firefox, Opera, Intenet Explorer).
    • Я проверила работоспособность плагина на различных базах данных (MS SQL server, MariaDB, PostgreeSQL).
    • Я проверила исполнение задания на соответствие фундаментальным правилам «Фундаментальные правила написания плагинов к «Redmine»».
    • Я проанализировала необходимость оповещения сотрудников холдинга. Отметила необходимость оповещения в задаче.
    • Я проанализировала необходимость обновления информации в инструкциях (в случае необходимости завела задачу).
    • Задача выложена на тестовый сервер.
    • Заведены задачи на написание автотестов.

    Вот такая вот не простая процедура проверки.

    Что может сделать с задачей администратор Redmine?

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

    Что может сделать с задачей заказчик?

    Заказчик может принять работу или не принять. Если не принял, то он отправляет задачу на перепроверку тестеровщику, написав комментарий. Если принял, то жмет кнопочку «Выполнено» и проставляет оценку выполнения и пояснение к оценке. Эти оценки влияют на ЗП исполнителя и руководителя.


    В совокупности получается вот такая вот схема жизненного цикла задачи.



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

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

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

    Спасибо всем кто дочитал до конца.
    Поделиться публикацией
    Комментарии 32
      +3
      Меня всегда «убивали» комментарии, в духе: «Спасибо, огромное! Как раз собирались начать использование <сабж поста>!». Но вот это случилось и со мной — и сказать-то больше нечего. В общем, спасибо огромное! Как раз рассматриваем перспективу работы на Редмайн, и данный пост очень кстати.
        +2
        Рад, что статья оказалась полезной. Когда писал, то терзался мыслью, что многие и без меня все это знают.
          0
          Как правило если человек занимается созидательной деятельностью, через некоторое время оказывается что он может научить чему-то полезному того, кто это не знает. На этом весь хабр держится имхо. Ведь дают же в тестах ответ типа «ваш результат лучше чем у 65% участников» — значит эти 65% могут почерпнуть от вас что-то новое.
            0
            С этим сложно не согласится
              0
              Понятное дело что есть и исключения ) Спасибо за статью, как раз внедряем похожий механизм
        0
        У Вас просто замечательная реализация. Доработками редмайн сами занимались или использовали готовые плагины?
          +2
          Мы все сами делаем. Мы занимаемся разработкой корпоративной среды на базе Redmine. Отказались практически от всех сторонних плагинов. Исключение DMSF.
            +2
            То есть «простому» пользователю не добиться такого функционала методом «ставим redmine, настраиваем через web-интерфейс и подключаем общедоступные плагины»? Или все-таки что-то из описанного в статье сделать можно?
              0
              Почти все можно настроить и в стандартном Redmine, но будет не так удобно настраивать и конечному пользователю тоже будет не очень удобно, не будет кнопок и многих других элементов интерфейса. Но суть статьи в принципах трекания задачки. Какие поля на какой стадии просить заполнять и т.д.

              В Redmine для редактирования задачи есть одна ссылочка «обновить», после ее нажатия открывается форма редактирования задачи. Можно задать права на обновление определенных полей, но акцентированного действия настроить не получится.
                +1
                Перепробовав несколько платных и бесплатных систем управления проектами в нашей маленькой компании, остановились на Redmine. Используем стандартные плагины, все довольны.
                Если у вас в компании такие же сложные связи задач и людей, то, в конечном итоге, можно будет дописать самим под свои требования, но для старта и успешного использования «из коробки» фукнционала хватит.
            0
            Кстати дополню, что возможно достаточно быстро установить замечательную систему Redmine на win, linux, osx с помощью Bitnami Redmine Installers
              0
              Про установку писал в своей первой статье habrahabr.ru/company/monandco/blog/198496/
                +1
                Как вы заставляете заказчика внятно формулировать «Цель»?
                  0
                  Чуть ниже ответил (по ошибке)
                  0
                  Как вы заставляете заказчика оценить работу и написать осмысленный отзыв? Он для каждой мелкой задачи должен это делать? А если не сделает?
                    +1
                    Как вы заставляете заказчика оценить работу и написать осмысленный отзыв? Он для каждой мелкой задачи должен это делать? А если не сделает?

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

                    Во-первых, у нас административно это закреплено. В правилах использования Redmine,

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

                    Сложнее с адекватностью пояснений к оценке было. Народ просто ставил Плохо и пробел в пояснении. Это побороли административно, добавили такой пункт в правила:

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

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

                    Он для каждой мелкой задачи должен это делать?

                    Да. Для каждой в которой он заказчик. Но он может ставить оценку «Хорошо», не давая пояснений
                    0
                    Цель в задаче указывает не заказчик, а руководитель проекта. Заказчик у нас как правило пишет заявку в которой, как может, указывает свои хотелки. Потом руководитель на основе заявки создает задачу, при этом заявка связана с задачей и исполнитель всегда может посмотреть исходную заявку.

                    Как руководитель определяет цель? Это во многом от заказчика зависит. Есть адекватные активные заказчики, которые знают чего хотят и могут изложить это доступным языком. Есть неадекватные.

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

                    На этой стадии некоторые задачки самоликвидируются. Если нет, то я своими словами говорю как я его понял и спрашиваю правильно или нет? Пото сразу фиксирую все это в задаче.

                    С объемными задачами, в которых несколько ключевых заказчиков все сложнее.
                      +3
                      У вас процесс-центричный подход. Переходы в очередной статус возможны только пройдя все предыдущие. В моей практике, было гораздо удобнее сделать роле-центричный, когда можно было за одно действие перевести задачу в любой доступный статус, если у тебя есть на это права.
                      Например, пошла у вас задача в работу, и решено ее закрыть. Как это сделать? Идти обратно по всем стадиям? Неудобно. То же самое, если нужно сделать доработки по результатам тестирования.

                      Это же касается и количества статусов. Они разрастаются, а смысла реального не дают.
                      Для отдела из 30 человек вполне достаточно следующего:

                      1. Новая
                      2. Готово к работе
                      3. Разработка
                      4. Тестирование
                      5. Закрыто

                      Статусы — накопители типа «проверена» являются вредными. Тестировщик может в него скидывать задачи, но они там будут отмокать любое время прежде чем пойти в продакшен. Иногда такая задержка может достигать месяца и более. Нет, после тестирования задача должна идти в разработку на общих основаниях, и как можно раньше. Разработчик ее и увидит сразу и не будет терять контекст за счет длительного ожидания. Особенно хорошо сюда ложится канбан, когда есть лимит задач в определенном статусе по каждому исполнителю.
                        +1
                        У вас процесс-центричный подход. Переходы в очередной статус возможны только пройдя все предыдущие. В моей практике, было гораздо удобнее сделать роле-центричный, когда можно было за одно действие перевести задачу в любой доступный статус, если у тебя есть на это права.


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

                        Если бы я все переходы показал, то картинка была бы такой :)



                        Про количество статусов, я частично разделяю ваше мнение. Но с другой стороны наши статусы появились не просто так. Думаю, конкретно для нашей среды, в них все таки есть смысл.
                          +1
                          По поводу скачков понятно.

                          А вот по количеству оценить просто. Введите метрику — среднее время исполнения задачи, от взятия в работу до выкладки на бой. Обычно это довольно хороший показатель забюрократизированности процесса, если отнормировать по трудоемкости. И потом проведите эксперимент с разными воркфлоу. С точки зрения теории, любые излишние элементы системы будут снижать ее КПД и повышать бюрократическое трение. С точки зрения моей практики это подтверждается (я добивался повышения скорости прохождения задач с месяца до недели исключительно с помощью оптимизации рабочего процесса).
                            0
                            По поводу скачков понятно.

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


                            Благодарю за совет. Планировали сделать метрики, но немного по другому. Сколько и в каком статусе и на ком проживает задача, что бы можно было отчеты строить: на ком скапливаются задачи и в каком статусе скапливаются задачи. Что бы в любом жизненном цикле (у нас их много) можно было анализировать узкие места.
                        0
                        Интересная и познавательная статья. Мы тоже используем у себя связку redmine+gitlab, но несколько с другим подходом. Кому интересно, подробнее можно прочитать вот тут: blog.ksdaemon.ru/2014/02/v-poiskakh-optimalnykh-sredstv-soprovozhdeniya-razrabotki-chast-tretya-schaste-blizko/

                        Понравилась идея с «Как проверить». Но у нас основополагающий документ — это ТЗ. И соответственно, тестировщики проверяют продукт на соответствие ТЗ. И если это не так — то или правится ТЗ под существующие реалии, либо правится софт, чтобы соответствовал ТЗ. Кстати, именно по ТЗ, тестировщики пишут тест-кейсы, которые так же фигурируют в задачах/багах.
                          +1
                          Кстати, вопрос: как вы учитываете вопрос временных трудозатрат? Одно дело, это оценка времени выполнения задачи постановщиком (менеджером, или ведущим разработчиком), другое — что скажет конечный исполнитель? И опять же, очень хочется понимать, сколько реально времени тратится на те или иные задачи, чтобы накапливать статистику и в дальнейшем иметь возможность пользоваться ей для более точных (адекватных) прогнозов. Есть возможность указывать временные трудозатраты прям в коммит-сообщениях, но даже это программисты нифига не делают. Да, можно требовать принудительно проставления, но это тоже не всегда верно/нужно…
                            +1
                            С логированием времени у нас ситуация следующая. Программист должен логировать время в задаче. К концу месяца руководитель проводит анализ соответствия плановых часов залогированным программиста и на свое усмотрение может изменить или нет плановые часы. Плановые часы напрямую влияют на ЗП программиста (вот такой вот flexible price).

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

                            Есть возможность указывать временные трудозатраты прям в коммит-сообщениях, но даже это программисты нифига не делают. Да, можно требовать принудительно проставления, но это тоже не всегда верно/нужно…


                            У нас кнопка настроена для быстрого логирования времени. Проблем с логированием нет поскольку это напрямую влияет на ЗП программиста.

                            +1
                            Хороший пример и антипример одновременно. Редмайн очень ценю, в свое время активно продвигал его использование на прошлой работе.
                            Выделение отдельных полей под специфику бизнеса можно только приветствовать, автоматизация основных шагов — типичная и абсолютно правильная доработка редмайна.
                            Теперь о дегте: самое плохое — задача с заголовком «Доработки» не должна существовать в принципе.
                            Причины:
                            1. Заголовок должен отражать цель задачи (насколько это возможно в одной строке)
                            2. Задача должна отвечать критерию завершимости
                            3. Результат выполнения задачи должен содержаться в ее статусе
                            «Доработки» в этом смысле никуда не годятся. Целью они не являются, могут не завершаться годами. Так можно назвать большой, динамически изменяемый набор задач, что и произошло: в описании указано несколько слабо связанных друг с другом подпунктов, которые де-факто являются отдельными задачами. Только их статус уже нельзя отследить из списка задач в редмайне — все похоронено в недрах задачи «Доработки». И боже упаси, если по ходу выполнения список будет меняться.
                            Граф переходов велик и страшен — если нужна скорость, то можно сделать автоматический переход по статусам (с соответствующей записью в историю), а вот ввод прямых переходов куда угодно — костыль.
                            Статусы «В очереди» и «Назначена» не имеют смысла — это не статусы самой задачи, а привязка ее к конкретной итерации и исполнителю. «Обратная связь» — не статус, а независимый флаг, показывающий, что задача заморожена в текущем статусе из-за недостатка информации.
                            Также может помочь выделение подстатусов со своими графами переходов.
                            Приоритеты в свое время переименовал вот так:
                            1. Немедленно — исполнитель должен буквально бросить все и делать прямо сейчас.
                            2. Срочно — делается в указанной итерации в первую очередь
                            3. Обязательно — должно быть сделано в указанной итерации
                            4. Желательно — хорошо бы сделать в текущей итерации, но предполагается возможность переноса на следующую
                            Других градаций не нужно — если ниже «желательно», то просто переносится в другую итерацию и ставится приоритет уже для нее. Названия приоритетов говорящие.
                            Исполнительно из списка задач берет максимально приоритетную.
                            Поля затрат времени желательно заполнять автоматически с возможность корректировки сотрудником.
                            «Плановые часы напрямую влияют на ЗП программиста»
                            А вот это плохо — стимулирует фальсификацию, да и наказывают рублем отнюдь не планирующего.
                              0
                              Теперь о дегте: самое плохое — задача с заголовком «Доработки» не должна существовать в принципе.


                              Соглашусь на 80% процентов. Большого количества таких задач быть конечно не должно. У нас для этого даже пункт в правилах есть:

                              Заголовки в сущностях (задачах, заявках и т.д.) должны отражать краткую суть проблемы, описанной в содержании сущности.
                              Заголовок должен быть кратким, но информативным. Например: “Проблема с расчетом ЗП. Фактические часы не соответствуют действительности в сводном отчете о ЗП”.

                              У нас некоторые задачи формируются из заявок сотрудников. Сотрудники скопом указывают кучку мелких доделок. Не всегда правильно с точки зрения экономии собственного времени бить хотелки сотрудников на задачи.

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


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

                              Статусы «В очереди» и «Назначена» не имеют смысла — это не статусы самой задачи, а привязка ее к конкретной итерации и исполнителю. «Обратная связь» — не статус, а независимый флаг, показывающий, что задача заморожена в текущем статусе из-за недостатка информации.

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

                              Приоритеты в свое время переименовал вот так:
                              1. Немедленно — исполнитель должен буквально бросить все и делать прямо сейчас.
                              2. Срочно — делается в указанной итерации в первую очередь
                              3. Обязательно — должно быть сделано в указанной итерации
                              4. Желательно — хорошо бы сделать в текущей итерации, но предполагается возможность переноса на следующую

                              У нас немного по другому, но тоже имеет право на жизнь, мне кажется:

                              Срок решения заявки зависит от приоритета. Автор заявки обязан максимально точно определить ее приоритет. Для определения приоритета необходимо пользоваться следующим набором правил:
                              • Заявка со срочным приоритетом требует решения в течение суток.
                              • Заявка с высоким приоритетом выполняются в течение текущего месяца.
                              • Заявка с нормальным приоритетом выполняется в порядке очереди после высоких.
                              • Заявка с низким приоритетом выполняется в порядке очереди после нормальных.

                              «Плановые часы напрямую влияют на ЗП программиста»
                              А вот это плохо — стимулирует фальсификацию, да и наказывают рублем отнюдь не планирующего.


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

                              В целом, спасибо за отзыв. Он был очень полезным.
                              0
                              Благодаря вашим комментариям и заметкам убедился, что redmine гораздо эффективнее с административными правилами, которые формируют нужный workflow. Мне было бы интересно развитие этой темы в дальнейших статьях. Спасибо за изложение своего опыта!
                                0
                                Думаю, про Redmine будет еще много статей. Про жизненный цикл, тоже планирую написать еще одну статью.
                                0
                                У тестировщика есть свой тестовый сервер для проверки задач, но прежде чем скидывать задачу на проверку программист должен выложить ее в рабочем состоянии на тестовый сервер.

                                Каким образом программист узнает, свободен ли этот тестовый сервер, и не тестирует ли на нем сейчас кто-то свои задачи? Постоянно спрашивает у тестировщика? Просто у нас были постоянные проблемы с этим: программистов несколько, а тестировщик один. В результате в общем чате постоянные вопросы типа «Стейджинг свободен?! Занимаю!» и т.п. А если тестировщик в данный момент занят, то вообще непонятно что: программист переходит к следующему таску, а данный таск «подвисает» в неком статусе «ожидает тестирования»… В общем, как-то нам это сложно показалось. У вас с этим как?
                                  0
                                  Если рабочее окружение не слишком громоздкое можно развернуть несколько серверов для тестирования.
                                    0
                                    У нас было три стейджинга на 1 тестировщика :) Потом маразм прошел и мы поняли, что все-равно один тестировщик в один момент времени использует только один сервер. Остальные два оставили для просмотра реквестерам фич. Но проблема одного тестового сервера на несколько готовых фич осталась.
                                    0
                                    У меня в отделе 1 тестировщик и два программиста (мы стараемся не разращивать штат :) ).

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

                                    У нас проблем с доступом к тестовому серверу нет, как вы понимаете :)

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

                                  Самое читаемое