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