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

Комментарии 17

Верстальщику надо слать всех на вики без всяких просмотров файлов. Когда третий раз пошлет матом или просто проигнорирует, задумаются.

Баги без описания как тестировать надо переоткрывать со соответствующим комментарием.

Комментарии коммитов… Тут сложно. Вам придется доказать команде что это действительно удобно. Можно попробовать сравнительно часто интересоваться у людей что было сделано. Цель — чтобы они сами захотели видеть комментарии к коммитам.
По поводу коммитов — нарисуйте пре-коммит хук в свн, который будет отклонять коммиты с пустым логом. В принципе можно ещё насетапить интеграцию коммит логов с JIRA, чтобы при просмотре из TortoiseSVN, например, айдишники багов превращались в линки на сами баги в JIRA. И наоборот, чтобы в JIRA по каждой баге можно было видеть список относящихся к ней коммитов. Если вашим разработчикам это не покажется удобным — я даже не знаю, что вам посоветовать.
У нас разработчик не может закрыть задачу — задачу закрывает РП, который смотрит, чтобы в трекере не было комментов типа «Fixed».
Мне, как руководителю отдела разработки, приходится решать аналогичные задачи. И я по опыту могу сказать, что описанные проблемы решаются организационными методами.

Требуйте, чтобы исполнители качественно выполняли свою работу.

Тут три ключевых слова.

1. Требуйте

Бывает сложно провести свою линию и настоять, но это нужно делать. Без этого ситуация имеет свойство скатываться к бардаку. Сотрудник должен знать, что халява не пройдет. По личным наблюдениям — если правила игры определены твердо и бесповоротно, то правила выполнять проще, не возникает ненужных терзаний.

2. Качественно

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

3. Свою работу

Каждый должен делать свою работу. Если бухгалтер выносит мозг программисту просьбами «ну расчитай быстренько зарплату, ты же разбираешься в программе», то этот бухгалтер не делает свою работу, получает зря деньги и мешает работать программисту. При этом, понятно, программистом предварительно должна быть написана внятная инструкция для бухгалтеров по пользованию его программой в части расчета зарплаты.
Отлично сказано, только вот со вторым пунктом…
«Не задокументировано — не выполнено». Вы надеюсь предоставляете сотруднику дополнительное время на написание текста? И у Вас наверняка есть шаблоны по которым может быстро отписать программист выполненную задачу, а не придумывать каждый раз? Наверняка, как руководитель проекта, Вы знаете, что очень многим программистам, намного сложнее выразить понятно-доступным языком, да и вообще — выразить в документе, чем в это время написать новый кусок программы.

Вообще тематика очень была бы интересной… Может быть для этого нужна новая профессия, а может она уже и есть? Эдакий документатор. Тогда знать было бы интересно, какими он должен был бы знаниями обладать. Фактически — это тот человек, который с утра до вечера должен предоставлять отчетную часть по реальному состоянию проекта. Проект-менеджер — этим не занимается, ибо задача о комментировании коммитов, тикетов и прочего, попросту ним будет переложена на тех кто непосредственно коммитит…
Не выдумывайте велосипед. Инженер, который в команде, расчерчивающей дом, занимается прокладкой труб (ничуть не меньший инженер, чем все остальные) — должен и обязан документировать свои действия, или уметь быстро восстановить то, что было n шагов назад. И свою работу документирует только он, а не «документатор». Потому что случись чего — вздёрнут на рее за просчёт в чертежах труб именно его. Технический писатель, о котором я говорил ниже, занимается написанием максимум пользовательской документации. Но при этом — по представленному разрабами описанию функционала (на крайний случай — по ТЗ глядя в полученный результат).
Повторюсь: следовательно для написания — должны быть шаблоны для быстрого написания, чтобы по ним уже «технопись» — писал пользовательское описание и хелповки. А то меня коробит лично когда вижу когда программисты пишут пользовательские хелпы, 99% из них базируются на принципе: «это ведь все так просто — пользователи просто идиоты» Плюс, опять же повторяясь, программистам должно быть выделено время не только на написание софта — но и на написание технической документации по функционалу, на что обычно все руководители относятся ровно так же как программисты пишут пользовательские хелпы: «Что там стоит написать две бумажки с описанием, это ведь элементарно, а программисты — ленивые просто». К ним до мозга не доходит, что креативно творчески написать описание — это тоже надо уметь.

И последний кирпичик в гроб этого вопроса:
Описание функциональности, должен писать не программист в процессе написания — а должно быть прописано задолго до того как проект начнется вообще кодироваться, и имя этому документу — ТЕХНИЧЕСКОЕ ЗАДАНИЕ. А программисту надо всего-лишь комментировать код, т.е. то как он писал тот функционал, который с него затребовали в соответствии с ТЗ.
«При этом, понятно, программистом предварительно должна быть написана внятная инструкция для бухгалтеров по пользованию его программой в части расчета зарплаты.»

Программистом ничего подобного предоставлено не должно быть… это должен предоставлять человек, который занимается поддержкой программы.
Поддерживаю. Это работа для техписа. В крайнем случае, кто-то в команде совмещает техписа с разрабом.
НЛО прилетело и опубликовало эту надпись здесь
Этот вопрос уже обсудили с верстальщиком. Убрали всё доступные «шары» на его личные документы по доступам.
Попробуем исправить ситуацию, как говорится «Огнем и мечом».
под катом смотрелось бы лучше
теги перепутал :)
Сейчас спрятал под кат.
в каком-то гиткасте видел забаный комит переводится как-то так: «лучший в мире патч, но худший в мире коментарий к комиту»
К сожалению, большинство разработчиков/дизайнеров/верстальщиков – “Птица гордая, пока не пнешь, не полетит” (с)
Так что выход один — директивные указания руководства, за несоблюдение штраф/фофан/в ухо.

что-то уже второй или третий топик за неделю по поводу нежелания работать как того требуется, и как с этим бороться… в принципе хорошая тенденция, ещёбы только помогало
эх помню было у нас начальство из Швейцарии. Так вот — не то что коммит без описания — коммит с не очень четким описанием служил причиной очень серьезного выговора от CEO. Прошло уже около четырех лет но привычка писать доступные другим человекам коммиты въелась намертво в меня и в большинство других сотрудников =)
И вот, спустя кучу времени, рапортую: нам — помогло! :)

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