SILVA, Francisco Eronildo da [1]
PINTO, Aurílio Guimarães [2]
FREITAS, Caio Guimarães [3]
ALMEIDA, Cristiany Caliri de [4]
RIBEIRO, Dallas dos Santos [5]
LEITE, Francisco Canindé da Silva [6]
OLIVIERA, Geveson de Souza [7]
MORAIS, Gilvanete Melo de [8]
PERES, Paulo Júnior de Jesus [9]
SILVA, Francisco Eronildo da; et.al. Применимость гибкой методологии разработки программного обеспечения – Scrum как ссылка. Междисциплинарный основной научный журнал знаний. 07 издание. том 03 02 года. PP 05-16, октябрь 2017. ISSN: 0959-2448
Резюме
Это исследование призвана проанализировать скорость, что гибкие методологии дают процесс разработки программного обеспечения, показаны как компании используют эти методы как способ сократить время и усилия в разработке программного обеспечения, принимая как Ссылка методологии SCRUM. Гибкая методология посылка, на которой результаты следует быстро достичь без ущерба для качества конечного продукта (программное обеспечение), соответственно СХВАТКИ входит методологию, которая призвана улучшить планирование проектов программного обеспечения, чья предпосылка разбить продукт на более мелкие куски и поэтому функциональность без клиента ждать слишком долго, чтобы просмотреть их. Среди авторов, искали Конституции этой работы концептуальные освещаются Арагон Фернандес (2014), Сомервилл (2007), Роджер Прессман (2011), Ким Pries (2010) и Кен Швабер (2014). Наиболее важные выводы, что использование гибких методологий может дать быстрый программного обеспечения развития, показывая большей эффективности, динамизм и предлагают преимущества для компаний, которые принять методологию, эти факты, продемонстрировали в этой работе.
Ключевые слова: подвижный, Scrum, управления, разработки программного обеспечения.
1. Введение
Гибкой начали иметь акцент на 80. Сайт DEVMEDIA говорит: «гибких методологий были вокруг течение многих лет, начиная с 80, но некоторая информация пройти через искажения, что затрудняет в начале использования методологий. Таким образом, разработчики пришли к пониманию гибкая методология как нечто, что можно, другими словами, мы можем разработать без документов, не по умолчанию и небрежно. Это не правда, гибкие методологии могут принести успех в проект и используются в промышленности». Эта работа показывает, что известные авторы на основе гибкой убить необходимый уход, что программное обеспечение проекта должны быть действенной и эффективной, и каждый день, вы получите разработки программного обеспечения и организации рынка, используются в промышленности и государственные учреждения, которые нанимают аутсорсинг фабрики в разработке их систем.
Это исследование ограничивает себя показать приносит преимущества гибкой разработки программного обеспечения. В качестве примера, если у вас есть modus operandi события CTI, программного обеспечения компании на внутреннем рынке и принятие общей методологии разработки программного обеспечения, который работает, но это зависит от клиента, отдав предпочтение гибкой методологии.
Управление зоны свободной торговли Манаус-SUFRAMA, который посредством торгов, нанял службы событий CTI и выбрал для перехода к гибкой методологии.
SUFRAMA является федеральным органом, отвечающим за управление налоговые стимулы. Большинство их систем имеют решающее значение и работают с ограничениями, так что ставки службу фабрика программного обеспечения для работы с гибких методов. Параметр для гибких методов в причине быстрой доставки и качества потому что традиционные engessava методики процесс.
Гибкого метода обходится с стопку бумаги, основное внимание на качество продукта, потому что важно, чтобы клиент работу программного обеспечения.
Это не вдаваться в подробности изменения в методологии, принятой SUFRAMA и да, показывают, что различных отраслей промышленности и государственных учреждений, выбирают для изменения вашей модели разработки программного обеспечения для гибкой методологии.
Несмотря на то что вариант для разработки программного обеспечения, гибкая методология, которая предлагает различные преимущества для развития безусловно могут не подходить для всех проектов. Для лучшего понимания этого вопроса, следует пересмотреть некоторые из истории гибкой разработки.
Общая цель этой работы заключается в том, делать систематический обзор гибкой методологии. SCRUM метод будет объектом настоящего исследования, где они будут перечислены недостатки и позитвы.
Это исследование оправдано необходимостью индустрии программного обеспечения может осуществлять поставки продукции с наименьшее возможное время для своих клиентов, не теряя из виду качества, экономики и удовлетворение.
Методология этого исследования является описательным и пояснительные исследования, как сбор библиографических данных.
2. Развитие
Это исследование начинается с обзора концепции программного обеспечения, который был первоначально предложен в 1968 году, на Конференции, организованной для обсуждения, что тогда называлось «кризис программного обеспечения». Программное обеспечение кризис привел косвенно во введении новой компьютерной техники, на основе интегральные. Рассмотрено применение интегрировано-цепи из компьютерных приложений, не представляется возможным, жизнеспособных предложений. Результирующее программное обеспечение было более крупные и более сложные, чем предыдущих систем программного обеспечения (СОММЕРВИЛЛЯ, 2007).
Инженерия программного обеспечения является филиалом инженерных, чьи фокус заключается в разработке в рамках соответствующих расходов высокого качества программных систем. Инженерия программного обеспечения — это слоистых технология, инструменты, методы, процесс и сосредоточиться на качестве. (СЪМЪРВИЛ, 2007). Любые инженерный подход (включая программное обеспечение) должна быть заземлена в организационной приверженности к качеству.
Всего управления качеством шесть σ1 (ГИГИ; ДЕКАРЛО; Уильямс, 2008) и аналогичные философии, они способствуют культуры непрерывного совершенствования процессов и эта культура, которая, в конце концов, приводит к развитию более эффективных подходов в области программного обеспечения. Краеугольным камнем, который поддерживает программного обеспечения является акцент на качество (ПРЕССМАН, 2011).
Что касается истории гибкой разработки, то же самое началось в 2001 году, с «Манифест для гибкой разработки программного обеспечения», который был подписан Кент Бек, американский инженер, создатель экстремального программирования и тестированием и шестнадцать более известных разработчики. Подробности этого факта может быть проверена на адрес https://www.agilealliance.org/agile101/the-agile-manifesto/.
Манифест подчеркивает индивиды и взаимодействие процессов и инструментов; программное обеспечение, работает более чем полная документация, сотрудничество с клиентом вместо переговоров контрактов и ответы перестроиться после плана.
Это не отнять важности документации или процессы и никоим образом не относятся неэффективность инструменты, средства, однако, что поставки программного обеспечения является более ценным, как декларирование Прессман:
«Гибкой разработки программного обеспечения сочетает философии с набором принципов развития. Философия выступает за удовлетворение клиента и доставки предварительного инкрементный; небольшой проект группы и высоко мотивированных; неофициальные методы; Минимальная программного обеспечения артефакты и, прежде всего, простота в общем развитии. Принципы разработки приоритеты доставки больше, чем анализ и дизайн (хотя эти мероприятия не обескуражиты); также приоритетность активной и постоянной связи между клиентами и разработчиками». (Прессман, 2011)
Проект включает в себя людей и изменения, особенно когда дело доходит до поставки. Таким образом гибких методологий, работать с высоко мотивированных команд, потому что они напрямую связаны с процессом, участвующих в каждой его части, чувствуя ответственность на себя успех работы и зная, что у вас есть возможность поддержать изменения во время весь процесс развития.
В гибкой разработки, вы не можете сделать план в комплекте с все, что мы должны выполнить, затем начать разработку, без контакта с клиентом, вместо этого, разработали добавочное, т.е. продукт делается постепенно и последовательно поставлены таким образом, любые необходимые изменения, запрошенные клиентом или видел членами проекта, в любой момент во время разработки, не полный урон приведет и изменения могут быть выполнены без серьезный ущерб, поскольку проект находится в стадии разработки и не было завершено.
Первоначальный приращения системы может предоставить высокий приоритет функцию, так что клиенты могут вскоре получить значение для вашей системы развития. Клиенты могут просмотреть требования на практике и указать изменения, которые будут включены в последующие выпуски системы.
Таким образом, клиент может сделать использование системных ресурсов более быстро. Что бы месяцев, чтобы быть доставлены в течение недель и можно проверить ошибки и укажите новые изменения или улучшения, не нужно добраться до конца разработки увидеть проблемы.
Эта методология также предоставляет больше знаний о системе к команде, потому что он будет понимать бизнес развивать его, что делает его, с большей скоростью и точностью, и в случае ошибки, команда потеряет меньше времени для анализа и может исправить ошибку быстро.
Изначально, согласно Агинальдо Арагон Фернандес (2014), схватки был разработан с акцент в оказании проектов разработки программного обеспечения в сложной среде. Однако, она все чаще применяется в продукт развития проектов других природах».
Арагон также говорится, что:
«Схватки состоит из итеративный и инкрементный метода для управления сложных проектов, цель которых заключается в обеспечении ускорения доставки и максимального соблюдения требований заказчика, сотрудничество между членами группы и производительности каждого участника. Это один из методов из так называемых «гибкой» более широко в it рынка, (Арагон Фернандес 2014).
Гибкие методологии могут быть применены в резолюциях сложных проблем, таких, как разработка программного обеспечения сообщает Швабер:
«Комплексный проект, который возникновения ситуаций, когда сложность промежуточные действия не позволяют определенный процесс под контролем, вы можете генерировать цикла продукции в приемлемого уровня качества. Сложность проекта прямо пропорциональна сложности требований клиентов и технология, Але в значительной степени зависит от особенностей каждого члена команды, принимая во внимание разнообразие навыков, знаний, отношения и т.д., которые можно найти в любой группы людей». Швабер (2004)
В подобных ситуациях Швабер рекомендует использовать концепцию управления эмпирического процесса, которая использует механизмы самоорганизации и чувство неотложности с следующими компонентами:
«Видимость: все аспекты, которые влияют на желаемые результаты должны быть видимыми для процессов управления.
Инспекции: различные аспекты процесса должен пройти через регулярные инспекции с целью выявления неприемлемых вариации.
Адаптация: процесс или его промежуточные продукты должны быть скорректированы после инспекции для сведения к минимуму будущих отклонения более суровые, дело характеристики и результаты находятся вне допустимых пределов и принятия конечного продукта. Швабер (2004)
Схватки состоит в набор практик, проводимых группами в определенных ролях, организованной в поток деятельности или фиксированная длительность события, полностью контролируется с артефакты и четко определенных правил, который стремится получить полезные продукты интервалы не хватает времени.
Каждый Scrum практики основаны на «скелет» представлены последовательных итераций деятельности в целях развития, (каждый из них генерации увеличение продукта), проверены и скорректированы ежедневно от его собственных сотрудников и ориентированных на список первоначальных требований.
В начале каждой итерации, команда рассматривает, что должно быть сделано и определяет какой жизнеспособной функциональность будет доставлен в конце итерации. Команда может использовать ваши лучшие усилия в оставшуюся часть итерации и функции в конце конечный продукт построен.
На рисунке ниже показан поток Scrum:
В рамках проекта Scrum все обязанности разделены между тремя ролями:
ProductOwner: лицо, ответственное за управление продукта отставания (обеспечение, видимый для всех), создавать и распространять требования проекта, а также план для последующих поставок, приоритизация результаты, которые принесут большую добавленную стоимость проекта.
Scrum Master: ответственный за выполнение метода Scrum, а также как научить вам всем участвует в осуществлении проектов и обеспечить что все последовать за правилами и практикой.
Scrum команда: группа по вопросам развития, коллективную ответственность за успех проекта в целом, и каждой итерации должны состоять из многопрофильной людей, способных самоорганизации и самоуправления.
Этот процесс, пропагандируемых Scrum охватывает следующие элементы, как показано ниже:
Видение: должен быть подготовлен ProductOwner, включая выпуски и план вехи продукта доставки каждого спринта, чтобы максимизировать окупаемость инвестиций проект разработки продукта.
Отставание продукта: также подготовленный ProductOwner, содержит перечень функциональных и нефункциональных требований, приоритеты и разделен релизы (спринт).
Совещание по вопросам планирования Спринт: Проект разделен в спринтах, продолжительностью тридцать календарных дней, чтобы быть выполнена один за другим, без перерыва. Планирование осуществляется в ходе встречи с участием команды Scrum и ProductOwner, в двух периодов по 4 часа:
В первый час установить область («что») будет рассматриваться спринтом, через выбор требований невыполненной работы продукта, которые будут размещены на отставание спринта.
В 4 часа поздно, фактическое планирование задач в спринте, («как») и официальный старт спринта, на котором время начинает работать на период 30 дней.
Спринт: собственный продукт развития итерации, который имеет фиксированную продолжительность. Спринт включает в себя их планирования встреч, анализом и ретроспективой.
: Ежедневно ежедневно Скрам пятнадцать минут, где каждый член группы отвечает на следующие вопросы:
- Что я сделал на проект с момента последней ежедневных Scrum?
- То, что я планирую делать до следующего ежедневных Scrum?
- Есть каких-либо ограничений или препятствий для что я чести моей приверженности текущего спринта и/или проекта?
Кроме того команда синхронизирует все мероприятия и программы заседаний, необходимых для продолжения реализации данного проекта.
До настоящего времени подробно немного больше мнений сторон.
Спринт обзорного совещания: в 4 часа, команды Scrum представляет ProductOwner (и другие заинтересованные стороны) работы, созданные в спринте и определяет среди них, что делать в следующем спринте.
Спринт ретроспективное совещание: в 3 часа, Scrum мастер призывает членов группы для обзора Scrum, процесс развития практики родовспоможения и модель процесса Scrum, с тем чтобы сделать его более эффективным и полезным для следующего спринта.
Согласно Швабер (2004) Sprint планирования заседаний, ежедневные Scrum, анализом и ретроспективой спринта являются, вместе, эмпирические проверки практики и адаптация схватки.
Существует две категории артефактов в контексте схватки: отставание таблицы и графики, которые показывают работу, по-прежнему не до конца (названный BurndownCharts).
Журналы являются таблицы: продукт отставания состоит из «живых» документа разработан и поддерживается ProductWoner, который, по определению, никогда не полный (поскольку есть всегда улучшений для реализации в продукт до тех пор, пока он, наконец, удаляется из тираж). Содержит список всех изменений, которые будут сделаны в продукта для будущих версий (функции, функции, технологии, адаптации, улучшения, исправления и т.д.). такие требования приказал по приоритету и подробное описание атрибутов, сложные факторы/корректировки и оценки (усилий и срок) вдоль будущих спринтах.
Отставание спринта: определяет задачи, которые должна выполнить команда Scrum для создания продукта с шагом (от продукта отставания) во время выполнения спринта. Ваши детали должно быть достаточно для вас, чтобы сопровождать на заседаниях Scrum Дарио, в задачах, которые длятся от четырех и 16 часов.
Каждой задачи должны быть задокументированы, по крайней мере с точки зрения ваших ответственных, статус (не начато, в прогресс, завершена) и количество часов, оставшихся трудозатрат каждый день спринта.
BurndownCharts шоу, графически, сумма общего объема работы (другие усилия) со временем, отражая ваши корреляции с прогрессом проектных групп в уменьшении вашей работы. Может использоваться в контексте продукта отставания (включая все спринты) или внутри каждого из спринтов (спринт Burndow).
Схватки, как упоминалось ранее, был первоначально создан для использования в проектах программного обеспечения в сложных условиях, т.е. когда требования изменяются с определенной частотой, которая может иметь область или декомпозиции работ или EAP СДР проекта организованы и Структура в пакеты, добавочное, последовательной и использования артефактов, будет доставлен клиенту в последующие периоды пятнадцати до тридцати дней.
Сначала эта концепция является идеально подходит для любого проекта или программы, целью которых является разработка продуктов или услуг другого характера, или даже, что включает в себя улучшение инициатив с использованием методологии Lean, шесть сигма, и т.д. Короче схватки это рекомендуемый подход, который показал сильный применимости, для проектов, которые требуют сочетание навыков и знаний сосредоточена на команды и привлечения совместных усилий.
Второй Pries & Куигли (2010) есть несколько способов адаптации Scrum для применения в различных типах программ и сложных проектов, таких как:
Комбинируя традиционные методы управления проектами: можно подключить концепций и артефактов, таких как СДР (структурная декомпозиция работ) и продукта отставания, анализа, BurndowsCharts и коммуникационный план, контроль заседаний освоенного объема Спринт (планирование, ежедневно, обзор, ретроспектива) и т.д.
Управление сложными программами: принятие Scrum в Scrum, где отставание продукта может быть разбита на суб отставания, каждый потребляются ваши соответствующие команды Scrum.
Опыт в функциональных областях, обслуживающих различные проекты (например, команды тестирования или качества): в Baclog продукте, может прийти в различных конструкций и задач в невыполненную работу на Spint, те задачи, которые вписываются в течение тридцати дней.
В сочетании с технологией в виде «каскад»: вам можно разделить расписание в модели Фиксированная длительность, чтобы синхронизировать, например, последовательность Sprint с веха (milestone) предусматривается в проекте, а также деятельности верификации и проверки формы Эволюция в каждом спринте.
Сочетание с шести сигм подход: вы можете обернуть каждый из этапов методологии DMAIC (определение, измерение, анализ, улучшение, управления) в спринте, работает один за другим.
Швабер (2004) упоминается возможность использования Scrum в контексте цена контракта продолжительность префиксом. В этих случаях отставания продукта может использоваться не только для того, чтобы продемонстрировать заказчику, что требования были поняты, но также понимается приоритет каждого поколения значение. Наиболее релевантные требования могут быть выбраны для первых нескольких спринтов и увеличивает функциональность надежно каждого последующего совещания.
Важно подчеркнуть, что принятие Scrum для Организации должно осуществляться осмотрительно и что существует много проблем, с которыми придется столкнуться.
Подключаем некоторые моменты, которые, если не управлять, может поставить под угрозу эффективность Scrum методологии:
Важно иметь хорошо функционирующей командой рабочей группы, поскольку успех работы зависит от интенсивных усилий на навыки, которые каждый из них имеет как дифференциал;
Важно, что каждый член схватки имеет сильное чувство самоуправления.
Убедитесь, что члены группы выделяются только один проект.
Вы должны обеспечить приверженность всех заинтересованных сторон (особенно от тех, которые представляют клиент).
Вы должны убедиться, что отставание хорошо документированы, поэтому Есть никаких недоразумений между тех, кто участвует.
Там могут быть некоторые трудности, чтобы «атомизации» задачи быть помещены в каждой строке отставания, а также для установления зависимости между ними, которые могут повлиять на планирование и значительный прогресс в осуществлении спринт.
Необходимо убедиться, что все заседания (планирование, ежедневно, обзор, ретроспектива) Спринт осуществляется вне и что фиксированной раз будут эффективно выполнены, рискуя повредить чувства дисциплины, которая имеет решающее значение для успеха метода.
Заключение
Перед цитаты из различных авторов является пресловутый для ловкость и скорость, что гибкие методологии, в частности SCRUM, выбрали для иллюстрации в этой работе, дают предприятий, которые нанимают фабрики программного обеспечения.
Среди преимуществ, мы можем выделить: большую гибкость в области контроля и управления хода работы, упор на коллективную работу и сосредоточиться на быстрые результаты, общая ответственность с группой, вызывая большее чувство приверженности, быстрее поставки и эффективность, сократить обратной связи, подчеркивая коммуникации и повышение удовлетворенности клиентов, имея время доставки программного обеспечения, сократилось, без потери качества и увеличить прибыль компании.
Ссылки
ФЕРНАНДЕС, А. А.; Абреу, в.ф.: Развертывание управления, 4-ый ed., Сан-Паулу, SP: Brasport книги и мультимедиа издательской компании Ltd., 2014.
ПРЕССМАН, р. 2011 программного обеспечения A профессиональный подход. Перевод в Ariovaldo Griesi, Марио Моро Fecchio. 7-ое изд.-Сан-Паулу, SP: MGH Editora Ltda, 2011.
PRIES, Ким х., QUIGLEI, Джон м. Scrum управления проектами. CRC пресс, 2010
СОММЕРВИЛЛ, i. программного обеспечения. 8. Эд. Сан-Паулу, Пирсон Addison Wesley, 2007 г.
ШВАБЕР, Кен. Менеджмент в гибком проекте с Scrum. Microsoft Press, 2014.
Agile-манифеста. Доступно в: <https: www.agilealliance.org/agile101/the-agile-manifesto/="">. На 21 октября 2016 г.</https:>
Манифест для гибкой разработки программного обеспечения. Доступно в: <http: www.manifestoagil.com.br/="">.</http:> Доступ на 21 октября 2016.
Обзор гибкой методологии. Доступно в: <http: www.devmedia.com.br/uma="" visao-geral-sobre-metodologia-agil/27944/="">.</http:> Доступ на 21 октября 2016.
[1] Окончил в области компьютерных наук, он действует как общественных сервер на SUFRAMA, что административные аналитик-вы.
[2] Окончил в области компьютерных наук, он действует как общественных сервер на SUFRAMA, что административные аналитик-вы.
[3] Окончил в области компьютерных наук, он действует как общественных сервер на SUFRAMA, что административные аналитик-вы.
[4] Окончил в области делового администрирования, выступает в качестве государственного служащего на SUFRAMA, как администратор.
[5] Окончил в области компьютерных наук, он действует как общественных сервер на SUFRAMA, что административные аналитик-вы.
[6] Окончил в области компьютерных наук, он действует как общественных сервер на SUFRAMA, что административные аналитик-вы.
[7] Окончил в области компьютерных наук, действует как сервер SUFRAMA, как административные аналитик-вы.
[8] Окончил в экономике, выступает в качестве государственного служащего на SUFRAMA, как экономист.
[9] Окончил в области компьютерных наук, он действует как общественных сервер на SUFRAMA, что административные аналитик-вы.
