Тестирование. Фундаментальная теория. Часть 2 — Методологии разработки ПО

Нарешті я дістався до другої шпори. Перша знаходиться тут. Ця присвячена методологіям розробки і також буде корисною для початківців у тестуванні, оскільки це також часто запитують на співбесідах.
І, як завжди, критика, уточнення, доповнення are extremely welcome.

Види методологій розробки програмного забезпечення:

Каскадна або поетапна розробка (іноді її називають «водоспадною моделлю») — це процес створення програмного забезпечення, який передбачає послідовне пройдення фаз аналізу, проектування, реалізації, тестування, інтеграції та підтримки. Цей підхід часто використовується при роботі над великими проєктами з тривалим терміном впровадження.
Ітеративна або інкрементна (еволюційна) модель дозволяє паралельно виконувати кілька завдань з постійним аналізом результатів і коригуванням попередніх етапів роботи. Це більш «швидкісний» підхід до розробки для великого числа кваліфікованих програмістів.
Спіральна методика характеризується пройденням проектом повторюваного циклу на кожному етапі розвитку: планування — виконання — перевірка — оцінка (англ. plan-do-check-act cycle). Цей підхід зазвичай використовується для проєктів з неокончательно сформованою візією результату або для проєктів, які потребують швидкого впровадження поетапно.
Гнучка методологія Agile-розробки — це так звана швидка розробка без втрати якості, коли головною метою є працездатний продукт, а не його документація. Це найсучасніший неформальний підхід до створення програмного забезпечення, у якому реагування на зміни вважається важливішим, ніж жорстке дотримання плану. Використовується для молодих швидкозростаючих проектів, які з кожною ітерацією програмного забезпечення фактично готові до його релізу.

SCRUM


