Застосування гнучкої методології розробки програмного забезпечення - Scrum як посилання

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:

Малюнок 1: потік Scrum - адаптовано з Швабер (2004)

В рамках проекту Scrum все обов'язки розділені між трьома ролями:

ProductOwner: особа, відповідальна за управління продукту відставання (забезпечення, видимий для всіх), виготовляти і навіть поширювати вимоги проекту, а також план для подальших поставок, пріоритизація результати, які принесуть велику додану вартість проекту.

Scrum Master: відповідальний за виконання методу Scrum, а також як навчити вам всім бере участь в здійсненні проектів і забезпечити що все послідувати за правилами і практикою.

Scrum команда: група з питань розвитку, колективну відповідальність за успіх проекту в цілому, і кожної ітерації повинні складатися з багатопрофільної людей, здатних самоорганізації і самоврядування.

Цей процес, пропагованих Scrum охоплює наступні елементи, як показано нижче:

Малюнок 2: елементи Scrum-адаптований Швабер (2004)

У Іден е: повинен бути підготовлений 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.

Досвід в функціональних областях, які обслуговують різні проекти (наприклад, команди тестування або якості): в Ba clog продукті, може прийти в різних конструкцій і завдань в невиконану роботу на 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, що адміністративні аналітик-ви.