Верь тому, что видишь, а не тому, что говорят люди

Печально, что нас никогда не учат отказываться от предположений. Себастьян Трун

Многие проблемы в разработке программного обеспечения возникают не из-за кода, а из-за того, что разработчики создают неправильное программное обеспечение. В этом нет ничего необычного, потому что программное обеспечение возникает, и большинство людей понимают, чего они хотят, только после того, как создано то, о чем они просили, и понимают, что это не так.

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

Плотники дважды отмеряют и один раз режут дерево. Разработчики редко бывают такими осторожными.

Тест желтого кота

Дом дракона снова сделал драконов крутыми, поэтому я читаю книгу Игра престолов.

Тест желтого кота принадлежит Сирио Форелю, мастеру фехтования, которому поручено обучить Арью Старк фехтованию.

Арья фехтует с Сирио. Он говорит ей, что собирается ударить слева. Она уклоняется влево, и он наносит ей удар. Арья говорит, что ты солгал. Сирио говорит, что его слова лгали, но глаза и рука кричали правду, а ты не видел.

Сирио рассказывает Арье историю о том, как он стал первым мечом Бравоса.

"Услышь меня. Корабли Браавоса плывут так далеко, как дуют ветры, в земли странные и чудесные, а когда они возвращаются, их капитаны приносят странных животных в зверинец Морского лорда. Такие животные, каких вы никогда не видели, полосатые лошади, большие пятнистые твари с шеями длиной с ходули, волосатые свиньи-мыши величиной с корову, жалящие мантикоры, тигры, несущие своих детенышей в сумке, страшные ходячие ящерицы с косами вместо когтей. Сирио Форель видел все это.

«В тот день, о котором я говорю, первый меч был недавно мертв, и Морской Лорд послал за мной. К нему приходило много браво, и так как многие были отосланы, никто не мог сказать, почему. Когда я подошел к нему, он сидел, а на коленях у него был толстый желтый кот. Он сказал мне, что один из его капитанов привел к нему зверя с острова за восходом солнца. «Вы когда-нибудь видели ее такой?» — спросил он меня.

«И я сказал ему: «Каждую ночь в переулках Браавоса я вижу тысячу таких, как он», и Морской Лорд рассмеялся, и в тот день меня назвали первым мечом».

Арья сморщила лицо. "Я не понимаю."

Сирио щелкнул зубами. Кот был обычным котом, не более. Остальные ожидали сказочного зверя, вот что они увидели. Насколько он велик, сказали они. Он был не крупнее любой другой кошки, только разжирел от лени, потому что Морской Лорд кормил его со своего собственного стола. Какие любопытные маленькие уши, говорили они. Его уши были отгрызены в кошачьих драках. И это был явно кот, но Морской Лорд сказал «она, и это то, что увидели остальные. Ты слышишь? Обсуждение на Reddit.

Команды разработчиков должны видеть, что там есть, и не верить тому, что им говорят.

Я работал над проектом, где мы создали систему записи на прием. Изначально мы думали, что это система записи на прием. Позже, когда мы поняли назначение программного обеспечения, оно заключалось в том, чтобы назначать нужных людей на встречи и отговаривать людей, которые не нужны бизнесу.

За первые 3 месяца проекта требования и понимание программного обеспечения были правильными только наполовину.

Откройте глаза

«Откройте глаза — это все, что нужно. Сердце лжёт и голова играет с нами злые шутки, а глаза видят правду. Смотри глазами, слушай ушами. Вкусите ртом. Нюхать носом. Почувствуйте своей кожей. Потом приходит размышление и таким образом познание истины» Сирио Ферел

Нам нужно видеть, что там есть, а не то, что люди говорят команде разработчиков или как, по мнению разработчиков, должно работать программное обеспечение. Первоначальные требования покрывают 50/70 процентов и всегда будут меняться.

Предположение — это ошибки, созданные разработчиками, предполагая, что они знают, как должно работать программное обеспечение. Разработчикам необходимо открыть глаза на предположения и как можно скорее уточнить их.

Если команда разработчиков строит на предположениях, когда предположение неверно, код и все остальное (код, devops, документацию, тесты) необходимо будет изменить.

Всегда быстрее и проще исправить требования до написания кода.

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

Тестировщики полезны для того, чтобы посмотреть на требования с другой точки зрения. Они смотрят на то, как требования не должны работать и как вы можете сломать программное обеспечение.

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

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

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

Наблюдать — это не то же самое, что видеть, а требования высокого уровня — это не то же самое, что подробные требования.

  • Значение слов основано на толковании
  • Презентации высокого уровня и оптимистичны/предвзяты
  • Понимание людей может быть запутанным или неверным или только с одной точки зрения (половина истории)
  • Требования, ситуации, люди, планы, схемы, проекты, документы и многое другое может лгать разработчикам.

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

После написания кода и создания программного обеспечения команда разработчиков несет ответственность за его изменение и исправление любых возникающих с ним проблем.

Разработчики создают программное обеспечение с неполной информацией, им нужно заполнить пробелы, чтобы создать полную картину.

Заключение

Подумайте о желтом коте, когда люди объясняют требования, потому что они часто ошибаются.

Уточните требования, предположения и все, что можно, перед созданием кода.

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

Изменить код сложнее, чем изменить требования.