12 практических методик Extreme Programming

Loading...

來自 National Research Nuclear University MEPhI 的課程

Разработка корпоративных систем. Часть 3. Гибкие методологии разработки

17 個評分

National Research Nuclear University MEPhI

Разработка корпоративных систем. Часть 3. Гибкие методологии разработки

17 個評分

Предметом курса являются методологии создания корпоративных систем — подходы к организации, планированию и управлению процессами их разработки. В разделе рассматриваются методологические основы «гибкой» разработки программных систем, а также систематизируются практические приемы — «лучшие практики» их применения. Исследуется влияние методологий разработки на характер и масштаб программных систем. Основное внимание при этом уделяется сравнительному анализу наиболее значимых «гибких» методологий разработки программных систем, которые нацелены на максимальную адаптивность к быстро изменяющимся условиям бизнеса. Систематизация «гибких» методологий проводится также и в аспекте их практической пригодности для разработки корпоративных систем. Будут рассмотрены следующие основные вопросы: Что такое методология? Чем отличаются строгие методологии от гибких? Почему необходимы методологии? При каких условиях применимы такие методологии? В чем особенности применения гибких методологий разработки к корпоративным приложениям? Какие этапы включает в себя каждая из гибких методологий? Как организуются процессы разработки? В чем особенности команды разработки? Почему важно непрерывное взаимодействие с заказчиком? Какие методологии лучше подходят для различных видов программных продуктов?

從本節課中

Классификация «гибких» методологий

В этом модуле будет рассмотрена классификация гибких методологий, таких, как Scrum, eXtreme Programming или ХP и Agile: каким образом происходила история развития этих методологий, какие практические приемы удалось наработать, какие из них сработали, какие не сработали.

12 практических методик Extreme Programming3:44

與講師見面

Зыков Сергей Викторович
Доцент
Кафедра кибернетики

На слайде представлены так называемые

12 практик экстремального программирования,

рекомендованные автором Кентом Беком.

И здесь важно отметить, что

все эти практики должны быть реализованы в совокупности.

Если мы выбрасываем хоть одну,

то как правило весь процесс распадается,

становится действительно анархичным

и разработка уже не приносит тех плодов,

как если бы мы использовали все эти подходы,

все эти принципы вместе.

Среди этих принципов есть довольно экзотичные,

как скажем, парное программирование,

которые подходят, может быть не всем,

может быть не всем нравятся,

но которые, к сожалению, так или иначе надо использовать.

Я остановлюсь на самых основных из этих практик.

Прежде всего, это быстрый выпуск версий,

релизов и быстрые итерации.

Т. е. на самом деле каждая итерация длится,

наверное, не более недели,

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

Т. е. мы действительно можем достаточно быстро

показывать заказчику, каким образом мы прогрессируем,

каким образом мы движемся вперед,

как мы дополняем ту функциональность,

которая ему крайне необходима,

и как мы меняемся в зависимости от тех требований,

которые возникают со стороны заказчика —

это могут быть новые требования,

это может быть коррекция существующих и т. д.

Метафора — очень важная вещь,

достаточно интересный принцип ХР,

который состоит в том, что для правильного

и единообразного понимания того,

как система будет работать,

мы должны выбрать одно слово

или несколько слов,

которые концентрированно описываю что же именно

мы собираемся делать, что должен делать наш продукт.

Для того чтобы корректно оттранслировать это

в терминологию заказчика, которая, на самом деле,

зачастую включает совершенно другие понятия,

мы используем метафору.

Простота реализации.

Я уже говорил о том, каждый фрагмент кода

должен быть реализован как можно более кратко,

как можно более лаконично,

как можно более просто, для того чтобы

не возникало последующих проблем

с его прочтением и, возможно, многозначной интерпретацией.

Опережающее тестирование — тесты до кода,

рефакторинг при этом, т. е. если это необходимо,

код рекомендуется упростить, упорядочить,

улучшить, но это уже после того,

как изменения приняты и включены в релиз,

и заказчик понял, что на самом деле,

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

или его прототип вполне может работать.

Парное программирование — достаточно экзотичная методика

для некоторых разработчиков, которые, являются, может быть,

индивидуалистами, которые считают, что их код

является наиболее грамотным, наиболее надежным,

наиболее безопасным, наиболее хорошо документированным

или вообще он документирует сам себя

и никакая документация ему не нужна,

наиболее коротким, наиболее красивым и т. д.

Т. е. не хотят терпеть рядом с собой ментора,

наставника или какого-то подсказчика,

который рассказывает, как лучше писать код.

На самом деле, зачем нужно парное программирование?

Для того чтобы в случае, если мы теряем

одного разработчика по какой-то причине

на время или навсегда — он может перейти в другой проект,

он может, наконец, просто заболеть.

Совместное владение кодом обеспечивается в этом случае.

Непрерывная интеграция, 40-ка часовая неделя —

как мы говорили, никаких переработок,

хорошо оборудованное рабочее место,

постоянный контакт с заказчиком

и соблюдение основных метрик

и стандартов кодирования — вот то, что предписывает ХР.

探索我們的目錄

免費加入並獲得個性化推薦、更新和優惠。

Coursera 致力於普及全世界最好的教育，它與全球一流大學和機構合作提供在線課程。

© 2018 Coursera Inc. 保留所有權利。

通過 App Store 下載

通過 Google Play 獲取