Еще раз про качество
-
Upload
ivan-grishaev -
Category
Engineering
-
view
62 -
download
0
Transcript of Еще раз про качество
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. Имеем на выходе● Для заказчика трудозатраты возрастают● Для руководства бонусы снижаются● Для молодых, талантливых и амбициозных программистов жизнь
проходит мимо● И еще один момент: менеджмент не всегда может правильно оценить
реальные трудозатраты с учетом возможности управления качеством продукта.
● На выходе: писать софт качественно - очень дорого. Мало кто может себе это позволить.