Как остановить позолоту и просто довольствоваться выпуском рабочих разработок [закрыто]

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

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

28 голосов | спросил Andy Bowskill 6 +04002012-10-06T19:17:24+04:00312012bEurope/MoscowSat, 06 Oct 2012 19:17:24 +0400 2012, 19:17:24

4 ответа


21

Лучше всего враг достаточно хорош.

Вы всегда можете проводить больше тестирования, писать лучшую документацию, выходить из этих угловых дел, заполнять то, что, по вашему мнению, отсутствует, сделать чистую архитектуру. Это никогда не заканчивается. Однако это должно закончиться. Должны быть предусмотрены сроки, которые должны быть выполнены, внешние ограничения, которые зависят от вашей части готового продукта. Стремление к совершенству в одной небольшой части продукта вредит продукту в целом.

ответил David Hammen 6 +04002012-10-06T21:02:57+04:00312012bEurope/MoscowSat, 06 Oct 2012 21:02:57 +0400 2012, 21:02:57
22

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

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

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

Что вам нужно сделать, это поднять свои «золотые» шаги в вашу команду и /или руководство и обсудить, почему вы считаете, что они важны. Если вы можете убедить их, что эти шаги полезны, они должны стать частью будущих выпусков.

ответил Bernard 6 +04002012-10-06T19:35:33+04:00312012bEurope/MoscowSat, 06 Oct 2012 19:35:33 +0400 2012, 19:35:33
14

Позолоченное программное обеспечение

Впервые я увидел, что золотое покрытие, используемое в качестве описания для программного обеспечения, было представлено в документе Barry Boehm , где он дал следующую причину:

  

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

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

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

Талант для бокса времени

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

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

Я надеюсь, что улучшения, которые вы определили, будут теми вещами, которые вы можете решить с помощью своей собственной осведомленности и помощи со стороны команды. Однако, я думаю, что это не так. Мое ожидание от руководителя или менеджера, который пишет ваши отзывы, будет заключаться в том, что они могут также обучать своих подчиненных, чтобы быть успешными. Это особенно важно, когда организация подвергается революционным изменениям, таким как переход от запланированного к Agile (или ad-hoc к Agile).

Быстрый и грязный или управляемый рисками прототип?

У меня был менеджер, который обычно запрашивал выполнение этих задач определенным образом.

  

Быстро и грязно, но красота.

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

Что мы можем принести в жертву, чтобы соответствовать нашей временной шкале?

В первой главе Экстремальное программирование объяснено , второе издание, Кент Бек рассказывает о том, что нужно, чтобы быстро двигаться , Его ответ заключается в том, что «вы делаете только то, что вам нужно сделать, чтобы создать ценность для клиента».

Риск

В первом выпуске той же книги Бек указывает немного более внимательно на мнение Бемма об управлении риском как критическом для его методологии, говоря:

  

«Риск - это основнойпроблема разработки программного обеспечения "

В обоих выпусках Beck перечисляет и описывает восемь общих рисков, за которым следует утверждение, что XP (или, возможно, расширение, Agile) обращается к каждому определенным образом. Для меня большая часть его объяснений сводится к использованию меньших приращений, и более быстрые итерации позволяют нам направить все на курс, прежде чем риски станут слишком большими для обработки.

Ментальность достаточности

Бек обсуждает ресурсы в контексте истории о Mountain People and the Forest Люди и вводит концепцию под названием «Ментальность достаточности». В контексте вашей ситуации он спрашивает: «Как бы вы это сделали, если бы у вас было достаточно времени?» Только эта первая глава, доступная в виде предварительного просмотра книги, может предоставить много пищи для размышлений о том, как XP (и другие Agile-методы) думают о ограничениях, таких как время.

Принуждение может быть симптомом, а не заболеванием

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

Критика и конкуренция

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

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

В нашем мире работы каждый человек в команде должен также конкурировать с другими. Немного шизофреник верит в то, что команда, которая разделяет работу и славу достижений, но затем использует ежегодный процесс управления эффективностью, который вознаграждает 20% его членов, наказывает или изгоняет 10% или более членов, и заявляет, что 70% -ое большинство вносит свой вклад без каких-либо стимулов. Я думаю, что это большой слон в комнате WRT, способствующий совместной работе, и, чтобы рассказать историю Кента Бекка, он показывает глубокие культурные связи с тем, что они являются горными людьми.

Путь вперед

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

Лидеры могут предпринять шаги в правильном направлении путем ролевого моделирования желаемого поведения, такого как откровенный разговор о своих проблемах (а не о ком-то другом), предлагая и следуя с помощью, имея диалог о том, как команда может перейти в стиль Agile Marine ( т.е. никто не оставил позади). Не у всех в команде одинаковые способности. Возможно, было бы целесообразно изучить членов группы пар или назначить задачи и роли, которые могут подчеркнуть дополнительные сильные стороны вовлеченных людей. Планирование роста или исправления навыков должно быть полезной частью работы как для руководителя, так и для подчиненного, но должно происходить на ранней стадии и частоэффективным.

ответил DeveloperDon 7 +04002012-10-07T04:29:00+04:00312012bEurope/MoscowSun, 07 Oct 2012 04:29:00 +0400 2012, 04:29:00
7

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

Или вы могли бы разработать новый навык, отличный от программирования, чтобы делать это в свое время, которое (в конечном итоге) удовлетворяет тому, что задание не может обеспечить. ;)

ответил duanev 7 +04002012-10-07T05:08:43+04:00312012bEurope/MoscowSun, 07 Oct 2012 05:08:43 +0400 2012, 05:08:43

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132