Як досягти успіху на семінарах із специфікацій BDD?

Сьогодні ми намагалися впровадити BDD у наш процес розробки програмного забезпечення, провівши семінар із специфікації.

Для цього семінару у нас було 2 розробника, 1 тестер і 1 бізнес-аналітик. Семінар тривав 1 год30, і до кінця цього року нам вдалося розібратися з деякими сценаріями BDD для нашої нової функції. Ми намагалися зосередитись на пошуку тих сценаріїв, які ми могли б пропустити, і складних.

Наприкінці семінару деякі люди насправді були незадоволені майстернею.

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

Цей експериментальний семінар тривав 1:30, і до кінця ми не відчували впевненості в тому, що зробили ... впевнені, що ми могли витратити на нього більше часу, але, чесно, більшість людей виснажуються після 1 години 30 мозкового штурму, щоб отримати бізнес. правила з мозку БА.

Отже, моє запитання полягає в тому, як насправді може працювати така майстерня. У теорії, якщо у вас є нова функція, яка повинна розвиватися, ви поміщаєте дерево "amigos" (dev / tester / ba) в одне приміщення, щоб вони могли спільно співпрацювати над написанням різних вимог до нової функції за допомогою прикладів. Я бачу всі переваги від цього. Спеціально з точки зору обміну знаннями та загальної продуктової / кінцевої цілі / бачення.

Нашим висновком цього експерименту було те, що насправді вигідніше спочатку мати бакалавра, щоб він працював самостійно на прикладах, а вже потім переглянув / переробив сценарії 3 "amigos". Маючи бакалавр працювати самостійно, ми насправді відчуваємо себе більш впевненими, що ми менше не будемо пропускати речі + ми все одно переглянемо сценарії після цього, щоб подвійно перевірити. Ми не думаємо, що простого одноразового мозкового штурму / навмисного сеансу виявлення насправді потрібно серйозно покрити всі вимоги до нової функції. Бізнес-аналітик насправді найкраща людина для подібних речей. Найкраще, що ми можемо зробити, - це переглянути те, що вона написала, і побачити, якщо тоді у нас є спільне розуміння (що може призвести до того, щоб переписати деякі її сценарії або додати нові, які вона могла б пропустити).

Тож як ти можеш так ефективно працювати на практиці ?

Якщо ви можете отримати сценарії з опису, ви закінчили.

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

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

Так само я можу сказати: "Ось форма для реєстрації користувача. Нам потрібно мати можливість створити нових користувачів, дозволити їм редагувати свої дані та видаляти себе, за винятком того, що видалення насправді не видаляється, воно повинно просто позначати їх як видалені щоб вони могли відновити свої акаунти, якщо хочуть ".

Ви можете запитати: "Чи відновлення облікового запису є частиною цієї функції?"

"Якщо ви хочете, це може бути дві функції".

"Гаразд, тому у нас є сценарії створення, читання, оновлення, видалення; це повинно бути досить простим. Поговоримо про відновлення облікового запису; це звучить цікавіше."

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

Якщо ви ніколи цього не робили раніше або ви не впевнені, поговоріть за сценаріями.

Зосередьтеся на незвичайних областях, особливо якщо є функції, яких ви ніколи не робили. Це фантастичні місця для розмов та записування будь-яких дивовижних прикладів. Зазвичай у мене виникають два запитання на основі шаблону BDD:

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

• Чи є якийсь інший контекст, який для однієї події дає різний результат?
• Чи є якийсь інший результат, який також важливий?

Якщо всі за столом виглядають нудно, можливо, ви добре розумієте функцію, про яку ви говорите. Досить часто говорити: "Це має працювати як X , але замість Y ". Саме так Ден Норт називає візерунок торта імбиру ; це як рецепт шоколадного торта, але з імбиром замість шоколаду.

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

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

Іноді BDD не працює.

Інша можливість полягає в тому, що ви знайдете сценарій, щодо якого невпевнений власник бізнесу. "О, я не думав про це! Не впевнений". Замість того, щоб намагатися знищити бізнес і покарати бізнес із впевненістю, можливо, варто відмовитися від BDD в цей момент і спробувати щось просте, щоб отримати зворотній зв'язок і дати бізнесу щось, над чим вони можуть повторити. Не змінюйте та пишіть сценарії, коли краще зрозумієте, що відбувається.

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

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

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

• Прості та складні речі (відомі) часто добре зрозумілі, і вам не потрібно детально розмовляти за сценаріями.

• Високоскладні речі (невідомі) взагалі не розуміються. Ви можете виявити це, розмовляючи за сценаріями. Відсутність впевненості означає, що BDD тут не працюватиме, тому перегляньте щось, що легко змінити, і натомість отримайте швидкий зворотний зв'язок. Будь-яка практика, яка зберігає ваші параметри, як тестування АБ, також чудова в цьому просторі.

• BDD блискуче працює в просторі між (знаючими) як механізм передачі знань та розкриття двох інших просторів. Це не молоток, і не все - цвях. Насправді, якщо ви можете зосередити час, витрачений на розмови, на що-небудь, це не стосується прикладів, які ви можете знайти; йдеться про пошук прикладів, яких ви не можете .

Тривалість зустрічі - це не ваша проблема. Добре, щоб ці зустрічі тривалий час тривали. АЛЕ всі повинні вийти з цього почуття впевненості. Те, що вони не зробили - це ваша проблема.

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

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

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

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

Завжди переконайтесь, що всі учасники наради готові до теми цієї зустрічі!

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

Загальний рецепт ефективних зустрічей:

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

Про скарги ...

Почнемо з цього:

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

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

Бізнес-аналітик не відчував впевненості у висвітленні нашого сценарію (мав відчуття, що ми могли пропустити інші важливі речі)

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

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

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

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

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

Пропозиції

• Будьте позитивними і підкресліть, що якщо процес буде правильним, ви будете в ньому краще.

• Спробуйте впорядкувати майстерню та тримати її на шляху.

• Можливо, дайте трохи можливостей для аналізу "вовк-одиночки", розпочавши семінар, коли кожен спроектував декілька сценаріїв самостійно (ще краще, перед семінаром), а потім попростуйте та об'єднайте їх.

І якщо ви не вважаєте, що робити цю мозкову атаку потрібно добре, будь ласка: попросіть бакалавра поодинці, але тоді робіть огляд як семінар. Чим більше очних яблук , тим краще, щоб процитувати Ерік Реймонд «S Закон Лінуса» :

Given enough eyeballs, all bugs are shallow.

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

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