Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Краткая история индустрии ПО
Опасность – Водопад – Шаг назад
В 1960‑е, когда разработка ПО была относительно новой индустрией, еще рано было говорить о формализации процесса. Программисты просто старались угадать, сколько времени займет процесс, и начинали писать программы. Часто их предположения оказывались ошибочны, и они катастрофически не вписывались в бюджет. В 1970‑е с целью привнести немного порядка в эту непредсказуемую сферу, многие разработчики (обычно по распоряжению менеджеров, не имеющих отношения к технологиям) пытались внедрить в разработку ПО «модель водопада»: упорядоченный алгоритм создания ПО за семь шагов. Обычно эта модель выглядела вот так.
И это, конечно, выглядит привлекательно! Модель состоит из семи упорядоченных шагов: выполнив один из них, вы просто переходите к следующему. Само название «водопад» не предусматривает повторов, ведь водопады не текут вверх по течению. У этой модели несомненно было одно хорошее качество: она мотивировала разработчиков посвящать больше времени планированию и дизайну до того, как они приступят непосредственно к написанию кода. Но в остальном это полная ерунда, подобный подход нарушает Правило цикла. Менеджеры нашли модель привлекательной, но программисты знали, что это абсурд: в применении к таким сложным сферам, как разработка ПО, подобные линейные процессы обречены на провал. Даже Винстон Ройс (Winston Royce), чья работа послужила фундаментом для создания этой модели, не признает ее эффективность в общепринятом виде. Интересно, что в своей работе он подчеркивает важность циклов в разработке и говорит о возможности возврата на несколько шагов назад, если ситуация того требует. И он никогда не использовал слово «водопад»! Но в университетах и корпорациях изучали именно этот линейный подход. Это можно объяснить лишь тем, что люди, которые никогда в жизни не имели дело с разработкой программного обеспечения, принимали желаемое за действительное.
Барри Бим любит тебя
Позже, в 1986‑м, Барри Бим представил другую модель, имевшую гораздо больше общего с реальным процессом разработки ПО. Это несколько пугающая своим видом схема, в которой процесс разработки начинается с середины и раскручивается по часовой стрелке, проходя через окружность снова и снова (рис. 8.3).
Его модель состоит из множества сложных деталей, но все они нам не нужны. В основном здесь можно отметить три замечательные идеи: оценка рисков, прототипы и цикличность. Согласно спиральной модели, вам нужно сделать следующее. 1. Определиться с основой дизайна. 2. Высчитать самые большие риски вашего дизайна. 3. Создать прототипы, которые уменьшат эти риски. 4. Протестировать прототипы. 5. Определиться с более детальным дизайном, основываясь на информации, которую вы получили. 6. Вернуться к пункту 2. В целом вы просто повторяете этот цикл, пока все не встанет на свои места. При таком раскладе у модели водопада нет никаких шансов, потому что в данном цикле все основывается на вышеупомянутом Правиле цикла. Также это позволяет нам ответить на вопросы, которые мы задавали ранее. • Вопрос цикла 1: Как сделать каждый цикл эффективным? Ответ спиральной модели: Оцените ваши риски и оптимизируйте их. • Вопрос цикла 2: Как можно максимально ускорить циклы? Ответ спиральной модели: Создавайте больше «черновых» прототипов. У спиральной модели было множество последователей, но еще более широкого распространения добился манифест Agile.
Манифест Agile
В 2001 году на лыжном курорте Сноуберд в штате Юта произошло событие, оказавшее очень сильное влияние на современный геймдизайн и разработку: группа программистов приняла Манифест Agile. Следуя по стопам Барри Бима, они сформировали список ценностей и принципов, лежащих в основе разработки высококачественного ПО. Давайте ознакомимся с самим манифестом и его 12 принципами.
Люди и взаимодействия важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану Иными словами, мы осознаем ценность понятий, которые находятся справа, но понятия слева мы ценим выше
Мы исповедуем следующие принципы. 1. Наша главная цель – удовлетворить заказчика быстрой и бесперебойной поставкой качественного программного обеспечения.
2. Приветствие изменений требований даже на поздних этапах разработки. Это может повысить конкурентоспособность полученного продукта. 3. Поставлять работающее ПО с частотой от раза в несколько недель до раза в несколько месяцев, стараясь изменять частоту в меньшую сторону. 4. Тесное общение заказчика с разработчиками на протяжении всего проекта. 5. Проектом должны заниматься заинтересованные люди, нужно обеспечить их необходимыми условиями работы, поддерживать их и доверять им. 6. Самый эффективный способ передавать информацию между членами команды – это личный разговор (лицом к лицу). 7. Работающее ПО – лучшая оценка хода процесса. 8. Процессы Agile подразумевают устойчивое развитие. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп в течение неопределенного срока. 9. Постоянное внимание к улучшению технического мастерства и удобному дизайну увеличивает гибкость. 10. Простота – искусство минимизации лишней работы – крайне необходима. 11. Лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды. 12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. Существует множество методологий, придерживающихся заявленных ценностей и принципов, но чаще других можно услышать про Scrum. Agile и Scrum оказали огромное влияние на разработчиков ПО и, в частности, на разработчиков видеоигр, особенно воодушевленных появлением этих принципов. По моим наблюдениям, около 80 % разработчиков используют в своей работе практики Agile. Если посмотреть на природу этого метода, станет понятно почему. Полное описание методов Agile вышло бы далеко за рамки этой книги, но я приведу несколько основных принципов, используемых большинством разработчиков. Гибкие цели. Центральным понятием Agile‑философии является утверждение, что мы не можем знать точно, какой результат получится в конце разработки. Команда куда легче приспосабливается к новым идеям по ходу разработки, если заранее не только допускает возможность внесения изменения в утвержденный план, но и действительно готова их вносить. Приоритизированный журнал пожеланий. Вместо того чтобы работать по заранее утвержденному списку функционала, Agile‑команды работают с журналом пожеланий – это список требований к функциональности, упорядоченный по степени их важности. Когда у кого‑то появляется новая идея, она вносится в журнал пожеланий (бэклог). В каждом спринте команда пересматривает журнал и изменяет приоритеты, важный функционал получает приоритет выше, приоритет незначительных задач понижается. Благодаря такому подходу можно с легкостью решить, над чем команда будет работать в дальнейшем: достаточно просто посмотреть верхние пункты журнала пожеланий. Важно понимать, что гарантии того, что вы реализуете весь журнал, нет – есть только гарантия, что самые важные задачи будут выполнены за отведенное время. Спринты. Вместо того чтобы фокусироваться на выполнении долгосрочной (многомесячной) цели, в Agile программисты работают сериями так называемых спринтов – коротких этапов (несколько недель) с четко сформулированными задачами, решение которых необходимо предоставить к концу этапа. Основатель Atari Нолан Бушлелл как‑то сказал: «Лучший источник вдохновения – это дедлайн», и это правда. Часто случается, что задачи волшебным образом выполняются, когда дедлайн уже рядом, и именно эта философия лежит в понятии спринтов: чем больше дедлайнов, тем больше задач будет сделано.
Scrum‑собрания. Вместо еженедельных собраний для подведения итогов в Agile разработчики проводят ежедневные scrum‑собрания, специально созданные для краткости и эффективности. Обычно эти собрания длятся всего 10–15 минут и проводятся стоя, что лишь подчеркивает их краткость. Во время такого собрания каждый из членов команды должен объяснить не больше трех вещей: что они сделали вчера, что они собираются сделать сегодня и с какими проблемами они столкнулись. Решение этих проблем обсуждается уже после окончания собрания один‑на‑один с членами команды, обладающими нужной квалификацией. С таким подходом каждый член команды знает, чем занимаются остальные, и каждый может оперативно получить помощь, если он в ней нуждается. День демо. В конце каждого спринта команда собирается вместе, лицом к лицу, чтобы посмотреть на результаты. В этот день команда проводит анализ рисков и планирует следующий спринт. Ретроспективы. Также в конце каждого спринта команда проводит «ретроспективное совещание», на котором обсуждает не столько продукт, над которым работает, столько используемые процессы. Это возможность обсудить, что команда делает правильно, а что – нет, и то, как им следует улучшить процессы для следующего спринта. Важно помнить, что Agile – это философия, а не четко сформулированная методология и что разные разработчики могут трактовать эту философию по‑разному. Несмотря на то что подходы разных команд могут различаться, все они преследуют одну цель: осуществить как можно больше итераций и сделать все, чтобы каждая из них была результативна с точки зрения управления рисками и целей прототипирования.
|
|||||||
Последнее изменение этой страницы: 2021-01-14; просмотров: 151; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 18.224.58.122 (0.015 с.) |