требований: для разных заказчиков один и тот же продукт будет как приемлемым, так и неприемлемым. • Мало договориться о "качестве" с заказчиком до начала работ. Надо построить процесс так, чтобы было видно, насколько далеко продукт от “качественного”. • Качество - ничто. Управление качеством - все. • Качественный софт - это софт, качеством которого можно явно управлять в процессе создания.
надо получать информацию. • Любой руководитель - это центр сбора информации. • Информация не берется из ниоткуда: ее создают люди. • На основании этой информации рассчитываются различные метрики, создаются отчеты, формируются бюджеты и т.п. • Несохраненная информация пропадает и не может участвовать в управлении. • Пример: учет трудозатрат (ежедневно, еженедельно, ежемесячно, никогда)
элементов проектной деятельности с точки зрения заказчика, начальников программистов и самих программистов. • За основу возьмем внутренние процессы одной достаточно крупной конторы...
и анализ исходников, динамический анализ (запуск кода - тестирование). • Один из методов статического анализа: code review. • Вопрос к аудитории: как проводится code review?
промежуточных результатов требуемому уровню качества. • У процесса есть модератор, который отвечает за весь процесс. • Модератор: ◦ определяет цель конкретного review. ◦ определяет, кто должен участвовать в процессе. ◦ находит того, кто будет делать review (если еще нет назначения). ◦ обеспечивает доступность объектов для review (исходники, документы и т.п.) для участников. ◦ проверяет актуальность документов, обеспечивающих процесс review. ◦ назначает дату и время сессии, оповещает всех участников. ◦ назначает секретаря для сессии ◦ обеспечивает документирование и классификацию результатов. ◦ проверяет наличие протокола сессии с подписями участников. • И, конечно, протокол должен быть разослан всем и помещен в “систему документоборота” проекта. • Вопрос к аудитории: а какие типы code review вы знаете?
ходу, по мере того, как пишется код) • Walkthrough (автор кода презентует результат непосредственно на сессии) • Technical review (рецензент проводит анализ кода до сессии на основе только своего опыта; результаты обсуждаются на сессии) • Inspection (рецензент проводит анализ кода до сессии, используя согласованные checklists; результаты обсуждаются на сессии)
документов и поддержание их в актуальном состоянии • Трудозатраты на инспекцию кода до сессии • Трудозатраты на проведение сессии (сколько там человеко-часов если сессия открыта для посещения всеми?) • Трудозатраты на оформление результатов сессии, создание дефектов и отслеживание их закрытия
регламентирующих документов (как называются, где лежат, прочитать последнюю версию) • Надо кодить с учетом checklists • Надо кодить с учетом стандартов • Надо уметь рецензировать чужой код • Надо уметь обсуждать технические проблемы • Надо аккуратно вести отчетность о проделанной работы
Для руководства бонусы снижаются • Для молодых, талантливых и амбициозных программистов жизнь проходит мимо • И еще один момент: менеджмент не всегда может правильно оценить реальные трудозатраты с учетом возможности управления качеством продукта. • На выходе: писать софт качественно - очень дорого. Мало кто может себе это позволить.
deeprefactoring
slashnephy
hirokunimaeta
licux
findyinc
macha64
niftycorp
mizchi
har1101
satohjohn
nrslib
o0h
blueswen
irinanazarova
jonoalderson
portentint
coloredviolet
mfonobong
kneath
axbom
lindahogenes
tammyeverts
madoxten
garrettdimon
reverentgeek