Scrum (Скрам) — це не абревіатура, цей термін був запозичений з регбі і означає групову сутичку навколо м’яча.
Scrum — це методологія управління проектами, яка ґрунтується на принципах тайм-менеджменту. Основною її особливістю є залученість усіх учасників до процесу, при цьому кожен учасник має свою визначену роль. Суть полягає в тому, що не лише команда працює над вирішенням завдання, але всі, кому цікаве вирішення завдання, не просто поставили його і розслабилися, а постійно «працюють» з командою, і ця робота не означає лише постійний контроль.
Основні терміни, що використовуються в методології Scrum:
Власник продукту (Product Owner) — це особа, яка має прямий інтерес до якісного кінцевого продукту і розуміє, яким чином цей продукт має виглядати/працювати. Ця особа не працює в команді, вона працює на боці замовника/клієнта (це може бути як інша компанія, так і інший відділ), але вона співпрацює з командою. Власник продукту встановлює пріоритети для завдань.
Скрам-майстер (Scrum Master) — це особа, яку можна назвати керівником проекту, хоча це не повністю відображає його роль. Головне, це людина, яка «заражена скрам-бактерією» настільки, що передає це як своїй команді, так і замовнику, і відповідає за те, щоб принципи Scrum дотримувалися.
Скрам-команда (Scrum Team) — це команда, яка приймає всі принципи Scrum і готова працювати з ними.
Спринт (Sprint) — це період часу, призначений для виконання певного (обмеженого) списку завдань. Рекомендується вибирати тривалість спринта від 2 до 4 тижнів (конкретна тривалість визначається командою один раз).
Беклог (Backlog) — це список всіх робіт. Можна сказати, що це загальний щоденник. Розрізняють 2 види беклогів: Product-беклог і спринт-беклог.
Product-беклог — це повний список усіх робіт, виконання яких дозволить нам отримати кінцевий продукт.
Спринт-беклог — це список робіт, який команда визначила і погодила з Власником продукту на найближчий звітний період (спринт). Завдання зі спринт-беклогу вибираються з product-беклогу.
Планування спринта — це зустріч, на якій присутні всі (команда, Скрам-мастер, Власник продукту). Протягом цієї зустрічі Власник продукту визначає пріоритети завдань, які він хотів би бачити виконаними до кінця спринта. Команда оцінює, скільки часу їм знадобиться для виконання бажаного. В результаті отримується список завдань, який не може змінюватися протягом спринта і повинен бути повністю виконаним до кінця спринта.
Приклад роботи PR-агентства, якщо вони працюють за методологією Scrum, може мати такий вигляд:
Компанія-клієнт «Ікс» бажає провести великомасштабну подію для своїх партнерів і журналістів через 2 місяці. Вона замовила послуги агентства «T» для організації цієї події. Компанію «Ікс» представляє PR-менеджер, який відповідає за організацію події з боку клієнта. У термінології Scrum цю роль називають Власником продукту. З боку агентства за організацію події відповідає аккаунт-менеджер (Scrum-мастер), якому підпорядковується команда (Scrum-команда). На спільному засіданні (плануванні спринта) компанія і агентство вирішили, що вони будуть звітувати і планувати кожні 2 тижні (тривалість спринта). На перші 2 тижні вони спланували список завдань (спринт-беклог), але команда оцінила, що вони не зможуть виконати все з цього списку. Тоді PR-менеджер (Власник продукту) вказує, які завдання з цього списку є найбільш пріоритетними на наступні 2 тижні, після чого команда береться за їх виконання. Однак, слід врахувати, що на момент планування першого спринта повинен бути спланований весь список завдань на 2 місяці (product-беклог), щоб уникнути ситуації, коли до моменту проведення події щось залишиться невиконаним.
Життєвий цикл спринту
Планування спринту
На початку кожного спринта проводиться планування спринта. У цьому плануванні беруть участь замовники, користувачі, керівництво, Власник продукту, Скрам Мастер і команда.
Планування спринта складається з двох послідовних зустрічей.
Перше планування спринта
Учасники: команда, Product Owner, Scrum Master, користувачі, менеджмент
Ціль: Визначити мету спринта (Sprint Goal) і Sprint Backlog — функціональність, яка буде розроблена протягом наступного спринта для досягнення цілі спринта.
Артефакт: Список задач спринта (Sprint Backlog)
Друге планування спринта
Учасники: Scrum Master, команда
Ціль: визначити, як саме буде розроблятися певна функціональність, щоб досягти цілі спринту. Для кожного елементу списку задач спринта (Sprint Backlog) визначаються конкретні завдання і оцінюється їх тривалість.
Артефакт: у списку задач спринта (Sprint Backlog) з’являються конкретні завдання.
Якщо під час спринту виявляється, що команда не зможе виконати заплановані роботи, то Скрам Мастер, Product Owner і команда зустрічаються, щоб визначити, як можна скоротити обсяг робіт (scope) і, при цьому, досягти цілі спринту.
Зупинка спринта (Sprint Abnormal Termination)
Зупинка спринта відбувається в виняткових випадках. Спринт може бути зупинений до того, як минуть відведені 30 днів. Команда може зупинити спринт, якщо вона розуміє, що не зможе досягти цілі спринта у відведений час. Product Owner також може зупинити спринт, якщо зникла необхідності досягнення цілі спринта.
Після зупинки спринта відбувається зустріч з командою, на якій обговорюються причини зупинки спринта. Після цього розпочинається новий спринт: проводиться його планування і починаються роботи.
Щоденна зустріч Scrum (Daily Scrum)
Ця зустріч проводиться щоранку на початку робочого дня. Вона призначена для того, щоб усі члени команди знали, хто чим займається в проєкті. Тривалість цієї зустрічі суворо обмежена і не повинна перевищувати 15 хвилин. Мета зустрічі — обмінюватися інформацією. Вона не призначена для вирішення проблем у проєкті. Будь-які питання, які потребують спеціального обговорення, повинні бути винесені за межі зустрічі.
Скрам-митинг проводить Скрам-майстер. Він по черзі задає запитання кожному члену команди:
— Що було зроблено вчора?
— Що буде зроблено сьогодні?
— З якими проблемами зіткнувся?
Скрам-мастер збирає всі відкриті для обговорення питання у вигляді елементів дій (Action Items) у форматі що/хто/коли, наприклад:
— Обговорити проблему з відображенням елемента керування
— Петя і Вася
— Відразу після скрам-мітингу
Діаграма згоряння задач (Burndown chart)

Графік, що демонструє кількість виконаної та залишеної роботи. Його оновлюють щодня для простого відображення прогресу роботи над спринтом. Графік повинен бути доступним для всіх.
Існують різні типи діаграм:
• діаграма спалювання робіт для спринту — відображає, скільки задач вже виконано і скільки ще залишилося виконати в поточному спринті.
• діаграма спалювання робіт для релізу проекту — відображає, скільки задач вже виконано і скільки ще залишилося до випуску продукту (зазвичай побудована на основі кількох спринтів).
Ретроспектива
У кінці кожного спринту Скрам-команда збирається на Ретроспективу. Мета Ретроспективи — переглянути якість існуючих процесів, взаємини між людьми та застосовувані інструменти. Команда визначає, що пройшло добре, а що — не дуже, а також виявляє потенційні можливості для поліпшень. Вони розробляють план поліпшень на майбутнє.

Канбан

Термін Канбан має прямий переклад: «Кан» означає видимий, візуальний, а «бан» означає картка або дошка.
На заводах Toyota картки Канбан широко використовуються, щоб не завантажувати склади та робочі місця заздалегідь виготовленими запчастинами. Наприклад, уявіть собі, що ви встановлюєте двері на Toyota Corolla. У вас біля робочого місця знаходиться пачка з 10 дверима. Ви розміщуєте їх по одній на нові автомобілі, і коли залишається 5 дверей у пачці, ви розумієте, що час замовляти нові двері. Ви берете карточку Канбан, записуєте на ній замовлення на 10 дверей і відносите її до того, хто виготовляє двері. Ви знаєте, що він виготовить їх саме в той момент, коли у вас залишаться останні 5 дверей. І саме так і відбувається — коли ви ставите останню дверку, прибуває пачка з 10 новими дверима. І так постійно — ви замовляєте нові двері лише тоді, коли вони вам потрібні.
А тепер уявіть собі, що така система діє на всьому заводі. Ніде немає складів, де запчастини лежать тижнями і місяцями. Усі працюють лише за запитом і виробляють саме стільки запчастин, скільки замовлено. Якщо раптом замовлень стало більше або менше — система легко сама пристосовується до змін.
Основним завданням карт Канбан у цій системі є зменшення кількості «робіт, що виконуються в даний момент» (work in progress).
Наприклад, на всю виробничу лінію може бути виділено рівно 10 карток для дверей. Це означає, що в будь-який момент часу на лінії не буде більше 10 готових дверей. Коли замовляти нові двері і яка їх кількість — це завдання для того, хто встановлює їх. Тільки він знає свої потреби і тільки він може розміщувати замовлення виробнику дверей, але він завжди обмежений кількістю 10.
Цей метод Бережливого виробництва (Lean manufacturing) був розроблений в Тойоті, і тепер багато виробничих компаній по всьому світу впроваджують його або вже впровадили.
Але це все стосується виробництва, а не розробки програмного забезпечення.
А що ж таке Канбан розробка відносно до ПЗ та чим вона відрізняєтсья від інших гнучких методологій, таких як SCRUM чи XP?
По-перше, потрібно відразу зрозуміти, що Канбан — це не конкретний процес, а система цінностей. Так само як SCRUM та XP. Це означає, що ніхто не скаже вам, що і як робити крок за кроком.
По-друге, весь Канбан можна описати однією простою фразою — «Зменшення роботи, яка виконується в даний момент (work in progress)».
Втретє, Канбан є ще більш «гнучкою» методологією, ніж SCRUM і XP. Це означає, що вона не підходить для всіх команд і всіх проектів. І це також означає, що команда повинна бути ще більш готовою до гнучкої роботи, ніж команди, які використовують SCRUM і XP.
Різниця між Канбан та SCRUM:
— У Канбан немає таймбоксів ні на що (ні на завдання, ні на спринти).
— У Канбан задачі більше і їх менше.
— У Канбан оцінки термінів для завдання є необов’язковими або зовсім їх немає.
— У Канбан «швидкість роботи команди» відсутня, і враховується лише середній час на повну реалізацію завдання.
Канбан і SCRUM суттєво відрізняються у своїй орієнтації на розробку. Якщо в SCRUM основна увага команди приділяється успішному виконанню спринтів (і це слід визнати), то в Канбан на першому місці стоять завдання.
У Канбан відсутні будь-які спринти, команда працює над завданням з самого початку до його завершення. Розгортання завдання відбувається, коли воно готове. Презентація виконаної роботи також відбувається відповідно до готовності. Команда не повинна оцінювати час виконання завдання, оскільки це має мало сенсу і майже завжди є помилковим на початку процесу.
Якщо менеджер вірить команді, то нащо потрібна оцінка часу? Завдання менеджера — створити пріоритетний пул завдань, а завдання команди — виконати якомога більше завдань з цього пулу. Все. Немає потреби в контролі. Все, що потрібно від менеджера — це додавати завдання до цього пулу або змінювати їх пріоритет. Саме так він керує проєктом.
Команда для роботи використовує Канбан-дошку. Наприклад, вона може виглядати так:

