Обзор прикладных методологий - выбираем адекватный...
DESCRIPTION
Обзор прикладных методологий - выбираем адекватный процесс. Александр Сербул Руководитель направления контроля качества интеграции и внедрений 1C- Битрикс. Причины появления процессов. Программирование – это как строить дом, каждый раз из новых материалов - PowerPoint PPT PresentationTRANSCRIPT
Обзор прикладных методологий - выбираем адекватный процесс
Александр СербулРуководитель направления контроля качества интеграции и внедрений
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