Обзор прикладных методологий - выбираем адекватный процесс

Александр СербулРуководитель направления контроля качества интеграции и внедрений

1C-Битрикс

Причины появления процессов

Программирование – это как строить дом, каждый раз из новых материалов

Большой объем требований от Клиента – структура, суть

Замена людей в проекте, «человеческие» риски

Много людей и «букв»

Кристаллизация историй успеха

Успех веб-проекта

Успешный – далее только в техническом плане.

• Может ли Клиент «завалить» успешный веб-проект?

• Все условия созданы, а Партнер «заваливает» веб-проект, почему?

• Люди или методологии?

• Компетенция, сертификации, совесть: «зачем делать просто, если можно сложно»?

Когда процесса - нет

Сделать к 1 ноября – конечно, деньги вперед!!!

Ничего не проектируется - зачем, все «понятно»

Разработчик делает «лишь бы работало до зарплаты»

Тестировщик покликал – багов нет!

Аврально вносятся изменения

Документация – а что это?

Этап сдан?

Делаем «на коленке»

Риски:

• Систему все сложнее развивать (экспонента)

• Новый программист пытается все переписать с нуля

• Программист может и не разобраться в такой веб-системе

• Веб-система - боится изменений

• Никто не помнит, как все работает (даже Заказчик!)

• Любое изменение рождает много ошибок

• Тестировщик не знает, как все проверить

Давайте все пропишем в ТЗ!

Процесс – «Водопад»:

• Подробно все проектируем, рисуем интерфейсы, описываем в ТЗ

• Получаем ТЗ на 1000-20000 страниц

• Кодируем

• Проводим нагрузочные испытания

• Тестируем

• Сдаем проект/этап Заказчику

Работает на сложных/больших, специфических проектах. Любое изменение требует больших затрат на пересогласование, перепроектирование…

Давайте все делать последовательно!

Давайте все пропишем в ТЗ!

Вы – не эксперты!

• Вы – не эксперты в предметной области!

• Эксперт – Клиент (если повезет)

• Нельзя «отрезать голову» у Клиента и заставить жить в офисе разработки

• По мере формализации требований – будут появляться НОВЫЕ идеи

• Это будет продолжаться – до запуска веб-системы

Итеративный процесс

Итеративный процесс

Повторяем все фазы, но на каждом этапе

Улучшается обратная связь с Заказчиком – он принимает каждый этап (итерацию)

Занимаемся самыми приоритетными задачам и рисками

Затраты на проект распределяются равномерно, а не в конце проекта

Постоянное тестирование – в процессе, а не в конце

Эффективная загрузка команды

(+) Эффективно работает на сложных, больших проектах. Изменения требований – можно пережить. RUP

(-) Много ролей, сложно настроить, внедрить, поддерживать процесс.

Agile-манифест разработки программного обеспечения

«Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

Люди и взаимодействие важнее процессов и инструментовРаботающий продукт важнее исчерпывающей документацииСотрудничество с заказчиком важнее согласования условий контрактаГотовность к изменениям важнее следования первоначальному плану

То есть, не отрицая важности того, что справа, мы всё таки больше ценим то, что слева.»

2001 год

Agile-манифест разработки программного обеспечения

«Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.»

«Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.»

«Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.»

«Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.»

«Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчикуконкурентного преимущества. .»

Agile

Agile – управление требованиями

Agile - планирование

Agile – короткие итерации, feedback

Agile – короткие итерации, feedback

Agile – полный цикл

Agile – tests

Код тестирует сам себя!

• Модульные тесты – для библиотек и т.п.

• Функциональные тесты – часто более полезны, больший охват, вероятность срабатывания

• Документация работы системы! Нет лишней работы

• Пишите просто, лаконично

• Тесты в веб-системе – это ВСЕГДА хорошо и полезно!

• Тесты все не покрывают, ну и что! 60% - и то хорошо

Agile – tests

Selenium

Документирование кода

Кому это нужно?

PHPDocumentor – подсказки в IDE, автогенерация документации

Поддержка актуальности документации в коде

Код должен быть понятен САМ ПО СЕБЕ

Модульные и функциональные тесты – тоже документирование

XP

XP – это «кровь и пот» боевых проектов, учимся на чужих ошибках!

Kent Beck, “Chrysler ComprehensiveCompensation System (C3)”, 1996

XP

Экстремальное программирование (extreme programming) – 13 правил

XP

Kanban

Цель - сократить время прохода задачи до «готовности»

• Задача = ММФ – минимальная маркетинговая фича

• Уменьшение числа || выполняемых задач (“work in progress”)

• Визуализация задач

• Постоянное совершенствование производства

Система очень проста, удобна как для веб-студий, так и для работы с фрилансерами.

Kanban

Kanban

Спасибо за внимание! Вопросы?

Александр Сербулserbul@1c-bitrix.ru

@AlexSerbul