Стовпці зліва направо:
Цілі проекту:
Необов’язковий, але корисний стовпчик. Сюди можна помістити високорівневі цілі проекту, щоб команда їх бачила і всі про них знали. Наприклад, «Збільшити швидкість роботи на 20%» або «Додати підтримку Windows 7».
Черга завдань:
Тут зберігаються завдання, які готові бути розпочатими. Завжди для виконання вибирається верхнє, найпріоритетніше завдання, і його картка переміщується до наступного стовпчика.
Розробка дизайну:
Цей та інші стовпці до «Закінчено» можуть змінюватися, оскільки саме команда вирішує, які кроки проходить завдання до стану «Закінчено».
Наприклад, в цьому стовпці можуть знаходитися завдання, для яких дизайн коду або інтерфейсу ще не визначені і обговорюються. Коли обговорення завершені, завдання переміщується до наступного стовпця.
Розробка:
Тут завдання знаходиться до тих пір, поки розробка фічі не буде завершена. Після завершення воно переміщується до наступного стовпця.
Або, якщо архітектура неправильна або недостатньо точна, завдання можна повернути до попереднього стовпця.
Тестування:
У цьому стовпчику завдання знаходиться, поки воно проходить тестування. Якщо знайдено помилки, воно повертається до Розробки. Якщо немає помилок, воно переходить далі.
Деплоймент:
У кожного проекту свій спосіб деплойменту. Для деяких це означає розміщення нової версії продукту на сервері, а для інших це просто коміт коду до репозиторію.
Закінчено:
Сюди картка потрапляє тільки тоді, коли всі роботи з завданням повністю завершені.

У будь-якій роботі можуть виникати термінові завдання. Заплановані або ні, але такі, які потрібно зробити прямо зараз. Для таких завдань можна виділити окреме місце (на зображенні позначене як «Expedite»). В Expedite можна помістити одне термінове завдання, і команда повинна почати його виконання негайно та завершити його якнайшвидше. Проте може бути тільки одне таке завдання! Якщо з’являється ще одне, воно повинно бути додане до «Черги завдань».
А тепер найважливіше. Бачите цифри під кожним стовпцем? Це число завдань, які можуть одночасно перебувати у цих стовпцях. Ці числа вибираються експериментальним шляхом, але вважається, що вони повинні залежати від кількості розробників у команді.
Наприклад, якщо у вашій команді є 8 програмістів, то у рядок «Розробка» ви можете помістити цифру 4. Це означає, що програмісти одночасно будуть виконувати не більше 4 завдань, що в свою чергу забезпечить їм багато причин для спілкування та обміну досвідом. Якщо ви встановите цифру 2, то 8 програмістів, які займаються двома задачами, можуть нудьгувати або витрачати занадто багато часу на обговорення. Якщо встановити 8, то кожен програміст буде займатися своєю задачею, і деякі задачі можуть тривати довго на дошці, адже головна мета Канбан — зменшення часу проходження завдання від початку до етапу готовності.
Ніхто не може дати точну відповідь на питання, якими повинні бути ці обмеження. Але можна спробувати спочатку розділити кількість розробників на 2 і побачити, як це працює у вашій команді. Потім ці числа можна підлаштувати під вашу команду.
Під «розробниками» я розумію не тільки програмістів, а й інших спеціалістів. Наприклад, для стовпчика «Тестування» розробники — це тестувальники, оскільки тестування — це їх обов’язок.

Каскадна модель (waterfall)

— високий рівень формалізації процесів;
— велика кількість документації;
— жорстка послідовність етапів життєвого циклу без можливості повернення до попереднього етапу.
Недоліки
• Каскадний проект повинен постійно мати актуальну документацію. Обов’язкове оновлення проектної документації. Надлишкова документація.
• Дуже негнучка методологія.
• Може створити хибне враження про роботу над проектом (наприклад, фраза «45% виконано» не несе корисної інформації, а є просто інструментом для керівника проекту).
• Замовник не має можливості заздалегідь ознайомитися з системою навіть з прототипом системи.
• Користувач не має можливості поступово звикати до продукту.
• Всі вимоги повинні бути відомі на початку життєвого циклу проекту.
• Виникає потреба в жорсткому управлінні і регулярному контролі, інакше проект швидко виходить з графіків.
• Відсутня можливість врахувати переробку, весь проект реалізується за один раз.
Переваги
• Висока прозорість розробки і фаз проєкту.
• Чітка послідовність.
• Стабільність вимог.
• Суворий контроль менеджменту проекту.
• Сприяє складанню плану проекту та формуванню проектної команди.
• Добре визначає процедуру контролю якості.

«Водоворот» або каскадна модель з проміжним контролем

