Чи варто кинути спробу зробити спритний, якщо QA займає 12 тижнів?

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

Ну, пряма відповідь на ваше запитання буде: Мушусь, я боюся - просто не вистачає деталей, щоб зрозуміти, чи варто чи ні кинути спробу.

Єдине, в чому я дуже позитивний, - це рівень спритності, який повинен визначатися потребами клієнта / ринку (про які ви нічого не давали).

• ^{Наприклад, як користувач IDE я дуже радий перейти на нову версію раз чи, можливо, два рази на рік, і ніколи не поспішаю з цим. Тобто, якщо цикл їх випуску становить 3 місяці ( 12 тижнів ), то я цілком задоволений цим.
   
  З іншого боку, я можу легко уявити собі, скажімо, фінансовій торговій компанії збанкрутують, якщо для адаптації їх програмного забезпечення до змін на ринку потрібно більше місяця - тестовий цикл 12 тижнів у цьому випадку буде дорогою до пекла. Тепер - які потреби у вашому товарі мають у цьому плані?}

Ще слід врахувати, який рівень якості необхідний для задоволення потреб вашого клієнта / ринку?

• ^{Справа в суті - в компанії, в якій я колись працював, ми виявили, що нам потрібна нова функція в продукті, що має ліцензію від якогось постачальника програмного забезпечення. Без цієї функції ми страждали досить сильно, так що так, ми дуже хотіли, щоб вони були спритними та оновлювались протягом місяця.
   
  І так, вони виявилися спритними, і так, вони опублікували це оновлення через місяць (якщо їх цикл QA становить 12 тижнів, вони, ймовірно, просто пропустили його). І наша функція спрацювала чудово - гадаєте, ми повинні були бути абсолютно щасливими? ні! ми виявили помилку регресії showstopper в деяких функціональних можливостях, які раніше працювали чудово - тому нам довелося дотримуватися старішої версії.
   
  Минув ще один місяць - вони випустили ще одну нову версію: наша функціябула там, але така ж помилка регресії була і там: знову ми не оновили. І ще місяць і ще.
   
  Зрештою, нам вдалося модернізувати лише через півроку стільки для їх спритності.}

Тепер давайте докладніше розглянемо ці 12 тижнів, про які ви згадали.

Які варіанти ви розглядали для скорочення циклу якості? як ви бачите з наведеного вище прикладу, просто пропустивши його, це може не дати вам того, чого ви очікуєте, тож вам буде краще бути, спритним і розглянути різні способи його вирішення.

Наприклад, чи розглядали ви способи поліпшити перевірку продукту?

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

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

оновлення на основі роз'яснень, наданих у коментарях

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

Колірний випуск я бачу. Гм. Хммм. Спробуйте додати постріл або два Lean в свою моторний коктейль. Я маю на увазі, якщо це не потреба клієнта / ринку, то це означатиме лише марнотратство (тестування) ресурсів.

Я, напевно, не бачу нічого злочинного в трактуванні спринту-релізу як просто деякої контрольної точки, яка задовольняє команду.

• ^{dev: так, це виглядає досить добре, щоб перейти до тестерів; QA: так, це виглядає досить добре для випадку, якщо потрібні подальші перевірки на судноплавство - такі речі. Команда (dev + QA) задоволена, ось і все.}

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

Ви все зрозуміли правильно. Крім того, з того, що ви описуєте, схоже, що ви потрапили до штату (зрілість команди / управління та відносини з клієнтом), що дозволяє використовувати регулярну ітераційну розробку моделі замість Scrum. Якщо так, то, можливо, вам також буде цікаво дізнатися, що за моїм досвідом у таких випадках, як регулярний ітератор, він почувався більш продуктивним, ніж Scrum. Набагато більш продуктивним - там було просто так набагато менше накладних витрат, це було просто так набагато легше зосередитися на розвитку (для QA , щоб відповідно зосередитися на тестуванні).

• ^{Я зазвичай думаю про це в плані Ferrari (як регулярний ітеративний) проти Landrover (як Scrum).
   
  Під час руху по шосе (а ваш проект, здається, досяг цього шосе ), Ferrari б'є пекло з Landrover.
   
  Це позашляховик, де потрібен джип, а не спортивний автомобіль - я маю на увазі, якщо ваші вимоги нерегулярні та / або якщо командна робота та досвід управління не такі гарні, вам доведеться вибирати Scrum - просто тому, що спроби їхати регулярно отримають вас застряг - як Ferrari застрягне бездоріжжя.}

