эта встреча открыта для всех )
Вы сами поняли что только что написали? :)
Здравствуйте.
(Для Вас уже не актуально, так как Вы приходили к нам на занятие, но может кому-то еще пригодится)
Мы собираем все ответы в базу данных и к моменту начала курсов прозваниваем всех, кто к нам регистрировался.
Сейчас занятия начинаются в 18.00
Да, курсы проходят в Днепропетровске.
Сергей, абсолютно справедливо подмечено.
Метрики нужно собирать с начала проекта. Для легаси проектов, а еще и больших, распределенных, настроить процесс можно, но добиться хороших показателей крайне тяжело. Черный пояс в мотивации команд тут необходим.
Однако, мы всегда пытаемся померять — узнать врага в лицо.
Не обязательно сразу брасаться покрывать 500 KLOC. В проекте у одного из наших менеджеров ребята выстроили график, как они хотят постепенно улучшить покрытие (за несколько месяцев). Повесили его на стену и старались придерживаться. Получился такой себе Burnup chart.
Насчет «Комментируемость 80% для публичных методов»:
Документируемость (наличие грамотного контракта публичного метода) спасает нас от падения системы в тех местах, где этот метод вызывается другими классами. Особенно это можно прочувствовать на очень больших проектах (подход Design by
Contract).
Играли. Возможно, расскажу в отдельной заметке...
У нас были вариации на эту тему. Были и есть проекты, где отдельно заводилась задача на Code Review для всего кода к данной User Story (кстати, один из таких проектов был распределенным, с участием команды заказчика и как раз с ними мы приняли решение заводить отдельные задачи, другие команды этого проекта поддержали).
Есть, когда Сode Review включен в задачу. На планировании учитываем. Тогда делаем отдельный стутус, как я писала в статье.
Юнит тесты, включаем в разработку, когда оцениваем — знаем что оцениваем имплементацию задачи + юнит тесты. На всякий случай на планировании я не устаю об этом напоминать.
Рефакторинг закладываем отдельной задачай. Предварительно пишем закзчику письмо. Плюсы и минусы (с точки зрения business value) проведения рефакторинга. Он может отказаться, если мы не показались убедительны.
Статистика. Когда это отдельная задача на Code Review — не больше 15% от общей оценки на имплементацию было достаточно.
Затраченное время на юнит тесты мы не меряем, т.к. без них не работаем.
Еще на стадии контрактов мы говорим о практиках, которые мы применяем...
Насчет прецедентов. У меня отказов — не было. Но жертвовать иногда приходилось. В след спринтах первым делом нагоняли этот технический долг.
Если появляются сомнения в достоверности репортов Сонара, можно применять один из его плагинов, поддерживающий mutation testing, который изменит значение условий true на false, и, соответственно, покажет, какие тесты отработали, а какие нет.
Токая проверка занимает время. Можно несколько раз ее включать, не обязательно всегда. Убедиться, что тесты пишутся грамотно, или же сделать выводы и провести беседы с разработчиками (они-то рады писать хорошие тесты, так что сопротивления не должно быть).
Есть еще подход к написанию кода — BDD. Можно с этим поиграться :)
Спасибо за отзыв. Насчет выкачивания — это применимо к T&M проектам, у нас в основном fixed price.
Привет!
Я так понимаю, что основная жалоба по поводу статьи — отсутствие практического примера, который можно было бы с пользой применить у себя.
Попробую один такой пример привести. Это презентация, которую лучше, конечно, слышать в моем исполнении, т.к. всю инфо на слайды не поместишь, но все же...
www.slideshare.net/...nce-report-scrum-12571662
Обратите внимание, встреча состоится в БЦ Enigma, ул. Шевченко, 53. Детали были высланы на почту всем зарегистрировавшимся.