У цій моделі передбачений проміжний контроль за допомогою зворотного зв’язку. Але це перевага також призводить до недоліків. Витрати на реалізацію проєкту в такому підході збільшуються практично в 10 разів. Ця модель, як ви вже зрозуміли, є незначною модифікацією попередньої і належить до першої групи.

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

Ітеративна модель

Ітеративні або інкрементальні моделі (існує кілька таких моделей) передбачають розбиття створюваної системи на набір частин, які розробляються за допомогою кількох послідовних прогонів всіх робіт або їх частин.

Каскадна модель з можливістю повернення до попереднього кроку при потребі переглянути його результати стає ітеративною.
Ітеративний процес передбачає, що різні види діяльності не є жорстко прив’язаними до певних етапів розробки, а виконуються за потреби, іноді повторюються, до тих пір, поки не буде досягнутий потрібний результат.
Разом з гнучкістю і можливістю швидко реагувати на зміни, ітеративні моделі вносять додаткові складнощі в управління проєктом і відстеження його прогресу. При використанні ітеративного підходу значно складніше адекватно оцінити поточний стан проєкту і спланувати довгостроковий розвиток подій, а також передбачити терміни і ресурси, необхідні для забезпечення певної якості результату.

Спіральна модель життєвого циклу програмного забезпечення

Дана модель чудово поєднує в собі поетапне прототипування і проєктування. Вона бере найкраще з висхідної та низхідної концепцій, поєднуючи їх в одну модель.

Переваги моделі:
1. Результат досягається в найкоротший термін.
2. Конкурентоспроможність є достатньо високою.
3. При зміні вимог не доведеться починати все з «нуля».
Проте у цій моделі є один суттєвий недолік: неможливість регламентування етапів виконання.

V модель — розробка через тестування

Ця модель має більш сучасний алгоритм, близький до сучасних методів, але все ще має деякі недоліки. Вона є одним із основних практик екстремального програмування і передбачає регулярне тестування продукту під час розробки.

V-модель забезпечує підтримку в плануванні та реалізації проекту. Протягом проекту вона вирішує наступні завдання:
• Мінімізація ризиків: V-подібна модель робить проект більш прозорим і підвищує якість контролю проекту шляхом стандартизації проміжних цілей та опису відповідних результатів і відповідальних осіб. Це дозволяє виявляти відхилення в проекті та ризики на ранніх етапах і покращує якість управління проектами, зменшуючи ризики.
• Підвищення та гарантування якості: Модель V є стандартизованою моделлю розробки, що дозволяє досягти бажаних якісних результатів від проекту. Проміжні результати можуть бути перевірені на ранніх етапах. Універсальна документація полегшує зрозумілість та перевірку.
• Зниження загальної вартості проекту: Ресурси для розробки, виробництва, управління та підтримки можуть бути заздалегідь розраховані та контрольовані. Отримані результати також є універсальними та легко прогнозованими. Це зменшує витрати на наступні етапи та проекти.
• Підвищення якості комунікації між учасниками проекту: Універсальний опис всіх елементів та умов сприяє взаєморозумінню всіх учасників проекту. Таким чином, зменшуються неточності у розумінні між користувачем, замовником, постачальником та розробником.

Модель на основі розробки прототипу

Дана модель базується на розробці прототипів та прототипуванні продукту і відноситься до другої групи.
Прототипування використовується на ранніх етапах життєвого циклу програмного забезпечення:
— Уточнити незрозумілі вимоги (прототип UI)
— Обрати один з ряду концептуальних рішень (реалізація сценаріїв)
— Проаналызувати здыйсненнысть проэкту
Класифікація прототипів:
— Горизонтальні прототипи — моделюють виключно інтерфейс користувача, не зачіпаючи логіку обробки та базу даних.
— Вертикальні прототипи — перевірка архітектурних рішень.
— Одноразові прототипи — для швидкої розробки.
— Еволюційні прототипи — перше наближення до еволюційної системи.

Модель Хаосу

Вкратце Стратегия хаоса — это стратегия разработки программного обеспечения основанная на модели хаоса. Главное правило — это,всегда решать наиболее важную задачу первой.

Экстримальне програмування (XP)

