Наши Положения ожидают от наших разработчиков быстрого выполнения работы. Раздел §36 оплачивает более быструю доставку, а §8 штрафует медленных участников, удаляя их, если они не закрывают задачи в течение десяти дней (на момент написания). Зачем даже десять дней, если наши задачи настолько маленькие? Сколько времени реально требуется на закрытие средней задачи? Можем ли мы сделать что-то, чтобы закрывать их быстрее?
Это очень распространенное заблуждение, поэтому я решил написать этот блог-пост. Когда я разговариваю с нашими новыми клиентами, они обычно спрашивают меня, как так может быть, что маленькая полуторачасовая задача закрывается пять дней и не является ли это серьезным узким местом для всего проекта? Они привыкли думать, что программист говорит, что реализация займет неделю, и затем в течение одной календарной недели, плюс-минус, результат доставляется.
В нашем случае программист говорит, что это займет 30 минут, и результат доставляется, скажем, через семь дней. Затем программист получает оплату за 30 минут своего рабочего времени. Это звучит странно для тех, кто не понимает, как работает оплата за результаты микрозадач. Позвольте мне объяснить.
В каждой задаче есть две разные вещи, которые едва связаны между собой: бюджет (стоимость) и продолжительность (время). Мы, программисты, - это ресурсы, которые проект покупает для выполнения своих рабочих пакетов, которые, когда они собираются вместе, создают рабочий программный модуль. Когда строится дом, ресурсы - это кирпичи, цемент, окна, плитка и руки строителей. Когда создается программный продукт, ресурсы -… руки программистов и почти ничего больше.
Эти ресурсы являются первой осью многомерной матрицы проекта, в то время как календарное время - вторая. Чтобы построить дом, нам нужно, скажем, пять человек работать 80 часов подряд, что равняется 400 человеко-часов. И, очевидно, нам также нужны кирпичи, цемент и все остальное. Десять календарных дней не будут достаточными, например, если грузовик, который доставляет кирпичи, задерживается на несколько дней. Мы можем потратить эти 400 часов работы много раз, если наша работа не организована должным образом, или просто потому, что люди - люди.
То же самое верно для программных проектов, но здесь нет кирпичей и цемента. Есть только люди, и они часто опаздывают. Когда задача на 30 минут находится в руках одного программиста, это не означает, что он или она сможет закончить ее ровно за 30 минут. Существует много зависимостей, вещей, на которые нам приходится ждать, иногда несколько дней. Вот краткое изложение того, через что обычный программист должен пройти, чтобы завершить довольно обычную микрозадачу:
Попросите автора заявки уточнить описание;
Откройте репозиторий кода;
Найдите место, где необходимы изменения;
Отправьте еще несколько запросов, если код не является достаточно понятным и чистым;
Обсудите изменения, внесенные в эти билеты;
Закройте заявки и, возможно, подайте новые.
Создайте ветку Git;
Make changes;
Запустите сборку и убедитесь, что она успешно завершилась;
Зафиксируйте и отправьте изменения;
Создайте запрос на внесение изменений (pull request);
Отвечайте на комментарии кодового рецензента;
Внесите необходимые изменения в ветку;
Ответьте на комментарии архитектора и внесите изменения;
Убедитесь, что PR проходит через слияние конвейера;
Попросите автора билета закрыть его;
Спорьте с автором;
Начните все заново, если проблема не решена.
Как видите, фактическая строка кода для написания находится где-то посередине этого списка и называется “Внести изменения”. Все остальное не имеет непосредственного отношения к написанию кода. Это все о доставке изменений и убеждении в их принятии.
Самые умные программисты знают, как сделать часть “внести изменения” как можно более маленькой и быстрой, чтобы оставить больше времени и энергии на все остальное. Кроме того, самые умные программисты знают, как вносить изменения таким образом, чтобы они были приняты быстрее. Похоже, это комбинация дисциплины, энтузиазма и искусства. Трудно объяснить, что именно нужно сделать и как. Об этом идет речь в навыках социотехнического взаимодействия.
Главное заключается в том, что наши лучшие программисты закрывают 30-минутные микрозадачи за 4-5 дней каждую. Zerocrat назначает им много задач одновременно, в соответствии с разделом §3, ожидая, что каждый программист закроет от шести до восьми задач в день.
Translated by ChatGPT gpt-3.5-turbo/42 on 2024-05-27 at 01:24
