 |
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция
Особенности управления процессом, ориентированным на разработчика
Форма организации процесса должна приниматься разработчиком, а не навязываться вне. Все технические решения принимаются исключительно разработчиком без участия менеджера.
Роль бизнес-консультантов.
Поскольку разработка программного продукта выполняется в предельно сжатые сроки, у разработчиков должна быть возможность оперативно получать консультации по предметной области. Поэтому гибкие методологии предполагают завлечение консультантов по предметной области в процесс разработки, в предельном случае предполагается что мы берём и принимаем в нашу команду консультанта по предметной области. Кроме того, постоянная вовлеченность консультанта в процессе разработки позволяет заказчику получать актуальную информацию о создаваемом программном продукте. То есть прямо сейчас, а не через год после окончания проекта.
Адаптация адаптивного процесса. Кроме адаптации программного продукта к меняющемся требованиям заказчика можно говорить об адаптации самого процесса разработки. К концу работы проекта форма организации разработки будет отличаться от изначального. Основной прием адаптации процесс разработки, это регулярный пересмотр.
В конце каждой итерации разработки организуется собрание и находятся ответы на следующие простые вопросы:
— что было сделано хорошо в течении последней итерации?
— чему мы научились?
— что можно сделать ещё лучше?
— что поставило нас в тупик – какие возникли принципиальные сложности.
Ответив на эти вопросы, мы поймём, как улучшить процесс разработки.
Примеры гибких методологий.
Экстремальное программирование — К. Бек, У. Каннигем, М. Фаулер.
Принципы экстремального программирования. 12 признаков по 4 группы (неупорядоченно):
Первая группа. Короткий цикл обратной связи.
— Игра в планирование: простой подход к планированию разработки проекта.
— Заказчик на рабочей площадке: любой разработчик можно задать вопрос, получить любую нужную консультацию с заказчиком.
— Разработка через тестирование: сначала разрабатываются тесты, потом пишется программный код.
— Парное программирование: обучение опытом, быстрое обучение, повышается качество кода. В каждом участке кода разбирается два человека – если умер один, то ничего страшного.
Вторая группа. Процесс разработки организуется непрерывно, а не пакетно.
— Частный выпуск небольших обновлений: заказчик может оценить результат и корректировать свои требования.
— Непрерывная интеграция: применение модульного объединения.
— Использование рефакторинга.
Третья группа. Понимание проекта всеми участниками.
— Метафора системы: выступает в качестве аналога архитектуры системы. Основная цель заключается в том, чтобы каждый участник проекта понимал архитектуру, основные функции и назначение будущего программного продукта. При этом, текущий проект может описываться путём сравнения с ранее выполненными проектами.
— Простота проектирования: проектируем намного проще и быстрей, проект корректируется под новые требования.
— Простота кодирования.
— Стандарты кодирования: использование общего стандарта построения.
— Коллективное владение кодом: любой разработчик может вносить изменения в любой фрагмент кода программы. За каждый участок кода отвечает, как минимум два разработчика. Повышает универсальность программистов.
Четвёртая группа. Социальная защита программиста.
— Обязательная 40 часовая рабочая неделя: 5 дневная неделя, 8 часов в сутки.
Методология скрам. Scrum (термин из регби, перевод — «толкучка»).
Методология управления проектами, активно применяющаяся при разработке информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки.
Историческая справка:
Подход впервые описали Хиротака Такэути и Икудзиро Нонака в статье The New Product Development Game. Они отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, обычно систематически производят лучшие результаты, и объяснили это как «подход регби». В 1991 году ДеГрейс и Шталь в книге «Злые проблемы, справедливые решения» ссылались на этот подход, как на Scrum (толкотня; схватка вокруг мяча (в регби)), спортивный термин, приведённый в статье Такэути и Нонакой. Кен Швабер в начале 1990-х использовал подход, который привел Scrum в его компанию. Впервые метод Scrum был представлен на общее обозрение задокументированным, чётко сформированным и описанным совместно Швабером и Джефом Сазерлендом на OOPSLA’96 в Остине. Швабер и Сазерленд на протяжении следующих лет работали вместе, чтобы обработать и описать весь их опыт и лучшие практические образцы для индустрии в одно целое, в ту методологию, что известна сегодня как Scrum. Швабер объединил усилия с Майком Бидлом в 2001 году, чтобы детально описать метод в книге «Agile Software Development with SCRUM».
Является методологий программных продуктов, может использоваться для сопровождения и поддержки программного обеспеченья. Это набор принципов который позволяет организовать процесс разработки таким образом, что заказчик получает относительно скоро (2-4 недели) очередную версию программного продукта с новой функциональностью, выбранным в соответствии с приоритетами. При этом функции которые будут реализованы (sprint) фиксируются в начале и не меняются до конца спринта. Таким образом, Scrum борется с меняющимся требованием, так как спринт имеет фиксированную длину и позволяет планировать.
Роли в Scrum.
По методике Scrum в производственном процессе есть определенные роли, разбитые на 2 группы «свиней» и «кур». Эти названия были использованы из-за шутки:
Свинья идёт по дороге. Курица смотрит на нее и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать ‘Яичница с беконом’?». «Так не пойдёт», — отвечает свинья, «ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично.»
Свиньи создают продукт, тогда как куры заинтересованы, но не настолько — ведь им всё равно, будет ли проект удачным или нет, на них это мало отразится. Требования, пожелания, идеи и влияние кур принимаются во внимание, но им не разрешают непосредственно включаться в ход скрам-проекта.
Действующие роли в методологии скрам.
А) Основные роли. Свиньи — полностью увлечены в процесс.
— Владелец проекта (product owner): представляет интересы заказчика. Представитель заказчика либо менеджер проекта. Поддержка списков требований в актуальном состоянии. Выставлять приоритеты каждому из требований исходя из бизнес целей проекта. Необязательно чтобы список требований был заполнен. В начале спринта из этого списка выбирает то подмножество которое команда будет реализовывать на протяжении одной итерации (спринта). Эти требования разбиваются на подзадачи и делается точная оценка времени на реализацию.
— Скрам-мастер (scrum master): следит за выполнением всех принципов скрам, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса. Руководитель проекта скорее относится к владельцу проекта и не должен фигурировать в качестве скрам-мастера.
— Скрам-команда (scrum team): кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и так далее. Размер команды в идеале составляет 7±2 человека. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.
Б) Дополнительные роли. Куры — частичные сотрудники.
— Конечные пользователи программного продукта.
— Продавцы-маркетологи: лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).
— Консультанты.
— Управляющие: люди, которые управляют персоналом.
Артефакты Scrum процесса
А) Product Backlog – документ содержащий список требований, которые упорядочены по приоритету. Могут редактировать все участники Scrum процесса. Заказчик может вводить требования в лог.
— User Story (Backlog item)
— Требование: уникальный индикатор, однозначное название, важность (числа Фибоначчи).
— Story Point: предварительная оценка трудоемкости (оценка стоимости разработки).
— Способ демонстрации – демонстрация функции по окончании спринта (текст теста).
— Категория (track). Например, «панель управления» или «оптимизация». При помощи этого поля владелец проекта может легко выбрать все пункты категории «оптимизация» и установить им низкий приоритет.
— Компоненты (components) — указывает, какие компоненты (например, база данных, сервер, клиент) будут затронуты при реализации истории. Данное поле состоит из группы checkbox’ов, которые отмечаются, если соответствующие компоненты требуют изменений.
— Инициатор запроса (requestor): владелец продукта может захотеть хранить информацию о всех заказчиках, заинтересованных в данной задаче. Это нужно для того, чтобы держать их в курсе дела о ходе выполнения работ.
— ID в системе учёта дефектов (bug tracker ID): если вы используете отдельную систему отслеживания ошибок, тогда в описании истории полезно хранить ссылки на все дефекты, которые к ней относятся.
Б) Sprint Backlog – подмножество из Product Backlog которые избраны Product Owner. Каждая функция разбивается на подзадачи и оценивается трудоемкость на реализацию
В) Burndown Chart – показывает запланированный и действительный ход работы
Поиск по сайту: