Еще раз про качество

Рыжков Евгений, 30.08.2016

специально для Deep Refactoring

1. Отказ от ответствености

● Я работал/работаю в крупных аутсорсинговых сервисных конторах (это не продуктовые конторы и не интеграторы!).

● Это исключительно мой взгляд на сложившийся порядок вещей.

2. Раскрою карты сразу

Качественный софт делать дорого (с точки зрения исполнителя и заказчика) и скучно (с

точки зрения молодых, талантливых и амбициозных).

4. Что такое качественный софт?● Все зависит от входных требований: для разных заказчиков один и тот

же продукт будет как приемлемым, так и неприемлемым.● Мало договориться о "качестве" с заказчиком до начала работ. Надо

построить процесс так, чтобы было видно, насколько далеко продукт от “качественного”.

● Качество - ничто. Управление качеством - все.● Качественный софт - это софт, качеством которого можно явно

управлять в процессе создания.

5. Управление - это информация● Чтобы чем-то управлять руководителю надо получать информацию.● Любой руководитель - это центр сбора информации.● Информация не берется из ниоткуда: ее создают люди.● На основании этой информации рассчитываются различные метрики,

создаются отчеты, формируются бюджеты и т.п.● Несохраненная информация пропадает и не может участвовать в

управлении.● Пример: учет трудозатрат (ежедневно, еженедельно, ежемесячно,

никогда)

6. Почему дорого и скучно?● Попробуем разобрать один из элементов проектной деятельности с

точки зрения заказчика, начальников программистов и самих программистов.

● За основу возьмем внутренние процессы одной достаточно крупной конторы...

7. Управляем качеством кода● Варианты: статический анализ (расчет метрик и анализ исходников,

динамический анализ (запуск кода - тестирование).● Один из методов статического анализа: code review.● Вопрос к аудитории: как проводится code review?

8. Что за процесс Review?● Цель процесса: гарантировать соответствие промежуточных результатов требуемому уровню качества.● У процесса есть модератор, который отвечает за весь процесс.● Модератор:

○ определяет цель конкретного review.○ определяет, кто должен участвовать в процессе.○ находит того, кто будет делать review (если еще нет назначения).○ обеспечивает доступность объектов для review (исходники, документы и т.п.) для участников.○ проверяет актуальность документов, обеспечивающих процесс review.○ назначает дату и время сессии, оповещает всех участников.○ назначает секретаря для сессии○ обеспечивает документирование и классификацию результатов.○ проверяет наличие протокола сессии с подписями участников.

● И, конечно, протокол должен быть разослан всем и помещен в “систему документоборота” проекта.● Вопрос к аудитории: а какие типы code review вы знаете?

9. Примеры типов code review● Informal review (выполняется на ходу, по мере того, как пишется код)● Walkthrough (автор кода презентует результат непосредственно на

сессии)● Technical review (рецензент проводит анализ кода до сессии на основе

только своего опыта; результаты обсуждаются на сессии)● Inspection (рецензент проводит анализ кода до сессии, используя

согласованные checklists; результаты обсуждаются на сессии)

10. Сколько же это стоит?!● Трудозатраты на создание регламентирующих документов и

поддержание их в актуальном состоянии● Трудозатраты на инспекцию кода до сессии● Трудозатраты на проведение сессии (сколько там человеко-часов если

сессия открыта для посещения всеми?)● Трудозатраты на оформление результатов сессии, создание дефектов и

отслеживание их закрытия

11. А когда же кодить?!● Надо быть в курсе регламентирующих документов (как называются, где

лежат, прочитать последнюю версию)● Надо кодить с учетом checklists● Надо кодить с учетом стандартов● Надо уметь рецензировать чужой код● Надо уметь обсуждать технические проблемы● Надо аккуратно вести отчетность о проделанной работы

12. Имеем на выходе● Для заказчика трудозатраты возрастают● Для руководства бонусы снижаются● Для молодых, талантливых и амбициозных программистов жизнь

проходит мимо● И еще один момент: менеджмент не всегда может правильно оценить

реальные трудозатраты с учетом возможности управления качеством продукта.

● На выходе: писать софт качественно - очень дорого. Мало кто может себе это позволить.

У меня все

Вопросы есть?