Дванадцять основних прийомів екстремального програмування (за першим виданням книги «Extreme programming explained») можна об’єднати в чотири групи:
• Короткий цикл зворотного зв’язку (Fine-scale feedback)
• Розробка через тестування (Test-driven development)
• Гра в планування (Planning game)
• Замовник завжди поруч (Whole team, Onsite customer)
• Парне програмування (Pair programming)
• Безперервний, а не пакетний процес
• Безперервна інтеграція (Continuous integration)
• Рефакторинг (Design improvement, Refactoring)
• Часті невеликі релізи (Small releases)
• Зрозуміння, яке спільне для всіх
• Простота (Simple design)
• Метафора системи (System metaphor)
• Колективна власність коду (Collective code ownership) або обраних шаблонів проектування (Collective patterns ownership)
• Стандарт кодування (Coding standard or Coding conventions)
• Соціальний захист програміста (Programmer welfare):
40-годинний робочий тиждень (Sustainable pace, Forty-hour week)

RATIONAL UNIFIED PROCESS (RUP)

 — методологія розробки ПЗ, створена компанією Rational Software.

В основі методології лежать 6 основних принципів:

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

Використання методології RUP спрямоване на ітеративну модель розробки. Особливістю методології є те, що ступінь формалізації може змінюватися в залежності від потреб проекту. Після завершення кожного етапу і кожної ітерації можна створювати всі необхідні документи і досягати максимального рівня формалізації. Також можна створювати лише ті документи, які необхідні для роботи, включно з можливістю їх повної відсутності. Завдяки такому підходу до формалізації процесів, методологія RUP є достатньо гнучкою і широко популярною. Ця методологія може бути застосована як у невеликих і швидких проектах, де за рахунок відсутності формалізації потрібно скоротити час виконання проекту та витрати, так і у великих і складних проектах, де потрібний високий рівень формалізму, наприклад, з метою подальшої сертифікації продукту. Ця перевага дає змогу використовувати одну і ту ж команду розробників для реалізації проектів різного обсягу та вимог.

MICROSOFT SOLUTIONS FRAMEWORK

 — методологія розробки програмного забезпечення була запропонована корпорацією Microsoft і базується на практичному досвіді Microsoft і описує управління людьми та робочими процесами під час розробки рішень.

Базові концепції та принципи моделі процесів MSF:

• єдине бачення проекту — всі зацікавлені сторони і учасники проекту повинні чітко уявляти кінцевий результат, всім повинна бути зрозуміла мета проекту;
• управління компромісами — пошук компромісів між ресурсами проекту, календарним графіком та реалізовуваними можливостями;
• гнучкість — готовність до змінюються проектних умов;
• концентрація на бізнес-пріоритетах — фокус на тих користях і вигодах, які очікує отримати споживач рішення;
• сприяння вільному спілкуванню всередині проекту;
• створення базової версії — фіксація стану будь-якого проектного артефакту, включаючи програмний код, план проекту, посібник користувача, налаштування серверів, та подальше ефективне керування змінами, аналітика проекту.
MSF пропонує перевірені методики для планування, проектування, розробки та впровадження успішних ІТ-рішень. Завдяки своїй гнучкості, масштабованості та відсутності жорстких інструкцій MSF здатний задовольнити потреби організації або проектної групи будь-якого розміру.
Методологія MSF складається з принципів, моделей та дисциплін з управління персоналом, процесами, технологічними елементами та питаннями, пов’язаними з цими факторами, які є типовими для більшості проектів.
Джерела: youmanager.pro, fresh2l.com, ru.wikipedia.org, tim.com.ua (деякі ворожі джерела були видалені зі списку).
Nice to read: www.scrumalliance.org/...​ns/Core-Scrum-Russian.pdf
👍ПодобаєтьсяСподобалось18
До обраногоВ обраному43
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Команда може зупинити спринт, якщо вона розуміє, що не зможе досягти цілі спринта у відведений час.

Це помилка

Чия? Команда може зупинити спринт просто вставши зі столу та піти додому. Чи в окоп ) То теж помилка? )

дуже цікава інформація все структоровано дякую)

До сих пір актуальна інформація. Дякую.

1.а вот Куликов в своей книге пишет что каскадная модель не применима к большим проектам вообще, потому что тестирование начинается поздно и любая ошибка влетит в копеечку.
2. в описании инкрементной итеративной модели ошибка —

корректировкой предыдущих этапов работы.

, в зависимости от анализа предыдущих этапов разработки, корректируются последующие (для оптимизации), разве нет?

Коментар порушує правила спільноти і видалений модераторами.

Кто это писал? Что за бред: цитирую:

Канбан — это даже еще более «гибкая» методология, чем SCRUM и XP. Это значит, что она не подойдет всем командам и для всех проектов.

Это я скопипастил 4 года назад ) А в чём собственно проблема?

А какой смысл со всей этой инфы на русском?) В основном же все хотят интервью со всеми определениями на английском!

Все хотят понимания, а на каком языке ты это понимаешь — менее важно. А требование по языку — это отдельное требование.

