СУММА ТЕХНОЛОГИЙ

Agile (гибкие)

Гибкие (англ. agile ) методики разработки позволяют сократить затраты на разработку до 40%. Они нацелены на минимизацию рисков неудачи проекта.

Заказать сайт, задать вопрос 

Концепция гибкой разработки родилась в 90х годах прошлого века, под влиянием масштабного кризиса отрасли разработки ПО, когда классическая "водопадная" ("waterfall") модель стала неэффективной и приводила к постоянным срывам сроков проектов, притом, что команды разработчиков работали более 100 (!!!) часов в неделю (!!!!!). В настоящее время "гибкие" методики используются всеми ведущими мировыми компаниям - Google, Microsoft, Intel.

Наша компания применяет гибкие методики в разработке сайтов и порталов с 2004 года.

Гибкая методология разработки (англ. Agile software development) — это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения. Существует несколько подобных методик.

Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности:

  1. планирование,
  2. анализ требований,
  3. проектирование,
  4. кодирование,
  5. тестирование,
  6. документирование.

Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки.

Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом bullpen. Как минимум, она включает и «заказчиков» (product owner - заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.

Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации, по сравнению с другими методами. Это привело к критике этих методов, как недисциплинированных.

Принципы Agile

Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile Manifesto. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды.

Agile Manifesto разработан и принят 11-13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты. Манифест подписали представители следующих методологий eXtreme Programming (XP), Scrum, DSDM, Adaptive Software Development, Crystal Clear, Feature-Driven Development, Pragmatic Programming. Agile Manifesto cодержит 4 ценности, 12 принципов и не содержит практик.

Подход включает ценности, значимость которых нивелирована:

  • личности и их взаимодействия важнее, чем процессы и инструменты;
  • работающее программное обеспечение важнее, чем полная документация;
  • сотрудничество с заказчиком важнее, чем контрактные обязательства;
  • реакция на изменения важнее, чем следование плану.

Принципы, которые разъясняет Agile Manifesto:

  • удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО;
  • приветствие изменения требований, даже в конце разработки ( это может повысить конкурентоспособность полученного продукта);
  • частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще);
  • тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
  • проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
  • рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
  • работающее ПО — лучший измеритель прогресса;
  • спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок;
  • постоянное внимание на улучшение технического мастерства и удобный дизайн;
  • простота — искусство НЕ делать лишней работы;
  • лучшие архитектура, требования и дизайн получаются у самоорганизованной команды;
  • постоянная (частая) адаптация (улучшение эффективности работы) к изменяющимся обстоятельствам.

Экстремальное программирование (XP)

