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

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

В чем тогда вопрос?

Если бы я хотел (продать / раздать) созданное вами программное обеспечение (сообществу / клиенту с открытым исходным кодом) прямо сейчас, как вы думаете, они будут счастливы (купить / использовать)?

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

Вопрос - это вопрос самоанализа, саморефлексия над вашим творением.

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

Этот вопрос дает представление о мыслях и восприятии того, что строители думают о своих творениях. Несомненно, некоторые из предположений и конструктивных решений, сделанных ранее, будут неверными. Мы знаем только то, что знаем, и принимаем наилучшее возможное решение в настоящее время на основе данных фактов. Учитывая результат этих разговоров, у нас есть прекрасная возможность пересмотреть и утвердить проекты.

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

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

Избегайте попадания в кроличью нору восприятия вины

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

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

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

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

Вопрос помогает нам развить интроспективное мышление.

Когда мы не исследуем творения, это приводит к недоработанному доказательству концепций, помещенных в репозиторий git. Следовательно, существует реальная необходимость в самоанализе. Заставить разработчиков собраться вместе, чтобы поверить в одну-единственную цель - я думаю, это ключ к выпуску программного обеспечения хорошего качества.

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

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

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

Во время самоанализа оцените все количественно

Нет смысла проводить самоанализ, если вы не можете измерить.

На основании всех отзывов, полученных разработчиками, ставьте количественные цели для вашего проекта. Дизайн и архитектура - это бесконечный процесс. Теоретически каждый компонент в приложении может быть улучшен, хотя эта идея верна, должен быть установлен потолок, а также сдерживаться бесконечная кроличья нора улучшений.

Упражнение по записи мыслей

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

Кредитное плечо на картах Таро Tec

В 2018 году дизайнерская фирма Artefact из Сиэтла выпустила Технологические карты Таро, чтобы побудить создателей задуматься о результатах технологий и возможностях для позитивных изменений. Каждая карточка должна содержать один вопрос, чтобы облегчить мозговой штурм. Основываясь на нашем первоначальном вопросе, дальнейшие моменты могут быть детально проработаны и количественно оценены. Это отличный способ самоанализа.

Например

  • Является ли приложение безопасным или вам кажется, что оно недостаточно защищено?
  • Легко ли пользоваться приложением?
  • Реализованы ли функции в соответствии с ожиданиями пользователей?
  • Правильно ли выполняется упаковка и развертывание с использованием надлежащей документации?
  • Существуют ли модульные тесты и инструменты покрытия кода?

Не будем забывать о шкале удобства использования системы (SUS).

Если вы разрабатываете приложение на основе пользовательского интерфейса, вы можете включить шкалу удобства использования системы (SUS). Это дает быстрый способ оценить удобство использования системы, созданной Джоном Бруком в 1986 году. SUS включает 10 пунктов в анкету, и пользователи отвечают по шкале Лайкерта (категорически не согласен или полностью согласен). В Scrum мы должны использовать все инструменты, которые помогают нам быть более эффективными.

Последние мысли

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

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

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

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

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

Надеюсь, вам понравилось читать. Сообщите мне свои мысли и мнения ниже.

Вы хотите писать для Serious Scrum или серьезно обсуждать Scrum?