Комментарии 2
Спасибо за толковую методичку, кое что из вашего списка сам внедрял, до других вещеё руки так и не дошли.
В который раз убеждаюсь, что нельзя держать информацию при себе, даже если кажется, что это всем давно уже известно и очевидно.
Вроде бы статья о совершенно простых и понятных вещах, которые, казалось бы, «даже у нас» уже давно пройдены. А все равно, то тут, то там глаза цепляются за какое-то решение, за какую-то идею, которую можно попробовать.
Вот из вашей статьи выбрал для себя:
Вроде бы статья о совершенно простых и понятных вещах, которые, казалось бы, «даже у нас» уже давно пройдены. А все равно, то тут, то там глаза цепляются за какое-то решение, за какую-то идею, которую можно попробовать.
Вот из вашей статьи выбрал для себя:
- добавить статус on hold. У нас множество задач зависают в статусе «в работе» и это неудобно при анализе проекта. А статус «Отложено» используется все-таки в других ситуациях.
- по какой-то необъяснимой причине мы не переводим технический долг в задачи. пора создать проект для фиксации технического долга
- мы не используем скрам, скорее элементы канбана (подход к непрерывному улчшению, а не просто доска). в рамках этого подхода стендапы нужны только для того, чтобы обсудить проблемы, видимые на доске. не стоит тратить время на обсуждение того, что было сделано вчера. Ваша практика специального чата для трех вопросов может оказаться отличным решением! Так и заинтересованные лица будут видеть, кто чем занят без вчитывания в карточки на доске, так и время стендапов будет использоваться более продуктивно
- также статья вдохновила меня на идею: пора в дженкинс воткнуть задачу, которая при коммите будет проверять формат комментария. И если формат нарушен — стучать емейлом по голове разработчику и его руководителю. Соглашения на словах не работают :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Построение процессов с нуля: от хаоса к порядку