Экстрема́льное программи́рование (англ. eXtreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

Заказать сайт, задать вопрос 

 Основные приёмы XP

Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:

  • Короткий цикл обратной связи (Fine scale feedback)
    • Быстрые прототипы
    • Игра в планирование (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)

 

Парное программирование

Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего. При необходимости клавиатура свободно передается от одного к другому. В течение работы над проектом пары не фиксированы: рекомендуется их перемешивать, чтобы каждый программист в команде имел хорошее представление о всей системе. Таким образом, парное программирование усиливает взаимодействие внутри команды.

 Коллективное владение

Коллективное владение означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы. Парное программирование поддерживает эту практику: работая в разных парах, все программисты знакомятся со всеми частями кода системы. Важное преимущество коллективного владения кодом — в том, что оно ускоряет процесс разработки, поскольку при появлении ошибки её может устранить любой программист.

Давая каждому программисту право изменять код, мы получаем риск появления ошибок, вносимых программистами, которые считают что знают что делают, но не рассматривают некоторые зависимости. Хорошо определённые UNIT-тесты решают эту проблему: если не рассмотренные зависимости порождают ошибки, то следующий запуск UNIT-тестов будет неудачным.

 Заказчик всегда рядом

«Заказчик» в XP — это не тот, кто оплачивает счета, а тот, кто на самом деле использует систему. XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.

Литература

  • Кент Бек: Экстремальное программирование — Питер, 2002, ISBN 5-94723-032-1.
  • Кент Бек, Мартин Фаулер: Экстремальное программирование: планирование — Питер, 2003, ISBN 5-318-00111-4.
  • Кент Бек: Экстремальное программирование: разработка через тестирование — Питер, 2003, ISBN 5-8046-0051-6.

Итерация в проекте разработки сайта или портала

Итерация (лат. iteratio — повторение) — в математике, одно из ряда повторений какой-либо математической операции, использующее результат предыдущей аналогичной операции.

Заказать сайт, задать вопрос 

Например: вычисление Факториала — N! = 1 х 2 х 3 x … x (N-1) x N, где N — любое целое число; Каждое последовательное умножение носит название «итерация».

Итерация в программировании

Итерация — это организация обработки данных, при которой действия повторяются многократно, не приводя при этом к вызовам самих себя.

Когда какое-то действие необходимо повторить большое количество раз, в программировании используются циклы. Например, нужно вывести 200 раз на экран текст «Hello, World!». Вместо 200-кратного повторения одной и той же команды вывода текста часто создается цикл, который прокручивается 200 раз, и 200 раз выполняет то, что написано в теле цикла. Один шаг цикла и называется итерацией.

Итерация в разработке программного обеспечения

Итерация — это организация работ в проекте следующим образом:

  1. Весь проект разделяется на участки работ - итерации,  выполнение которые занимает 1 (одну) неделю;
  2. В конце каждой итерации заказчик видит значимое изменение в состоянии проекта;
  3. После каждой итерации происходит оценка хода проекта:
    1. уточнение требований или пожеланий заказчика,
    2. анализ требований исполнителями,
    3. оценка исполнителями динамики проекта и сроков его реализации,
    4. внесение исполнителями изменений в план разработки и бюджет проекта,
    5. утверждение плана и бюджета с заказчиком;
  4. Если изменения требований или какие-то неучтённые ранее причины серьёзно меняют план и/или  бюджет проекта, и изменения не принимаются одной из сторон, то проводятся переговоры между сторонами исходя из стратегии обоюдного выигрыша (win-win).

Scrum- Скрам процессы разработки интернет сайтов, порталов

= scrimmage (англ.) * 1. существительное: 1) драка, потасовка Синонимы: scuffle, fight 2) спорт. драка за мяч (в регби) 2. глагол: 1) драться, участвовать в потасовке 2) спорт. драться за мяч

Заказать сайт, задать вопрос 

Scrum — методология управления проектами. Scrum чётко делает акцент на качественном контроле процесса разработки.

Подход впервые описали Хиротака Такеути и Икудзиро Нонака[1] в статье The New Product Development Game (Гарвардский Деловой Обзор[2], январь-февраль 1986). Они отметили, что проекты, над которыми работают небольшие, кросс-функциональные команды, обычно систематически производят лучшие результаты, и объяснили это как «подход регби». В 1991 году ДеГрейс и Шталь в книге «Злые проблемы, справедливые решения»[3] ссылались на этот подход, как на Scrum (толкотня; схватка вокруг мяча (в регби)), спортивный термин, приведённый в статье Такеути и Нонакой. Кен Швабер в начале 1990-х использовал подход, который привел Scrum в его компанию. Впервые метод Scrum был представлен на общее обозрение задокументированным, чётко сформированным и описанным совместно Сазерлендом и Швабером на OOPSLA’96[4]  в Остине. Швабер и Сазерленд на протяжении следующих лет работали вместе, чтобы обработать и описать весь их опыт и лучшие практические образцы для индустрии в одно целое, в ту методологию, что известна сегодня как Scrum. Швабер объединил усилия с Майком Бидлом[5] в 2001 году, чтобы детально описать метод в книге «Agile Software Development with SCRUM». Не обращая внимания на то, что для Scrum предрекли судьбу управления проектами по разработке ПО, он может также использоваться в работе команд обслуживания программного обеспечения (software maintenance teams), или как подход управления разработкой и сопровождением программ: Scrum of Scrums.


 Определение Scrum

