Выбор методологии разработки Александр Сербул Руководитель направления контроля качества интеграции и внедрений 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