Жаргон программной инженерии может быть излишне сложным.

Нам нравятся наши сокращения и расширенный словарный запас.

Отказ от ответственности: все высказанные мнения принадлежат мне.

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

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

Эта чрезмерная инженерия относится не только к реальной инженерии, но также к терминологии и жаргону ...

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

«Информационный радиатор»

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

- Agile Alliance

Он «излучает» информацию, как я излучаю сарказм?

Вот тот экран, который называется монитором. Если он показывает статус сборки, то это монитор статуса сборки. Просто называйте вещи своими именами, пожалуйста.

«Скрам»

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

Ладно, не совсем, но все же.

Это статусная встреча. «Я сделал ____ вчера. Я делаю ____ сегодня. Никаких блокираторов ». Это показывает ваш статус.

Хуже всего в этом случае, когда менеджеры, сертифицированные по Agile, спорят с вами и настаивают: «Скрамы - это не статусные встречи». Мы могли бы переименовать процесс в «Фестиваль пердежа», и это все равно было бы статусной встречей.

"Готовое решение"

С этим две проблемы: во-первых, очень и очень мало приложений, которые работают «из коробки», и, во-вторых, вы когда-нибудь пробовали заводить машину, которая не заводится? Да, я тоже.

В программном обеспечении это происходит чаще, чем вы думаете. Так что «под ключ» для меня абсолютно ничего не значит.

«День 0»… «День 1»… и т. Д.

Они были определены для различных ниш, таких как создание сетей или разработка программного обеспечения и т. Д., Но в целом они означают схожие вещи:

«День 0» обычно относится к дизайну, требованиям, архитектуре и т. Д.

«День 1» обычно относится к фактическому внедрению, настройке и эксплуатации.

«День 2» и далее обычно относятся к обслуживанию, исправлению ошибок, оптимизации и т. Д.

… Разве это не SDLC буквально? Когда кто-то говорит День 0, я всегда должен дополнительно спрашивать их, имеют ли они в виду планирование, дизайн, тестирование или…

В следующий раз просто скажите: «Сбор требований». Ах хорошо. Видеть? Легкий.

«Истории пользователей»

«Как финансовый аналитик, я хочу иметь возможность видеть данные клиентов в аккуратно отображаемой таблице, чтобы я мог сразу все видеть, удобно сортировать значения и визуализировать…»

Ненавижу пользовательские истории. Ненавижу пользовательские истории. НЕНАВИЖУ ИСТОРИИ ПОЛЬЗОВАТЕЛЕЙ.

Ничто другое в разработке программного обеспечения (кроме интервью) не злит меня так страстно, как рассказ о пользователях Agile. Слишком много письменной информации, но так мало информации.

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

Вы хотите знать, что на самом деле полезно для разработчиков? Что-то вроде этого:

Description: Display customer data in table
Acceptance Criteria:
- Columns: full name, address, company, data usage this month (in MB)
- All columns are sortable (insert details here)
- Columns fuzzy-searchable for specific values
- Each customer row can be drilled down, links to that customer's extended details (See: Other-Ticket)

Каждая пуля - это карточка Trello. Простой.

Используйте списки. Пожалуйста.

«Спринты», «Скорость спринта» и «Очки истории»

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

Практики Agile обычно используют последовательность чисел Фибоначчи для обозначения степени сложности пользовательской истории (т. Е. «Баллов истории»). 1, 2, 3, 5, 8, 13, 21…

Самая большая проблема с этим? Я работал в нескольких компаниях, и у каждой из них была совершенно разная интерпретация баллов.

Что, черт возьми, означают очки? Дней? По словам одной компании, конечно. В другой компании, когда я спросил об этом, премьер-министр сказал: «Просто используйте свое наиболее обоснованное предположение».

Какие?!

Причина, по которой мы придумываем структуры и процессы, состоит в том, чтобы убрать догадки и путаницу.

Какой смысл придумывать еще что-нибудь, чтобы нас запутать ?!

Циклы. Часы. Мы доставляем наше программное обеспечение двухнедельным циклом. На заполнение каждого билета уходит X часов. ТАК. МНОГО. ПОЛЕГЧЕ.

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

Фреймворки должны устранять путаницу, а не создавать ее.

«Свиньи» и «Куры»

О, дорогой господин. Согласно Визуальной парадигме:

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

… Это действительно необходимо? То есть в основном «свиньи» - это разработчики, а «цыплята» - «все остальные»?

Зачем использовать метафоры животных? Звучит как «Скотный двор», но с цыплятами.

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

Думаю, некоторые свиньи более равны, чем другие ¯ \ _ (ツ) _ / ¯

Каждый акроним когда-либо

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

Посчитайте, сколько вы получите.

Есть намного больше, чем это. И их слишком много.

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

Разбивка результатов

41/41 - Ты умнее меня. Отличная работа.

30-40 / 41 - Выше среднего, вы действительно много чего знаете.

20–30 / 41 - Наверное, в среднем.

10–20 / 41 - Вы можете просмотреть некоторые из них; их довольно полезно знать.

‹10/41 - Да, эта индустрия сумасшедшая, и есть чему поучиться.

«Диаграмма выгорания»

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

Больше ничего не имеет смысла. Почему мы «сжигаем» пользовательские истории? Это напоминает мне религиозных фанатиков, сжигающих научные книги. И каким образом это говорит нам о нашей скорости? Используем ли мы огонь для питания ракетного корабля?

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

«Календарь Нико-Нико»

Niko - календарь Niko - это визуальный иконический инструмент для отслеживания настроения команды.

Итак… календарь настроения.

Nikoniko в переводе с японского означает «улыбающийся».

Отлично, еще кое-что люди должны искать. Больше сложности и еще больше дерьма нам не нужно. Черт, даже в переводе, я понятия не имею, что такое «календарь улыбок».

Кроме того, может ли кто-нибудь объяснить мне, какова функция этого? Какую ценность это добавляет?

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

Есть еще кое-что, но это превращается в тираду.

Я остановлюсь здесь.

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

Но Agile можно использовать не по назначению, и один из таких способов - постоянно наращивать сложность.

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

Удачного выродка.