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

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

Какие инструменты есть для управления процессом разработки? Принято считать, что самыми продвинутыми и развитыми инструментами являются всякого рода интегрированные трекеры и инструменты управления проектами, коих в наши дни развелось огромное количество — от «старых добрых» 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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



24 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Доской и клеящимися листочками можно (и, наверное, даже нужно) обойтись в небольшой команде, которая сидит в одной комнате. Увы, в условиях аутсорса банальный co-location команды не всегда возможен даже тогда, когда все участники физически находятся в одном зданиии. И это не говоря про случаи распределенных команд или больших проектов, в которых участвует 15-20 и более человек.

Кроме того, в случае физической доски метрики (тот же sprint burndown) придется собирать и считать вручную, в то время как программа все посчитает и обновит график автоматически. А как показать текущее состояние доски, например, сидящему за океаном product owner’у? Можно, конечно, по Веб-камере — и это даже успешно практиковалось одной из команд, которую я коучил, но это, все же, морока.

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

Коллеги, не нужно забывать, что это всего лишь инструмент :) В свое время Крей однозначно ответил на тему всяко-разного инструментария :)
Хоть на бумаге это все рисовать — лишь бы работало. Потому что самый главное в планировании и трэкинге — все-таки ряд качеств разработчика, который никакими навороченными инструментами не компенсируешь :)

Касательно боарда: был проект, когда просто фотографировали на каждом проектном статусе дважды в день изменения на досках и выкладывали в вики — работало на ура. И распределенности-удаленности не помешали :)

Я в своё время потратил сотни рабочих часов, на только подбор средства управления проектами... их окупить уже нереально, даже если бы я нашёл то идеально средство...

То есть — так и не удалось найти то, что было нужно?

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

\\ Всегда ваш К.О.

З. Ы. Больше всего мне понравился XPlanner, но он уже старенький, некоторых вещей ему не достает. А так, конечно, старая добрая боард для спринта и эксельные таблички для проекта в целом.

Я слышал чудесное мнение по этому поводу: если что-то нельзя автоматизировать с помощью excel — это нельзя автоматизировать вообще!

Є така чудова штука як greenhopper(www.atlassian.com/...tour/scrum.jsp для jira, яка дуже підходить під скрам.

В нашей компании используется google-таблица, в которой всё очень наглядно. Имитация календаря со списком задач на день (из жиры). Все нюансы решает девлид или тимлид по конкретным приоритетам в течение дня. По окончанию дня — подсвечиваем ячейку в зависимости от успешности работы. Всё гениальное — простынь.

Согласен на все сто с идеей адаптации процесса и частным случаем в виде Скрам Доски

Мы используем PivotalTracker и очень довольны. Общего офиса у нас нет, так что сравнивать с эффективностью scrum board не берусь.

+100500. Как в свое время сказал отэц Коберн в «Люди как нелинейные...» в лохматом 1999-м, лучшее средство управления и коммуникации — маркерная доска и заинтересованные люди :) Сам придерживаюсь принципа «белых досок много не бывает».

Касательно инструментов — можно также упомянуть извечные стоны разработчиков о несовершенстве инструментов планирования и трэкинга, хотя разруха — она не в сортирах [с] проф. Преображенский

Через полвека отраслевой эволюции имеем на выходе школьную доску с пометками.

Еще пару лет прогресса и хорошим инструментом станут дубины и камни. )

Это вовсе не регресс. Это как разобрать сложный прибор и нужную тебе часть распаять на монтажном столике.

как разработчик плагинов под продукты atlassian (bamboo, jira) — плюсану за них. Очень легко расширяемы, большое комьюнити, java(легко найти программера), используют миллионы компаний.

О, а расскажите — сколько может стоить иметь JIRA и менять ее под свои процессы? Надо штатного java-разработчика иметь фултайм? Или аусорс?

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

Все должно быть зависит от проектов и задач. Мы вполне успешно применяем JIRA в gamedev-е. Команда около 15 человек. И не одно Java программиста. Planning Board, Scrumm Board средствами JIRA.

Подозреваю, что сверху там еще GreenHopper стоит? JIRA сама по себе ничего agile-нужного не предлагает вроде бы...

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

www.atlassian.com/...re/greenhopper

угу, мы тоже, только вот все это идет жире, как кобыле 5я нога.

А может просто админы... ну, не очень...

извините, только сейчас увидел комментарий:) Стоить может много. Я лично берусь за 30$/час при адекватном тех задании. Если же самому разбираться, как наложить джиру на ваш бизнес, то надо исследовать. Фуллтайм вам точно не нужен чел(в яндексе, atg всего пара jira программистов). Если нужна консультация — напишите на dementievda at gmail.com

Підписатись на коментарі