Agile
Agile – це здатність створювати та реагувати на зміни. Це спосіб впоратися з невизначеним і неспокійним середовищем і зрештою досягти успіху в ній. Автори Agile Manifesto обрали «Agile» як назву всієї цієї ідеї, тому що це слово уособлює адаптивність і реакцію на зміни, які так важливі для їхнього підходу. Насправді йдеться про осмислення того, як ви можете зрозуміти, що відбувається в середовищі, в якому ви перебуваєте сьогодні, визначити, з якою невизначеністю ви стикаєтеся, і з'ясувати, як ви можете адаптуватися до цього в міру поступу.
Гнучка розробка програмного забезпечення - це більше, ніж такі фреймворки як Scrum, Extreme Programming або Feature-Driven Development (FDD). Гнучка розробка програмного забезпечення – це більше, ніж такі практики, як парне програмування, розробка на основі тестування, стендапи, сесії планування та спринти.
Гнучка розробка програмного забезпечення - це загальний термін для набору структур і практик, що ґрунтуються на цінностях та принципах, викладених у Маніфесті гнучкої розробки програмного забезпечення та 12 принципах, що лежать у його основі. Коли ви підходите до розробки програмного забезпечення особливим чином, зазвичай добре жити відповідно до цих цінностей і принципів і використовувати їх, щоб допомогти зрозуміти, що робити у вашому конкретному контексті.
Одна річ, яка відрізняє Agile від інших підходів до розробки програмного забезпечення - це зосередження уваги на людях, які виконують роботу, і на тому, як вони працюють разом. Рішення розвиваються в результаті співробітництва між крон-функціональними командами, що самоорганізуються, що використовують відповідні методи для свого контексту. Спільнота Agile-розробників програмного забезпечення приділяє велику увагу спільній роботі та команді, що самоорганізується. Це не означає, що менеджерів немає. Це означає, що команди можуть самостійно визначати, як вони мають намір підходити до справи. Це означає, що ці команди крос-функціональні. Цим командам не обов'язково повинні бути задіяні певні ролі, просто коли ви збираєте команду разом, ви переконаєтеся, що у вас є всі необхідні навички у команді. Є ще місце для менеджерів. Менеджери стежать за тим, щоб члени команди мали або набули правильного набору навичок. Менеджери створюють середовище, яке дозволяє команді бути успішним. Менеджери здебільшого відступають і дозволяють своїй команді з'ясувати, як вони збираються випускати продукти, але вони втручаються, коли команди намагаються, але не можуть вирішити проблеми. Коли більшість команд та організацій починають займатися гнучкою розробкою, вони зосереджуються на практиках, які допомагають у спільній роботі та організації роботи, і це чудово. Однак інший ключовий набір практик, яким не так часто слідують, але які повинні дотримуватися, - це конкретні технічні практики, які безпосередньо пов'язані з розробкою програмного забезпечення таким чином, щоб допомогти вашій команді впоратися з невизначеністю.
Зрештою Agile - це спосіб мислення, заснований на цінностях та принципах Agile Manifesto. Ці цінності та принципи містять вказівки про те, як створювати зміни та реагувати на них, а також як справлятися з невизначеністю. Можна сказати, що перша пропозиція Agile Manifesto містить у собі всю ідею: «Ми відкриваємо найкращі способи розробки програмного забезпечення, роблячи це і допомагаючи іншим це робити». Коли ви стикаєтеся з невпевненістю, спробуйте щось, що, на вашу думку, може спрацювати, отримайте зворотний зв'язок та внесіть відповідні корективи. При цьому пам'ятайте про цінності та принципи. Дозвольте вашому контексту визначати, які рамки, практики та методи ви використовуєте для співпраці зі своєю командою та надання цінності вашим клієнтам.
Якщо Agile – це спосіб мислення, то що це говорить про ідею Agile-методологій? Щоб відповісти на це питання, вам може бути корисно чітке визначення методології. Алістер Кокберн припустив, що методологія - це набір умовностей, яким команда погоджується слідувати. Це означає, що кожна команда матиме свою власну методологію, яка в малій чи великій мірі відрізнятиметься від методології будь-якої іншої команди. Таким чином, Agile-методологія - це умовність, яку команда вирішує слідувати відповідно до цінностей і принципів Agile. Ви, напевно, скажете: «Зачекайте, – я думав, що Scrum та XP – це Agile-методологія». Алістер застосував термін “framework” до цих концепцій. Вони, безумовно, народилися на основі методології однієї команди, але вони стали фреймворками, коли були узагальнені використання іншими командами. Ці фреймворки допомагають зрозуміти де команда починає свою методологію, але вони не повинні бути її методологією. Команді завжди необхідно адаптувати використання фреймворку, щоб воно відповідало його контексту.
Ключові концепції Agile
Користувальницькі історії ( User Stories ): після консультації із замовником або власником продукту команда ділить роботу, яку необхідно виконати, на функціональні етапи, які називаються «історіями користувача». Очікується, що кожна історія користувача внесе свій внесок у цінність всього продукту;
Щоденні збори ( Daily Meeting ): кожен день в той самий час група збирається, щоб ознайомити всіх з інформацією, яка має життєво важливе значення для координації: кожен член команди коротко описує всі «завершені» вклади та будь-які перешкоди, що стоять на їхньому шляху ;
Персонажі ( Personas ): коли цього вимагає проект - наприклад, коли досвід користувача є основним фактором результатів проекту - команда створює докладні синтетичні біографії фіктивних користувачів майбутнього продукту: вони називаються людьми;
Команда ( Team ): «Команда» в Agile розумінні - це невелика група людей, призначених на один і той же проект або effort, майже всі з них на постійній основі. Незначна меншість членів команди може працювати неповний робочий день або мати обов'язки, що конкурують;
Інкрементальна розробка ( Incremental Development ): майже всі Agile-команди віддають перевагу стратегії інкрементального розвитку; у контексті Agile це означає, що можна використовувати кожну наступну версію продукту, і кожна ґрунтується на попередній версії, додаючи видимі для користувача функціональні можливості;
Ітеративна розробка ( Iterative Development ): Agile-проекти є ітеративними, оскільки вони навмисно дозволяють «повторювати» дії з розробки програмного забезпечення та потенційно «переглядати» ті самі робочі продукти;
Ретроспектива ( Milestone Retrospective ): після того, як проект був запущений протягом деякого часу або в кінці проекту, всі постійні члени команди (не тільки розробники) вкладають від одного до трьох днів докладний аналіз значущих подій проекту.
Agile Manifesto :
люди та взаємодія важливіші за процеси та інструменти;
працюючий продукт важливіший за вичерпну документацію;
співробітництво із замовником важливіше за погодження умов контракту;
готовність до змін важливіша за проходження початкового плану.
Основні принципи Agile Manifesto:
найвищим пріоритетом визнається задоволення замовника за рахунок раннього та безперебійного постачання цінного програмного забезпечення;
зміна вимог вітається навіть у кінці розробки (це може підвищити конкурентоспроможність одержаного продукту);
часте постачання працюючого програмного забезпечення (кожні кілька тижнів або кілька місяців з перевагою меншого періоду);
спілкування представників бізнесу з розробниками має бути щоденним протягом усього проекту;
проекти слід будувати довкола зацікавлених людей, яких слід забезпечити потрібними умовами роботи, підтримкою та довірою;
найефективніший метод обміну інформацією в команді – особиста зустріч;
працююче програмне забезпечення - найкращий вимірювач прогресу;
спонсори, розробники та користувачі повинні мати можливість підтримувати постійний темп на невизначений термін;
постійна увага до технічної досконалості та гарного проектування збільшують гнучкість;
простота як мистецтво робити зайвої роботи дуже важлива;
кращі вимоги, архітектура та проектні рішення виходять у команд, що самоорганізуються;
команда регулярно обмірковує способи підвищення своєї ефективності і коригує робочий процес.
Існують методології , які дотримуються цінностей та принципів заявлених в Agile Manifesto, деякі з них:
Agile Modeling - набір понять, принципів та прийомів (практик), що дозволяють швидко та просто виконувати моделювання та документування у проектах розробки програмного забезпечення. Не включає детальну інструкцію з проектування, не містить описів, як будувати діаграми на UML. Основна мета: ефективне моделювання та документування; але не охоплює програмування та тестування, не включає питання управління проектом, розгортання та супроводу системи. Однак включає перевірку моделі кодом.
Agile Unified Process (AUP) спрощена версія IBM Rational Unified Process (RUP), розроблена Скоттом Амблером, яка описує просте та зрозуміле наближення (модель) для створення програмного забезпечення для бізнес-додатків.
Agile Data Method - група ітеративних методів розробки програмного забезпечення, в яких вимоги та рішення досягаються в рамках співпраці різних крос-функціональних команд.
DSDM ґрунтується на концепції швидкої розробки додатків (Rapid Application Development, RAD). Є ітеративним та інкрементним підходом, який надає особливого значення тривалій участі в процесі користувача/споживача.
Essential Unified Process (EssUP).
Екстремальне програмування (Extreme programming, XP).
Feature driven development (FDD) - функціонально-орієнтована технологія. Поняття функції або властивості (англ. feature) системи, що використовується в FDD, досить близько до поняття прецеденту використання, що використовується в RUP, істотна відмінність - це додаткове обмеження: «кожна функція повинна допускати реалізацію не більше, ніж за два тижні». Тобто, якщо сценарій використання досить малий, його можна вважати функцією. Якщо ж великий, його треба розбити на кілька щодо незалежних функцій.
Getting Real – ітеративний підхід без функціональних специфікацій, що використовується для веб-додатків. У цьому методі спочатку розробляється інтерфейс програми, та був її функціональна частина.
OpenUP – це ітеративно-інкрементальний метод розробки програмного забезпечення. Позиціонується як легкий та гнучкий варіант RUP. OpenUP ділить життєвий цикл проекту на чотири фази: початкова фаза, фази уточнення, конструювання та передачі. Життєвий цикл проекту забезпечує надання заінтересованим особам та членам колективу точок ознайомлення та прийняття рішень протягом усього проекту. Це дозволяє ефективно контролювати ситуацію та вчасно приймати рішення щодо прийнятності результатів. План проекту визначає життєвий цикл, а кінцевим результатом є остаточний додаток.
Scrum встановлює правила керування процесом розробки та дозволяє використовувати вже існуючі практики кодування, коригуючи вимоги або вносячи тактичні зміни. Використання цієї методології дає можливість виявляти та усувати відхилення від бажаного результату на ранніх етапах розробки програмного продукту.
Ощадлива розробка програмного забезпечення (lean software development) використовує підходи з концепції ощадливого виробництва.
Маніфест тестування в Agile :
постійне тестування, а не лише наприкінці розробки;
запобігання багам більш значуще, ніж їх пошук;
розуміння тестованого продукту вище за перевірку функціоналу;
побудова кращої системи у зв'язці з командою вище від пошуку методів її зламати;
вся команда відповідає за якість, а не лише тестувальник.
Особливості тестування в Agile
В Agile, тестування – це відповідальність кожного. Критерій якості повинен дотримуватися протягом усього циклу. У той час як бізнес-аналітики зосереджуються на створенні докладних історій користувача, розробники зосереджуються на розробці якісного коду, QA несе відповідальність за уточнення критеріїв прийнятності для кожної користувальницької історії, тестування завершеної функціональності в кожному спринті з точки зору клієнта і перевірка всієї раніше виконаної виконаної. Ролі та відповідальність QA не обмежуються лише тестуванням у Agile, але також включають наступне:
QA працюють у тісній співпраці з власниками продуктів, бізнес-аналітиками та командою розробників, щоб зрозуміти продукт, для кого він призначений і які будуть критерії успіху продукту.
Вони заглиблюються в критерії приймання, створені бізнес-аналітиками, для написання прикладів, візуалізації робочого процесу, тестування стандартних елементів і проведення негативного тестування.
Досвідчений QA також добре обізнаний з обсягом випуску і відповідно встановлює межі свого тестування.
Тестувальники повинні спілкуватися з командою та ставити запитання під час тестування, що дозволяє їм виявляти прогалини у вимогах або отримувати відповіді на невирішені питання. Комунікація та співпраця з командою мають вирішальне значення, оскільки вони допомагають зробити тестування більш точним та надійним. Це також допомагає досягти необхідного темпу, щоб рухатися швидше, з ранніми відгуками про тестування та підвищеною якістю.
Як член Agile команди, тестувальник завжди має бути синхронізований із командою проекту, відвідуючи сесії планування спринтів для виявлення можливих проблемних областей та щоденних мітингів для сприяння співпраці. Відвідування ретроспективи спринту дає змогу виявити слабкі місця та визначити рішення усередині команди. Відвідування мітингів з огляду спринту або демонстрації продукту дозволяє тестувальнику побачити, як працює нова функція, і дає можливість задати важливі питання розробникам.
Документування сценаріїв тестування та виконання тестів з доказами важливе для тестувальників, але воно має бути мінімальним та коротким.
Які стратегії використовує QA для Agile-тестування?
Кожна організація має різні підходи та стратегії, які вони використовують для тестування додатків. Методологія Agile передбачає підготовку документації, достатньої лише задоволення насущних потреб команди. Таким чином, QA підготують досить високорівневу документацію для стратегій тестування та планів для керівництва командою. Нижче наведено кілька стратегій, які я виконую під час підготовки до тестування в Agile:
Надзвичайно важливо мати чіткий план на початок тестування. Перед початком тестування сплануйте свій час і тест-кейси, і це дозволить вам відразу ж поринути у тестування після розгортання програми.
Я використовую поєднання ручного та автоматизованого тестування. Автоматизоване тестування допомагає мені прискорити мої регресійні тести за допомогою наборів тестів перед складання, а ручне тестування допомагає мені, коли мені потрібно проводити більш сфокусоване тестування.
Як тестувальник, я завжди вірю в проведення смоук-тестів основних або базових функцій відразу після розгортання програми, що допомагає мені виявляти будь-які критичні помилки раніше.
Виконує приймальні випробування, засновані на критеріях приймання, щоб забезпечити краще покриття тестами. Кожен критерій приймання може мати одне або кілька приймальних випробувань та орієнтований на задані умови.
Тестування ефективності потоку допомагає визначити, чи можуть користувачі безперешкодно переміщатися продуктом. Це допомагає визначити, чи збиває вас з пантелику якась частина потоку, і допомагає визначити, чи потрібно вам додавати або видаляти якісь кроки.
Перевірка бізнес-правил та визначень даних – важлива частина тестування.
Проведення дослідницького тестування дозволяє тестувальникам йти невизначеним шляхом і знаходити приховані ризики та дефекти у додатку.
Проведення регресійного тестування – важлива частина гнучкого тестування. Регресійне тестування гарантує, що перевірені функції працюють належним чином після запровадження нових функцій.
Використання кросбраузерного тестування є надзвичайно важливим для гнучкого тестування, оскільки тестувальник може швидко протестувати декілька пристроїв та браузерів за обмежений час.
Наявність програм для обміну повідомленнями в реальному часі, таких як Slack та Zoom, дозволяє всім у команді бути на зв'язку та швидко відповідати на важливі питання.
Джерела:
Дод. матеріал:
Last updated