Команда разработчиков, членом которой я являюсь, недавно адаптировалась к работе в соответствии с Agile-практиками. Это лично высветило тот факт, что я не могу остановить себя позолоченным кодом (и документацией), и, следовательно, я превышаю первоначальные оценки, когда я мог бы предоставить решения, отвечающие требованиям намного раньше.
Я думаю, что моя этика граничит с навязчивостью, так как я слишком привязан к своему коду и редко довольствуюсь выпуском, пока не реорганизовал и не усовершенствовал его до n-й степени. Я счастлив, что понял это, но как я могу изменить свое отношение / менталитет, чтобы быть довольным своим прогрессом и выпустить вовремя вместо этого?
agile
programming-practices
productivity
development-process
scrum
Энди Боускилл
источник
источник
Ответы:
Лучший враг достаточно хорошего.
Вы всегда можете сделать больше тестов, написать лучшую документацию, найти те угловые случаи, заполнить то, что вы считаете недостающими функциями, сделать архитектуру чище. Это никогда не заканчивается. Однако это должно закончиться. Есть сроки выполнения, которые должны быть соблюдены, внешние ограничения, которые зависят от вашей части продукта, который будет завершен. Стремление к совершенству в одной маленькой части продукта вредит продукту в целом.
источник
Прежде всего, я хотел бы, чтобы у большего числа разработчиков была эта проблема, не потому, что программное обеспечение будет выпущено позже, чем ожидалось, а потому что это, вероятно, будет более качественный выпуск.
Если вы превышаете ваши собственные первоначальные оценки, возможно, вам нужно включить ваши «золотые» шаги как часть ваших оценок. Если они не являются вашими собственными оценками, возможно, вам следует принять участие в их формулировании.
В любом случае, если у вас есть срок выпуска, вы должны придерживаться его. Любое «позолота» следует оставить как последний шаг, который не должен задерживать релиз. Если вы абсолютно уверены, что он должен быть включен как часть релиза, рассмотрите возможность добавления «позолоты» в свое собственное время (то есть вне рабочего времени).
Что вы должны сделать, это сообщить о своих «позолоченных» шагах своей команде и / или руководству и обсудить, почему вы считаете их важными. Если вы сможете убедить их в том, что эти шаги полезны, они должны стать частью будущих выпусков.
источник
Позолоченное программное обеспечение
Впервые я увидел, что позолота, используемая в качестве описания программного обеспечения, была в статье Барри Бома, где он привел следующую основную причину:
В своем описании он рекомендует использовать методы, описанные в его исследовании, в том числе модель жизненного цикла спирального программного обеспечения, в которой были определены проекты для создания серии прототипов по одному на цикл, а по мере увеличения спирали - полнофункциональный продукт. Спираль имела широкое влияние среди исследователей программного обеспечения и была важным мостом между водопадом и Agile. Критическое ограничение спирали состоит в том, что каждый раз вокруг спирали циклы становятся длиннее и дороже.
Как и в Agile, спираль пытается избежать позолоты, ограничивая область охвата и составляя график выполнения проекта достаточно долго, чтобы команды могли выполнить требования, и в то же время быть достаточно коротким, чтобы позволить сосредоточиться на цели с первого дня до дня поставки. Один из способов, благодаря которым Agile-методы, такие как Scrum, превосходят, - это то, что Scrum спринтится в течение периода времени, который не увеличивается с помощью итераций. Судя по документу, управление проектами оказывает большее влияние на золотое покрытие, чем отдельные разработчики.
Талант для бокса времени
Умение рассчитывать время очень важно, но это не бинарный навык. У вас его нет или не хватает. Вы лучше или менее хорошо с этим. Будь то от вашего босса или от вас, я бы предпочел, чтобы никто не сказал, что вы не можете остановить золотое покрытие. Это звучит для личного, всепроникающего и постоянного.
Анализ первопричин может помочь выявить несколько проблем. Я совершенно уверен, что они не все будут указывать на вас, и что если вы не работаете с психопатами, другие в вашей команде увидят аналогичные потребности в улучшении своих навыков Agile. Если вы знаете кого-то без проблем, вы не очень хорошо его знаете. Если вы знаете кого-то, кто думает, что ему не нужно совершенствоваться, он не очень хорошо себя знает.
Я надеюсь, что улучшения, которые вы определили, станут тем, что вы сможете решить с помощью вашей собственной осведомленности и помощи команды. Тем не менее, я думаю, что это не то, где это заканчивается. Я ожидаю от супервизора или менеджера, который пишет ваши отзывы, то, что они также могут обучать своих подчиненных, чтобы быть успешными. Это особенно важно, когда в организации происходят революционные изменения, такие как переход от планового к гибкому (или специальному к гибкому).
Быстрый и грязный или управляемый риском прототип?
У меня был менеджер, который раньше просил, чтобы задачи выполнялись определенным образом.
Он знал глупость этого, и это было частью его странного чувства юмора. Многие люди говорят такие вещи, и они очень серьезно. Где-то есть компромисс или возможность облегчить проблему с помощью улучшенной технологии или подхода.
Чем мы можем пожертвовать, чтобы соответствовать нашему времени?
В первой главе « Объяснение экстремального программирования» , второе издание, Кент Бек рассказывает о том, что нужно для быстрого движения. Его ответ таков: «Вы делаете только то, что вам нужно, чтобы создать ценность для клиента».
риск
В первом издании той же книги Бек отождествляет себя с мнением Бема о контроле над рисками как критически важного для своей методологии, говоря:
В обоих изданиях Бек перечисляет и описывает восемь распространенных рисков, за которыми следует утверждение, что XP (или, возможно, расширение, Agile) обращается к каждому по-своему. Для меня большая часть его объяснения сводится к использованию меньших приращений, а более быстрые итерации позволяют нам все вернуть на прежний курс, прежде чем риски станут слишком большими, чтобы с ними справиться.
Менталитет достаточности
Бек обсуждает ресурсы в контексте рассказа о горских людях и лесных людях и представляет концепцию, называемую «ментальность достаточности». В контексте вашей ситуации он спрашивает: «Как бы вы это сделали, если бы у вас было достаточно времени?» Только эта первая глава, доступная в виде предварительного просмотра книги, может дать пищу для размышлений о том, как XP (и другие Agile-методы) думают о таких ограничениях, как время.
Принуждение может быть симптомом, а не болезнью
Несколько лет назад я посмотрел книгу о промедлении, в которой говорилось, что большая часть прокрастинации возникает из-за страха. Если вы не начнете, вы не ошибетесь и, возможно, вас не будут критиковать. Принуждение и перфекционизм дают то, что наш моральный смысл говорит нам лучше, чем промедление, но, вероятно, имеет тот же результат. Считаете, что, возможно, у вас есть проблемы с промедлением в другой форме?
Критика и конкуренция
В Agile методологиях, таких как Scrum, возможности подвергнуться критике или наказанию за проволочки никогда не были выше. Это порочный круг. Я откладываю, потому что меня критикуют, меня критикуют, потому что я откладываю. С ежедневными скрам-встречами мы всегда находимся в состоянии готовности, потому что мы всегда в течение дня или меньше сообщаем команде, что мы достигли.
В идеальной команде Scrum ежедневно дает возможность исправить промедление. Ошибки не должны успевать набирать обороты до прибытия помощи. Команды не всегда находятся там, где им следует доверять, поэтому лидерам в команде, возможно, придется активно противостоять либо критике, либо страху критики, чтобы все могло двигаться вперед.
В нашем мире работы каждый человек в команде должен также конкурировать с другими. Немного шизофренично верить в наличие команды, которая разделяет работу и славу достижений, но затем использует ежегодный процесс управления эффективностью, который вознаграждает 20% ее членов, наказывает или исключает 10% или более членов, и делает вид, что 70% -ое большинство вносит свой вклад без стимулов. Я думаю, что это большой слон в комнате, продвигающий командную работу, и, ссылаясь на историю Кента Бека, он показывает глубокие культурные связи с тем, чтобы быть горскими людьми.
Путь вперед
Как член Agile команды, было бы хорошо изучить и обсудить с другими, что работает. Если ваша команда использует TDD для автоматизации своих модульных тестов с помощью инструмента, попросите человека, который сделает это лучше всего, обучить вас. Если у вашего руководителя или менеджера возникли проблемы с вашим подходом к документированию, выясните, что ему нравится или кто делает это так, как ему нравится, и следуйте их подходу. Если это сводится к сырой скорости кодирования, исследуйте, что требуется, чтобы кодировать быстрее.
Лидеры могут предпринять шаги в правильном направлении, путем ролевого моделирования желаемого поведения, такого как откровенный разговор о своих собственных проблемах (не чьих-либо), предлагая и выполняя помощь, имея диалог о том, как команда может перейти в стиль Agile Marine (то есть без человека). осталось позади). Не все в команде имеют одинаковые способности. Может быть уместно исследовать членов команды спаривания или назначать задачи и роли, которые могут подчеркнуть взаимодополняющие сильные стороны вовлеченных людей. Планирование роста или исправления навыков должно быть полезной частью работы как для руководителя, так и для подчиненного, но должно происходить рано и часто, чтобы быть эффективным.
источник
Вы тоже программируете для развлечения? Меня также раздражали ограничения на работе, которые приносили удовольствие от программирования, и чтобы компенсировать это, я иногда запускаю новый проект дома и "делаю это правильно". Раскол позволяет мне удовлетворить и мои потребности, и компанию.
Или вы могли бы развить новый навык, отличный от программирования, чтобы в свободное время (в конце концов) удовлетворить то, что не может обеспечить работа. ;)
источник