290 likes | 413 Views
Обзор прикладных методологий - выбираем адекватный процесс. Александр Сербул Руководитель направления контроля качества интеграции и внедрений 1C- Битрикс. Причины появления процессов. Программирование – это как строить дом, каждый раз из новых материалов
E N D
Обзор прикладных методологий - выбираем адекватный процесс Александр Сербул Руководитель направления контроля качества интеграции и внедрений 1C-Битрикс
Причины появления процессов • Программирование – это как строить дом, каждый раз из новых материалов • Большой объем требований от Клиента – структура, суть • Замена людей в проекте, «человеческие» риски • Много людей и «букв» • Кристаллизация историй успеха
Успех веб-проекта • Успешный – далее только в техническом плане. • Может ли Клиент «завалить» успешный веб-проект? • Все условия созданы, а Партнер «заваливает» веб-проект, почему? • Люди или методологии? • Компетенция, сертификации, совесть: «зачем делать просто, если можно сложно»?
Когда процесса - нет • Сделать к 1 ноября – конечно, деньги вперед!!! • Ничего не проектируется - зачем, все «понятно» • Разработчик делает «лишь бы работало до зарплаты» • Тестировщик покликал – багов нет! • Аврально вносятся изменения • Документация – а что это? • Этап сдан?
Делаем «на коленке» • Риски: • Систему все сложнее развивать (экспонента) • Новый программист пытается все переписать с нуля • Программист может и не разобраться в такой веб-системе • Веб-система - боится изменений • Никто не помнит, как все работает (даже Заказчик!) • Любое изменение рождает много ошибок • Тестировщик не знает, как все проверить
Давайте все пропишем в ТЗ! • Процесс – «Водопад»: • Подробно все проектируем, рисуем интерфейсы, описываем в ТЗ • Получаем ТЗ на 1000-20000 страниц • Кодируем • Проводим нагрузочные испытания • Тестируем • Сдаем проект/этап Заказчику • Работает на сложных/больших, специфических проектах. Любое изменение требует больших затрат на пересогласование, перепроектирование…
Давайте все делать последовательно!
Вы – не эксперты! • Вы – не эксперты в предметной области! • Эксперт – Клиент (если повезет) • Нельзя «отрезать голову» у Клиента и заставить жить в офисе разработки • По мере формализации требований – будут появляться НОВЫЕ идеи • Это будет продолжаться – до запуска веб-системы
Итеративный процесс • Повторяем все фазы, но на каждом этапе • Улучшается обратная связь с Заказчиком – он принимает каждый этап (итерацию) • Занимаемся самыми приоритетными задачам и рисками • Затраты на проект распределяются равномерно, а не в конце проекта • Постоянное тестирование – в процессе, а не в конце • Эффективная загрузка команды • (+) Эффективно работает на сложных, больших проектах. Изменения требований – можно пережить. RUP • (-) Много ролей, сложно настроить, внедрить, поддерживать процесс.
Agile-манифест разработки программного обеспечения «Мы постоянно открываем для себя более совершенные методыразработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что: Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану То есть, не отрицая важности того, что справа, мы всё таки больше ценим то, что слева.» 2001 год
Agile-манифест разработки программного обеспечения «Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.» «Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчикуконкурентного преимущества. .» «Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.» «Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.» «Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.»
Agile –tests • Код тестирует сам себя! • Модульные тесты – для библиотек и т.п. • Функциональные тесты – часто более полезны, больший охват, вероятность срабатывания • Документация работы системы! Нет лишней работы • Пишите просто, лаконично • Тесты в веб-системе – это ВСЕГДА хорошо и полезно! • Тесты все не покрывают, ну и что! 60% - и то хорошо
Agile –tests Selenium
Документирование кода • Кому это нужно? • PHPDocumentor – подсказки в IDE, автогенерация документации • Поддержка актуальности документации в коде • Код должен быть понятен САМ ПО СЕБЕ • Модульные и функциональные тесты – тоже документирование
XP XP – это «кровь и пот» боевых проектов, учимся на чужих ошибках! Kent Beck, “Chrysler ComprehensiveCompensation System (C3)”, 1996
XP Экстремальное программирование (extreme programming) – 13 правил
Kanban • Цель - сократить время прохода задачи до «готовности» • Задача = ММФ – минимальная маркетинговая фича • Уменьшение числа || выполняемых задач (“work in progress”) • Визуализация задач • Постоянное совершенствование производства • Система очень проста, удобна как для веб-студий, так и для работы с фрилансерами.
Спасибо за внимание! Вопросы? Александр Сербул serbul@1c-bitrix.ru @AlexSerbul