Мало кому з розробників вдається пройти «тест рудого кота» — і ось чому

Шкода, що нас не вчать ігнорувати припущення (Себастьян Трун)

Solution Architect Бен Хоскінг вважає, що проблеми з програмним забезпеченням виникають не через хибний код. Просто розробники створюють «не те». Він певен, що, на жаль, більшість людей розуміють, чого ж вони хочуть, лише після того, як отримують своє замовлення. Ось тоді вони і усвідомлюють, що їм треба було щось зовсім інше. 

Але розробники все ж можуть вплинути на ситуацію: варто задавати більше питань та пройти «тест рудого кота». 

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

Що ж, передаємо йому слово.

Тест рудого кота

Завдяки «Дому дракона» дракони знову в моді, тож я читаю книгу «Гра престолів».

Отже, поговоримо про «тест рудого кота» від Сиріо Фореля, майстра меча, якого найняли, щоб навчити Ар’ю Старк фехтуванню.

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

Сиріо розповідає Ар’ї, як він став першим мечем Браавосу:

«Послухай мене. Кораблі Браавосу допливають усюди, де дмуть вітри, до земель дивних і чудових, і коли вони повертаються — їхні капітани приводять чудернацьких тварин до звіринця Морського Лорда. Тварин, яких ти ніколи не бачила: смугастих коней, величезних плямистих тварюк із шиями завдовжки з ходулі, волохатих мишосвиней розміром з корову, мантикор, що жалять, тигрів, які носять своїх дитинчат у сумці, жахливих двоногих ящурів з косами замість кігтів. Сиріо Форель бачив їх усіх.

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

“Чи бачив ти коли-небудь щось подібне?” — запитав він мене.

Я відповів йому: “Щоночі я бачу тисячі таких, як він, у провулках Браавосу”. І Морський Лорд засміявся, і того ж дня мене назвали Першим Мечем».

Ар’я скривилася: «Я не розумію».

Сиріо клацнув зубами: «Той кіт був звичайнісіньким. Інші очікували казкового звіра і бачили його. “Який він великий”, — казали вони. А він був не більший, ніж інші коти, лише товстий від лінощів, бо Морський Лорд годував його із власного столу. “Які цікаві маленькі вушка”, — казали вони. Насправді його вуха були відгризені в котячих бійках. І то явно був кіт. Але Морський лорд сказав “вона” — і інші бачили кішку».

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

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

Протягом перших трьох місяців ми бачили лише половину задачі.

Розплющіть очі

«Розплющити очі — це все, що потрібно. Серце бреше, розум викидує коники, і лише очі бачать так, як є. Дивися очима, слухай вухами. Пробуй ротом. Нюхай носом. Відчувай шкірою. Потім прийде розуміння, і таким чином, ти дізнаєшся правду» (Сиріо Форель).

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

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

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

Внести правки завжди виходить швидше та простіше, якщо це робиться до того, як написано код.

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

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

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

Розробка програмного забезпечення

Дивитися — це не те саме, що бачити. Так само і вимоги високого рівня не дорівнюють детальним вимогам.

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

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

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

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

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

Висновки

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

Автор: Бен Хоскінг

Переклала Євгенія Козловська