экстремальное программирование. Технологии разработки программных приложений Этапы жизненного цикла
 Скачать 1.5 Mb.
|
Жизненные циклы разработки программного обеспечения. Экстремальное программированиепо дисциплине:«Технологии разработки программных приложений»Этапы жизненного цикла:
Основные методологии разработки программного обеспечения:
Кент Бек учился в Орегонском университете с 1979 по 1987 год, получил степени бакалавра и магистра по информатике. Был одним из пионеров в введении в практику шаблонов проектирования ПО, создании методологии разработки через тестирование, а также коммерческого использования языка Smalltalk. Бек популяризовал CRC-карты вместе с Уордом Каннингемом, совместно с Эрихом Гамма является создателем фреймворка для тестирования JUnit. Кент Бек живёт в городе Медфорд штат Орегон, работает на Facebook. Кент Бек Четыре направления экстремального программирования: Усовершенствовать взаимосвязь разработчиков Упростить проектные решения Усилить обратную связь с заказчиком Проявлять больше активности Кент Бек Основная проблема разработки программного обеспечения — это риск: Смещение графиков Закрытие проекта Система теряет полезность Количество дефектов и недочетов Несоответствие решаемой проблеме Изменение характера бизнеса Недостаток возможностей Текучка кадров Кент Бек Игра в планированиеПланирование в XP проводят в два этапа — планирование релиза и планирование итераций. Как и любая другая игра, планирование имеет своих участников и свою цель. Ключевой фигурой является, конечно же, заказчик. Именно он сообщает о необходимости той или иной функциональности. Программисты же дают ориентировочную оценку каждой функциональности. Прелесть игры в планирование заключается в единстве цели и солидарности разработчика и заказчика: в случае победы побеждают все, в случае поражения все проигрывают. Но при этом каждый участник идет к победе своей дорогой: заказчик выбирает наиболее важные задачи в соответствии с бюджетом, а программист оценивает задачи в соответствии со своими возможностями по их реализации. КомандаСо стороны исполнителей в команду входят разработчики и тестировщики, иногда коуч, направляющий команду, и менеджер, который обеспечивает команду ресурсами. План релизовПлан релизов определяет даты релизов и формулировки пользователей, которые будут воплощены в каждом из них. Исходя из этого можно выбрать формулировки для очередной итерации. В течение итерации изготавливаются тесты приемки, которые выполняются в пределах этой итерации и всех последующих, чтобы обеспечить правильную работу программы. План может быть пересмотрен в случае значительного отставания или опережения по итогам одной из итераций. Планирование итерацийПланирование итераций начинается со встречи в начале каждой итерации с целью выработки плана шагов для решения программных задач. Каждая итерация должна длиться от одной до трех недель. Формулировки внутри итерации сортируются в порядке их значимости для заказчика. Кроме того, добавляются задачи, которые не смогли пройти тесты приемки и требуют доработки. Формулировки и результаты тестов переводятся в программные задачи. Задачи записываются на карточках, которые образуют детальный план итерации. СобранияКаждое утро проводится собрание для обсуждения проблем, их решений и для усиления концентрации команды. Собрание проводится стоя для избежания длительных дискуссий не интересных всем членам команды. В типичном собрании большинство участников ничего не вносят, просто участвуют, чтобы послушать, что скажут другие. Большое количество времени людей тратится, чтобы получить небольшое количество коммуникации. Поэтому участие всех людей в собраниях уводит ресурсы из проекта и создает хаос в планировании. ПростотаПростой дизайн всегда занимает меньше времени, чем сложный. Поэтому всегда делайте самые простые вещи, которые только смогут работать. Всегда быстрее и дешевле заменить сложный код сразу, прежде чем вы потратите много времени на работу с ним. Сохраняйте вещи такими простыми, как только возможно, не добавляя функциональность до того, как это запланировано. Имейте в виду: сохранять дизайн простым — это тяжелая работа. Система метафорМетафора системы — это ее сравнение с чем-то знакомым, чтобы сформировать у команды общее видение. Обычно метафору системы продумывает тот, кто разрабатывает архитектуру и представляет систему целиком. Заказчик на рабочей площадкеОсновной проблемой разработки программного обеспечения является недостаток знаний программистов в разрабатываемой предметной области. Экстремальное программирование нашло выход и из этой ситуации. Нет, это не стажировка разработчика на предприятии заказчика — он тогда не захочет программировать. Наоборот, это участие заказчика в процессе разработки. User StoryUser Story (что-то типа рассказа пользователя) — это описание того как система должна работать. Каждая User Story написана на карточке и представляет какой-то кусок функциональности системы, имеющий логический смысл с точки зрения Заказчика. Форма один-два абзаца текста понятного пользователю (не сильно технического). Тестирование до начала разработкиТестирование, в его классическом понимании, — довольно скучная процедура. Обычно нанимают тестировщика, который периодически выполняет одни и те же действия и ждет того дня, когда его, наконец, переведут на другую должность или появится возможность поменять работу. В экстремальном программировании роль тестирования интереснее: теперь вначале идет тест, а потом код. Как же тестировать то, чего еще нет? Ответ прост и банален: тестируйте свои мысли — чего следует ожидать от будущего куска программы или функциональности. Это позволит лучше понять, что требуется сделать программистам, и проверить работоспособность кода сразу, как только он будет написан. Парное программированиеВесь код для продукционной системы пишется парами. Два разработчика сидят рядом. Один набирает, другой смотрит. Время от времени они меняются. Не разрешается работать в одиночку. Если по какой-то причине второй из пары пропустил что-то (болел, отходил и т.п.) он обязан просмотреть все изменения сделанные первым. Смена позицийВо время очередной итерации всех работников следует перемещать на новые участки работы. Подобные перемещения необходимы, чтобы избежать изоляции знаний и устранить «узкие места». Особенно плодотворной является замена одного из разработчиков при парном программировании. Коллективное владение кодомКоллективное владение кодом стимулирует разработчиков подавать идеи для всех частей проекта, а не только для своих модулей. Любой разработчик может изменять любой код для расширения функциональности и исправления ошибок. Соглашение о кодированииВы в команде, которая работает над данным проектом продолжительное время. Люди приходят и уходят. Никто не кодирует в одиночку и код принадлежит всем. Всегда будут моменты, когда необходимо будет понять и скорректировать чужой код. Разработчики будут удалять или изменять дублирующий код, анализировать и улучшать чужие классы и т.п. Со временем нельзя будет сказать кто автор конкретного класса. Частая интеграцияКаждая пара разработчиков должна отдавать свой код, как только для этого появляется разумная возможность. Это может быть, когда все UnitTest-ы проходят на 100%. Отдавая изменения несколько раз в день, Вы сводите проблемы интеграции практически к нулю. Интеграция — это деятельность вида «заплати сейчас или заплати больше позднее». Поэтому, интегрируя изменения ежедневно маленькими порциями, вы не окажетесь перед необходимостью тратить неделю, чтобы связать систему в одно целое непосредственно перед сдачей проекта. Всегда работайте над последней версией системы. Сорокачасовая рабочая неделяЧеловек, особенно если он программист, ради дела способен на многое: задержаться на работе, выйти на работу на выходные, отказаться от отпуска, несколько суток не спать, сидя за клавиатурой… В общем, чего только не сделаешь ради любимого занятия. Но экстремальное программирование категорически против такого самопожертвования и нарушения принятых норм трудового права. Принципы XP
Преимущества XP заказчик получает именно тот продукт, который ему нужен, даже если в начале разработки сам точно не представляет его конечный вид команда быстро вносит изменения в код и добавляет новую функциональность за счет простого дизайна кода, частого планирования и релизов код всегда работает за счет постоянного тестирования и непрерывной интеграции команда легко поддерживает код, т.к. он написан по единому стандарту и постоянно рефакторится быстрый темп разработки за счет парного программирования, отсутствия переработок, присутствия заказчика в команде высокое качество кода снижаются риски, связанные с разработкой, т.к. ответственность за проект распределяется равномерно и уход/приход члена команды не разрушит процесс затраты на разработку ниже, т.к. команда ориентирована на код, а не на документацию и собрания недостатки XP успех проекта зависит от вовлеченности заказчика, которой не так просто добиться трудно предугадать затраты времени на проект, т.к. в начале никто не знает полного списка требований успех XP сильно зависит от уровня программистов, методология работает только с senior специалистами менеджмент негативно относится к парному программированию, не понимая, почему он должен оплачивать двух программистов вместо одного регулярные встречи с программистами дорого обходятся заказчикам требует слишком сильных культурных изменений, чтобы не контролировать каждую задачу из-за недостатка структуры и документации не подходит для крупных проектов т.к. гибкие методологии функционально-ориентированные, нефункциональные требования к качеству продукта сложно описать в виде пользовательских историй Приложения для внедрения XP в команде
|