Скрам процессы

Scrum — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные небольшие промежутки времени (спринты от 2 до 4 недель) предоставлять конечному пользователю работающее ПО с добавленными возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго-фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.

Главные действующие роли в Scrum:

  • ScrumMaster — тот, кто ведёт Scrum митинги и следит, чтобы при этом соблюдались все принципы Scrum (роль не предполагает ничего кроме корректного ведения самого Scrum-а, руководитель проекта скорее относится к Product Owner и не должен являться ScrumMaster);
  • Владелец Продукта (Product Owner) — человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон;
  • кросс-функциональную Команду (Scrum Team), состоящую как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т. д. (при этом размер команды в идеале составляет 7±2 человека). Команда является единственным полностью вовлечённым участником разработки, и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении итерации-спринта.

На протяжении каждого итерации-спринта[6], 7-15-30 дневного периода (длительность определяется командой), создаётся функциональный рост программного обеспечения.

Набор возможностей, которые реализуются в каждом спринте, происходят из этапа, называемого product backlog (документация запросов на выполнение работ), обладающего наивысшим приоритетом по уровню требований к работе, который должен быть выполнен. Запросы на выполнение работ (backlog items), определенных на протяжении совета по планированию спринта (sprint planning meeting), перемещаются в этап спринта. На протяжении этого собрания Владелец Продукта информирует о заданиях, которые должны быть выполнены. Тогда Команда определяет, сколько из желаемого они могут выполнить, чтобы завершить необходимые части на протяжении следующего спринта[7]. Во время спринта команда выполняет определенный фиксированный список заданий (т. н. sprint backlog). На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать как заморозку требований (requirements) во время спринта.

Роли в scrum-процессе

По методике Scrum в производственном процессе есть определенные роли, разбитые на 2 группы «свиней» и «цыплят». Эти названия были использованы из-за шутки[8]

Курица говорит свинье: «Давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как мы его назовем?» Курица подумала и говорит: «Почему бы не назвать 'Бекон с яйцами'?». «Так не пойдёт», — отвечает свинья, «ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично.»

Так что свиньи создают продукт, тогда как цыплята заинтересованы, но не настолько — ведь им всё равно, будет ли проект удачным или нет, на них это мало отразится. Требования, пожелания, идеи и влияние цыплят принимаются во внимание, но им не разрешают непосредственно включаться в ход Scrum-проекта.

«Свиньи»

Свиньи полностью включены в проект, в Скрам процесс, они как бы едины со «своей сущностью» на производственной линии.

  • Владелец Продукта (Product Owner)
  • Руководитель (ScrumMaster)
  • Команда (Scrum Team)

«Цыплята»

  • Пользователи (Users)
  • Клиенты, Продавцы (Stakeholders)
  • Эксперты-консультанты (Consulting Experts)

 

Артефакты

 Product backlog (бэклог)

Product backlog — это документ, содержащий список требований к функциональности, которые упорядочены по степени важности. Product backlog представляет собой список того что должно быть реализовано. Элементы этого списка называются «историями» (user story) или элементами backlog’a (backlog items). Product backlog открыт для редактирования для всех участников Scrum-процесса.