я по этой чудесной информации обучался до первой своей работы, большое спасибо автору!Все коротко изложено и понятно.

Дякую за статтю.

Умерла илюстрация из раздела:

MICROSOFT SOLUTIONS FRAMEWORK
Не осталась ли она у вас где-то?

Спасибо, починил. С другого ресурса взял. Сайт видимл съехал, хост пингуется, но ошибка 404.

Теперь понятна массовая любовь к Trello — используют его как сервер канбан-досок.

Тю. Ничего не понимаю. Есть “положення про відділ” в котором ты работаешь и шлешь лесом всех, кто говорит что то делать не в компетенции отдела. И, самое главное, есть “посадові інструкції” когда шлешь лесом всех, включая твоего начальника, если задание не соответствует твоей должности :) Легко и просто, зачем эти приколы ? Если надо совтец разработать — сиди разрабатывай, хуле, тыжпрограмист :)

Что поделать — некоторым нравится забивать свою голову ненужными теориями, высосанными из пальца методологиями и другим непотребным хламом, который не относится к работе.

Если должность и место работы в вашей подписи «Менеджер Буфера Обмена в ГосСлужба» правдивы, то я не могу не заметить, что описанная позиция идеально с ними согласуется.

А хтось може пояснити різницю між спіральною та ітеративною розробкою ?

І може в когось є більш детальна інфа по MSF та RUP ? Хотілось би чогось детального, як про скрам

И еще просьба к гибкометодологам напишите плиз в какой-нить методичке, что

Daily Scrum Meeting
надо проводить в 11-00, а то у меня на утреннюю тренировку по футболу люди не могут ходить — в общем гибкости не хватает :)

11:45

куда 600 баксов сдавать? :)

Это уже не шпаргалка. «До*** масла» ©

Абсолютно всё. Зачем забивать себе этим голову? Все эти спиральки, Канбан-доски и Agile с Waterfall имеют очень посредственное отношение как к программированию, так и к тестированию.
Но за материал спасибо — столько ужаса в одном месте давно не видел. Буду давать ссылку друзьям.

Всё не лишнее, ибо всё это спрашивают на собеседованиях. И про вотерфол и про скрам и даже про канбан. Поэтому знать общие ответы на общие вопросы надо.

На собеседованиях так подробно не спрашивают.
Сложно представить себе ситуацию, когда разработчика не берут на работу, потому что он не знает что такое «спиралевидная разработка», а не потому что он не умеет кодить.

На собеседовании такое спрашивают — тестировщиков, джунов. Про разработчиков в этой теме вроде нигде не сказано.

Меня спрашивали много по скраму, канбану, вотерфолу и ви модел. Дэвов меньше по этому всему спрашивают, чем тестировщиков.

Много текста, который разжевывает тезисы. Шпаргалка — это когда очень кратко (тезисно) обозначены моменты, а тут получился конспект. Его так незаметно не вытянешь да и пока найдешь нужное )
Сравнительная таблица могла бы быть — что совпадает, что различается, плюсы/минусы.

Еще добавлю по практическому использованию для собеседований. Если на них затрагивается, например, скрам, то стараются выяснить какой именно скрам был на проектах у кандидата. Для кого-то это ежедневные стендапы и все, где-то спринты расписаны на несколько штук вперед и при этом нет деливери рабочего решения в конце спринта — просто разбили скоуп вотерфолла на несколько этапов, бывает что никто не грумит бэклог и решение о том, что взять в спринт принимается на основе личных предпочтений каждого участника, бывает что Вася — всегда занимается лоу-левелом, а Маша — UI, тогда как Петя — сетевыми интерфейсами и задачи такого типа всегда будут падать именно на них, взаимозаменяемости нет и об оценки в попугаях даже и речи быть не может — пишут сколько конкретно часов займет именно вот эта подзадача. Ну и так далее. А кроме скрама и вотерфолла обычно только декларативно, мол, у нас тут V-Model, но вот команды работают по скраму(мы ж прогрессивные), но у нас процессы строгие, так что сначала мы полностью заканчиваем каждый этап... В материалах ознакомительных на входе в проект прочитаешь по какому принципу идет разработка, а потом увидишь реальность. Для джуниора важнее понимать, что именно _может_быть_еще_кроме_самого_написания_кода_, чтоб он чуть представлял влияние своих действий на задачи проекта.

Все. Это просто взято и скопипащено с википедии. Ни примеров, ничего

