Открыть список
Как стать автором
Обновить

Комментарии, SVN, bug-, issue-tracker и работа в команде

Чулан
Размышления, вызванные топиком «Как бороться с человеческим фактором при внедрении ПО?».

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

Первое время было весьма непривычно работать с такими продуктами как JIRA, SVN. Тот же Zend поначалу казался перенавороченным монстром, после более привычного PHP Expert Editor.

Но, спустя некоторое непродолжительное время, я почувствовал все прелести этих продуктов. SVN — лучший друг и товарищ при командной разработке, JIRA — позволяет довольно обстоятельно вести отчеты о проделанных изменениях и временных затратах, Zend — это вообще практически незаменимая вещь при работе над огромным проектом. Один только автокомплит имён классов, методов и переменных (которые в таком проекте довольно многословны, хоть и осмысленны) экономит кучу времени.

Проблема-то, не в этих замечательных программных продуктах.

Нет, проблема — она в отношении остальных к этим продуктам.

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

Делается это просто, ничего ведь сложно нет: SVN -> Show Log (или Show History, если из-под Zend) и вуаля: дата коммита, список файлов и комментарий каждого коммита. Но тут-то и ждало меня удивление. В длинном и впечатляющем списке коммитов были весьма немалые лакуны в комментариях. Выглядело это приблизительно таким образом:
...
...
1984 janson: Исправление бага с получением данных из галактической БД...
1983 разработчик1:
1982 разработчик1:
1981 разработчик2:
1980 разработчик2:
1979 разработчик2:
1978 разработчик1:
1977 верстальщик:
1976 разработчик2:
1975 janson: Добавление функционала по коннекту к лунному спутнику с проверкой...
1974 janson: Изменения в шаблонах отправки факса премьер-министру.
1973 разработчик1:
1972 разработчик1:
1971 разработчик1:
1970 разработчик2:
1969 janson: Открытие окна для визуальной связи с природой.
1968 верстальщик:
1967 верстальщик:
...



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

Возможно это совсем неважно. Вероятно, для многих так оно и есть, но когда количество тасок начинает исчисляться сотнями, то даже просто вспомнить, какой характер носили изменения в той или иной ревизии — проблематично.

Скажете — для описания проведенных работ есть JIRA. :) Да, она есть. К великому сожалению, большинство тасок заканчиваются собственно общим описанием проблемы (в большинстве случаев, составленное менеджером или клиентом) и вердиктом «Fixed». А мы все знаем, как часто у клиента при малейших странностях и неполадках возникает проблема из разряда «СРОЧНО! Ничего не работает!».

И в итоге имеем таски:

Описание:
У клиента не работают некоторые из сайтов конфедерации.

Статус:
Fixed.


О том же, какие сайты он не работают, и как проявляется этот баг — знает только клиент (но не может внятно обьяснить, что в принципе понятно — он зачастую не является специалистом в вопросах XML-импорта или ajax-запросов к сайтам галактической конфедерации), и отважный джедай-разработчик, который разобрался таки в этой проблеме (но только разработчик будет это помнить недолго — неделя, максимум месяц, если проблема специфическая и необычная). О характере изменений и проведенных работ не будет никакого комментария.

Неужели эти отважные, но ленивые джедаи не в курсе о тех выгодах, которые сулит банальное упоминание о свершенном? Да нет, как раз они в курсе — ибо когда разбирают таску с комметариями, то шустро врубаются в суть проблемы и решают её, или последствия от предыдущих свершений у этого же клиента. Но писать комментарии самому — это выше их сил.

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

В итоге, через пару месяцев обнаружилось, что доступы туда забивали только я и верстальщик, которому это быстро надоело, потому что теребили всё равно его лично, с просьбой глянуть доступы в его локальных .doc файлах. Хотя не пойму, что может быть сложного, набрать в браузере: 192.168.0.XXX/wikipedia/, тем более, что любой браузер может сделать закладку на этой странице.

Грустно это всё. И непонятно — как это изменить?
Теги:командная работачеловеческий факторорганизация работыразмышления
Хабы: Чулан
Всего голосов 20: ↑12 и ↓8 +4
Просмотры363

Похожие публикации

Junior Sales Representative
от 20 000 до 50 000 ₽PingdeliveryМожно удаленно
Инженер по сопровождению продукта "Фактор"
от 100 000 до 140 000 ₽HFLabsМожно удаленно
Менеджер по продажам и работе с клиентами
от 40 000 до 100 000 ₽ITIS.TEAMСанкт-ПетербургМожно удаленно
Офис-менеджер (удалённая работа)
от 20 000 до 36 000 ₽NetPingМожно удаленно
.NET Developer (Удалённая работа)
от 60 000 до 100 000 ₽WowVendorМожно удаленно

Лучшие публикации за сутки