Евгений Рыжков. Еще раз про качество.

https://www.youtube.com/watch?v=TIRzBDE3_sA

Transcript

1. Еще раз про качество Рыжков Евгений , 30.08.2016 специально для Deep Refactoring
2. 1. Отказ от ответствености • Я работал/работаю в крупных аутсорсинговых сервисных конторах (это не продуктовые конторы и не интеграторы!). • Это исключительно мой взгляд на сложившийся порядок вещей.
3. 2. Раскрою карты сразу Качественный софт делать дорого (с точки зрения исполнителя и заказчика) и скучно (с точки зрения молодых, талантливых и амбициозных).
4. 4. Что такое качественный софт? • Все зависит от входных требований: для разных заказчиков один и тот же продукт будет как приемлемым, так и неприемлемым. • Мало договориться о "качестве" с заказчиком до начала работ. Надо построить процесс так, чтобы было видно, насколько далеко продукт от “качественного”. • Качество - ничто. Управление качеством - все. • Качественный софт - это софт, качеством которого можно явно управлять в процессе создания.
5. 5. Управление - это информация • Чтобы чем-то управлять руководителю надо получать информацию. • Любой руководитель - это центр сбора информации. • Информация не берется из ниоткуда: ее создают люди. • На основании этой информации рассчитываются различные метрики, создаются отчеты, формируются бюджеты и т.п. • Несохраненная информация пропадает и не может участвовать в управлении. • Пример: учет трудозатрат (ежедневно, еженедельно, ежемесячно, никогда)
6. 6. Почему дорого и скучно? • Попробуем разобрать один из элементов проектной деятельности с точки зрения заказчика, начальников программистов и самих программистов. • За основу возьмем внутренние процессы одной достаточно крупной конторы...
7. 7. Управляем качеством кода • Варианты: статический анализ (расчет метрик и анализ исходников, динамический анализ (запуск кода - тестирование). • Один из методов статического анализа: code review. • Вопрос к аудитории: как проводится code review?
8. 8. Что за процесс Review? • Цель процесса: гарантировать соответствие промежуточных результатов требуемому уровню качества. • У процесса есть модератор, который отвечает за весь процесс. • Модератор: ◦ определяет цель конкретного review. ◦ определяет, кто должен участвовать в процессе. ◦ находит того, кто будет делать review (если еще нет назначения). ◦ обеспечивает доступность объектов для review (исходники, документы и т.п.) для участников. ◦ проверяет актуальность документов, обеспечивающих процесс review. ◦ назначает дату и время сессии, оповещает всех участников. ◦ назначает секретаря для сессии ◦ обеспечивает документирование и классификацию результатов. ◦ проверяет наличие протокола сессии с подписями участников. • И, конечно, протокол должен быть разослан всем и помещен в “систему документоборота” проекта. • Вопрос к аудитории: а какие типы code review вы знаете?
9. 9. Примеры типов code review • Informal review (выполняется на ходу, по мере того, как пишется код) • Walkthrough (автор кода презентует результат непосредственно на сессии) • Technical review (рецензент проводит анализ кода до сессии на основе только своего опыта; результаты обсуждаются на сессии) • Inspection (рецензент проводит анализ кода до сессии, используя согласованные checklists; результаты обсуждаются на сессии)
10. 10. Сколько же это стоит?! • Трудозатраты на создание регламентирующих документов и поддержание их в актуальном состоянии • Трудозатраты на инспекцию кода до сессии • Трудозатраты на проведение сессии (сколько там человеко-часов если сессия открыта для посещения всеми?) • Трудозатраты на оформление результатов сессии, создание дефектов и отслеживание их закрытия
11. 11. А когда же кодить?! • Надо быть в курсе регламентирующих документов (как называются, где лежат, прочитать последнюю версию) • Надо кодить с учетом checklists • Надо кодить с учетом стандартов • Надо уметь рецензировать чужой код • Надо уметь обсуждать технические проблемы • Надо аккуратно вести отчетность о проделанной работы
12. 12. Имеем на выходе • Для заказчика трудозатраты возрастают • Для руководства бонусы снижаются • Для молодых, талантливых и амбициозных программистов жизнь проходит мимо • И еще один момент: менеджмент не всегда может правильно оценить реальные трудозатраты с учетом возможности управления качеством продукта. • На выходе: писать софт качественно - очень дорого. Мало кто может себе это позволить.
13. У меня все Вопросы есть?