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

1. Обзор прикладных методологий - выбираем адекватный процесс Александр Сербул Руководитель направления контроля качества интеграции и внедрений 1C-Битрикс

2. Причины появления процессов • Программирование – это как строить дом, каждый раз из новых материалов  • Большой объем требований от Клиента – структура, суть • Замена людей в проекте, «человеческие» риски • Много людей и «букв» • Кристаллизация историй успеха

3. Успех веб-проекта • Успешный – далее только в техническом плане. • Может ли Клиент «завалить» успешный веб-проект? • Все условия созданы, а Партнер «заваливает» веб-проект, почему? • Люди или методологии? • Компетенция, сертификации, совесть: «зачем делать просто, если можно сложно»?

4. Когда процесса - нет • Сделать к 1 ноября – конечно, деньги вперед!!! • Ничего не проектируется - зачем, все «понятно» • Разработчик делает «лишь бы работало до зарплаты» • Тестировщик покликал – багов нет! • Аврально вносятся изменения • Документация – а что это? • Этап сдан?

5. Делаем «на коленке» • Риски: • Систему все сложнее развивать (экспонента) • Новый программист пытается все переписать с нуля • Программист может и не разобраться в такой веб-системе • Веб-система - боится изменений • Никто не помнит, как все работает (даже Заказчик!) • Любое изменение рождает много ошибок • Тестировщик не знает, как все проверить

6. Давайте все пропишем в ТЗ! • Процесс – «Водопад»: • Подробно все проектируем, рисуем интерфейсы, описываем в ТЗ • Получаем ТЗ на 1000-20000 страниц • Кодируем • Проводим нагрузочные испытания • Тестируем • Сдаем проект/этап Заказчику • Работает на сложных/больших, специфических проектах. Любое изменение требует больших затрат на пересогласование, перепроектирование…

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

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

9. Вы – не эксперты! • Вы – не эксперты в предметной области! • Эксперт – Клиент (если повезет) • Нельзя «отрезать голову» у Клиента и заставить жить в офисе разработки • По мере формализации требований – будут появляться НОВЫЕ идеи • Это будет продолжаться – до запуска веб-системы

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

11. Итеративный процесс • Повторяем все фазы, но на каждом этапе • Улучшается обратная связь с Заказчиком – он принимает каждый этап (итерацию) • Занимаемся самыми приоритетными задачам и рисками • Затраты на проект распределяются равномерно, а не в конце проекта • Постоянное тестирование – в процессе, а не в конце • Эффективная загрузка команды • (+) Эффективно работает на сложных, больших проектах. Изменения требований – можно пережить. RUP • (-) Много ролей, сложно настроить, внедрить, поддерживать процесс.

12. Agile-манифест разработки программного обеспечения «Мы постоянно открываем для себя более совершенные методыразработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что: Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану То есть, не отрицая важности того, что справа, мы всё таки больше ценим то, что слева.» 2001 год

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

14. Agile

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

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

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

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

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

20. Agile –tests • Код тестирует сам себя! • Модульные тесты – для библиотек и т.п. • Функциональные тесты – часто более полезны, больший охват, вероятность срабатывания • Документация работы системы! Нет лишней работы • Пишите просто, лаконично • Тесты в веб-системе – это ВСЕГДА хорошо и полезно!  • Тесты все не покрывают, ну и что! 60% - и то хорошо

21. Agile –tests Selenium

22. Документирование кода • Кому это нужно? • PHPDocumentor – подсказки в IDE, автогенерация документации • Поддержка актуальности документации в коде • Код должен быть понятен САМ ПО СЕБЕ • Модульные и функциональные тесты – тоже документирование

23. XP XP – это «кровь и пот» боевых проектов, учимся на чужих ошибках! Kent Beck, “Chrysler ComprehensiveCompensation System (C3)”, 1996

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

25. XP

26. Kanban • Цель - сократить время прохода задачи до «готовности» • Задача = ММФ – минимальная маркетинговая фича • Уменьшение числа || выполняемых задач (“work in progress”) • Визуализация задач • Постоянное совершенствование производства • Система очень проста, удобна как для веб-студий, так и для работы с фрилансерами.

27. Kanban

28. Kanban

29. Спасибо за внимание! Вопросы? Александр Сербул serbul@1c-bitrix.ru @AlexSerbul