Выбор методологии разработки

Выбор методологии разработки
Александр Сербул
Руководитель направления контроля качества интеграции и внедрений
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 Comprehensive
Compensation System (C3)”, 1996
XP
Экстремальное программирование (extreme
programming) – 13 правил
XP
Kanban
Цель - сократить время прохода задачи до
«готовности»
Задача = ММФ – минимальная маркетинговая фича
Уменьшение числа || выполняемых ЧЕЛОВЕКОМ задач (“work
in progress”)
Визуализация задач
Постоянное совершенствование производства
Система очень проста, удобна как для веб-студий, так и для
работы с фрилансерами.
Kanban
Kanban
Спасибо за внимание!
Вопросы?
Александр Сербул
serbul@1c-bitrix.ru
@AlexSerbul