Какие идеи в разработке программного обеспечения кажутся плохими, но эффективными
Самое противоречивое из всех - не противостоять толпе, а думать самостоятельно - Питер Тиль
Если вы спросите всех, не любят ли они консервированный смех, все скажут, что это ужасно. Актеры, режиссеры и публика не любят консервированные смехотворные композиции, но они используются постоянно.
Если все думают, что смех - это чушь, зачем его используют?
Причина использования консервированного смеха заключается в том, что есть некоторые свидетельства того, что сдержанный смех заставляет публику смеяться дольше и сильнее. Интересно, что он оказался более эффективным против плохих шуток.
«Введение смехотворных треков в их комические программы увеличит юмористические и благодарные отклики аудитории, даже - и особенно - когда материал низкого качества». Роберт Б. Чалдини - Влияние: психология убеждения
Он работает на основе принципа социального доказательства или социального влияния, когда люди копируют других, чтобы соответствовать согласованному поведению группы. Вики-определение
«Социальное доказательство - это психологическое и социальное явление, при котором люди копируют действия других в попытке предпринять действия в данной ситуации. Этот термин был введен Робертом Чалдини в его книге «Влияние» 1984 года, и это понятие также известно как информационное социальное влияние.
Социальное доказательство считается важным в неоднозначных социальных ситуациях, когда люди не могут определить подходящий способ поведения, и основывается на предположении, что окружающие люди обладают более глубокими знаниями о текущей ситуации ».
Социальное доказательство эффективно, потому что естественная реакция - следовать за толпой и в безопасности чисел.
Что такое банальный смех при разработке программного обеспечения?
Принцип социального доказательства. В нем говорится, что одно из средств, которые мы используем для определения того, что правильно, - это выяснение того, что другие люди считают правильным.
Есть несколько кандидатов на банальный смех при разработке программного обеспечения - то, что все делают, что неэффективно, но толпа заставляет людей это делать.
Agile-проекты
Есть много проектов, которые называются Agile, но на самом деле хаос #HoskWisdom
Agile-проекты подходят для некоторых проектов, но Agile-проекты стали настолько популярными, что используются для всех проектов, даже для тех, где это не очень хорошая идея.
Клиенты настаивают на гибком проекте, но не учитывают время, усилия и быстрое принятие решений. В идеале гибкие проекты нуждаются в том, чтобы решение предоставлялось небольшими порциями.
Несмотря на то, что гибкие проекты используются не по назначению, я бы все равно остановился на них, они более эффективны, чем проекты водопада. Быстро создавайте функциональные возможности и получайте быструю обратную связь от пользователей.
Истории
Очки истории для 90% проектов такие же, как дни, например 1 сюжетный балл - 1 день.
Существует постоянное давление, чтобы получить установленное количество очков истории за спринт, и мера становится целью вместо функциональности, предоставляемой в спринте.
Сюжетные точки - это быстрый способ оценить работу, сравнив текущую работу с чем-то похожим и не тратя слишком много времени на создание оценки, оставляя больше времени на выполнение работы.
Краткосрочные исправления
Показатели производительности являются краткосрочными, что побуждает к краткосрочным размышлениям и действиям. Результат выглядит как быстрый прогресс, но способствует возникновению долгосрочных проблем (таких как технический долг и устаревшая кодовая база).
Создание программного обеспечения - это начало, а не конец, потому что реальная стоимость - это поддержание кода.
Краткосрочные исправления по отдельности не кажутся вредными, но создаются для создания устаревшего кода - Тирания плохого кода приводит к трагедии устаревшего кода
Более быстрая разработка
Сосредоточение внимания на ускорении разработки обычно следует обычным методам, которые редко срабатывают.
Почему добавление большего количества людей в проект не ускоряет его
Как мы пытаемся ускорить ИТ-проекты и почему это не работает
Сосредоточенность на продуктивности, привлечении большего количества людей, ускорении работы не ведет к более быстрому развитию. Разработка программного обеспечения - игра проигравших, и самый быстрый способ запустить код в производство - это уменьшить количество ошибок и ошибок. Более быстрый способ запустить код в производство - это создать качественный код с меньшим количеством ошибок.
