Когда в руках молоток...

...все задачи кажутся гвоздями. А когда отвертка, надо полагать — шурупами. В любом случае, понятно, что инструмент сильно влияет на способ решения задач. Задачи разные, инструменты тоже, соответственно, разные. Как выбрать правильно? Или, хотя бы — приемлемо? Говорят, шуруп, забитый молотком, держится лучше гвоздя закрученного отверткой.

Какие инструменты есть для управления процессом разработки? Принято считать, что самыми продвинутыми и развитыми инструментами являются всякого рода интегрированные трекеры и инструменты управления проектами, коих в наши дни развелось огромное количество — от «старых добрых» JIRA, Bugzilla и Trak до «новомодных» Basecamp, Podio и Pivotal Tracker. О них я и хочу поговорить.

Сразу оговорюсь — я не собираюсь их сравнивать, и тем более, делать какие-либо заключения относительно того, какой из них лучше. Как раз наоборот, я хочу предостеречь вас от неправильных выводов, которые можно сделать из подобных сравнений.

Сложно сказать что-то новое об инструментах. То, что об их качествах нельзя судить в отрыве от контекста их применения, уже сказано тысячу раз. Что лучше — PHP или Java? А может, Ruby? Я слышал, что Ruby — это клево! А что лучше — скрипка или гитара? Я слышал, что гитаристов сейчас много, но играют они похуже! Какую обувь купить для занятия спортом? Кроссовки, вроде, рекомендуют везде, но мне в ластах плавать удобнее!

Каков же контекст применения инструментов управления разработкой? Очевидно — это ваш процесс: ваши соглашения, явные или неявные, о том, как именно разрабатывать. Может быть, они не выражены формально, и процесс выглядит примерно так: ну, наш ПМ, он создает задачи в трекере, ассайнит их на разработчиков, а я смотрю, что там на меня заассайнили, ну и делаю это. Если что-то не так — я иду и говорю с ним. Может быть, ваша команда работает по CMMI 5 или RUP и у вас сотни проектных артефактов, всякие диаграммы, требования, запросы на изменения, сложные бизнес-процессы, и участие в вашей команде требует трехмесячного курса изучения пятисотстраничной документации, формализующей ваш процесс. Но скорее всего — вы где-то посередине.

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

В чем же тут опасность? Например в том, что если вы не занимаетесь своим процессом, и он у вас находится в неявном состоянии, инструмент заменяет вам процесс. Вы перестаете думать о том, как же разрабатывать и принимать решения о процессе, и вместо этого пользуетесь теми практиками, которые диктует вам инструмент. Если вы не понимаете зачем нужны приоритеты у задач — как вы поймете, что в вашем трекере приоритет реализован неправильно? Зачем нужно поле «release version» при заполнении тикета, если у вас нет политики релизов? Вы начинаете верить в то, что разработчики трекера лучше вас знают то, как разрабатывать ваш проект. Характерый симптом — если вы не можете ответить на вопрос «а зачем?» для половины вещей, которые вы там делаете.

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

Что на этот счет говорит agile? Одна из основных, корневых концепций agile — это идея «Inspect & adapt» (что является здравым смыслом, на мой скромный взгляд) следуя которой, процесс разработки является предметом экспериментов, ошибок, находок и всяческого развития. Это означает, что он живой и постоянно меняющийся. Следовательно, и инструмент должен в этом помогать. Хотя бы не мешать.

Все, конечно, уже слышали про scrum board — бумажный оффлайновый трекер задач, который стал практически «визитной карточкой» scrum. Можно долго рассуждать о его преимуществах (и недостатках), но я хочу выделить одну важную особенность: его очень легко и дешево менять. Это та модель процесса, которая поддается изменениям гораздо лучше, чем любая электронная система трекинга. Если вы хотите управлять вашим процессом, а значит — иметь возможность менять его, вам нужен инструмент, который будет помогать вам в этом, а не препятствовать! Ничего удивительного, что адепты agile, которые так любят и холят свой процесс, предпочитают доску. Впрочем, она вовсе не заменяет трекер полностью, и как правило, используется совместно.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU