Показаны сообщения с ярлыком issue tracking. Показать все сообщения
Показаны сообщения с ярлыком issue tracking. Показать все сообщения

2013-01-31

github и домовладение

Добрейшего!

Как человек, проживающий четвёртый год в своём доме, не смог пройти мимо ещё одного необычного применения для гитхаба. Один мужик все свои задачу по содержанию своего дома ведет в трекере открытого проекта: https://github.com/frabcus/house/issues.

Сразу скажу, что github в данном случае - просто первый попавшийся под руку инструмент для отслеживания задач. Просто автор уже ведет там свои проекты и решил не бегать между разными платформами и остался там же. По мне, так Basecamp для этой же задачи подошёл бы идеально. Однако, всё равно хорошо получилось.

Конечно же, каждая задача представлена в виде записи в issue tracker, в которой описывается проблема и комменты по ходу решения. Ну и она по закрывается по мере решения задачи. Что характерно - в комменты влазят вроде посторонние люди и предлагают свои решения :))

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

Отдельно стоит отметить теги. Поскольку одна проблема может иметь отношение к разным системам в доме, то логично каждой такой системе или проблемной области жать тегу и вешать её везде, где придётся. Среди меток - и сам дом. и его украшение, и электрика, и газ, и вода - всё, до чего руки дотянулись.

Ну и как на гитхабе без форков? Их есть там. Правда, те, что смотрел, были дохленькие.

В общем, штука получилась забавная. Правда, мне пока не пригодится - свои задачи по дому пока удаётся держать в голове.

2011-09-29

eTraxis вышел на новую орбиту

Добрейшего!

За суетой чуть не забыл о важном. Как известно постоянным читателям бложика, я пристально слежу за развитием eTraxis - системы для управления задачами, отслеживания ошибок, да и вообще трекинга чего угодно. Так вот, он сделал ещё один шаг вперёд! Его онлайн-версия, etraxis.com, о которой я уже писал, теперь стала полноценным продуктом.

Что значит полноценным? Теперь для пользователей стали доступны расширенные возможности работы, а именно - больше шаблонов, больше активных пользователей, больше места под вложения. Что значит продуктом - да, теперь за неё можно заплатить деньги. :) Были добавлены тарифные планы, каждый из которых даёт расширенные возможности.

Конечно же, бесплатный онлайн-трекинг всё также доступен и в нём по-прежнему действует ограничение на 2 активных шаблона записей и 5 пользователей. Если заказчику нужно больше пространства для манёвра - достаточно заплатить, например через банковскую карту. Сейчас после регистрации в сервисе по умолчанию создается шаблон с типовым сценарием работы над проблемой и группы пользователей. Так что дополнительная настройка workflow - это уже шаг на усмотрение пользователя.

Open source версия всё также никуда не делась. Она по-прежнему доступна и активно поддерживается. Новые версии как выходили, так и будут продолжать выходить стабильно. Функциональность open source решения полностью поддерживается онлайн-сервисом и опробуются именно там.

Итак, заходим, пробуем, ну и конечно же покупаем :)

2010-10-25

eTraxis теперь в линейке 3.х

Добрейшего.

Прошел всего какой-то год (без нескольких дней), с того дня как я объявил о переходе eTraxis на линейку 2.х. И таки шо бы вы думали? Да, он теперь перерос в линейку 3.х! :) С чем и поздравляю его бессменного новатора - Артёма. Напомню, что мне довелось одно время быть соучастником этого проекта, так что за судьбой его слежу пристально.

Для тех, кто не в курсе, краткое содержание предыдущих серий.

eTraxis - это система отслеживания запросов на изменение. Такие системы ещё называют багтрекерами, трекерами, системами отслеживания ошибок, системами управления задачами. По-разному, в общем, называют. Казалось бы, систем таких - навалом, зачем ещё одна? Многим из них не хватает одного - гибкости настройки жизненного цикла (кто не знает, что это такое - читаем заметку про багтрекеры). А те, что гибко настраиваются - нетривиальны в настройке. Даже Redmine, который я уже некоторое время описываю в своих заметках, местами непрост в части, касающейся настройки графа переходов и прав пользователей.

2010-09-20

Личный опыт внедрения Redmine

Добрейшего.

Не так давно задумал совершить ряд движений и поменять СМ-процесс в своём проекте и, если получится, на проекте соседнем. Поводом было то, что меня перестал устраивать текущий инструмент отслеживания запросов на изменения. Начав думать над одним, огляделся и понял, что пора бы и всё остальное поменять, до чего давно не доходили руки.

В общем, перво-наперво задача стояла поменять систему отслеживания запросов на изменения, или попросту багтрекер. К моменту написания заметки на пробу использовал Jira, подумывал оценить её и предложить соседней команде в качестве альтернативы использовавшегося ими Eventum. Когда стали обсуждать переход в участниками команды, решили посмотреть на прайс Джиры... посмотрели и решили, что Redmine, обладающий тем же функционалом, но за бесплатно, вполне подойдет :) У меня был опыт его настройки и внедрения в процесс, так что переход обещал быть быстрым.

2010-08-19

Пример выбора иструментов, или Как жить дальше?

Добрейшего.

На своем опыте убеждаюсь, что вопрос выбора инструментария может встать даже в устоявшихся проектах и коллективах. А всё потому, что на основном месте работы сложилась занятная ситуация с организацией и инструментами разработки.
Есть следующие команды разработчиков. Большая команда разработчиков - назовем её Команда Ф (так оригинальнее). Есть маленькая команда разработчиков (Команда Д). И есть я, пусть это будет Командой А (ничего общего с тупым сериалом 80-х).
Есть и другие команды - техподдержка, дизайнеры, верстальщики, менеджеры, редакторы - но они нас не интересуют в разрезе заметки.

2010-05-25

Google Wave // как не надо делать багтрекинг

Добрейшего.

Через старый уважаемый сайт набрел на статью на молодом гиковом сайте. В общем, на Хабре выложили пост про использование Google Wave в качестве багтрекера, а на RSDN выложили на него ссылку с комментариями.

Вкратце - есть команда 30 человек. Они использовали 5 лет Trac и заодно перепробовали кучу других тулов для управления задачами. Им нужен был инструмент, который позволил бы не только отслеживать задачу, но и как-то оперативно поддерживать весь поток сопутствующей информации - в первую очередь обсуждений в IM системы Jabber. В конце концов остановились на Google Wave - поскольку именно там они могут  теперь вволю трепаться о проекте и при этом там же вести информацию о задачах. Плюс ещё пару фишек разработали для Волны. Все жутко довольны, чего и всем советуют. Щастье всем даром и пусть никто не уйдет обиженным.

Что тут скажешь: разруха - она в головах, а не в клозетах. Если в команде бардак и никто не хочет взять на себя труд остановить его и взять всё под какое-то подобие контроля - жди беды. Люди будут упорно вариться в этом броуновском движении и не будут упорядочивать свою работу, даже когда проект разрастется до сотни человек и понадобятся совсем другие механизмы работы.

На RSDN автор высказался примерно в таком же ключе. Ну, и я его поддержал. Основные мысли:
- для оправдания бардака люди будут пробовать всё новые тулзы, которые будут как-то помогать поддерживать любимый уровень энтропии;
- делать из обсуждений задач полноценные артефакты процесса (т.е. присваивать обсуждению тикета статус отдельной самодостаточной единицы) - неправильно. Надо резюмировать результаты любых обсуждений и уже их аттачить в качестве комментариев к записям в системе трекинга;
- подобная система не способна нормально структурировать работу, а также получать статистику и числовые показатели.
Ну и не могу не процитировать камрада с RSDN:
Управление проектом — это чёткое понимание в каждый момент времени, где ты находишься. Из того что я вычитал, там даже близко нет "управления". Есть группа людей, которая "just for fun" занимается какой-то деятельностью. Всё это будет продолжаться, пока у кого-то хватит терпения оплачивать этот фан. Потом их разгонят, на форумах будут сообщения — "была классная контора, но потом прогнила".
Как-то так, да. Вообще, некоторые основы отслеживания задач уже были мной высказаны в заметке про основы багтрекинга, так что рекомендую перечитать её и сравнить с обоими постами.

Мой вывод: Google Wave (по крайней мере, предложенная реализация) не способен предоставить нужный уровень зрелости для отслеживания задач (багтрекинга) относительно большого проекта. Так что используйте что-то, что способствует применению правильных практик. Например, eTraxis ;)

UPDATE: Собственно, предмет споров самоустранился:
http://googleblog.blogspot.com/2010/08/update-on-google-wave.html

2009-10-19

eTraxis // Теперь в линейке 2.x

Некоторое время назад я участвовал в разработке open source проекта eTraxis — системы отслеживания ошибок, а точнее — системы отслеживания запросов на изменения. Если вдруг кто до сих пор не знает, что это за класс систем — читайте мою статью про системы отслеживания запросов на изменения из цикла материалов по Software Configuration Management.

Система эта предоставляет веб-ориентированный интерфейс — что, в общем-то, уже почти стандарт. Серверная часть традиционна — PHP + Apache, а вот парк СУБД даст фору многим подобным системам: помимо традиционного же MySQL поддерживаются PostgreSQL, MSSQL и Oracle.
Из базовых фич:

2009-09-06

SCM // 3. Отслеживание запросов на изменение

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

Отслеживание запросов на изменение

Для начала, как вообще возникают изменения на проекте? Вариантов всего несколько: