Комментарии 17
Спасибо за статью! Данные правила можно перенести почти на любую проектную работу!
Резюмируя, причина неработающего стандартного SDLC в 2022 году в том, что не отважились поделиться информацией о проблемах с руководителями. Хорошо объясняет культуру и качество руководства в компании. Инструменты тут ничем не помогут.
Правило "Не делаем задачи с t > 60 минут без задачи в Jira." очень странное, без задачи в Jira даже на мелкие фиксы вы столкнетесь с тем, что вас будут обманывать в объеме этих задач, чтобы не возиться с Jira, плюс ваша аналитика объема спринта будет не точная из за эдхока, что напрямую влияет на ваш объем спринта при планировании.
Это сознательный отказ от документирования таких задач. Создалось впечатление, что это была уступка руководству, которое исторически привыкло относиться к ИТшникам как к обслуге, а не равноправным участникам создания добавленной стоимости. Гугление как метод решения такой проблемы, конечно, результата не даст. В общем, неоднозначная статья в блоге неоднозначной компании.
Алексей, спасибо за комментарий, такой риск действительно есть. Это компромиссное решение. Накапливаем статистику, смотрим динамику. Меняем подход при необходимости.
Спасибо за то, что поделились мнением!
На что планируете заменить Jira?
Посмотрите в сторону SAFe, но все равно придется менять процессы управления командами и согласования задач. Согласиться на определенный процент эдхока, начать планировать ключевые цели для компании и самое главное их достигать в процессе инкремента.
Ветки задач никогда не удаляются.
хотелось бы узнать аргументацию для такого требования
Очень полезная статья, спасибо автору.
Меня зовут Сергей, и я хочу очень кратко поделиться и нашим опытом (пока что я не хочу называть компанию, в которой работаю - извините). Некоторое время назад наша компания тоже решила изменить порядок ведения проектов и пойти по пути строго документирования разработок.
Мы используем связку YouTrack + GitLab. В YT созданы проекты для каждого из наших продуктов. Главной вехой в каждом проекте является своего рода спецификация требований в табличной форме, содержащая ссылки на истории пользователя, функциональные и нефункциональные требования, информацию о команде проекта, его ландшафте и информацию о доступах к стендам.
Дочерними вехами к главной вехе (да, вот так) идут предпроектное обследование, MVP и диаграммы проекта. Соответственно к вехам второго уровня дочерними задачами уже идут задачи анализа и пользовательские истории. К пользовательским историям дочерними задачами связываются задачи с типом "функциональность", к которым дочерними задачами идут требования на разработку с учётом версионности. Для каждого проекта есть доска разработка и доска управления, соответственно для разработчиков и аналитиков.
"Правила игры" практически такие же, как и описаны в статье автора - всё фиксировать, ничего не изменять и не открывать завершённые и закрытые задачи. Стандарт ведения проектной работы достаточно подробно, но в то же время несложно описан в базе знаний YT, что снижает порог входа новых сотрудников в проект.
Канбан же в YT мы используем для задач третьей линии поддержки, связывая такие задачи с требованиями на разработку в профильных проектах, если такие задачи влекут за собой изменение функциональности.
Ну а дальше всё, как и в большинстве других ИТ-компаний - спринты, митинги, дедлайны...
Если кому-то будет интересно, то могу попробовать написать объёмную статью с нашим взглядом и опытом на управление проектами.
Всем добра!
Можно узнать, почему вы не используете Bit bucket?
Мне, почему то, кажется самоочевидным, что tickets/issues и изменения (MR, PR) должны быть частью одной системы. Тогда много вещей делается автоматически: понятно, какое изменение к какой задачке относится, нельзя сделать изменение, не определив задачку (не создав ticket). Всё проще и меньше шансов ошибиться.
Я чего-то не понимаю?
Наводим порядок в управлении разработкой с помощью Gitlab и Jira