В первой части написано, что это не отсебятина, а копипаст. Но не с вики, а с разных ресурсов. Где мне описание больше понравилось, то и вставлял. Будучи джуном трудно иметь практический опыт по всем методологиям, согласны? Это шпоргалка для джуна/трейни для повторения в маршрутке перед собеседованием, не больше. Это и сказано в первой части.

Коментар порушує правила спільноти і видалений модераторами.

Сам термин Scrum, я бы определила так — это методология управления проектами, которая построена на принципах тайм-менеджмета.
Gennadii, я розумію що мопед не ваш, ви тільки копі-пасту розмістили і все таке інше.
Але Scrum — не методологія. Відкрийте Scrum guide для початку, ознайомтеся з об’єктом, про який пишете. Не треба бездумного копі-пасту, тим паче для новачків. Не вчіть їх одразу неправильних визначень.
Во-первых, нужно сразу понять, что Канбан — это не конкретный процесс, а система ценностей. Как, впрочем, и SCRUM с XP.
В-третьих, Канбан — это даже еще более “гибкая” методология, чем SCRUM и XP.
WAT?? (facepalm)
Gennadii, я розумію що мопед не ваш, ви тільки копі-пасту розмістили і все таке інше.
Именно. Я ж для этого и список ресурсов скинул специально. Я не так много работаю, чтоб на своём опыте столько методологий расписать. Это шпаргалка для себя и кому нужно.

Из вики: Scrum is an iterative and incremental agile software development methodology for managing product development.

Просто сказать: “Это г...” — не серьёзно. Тема создавалась с целью обсуждения, а не оценки. Ваши мысли на счёт методологий?

Відколи вікі стала ресурсом на який варто ссилатися? Її пишуть такі самі копі-пастери.
Відкрийте вже Scrum Guide від розробників фреймворку, і перестаньте апелювати до вікі.

А обговорювати тут немає чого. В своїй масі, даний матеріал — це набір тексту, місцями далекого від правди, з перекрученими термінами і визначеннями. Він аж ніяк не закладе правильний базис для початківців, скоріше принесе їм проблем.

Якщо вже дуже хочеться щось порекомендувати початківцям — є непогана книжка від Бориса Вольфсона по Agile методологіях та підходах (не покриває «класичні» waterfall і т.д.), хоча 2012 року та з певними помилками, але явно краще чим гора копі-пейст тексту: blog.byndyu.ru/...2012/02/blog-post_04.html

Можна просто подати на неї ссилку, і нема необхідності копі-пастити з неї текст на ДОУ.

Відколи вікі стала ресурсом на який варто ссилатися?
Российская — нет. Английская — конечно.

Любая — это очень сомнительный источник знаний когда речь идет об узкопрофильных статьях...

Был бы благодарен за конкретные определения, что есть фреймворк, а что есть методология в рамках разработки софта. За книгу спасибо — обязательно прочитаю. На счёт ссылки на книгу вместо сжатой инфы не согласен. Когда идёшь на собеседку и надо быстро повторить по дороге в офис, то книгу читать не станешь.

xxx: Завтра иду не собеседование тестировщиком, опыта ноль. Что посоветуете прочитать?
yyy: Pаз собеседование уже завтра, то почитать советую Рэя Брэдбери, он прекрасно пишет.

Методология — описывает процесс разработки софта, а скрам — это просто фреймворк (рамочка которая имеет ряд рекомендаций, которые можно натянуть на свой процесс...)

Кроме того в статье еще много «поверхостных суждений» как-то V-Model — разработка через тестирование.

Вы делаете хорошее дело и за это безусловно зачет! Но одно из двух: или надо делать качественно (тем более, что вы QA :)), или может не стоит сразу обьять необьятное? (надеюсь «пока необьятное»)

тем более, что вы QA :)
Хороший пример гало-эффекта.
Гало-эффект — это когда люди ошибочно полагают, что тот, кто здорово катается на лыжах, будет столь же здорово руководить гончарной мастерской или отделом банка, или что хороший шахматист и в жизни просчитывает все ходы наперед.

Отличный коммент, давай статью на тему гало-эффекта у программистов и QA)

материал хороший, большое спасибо. Главное, чтоб люди хорошо владели материалом и понимали его, а не тупо заучивали.

Когда идёшь на собеседку
Стрельнуть неплохо сигаретку,
Достав селедку из газетки,
Что Маня принесла (соседка),
А маны покурить в беседке —
Оставим это тем, кто относится к делу серьёзно. Хотя ну их — скучные они.
Антоша, зажигай!

Попытка урвать лайков а ля Наталия не удалась

Підписатись на коментарі