ОСНОВНЫЕ ПРИНЦИПЫ ХР
1.Планирование
2.Частая смена версий
3.Метафора
4.Простой проект
5.Тесты
6.Переработка системы
7.Программирование в паре
8.Непрерывная
интеграция
9.Коллективное владени
е
10.Заказчик с постоянным участием
11.40-часовая неделя
12.Открытое рабочее пространство
13.Стандарты кодировани
я
14.Не более чем правила
Область применимости ХР: небольшие и средние проекты.
46
Extreme programming explained
Короткий цикл обратной связи (Fine scale feedback)
Разработка через тестирование (Test driven development)
Игра в планирование (Planning game)
Заказчик всегда рядом (Whole team, Onsite customer)
Парное программирование (Pair programming)
Непрерывный, а не пакетный процесс
Непрерывная интеграция (Continuous Integration)
Рефакторинг (Design Improvement, Refactor)
Частые небольшие релизы (Small Releases)
Понимание, разделяемое всеми
Простота (Simple design)
Метафора системы (System metaphor)
Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
Стандарт кодирования (Coding standard or Coding conventions)
Социальная защищенность программиста (Programmer welfare):
40-часовая рабочая неделя (Sustainable pace, Forty hour week)
РЕФАКТОРИНГ
Рефакторинг — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы
В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований
Цель рефакторинга — сделать код программы более легким для понимания; без этого рефакторинг нельзя считать успешным
НЕОБХОДИМОСТЬ РЕФАКТОРИНГА
1.Дублирование кода
2.Длинный метод
3.Большой класс
4.Длинный список параметров
5.«Завистливые» функции — метод, который чрезмерно обращается к данным другого объекта
6.Избыточные временные переменные
7.Классы данных
8.Не сгруппированные данные
SCRUM
Ken Schwaber & Jeff Sutherland, 199
Технология (набор принципов), на которых строится процесс разработки, позволяющий в жѐстко фиксированные небольшие промежутки времени (спринты от 2 до 4 недель) предоставлять конечному пользователю
работающее ПО с новыми
возможностями, для которых определѐн
наибольший приоритет.
С ЧЕГО ВСЕ НАЧИНАЛОСЬ
Курица говорит свинье: «Давай откроем ресторан!»
Свинья смотрит на курицу и отвечает: «Хорошая идея, и как мы его назовем?»
Курица подумала и говорит: «Почему бы не назвать «Яичница с беконом?»».
«Так не пойдѐт», — отвечает свинья, «ведь тогда мне придѐтся полностью посвятить себя проекту, а ты будешь вовлечена только частично»…
РОЛИ
«Свиньи»
ScrumMaster — тот, кто ведѐт Scrum митинги. Является интерфейсом между менеджментом и командой (менеджер проекта или teamlead). Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды - команда является самоорганизующейся и
самоуправлямой
Владелец Продукта (Product Owner) — человек, отвечающий за разработку продукта который представляет интересы конечных пользователей и других заинтересованных в продукте сторон. Ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта
Команда (Scrum Team), состоящая как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т. д. (7±2 человека).
«Цыплята»
Пользователи (Users)
Клиенты, Продавцы (Stakeholders)
Эксперты-консультанты (Consulting Experts)
Product Backlog — приоритезированный список
имеющихся на данный момент бизнес-требований и технических требований к системе.
Включает в себя use cases, defects, enhancements, technologies, stories, features, issues, и т.д..
Также включает задачи, важные для команды, например
ПЛАНИРОВАНИЕ СПРИНТА
ПРОЦЕСС. ВСТРЕЧИ
Планирование спринта (Planning Meeting)
Митинг (Daily Scrum)
Что сделано с момента предыдущего митинга до текущего?
Что будет сделано с момента текущего митинга до следующего?
Какие проблемы мешают достижению целей спринта?
Демонстрация (Demo Meeting)
Ретроспектива (Retrospective Meeting)