Наш повний продукт справді складається з безлічі менших деталей, які можна оновити незалежно. Я думаю, що наші клієнти дуже готові модернізувати ці менші компоненти набагато частіше. Мені здається, що ми, мабуть, повинні зосередитись на випуску та QA'ing тих менших компонентів на кінці спринтів, а не ...

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

• ^{Слід пам’ятати про цю стратегію - перевірити перевірку, що зміни локалізуються там, де очікується. Навіть якщо це доходить до порівняння файлів по бітам для компонентів, які не змінилися, перейдіть до нього, або ви не отримаєте його. Справа в тому, що за якість випуску відповідає QA, а не ми, розробники.
   
  Це головний біль тестера, щоб переконатися, що несподівані зміни не проскочили - адже відверто кажучи, як розробник у мене є достатньо інших речей, щоб переживати про це, що для мене важливіше. І тому вони (тестери) справді потребують надійного підтвердження того, що все контролюється з випуском, який вони перевіряють.}

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

Моя порада - розділити команду на три команди:

Тестування функцій - Швидкий поворот на тестуванні нових розробок.

Регресійне тестування - Повна перевірка продукту перед виходом із дверей. Це не повинно зайняти 3 місяці, навіть після зменшення розміру команди, оскільки більшість помилок знайде перша команда.

Автоматизоване тестування - складання повного набору регресійних тестів для прискорення роботи команди регресійного тестування.

Третя команда - бонус, але якщо ви не можете мати перших двох команд, то ви також можете бути водоспадом.

Для ілюстрації:

Зауважте, що ваша команда з питань якості, ймовірно, працює поза колом (ATDD), а ви працюєте всередині.

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

Здається, у вас є проблема "Визначення закінченого".

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

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

QA нічого не повинен знайти.

До цього буде важче дістатися. Напевно у вас будуть деякі речі, які прокрадаються перші кілька разів. Автоматизовані тести приймання та тести "регресії" - ваші найкращі друзі тут. TDD допоможе вам зібрати велику частину таких наборів. Ви повинні мати можливість знати - швидко - якщо ви щось зламали.

Чи є у вас представник замовника / власник продукту, який може побачити даний випуск до того, як QA буде виконаний з ним і надати вам авторитетний зворотний зв'язок по ньому? Якщо це так, ви можете зробити і отримати більшу користь, спритних методів, розглядаючи QA як вторинне, дещо повільне джерело зворотного зв'язку. Випуск буде лише "офіційно готовим" після того, як QA закінчиться, але вам не доведеться чекати їх перед початком наступного.

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

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

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

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

Шкода, що зворотний зв'язок займає так довго, але я не думаю, що варто зупинятися на спритності. В кінці спринту (або пари) ви випускаєте товар, на який ви впевнені, що його можна буде випустити на ринок. Для вашої команди спритний приносить можливість зосередитись на роботі, яка повинна бути виконана, і зберігати виріб, що звільняється. Коли QA знайде проблеми, я пропоную створити звіти про помилки для цих питань та вирішити їх у наступному спринті (якщо вони мають достатньо високий пріоритет).

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

Проблема лежить (на ваших очах) у відділі контролю якості, чи можна там проблему вирішити? Ви це обговорювали?

12 тижнів триває, але, сподіваємось, QA може надати вам зворотній зв'язок та повідомлення про помилки протягом цього часу (а не після трьох місяців).

Тоді ви все ще можете відповісти на найважливіші проблеми по-грішному і зможете виправити багато, якщо не все, перш ніж вони навіть закінчили!

Що роблять QA люди, виконуючи кілька спринтів? Схоже, вони відчувають потребу перевірити все після кожної зміни (саме тому вони чекають цілого ряду змін.).

Команда розробників спритна, але решта компанії - ні.

Той, хто відповідає за QA, або не знає, чим він займається, або вони здійснили хитрість розуму джедаїв у керівництві, і їм дозволено провести час. Як QA може зайняти більше часу, ніж розвиток?