Обязательные поля бэклога

  • ID — уникальный идентификатор, порядковый номер, применяемый для идентификации историй в случае их переименования.
  • Название (Name) — краткое описание истории. Оно должно быть однозначным, чтобы и разработчики, и product owner могли понять, о чем идёт речь и отличить одну историю от другой.
  • Важность (Importance) — степень важности данной истории, по мнению product owner’a. Обычно представляет собой натуральное число, иногда для этой цели используются числа Фибоначчи. Чем больше значение, тем выше приоритет.
  • Предварительная оценка (initial estimate) — начальная оценка объёма работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в story point’ах. Приблизительно соответствует числу «идеальных человеко-часов».
  • Как продемонстрировать (how to demo) — краткое пояснение того, как завершённая задача будет продемонстрирована в конце спринта. Данное поле может представлять собой код автоматизированного теста для приёмо-сдаточного испытания.

Дополнительные поля

Иногда, также, используются дополнительные поля в product backlog, в основном для того, чтобы помочь product owner’у определиться с его приоритетами.

  • Категория (track). Например, «панель управления» или «оптимизация». При помощи этого поля product owner может легко выбрать все пункты категории «оптимизация» и установить им низкий приоритет.
  • Компоненты (components) — указывает, какие компоненты (например, база данных, сервер, клиент) будут затронуты при реализации истории. Данное поле состоит из группы checkbox’ов, которые отмечаются, если соответствующие компоненты требуют изменений.
  • Инициатор запроса (requestor). Product owner может захотеть хранить информацию о всех заказчиках, заинтересованных в данной задаче. Это нужно для того, чтобы держать их в курсе дела о ходе выполнения работ.
  • ID в системе учёта дефектов (bug tracking ID) — если вы используете отдельную систему для учёта дефектов (например. Jira), тогда в описании истории полезно хранить ссылки на все дефекты, которые к ней относятся.

Встречи

Планирование спринта (Planning Meeting)

Происходит в начале итерации.

  • Выбирается объём работ, обязательства по выполнению которой за спринт принимает на себя команда
  • Обсуждается и определяется, каким образом будет реализован этот объём работ
  • Каждая запись PBL принятая к реализации разбивается на подзадачи, которые оцениваются в идеальных человеко-часах
  • Ограничен 4-8 часами в зависимости от продолжительности итерации, опыта команды и т. п.

Митинг (Daily Scrum)

Burndown-диаграмма, отображает текущее состояние спринта, степень отставания/опережения плана.

Происходит каждый день в течение спринта. Является «пульсом» хода спринта. Митингу присущи следующие ограничения:

  • начинается точно вовремя;
  • все могут наблюдать, но только «свиньи» говорят;
  • ограничен во времени 15-ю минутами;
  • проводится в одном и том же месте в течение спринта.

В течение митинга каждый член команды отвечает на 3 вопроса.

  • Что сделано с момента предыдущего митинга до текущего?
  • Что будет сделано с момента текущего митинга до следующего?
  • Какие проблемы мешают достижению целей спринта? (Над решением этих проблем работает Скрам Мастер. Обычно это решение проходит за рамками митинга и в составе лиц, непосредственно затронутых данным препятствием.)

Демонстрация (Demo Meeting)

  • Происходит в конце итерации.
  • Команда демонстрирует инкремент функциональности продукта всем заинтересованным лицам.
  • Привлекается максимальное количество зрителей.
  • Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).
  • Ограничена 4-мя часами в зависимости от продолжительности итерации и инкремента продукта.

Ретроспектива (Retrospective Meeting)

  • Все члены команды рассказывают своё отношение к ходу прошедшего спринта.
  • Отвечают на два основных вопроса (Что было сделано хорошо в прошедшем спринте? Что надо улучшить или не допускать в следующем?).
  • Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).
  • Ограничена 1—3-мя часами.

Примечания

  1. Hirotaka Takeuchi, Ikujiro Nonaka
  2. Harvard Business Review
  3. Peter DeGrace, Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms Yourdon Press Computing Series, 1990 (первое издание) ISBN 0-13-590126-X
  4. OOPSLA 2006
  5. Mike Beedle
  6. Sprint — рывок; бросок; бег на короткую дистанцию; спринт
  7. Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004, 163pp, ISBN 0-7356-1993-X
  8. page 7