Как Вы применяете Толпу к улучшениям унаследованного кода и обслуживанию? [закрытый]
Вы можете использовать Promise.all для параллельного выполнения всех промежуточных шагов перед запуском third:
var obj = {};
await Promise.all([ pre(obj), first(obj), second(obj)]);
await third(obj);
Если я правильно понимаю ваш вопрос, то по время Promise.all закончится, obj будет содержать мутации бега pre, first и second.
Будьте осторожны с обработкой ошибок, а также с недетерминированным доступом к объекту obj.
11 ответов
Если у Вас есть так много маслобойки в Вашей среде, то Ваш ключ будет более короткими повторениями. Я услышал о командах, делающих ежедневные повторения. Можно также двинуть стиль шрифта Kanban, где у Вас есть очередь, которая имеет фиксированный предел (обычно очень низко, как 2 или 3 объекта), и больше объектов не может быть добавлено, пока те не сделаны.
то, Что я сделал бы, испытывают недельные повторения с ежедневными выдерживать-взлетами, неудовлетворенное установление приоритетов, и "сделанный, сделанный". Тогда переоцените после 5 или 6 недель для наблюдения то, что могло быть улучшено. Не бойтесь попробовать процесс, как - и не бойтесь настроить его к своей среде, как только Вы попробовали его.
был также PDF, названный Гибкий для Поддержки и Операций за 5 минут , который был недавно отправлен на список Разработки Толпы на Yahoo!
В основном, как я преодолеваю незапланированные задачи и задачи, которые очень трудно оценить с процессом толпы? или я просто применяю неправильный процесс для этой среды?
Вы используете неправильный процесс для этой среды. То, в чем Вы нуждаетесь, является процессом управления стеком/очередью, который является отдельным к Вашему, планировал/оценивал процесс разработки ТОЛПЫ.
причина этого является простой и двукратной:
-
, Как Вы упоминаете в своем сообщении, часто очень трудно оценить задачи обслуживания, особенно где унаследованные системы включены. Задачи обслуживания в общих и унаследованных системах конкретно имеют тенденцию включить 'изогнутые' проблемы или иметь длинный 'хвост', где одна на вид простая фиксация требует немного более трудного изменения в другом компоненте, который в свою очередь требует перестройки операции некоторой подсистемы, которая в свою очередь... Вы понимаете.
-
Довольно часто при контакте с задачами обслуживания, к тому времени, когда Вы закончили оценивать, Вы также закончили решать проблему . Это сокращает процесс оценки как инструмент планирования. Те, кто настаивает на том, чтобы делить оценку от решения проблемы для задач обслуживания, просто добавляют ненужные издержки.
Помещенный просто, Вам нужна система массового обслуживания. Это будет иметь эти компоненты:
- А 'пул' задач, которые были идентифицированы как требование внимания. Недавно повышенные объекты должны всегда входить в пул, никогда очередь.
- процесс А перемещения этих задач из пула и на очередь. Обычно комбинация бизнеса/технических знаний требуется.
- очередь А задач, которые ясно заказаны таким образом, что разработчики, ответственные за обслуживание очереди, могут просто выбрать от передней стороны ее.
- метод А для того, чтобы переместить объекты в очереди (повторное присваивание приоритета). Позволить 'проходить, минуя очередь,' для критических/чрезвычайных объектов.
- метод А для обеспечения завершенных объектов, который не прерывает обслуживание очереди. Это важно, потому что издержки поставляющих объектов обслуживания обычно значительно ниже, чем техническая разработка. Вы не хотите свою команду обслуживания, сидящую без дела в течение дня, ожидая сборки, и тестируете команды, чтобы дать им хорошо каждый раз, когда они поставляют bugfix.
существуют другие нюансы для организации очередей управления, но получение их на месте должно установить Вас на правильном пути.
Никто не сказал, что неудовлетворенные объекты должны быть новым кодом. Работы по техническому обслуживанию, могут ли исправления ошибок, улучшения или меры данных быть помещены в Отставание продукта, оценили и расположили по приоритетам. Это - на самом деле одно из самых больших преимуществ использования Толпы - больше споров с пользователями о том, является ли что-то исправлением ошибки или улучшением.
С Водопадом, существует молчаливое понимание, что ошибки являются ответственностью разработчиков. Так или иначе они находятся на рычаге для фиксации их, не влияя на разработку нового кода и функций. Таким образом, они "свободны" пользователям, но значительному неудобству разработчикам.
В Толпе, Вы распознаете, что вся работа занимает время. Там не "свободно". Таким образом, разработчики свободно признают, что что-то - ошибка, но она все еще входит в Отставание продукта. Тогда это до Клиента, чтобы решить, если исправление ошибки более важно, чем добавление новых опций. Существуют некоторые ошибки, с которыми можно жить.
Как заголовок предлагают... Как я могу применить процесс толпы к чему-нибудь, что не работает над новым кодом и может быть оценено до некоторой степени?
Наоборот, я услышал, что команды находят принятие Толпы легче в этап технического обслуживания.. потому что изменения меньше (никакие главные конструктивные изменения) и следовательно легче оценить. Любой новый запрос на изменение добавляется к отставанию продукта, оцененному devs и затем расположенному по приоритетам владельцем продукта.
то, Как я могу применить процесс толпы к обслуживанию и чрезвычайной ситуации, фиксирует (который может занять с без 5 минут 2 недели для фиксации), тип среды, когда я все еще хотел бы запланировать сделать вещи?
при намеке на противопожарный тип действия сохраните часть итеративной квоты работы для таких операций.. На основе исторических тенденций/действия необходимо быть в состоянии сказать, например, у нас есть скорость 10 точек истории на повторение (4 5day-повторения команды человека). Каждый из нас проводит приблизительно день в неделю, отвечая на чрезвычайные ситуации. Таким образом, мы должны только выбрать 8 ценности точек неудовлетворенных объектов для следующего повторения, чтобы быть реалистичными. Если у нас не будет чрезвычайных проблем, мы поднимем следующий главный объект с расположенного по приоритетам отставания.
CoryFoy упоминает более динамический/оперативный подход с kanban пост в его ответе.
В основном, как я преодолеваю незапланированные задачи и задачи, которые очень трудно оценить с процессом толпы? или я просто применяю неправильный процесс для этой среды?
Толпа AFAIR не передает под мандат метод оценки.. Используйте тот, которым команда является самой довольной.. дни человека / история указывают / и т.д. Единственным способом поправиться при оценке является практика и опыт, которому я верю. Чем больше та же группа людей находятся вместе для оценки новых задач, тем лучше их оценки добираются. В виде обслуживания среды я предположил бы, что легче оценить, потому что система более или менее известна группе. В противном случае планируйте/используйте скачки для получения большей ясности.
я обнаруживаю это, Вы пытаетесь съесть слона здесь.. Я предложил бы следующие укусы
Обработка все фиксирует и улучшения как отдельные истории и оценка соответственно. Мое персональное представление состоит в том, что вещи, которые занимают менее тогда 10-15 минут для фиксации, должны просто быть немедленно сделаны. Для тех, которые занимают больше времени, они становятся частью тока, 'фиксируют & улучшение' итеративный цикл. Как с оценкой регулярных требований, Вы берете лучшее предположение в качестве команды. Поскольку больше информации обнаруживается, и оценки прочь, корректируют повторение и предстоящие спринты.
трудно применить итеративный цикл к мерам и улучшениям так чаще тогда не, они препятствуют тому, чтобы система работала, как они должны и 'бизнес' оказать давление для них для движения живого ASAP. В этой точке это может разработать лучшее перемещение в действительно короткий итеративный цикл, как одна или две недели.
Вы спрашиваете о том, как использовать процесс для чрезвычайных ситуаций. Попытайтесь зарезервировать слово "чрезвычайная ситуация" для вещей, которые требуют взламывания кода в продуктивной среде с пользователями, соединенными одновременно. Иначе заинтересованные стороны, вероятно, злоупотребят словом и объявят чрезвычайное положение на чем-либо, что они хотели бы иметь действительно быстро. Отсутствие процесса не означает из-под контроля: кто-то должен быть ответственен за объявление чрезвычайной ситуации, и кто-то (лучшая практика - кто-то еще), должен авторизовать изменения вне нормального процесса и затем взять на себя ответственность за него.
Кроме этого, предложение использования каждого повторения для завершения многих мер и улучшений является, вероятно, лучшим способом пойти.
Это во многом зависит от жизненного цикла приложения. Если бы это - приложение 'Заката', которое будет скоро повторено, конечно, фокус только был бы на исправлении ошибок высшего приоритета.
, Если бы продукт 'Зрел' и имеет дорожную карту и продолжает развиваться, Вы имели бы, фиксирует и улучшения для заботы о. Существует много импульса, чтобы содержать дизайн в чистоте и развиться путем рефакторинга. Это может означать периодические незначительные и главные версии [за исключением eFixes - чрезвычайная ситуация фиксирует/текущей исправления]. Можно практиковать гибкий к восхищению основ как улучшение, и меры могли быть историей обшитая и сделанная часть отставания Sprint. Весь список сделал бы Ваше Отставание продукта.
Нижняя строка: Если Вы хотите осуществить рефакторинг и содержать Ваше проектирование приложений в чистоте [программисты склонны брать ярлык, если фокусом является исключительно устранение ошибки], это могло бы только произойти с 'живущим' приложением. Тот, который развит и обновлен. И гибкий естественное соответствие.
, Даже если Вы имеете только, фиксирует (что это - полное по Тьюрингу;) или приложение Заката), помогает, могут ли они все включиться в спринт и прокрученный в производственный конец каждого спринта. Если меры должны включиться в производство как и когда они фиксируются, намного более трудно применить Толпу.
Мы применили толпу в этом контексте.
Некоторые ключи успеха.
1. Все на предприятии покупают идею толпы (это крайне важно для успеха)
2. Sprint приблизительно 2 недель (наши первые 2-3 бегут где из 1 недели для понимания процесса)
3. Ни при каком обстоятельстве точка могла быть добавлена к текущему спринту 4. Если реальная чрезвычайная ситуация возникает, останавливают спринт, делают ретроспективу и запускают новый спринт.
5. Займите время для размышлений о прошлом (время, чтобы совместно использовать хотя о последнем спринте и проанализировать его)
6. В спринте вставляют по крайней мере одну задачу улучшить процесс (часто добавляемый к отставанию в ретроспективе); это хорошо для морального духа отряда, и в конце дня Вы будете в своем способе иметь меньше чрезвычайной ситуации.
7. ВРЕМЯ, УПАКОВЫВАЕМОЕ ежедневно, встает, встречаясь
Для оценки, обычно чем больше Вы оцениваете, тем более точными Вы становитесь. То, что хорошо с Толпой, - то, что каждый программист выбирает свою задачу и может установить новую оценку, если он думает, что это не является реалистическим. И если у Вас все еще есть некоторая проблема с оценкой, позвольте своей команде найти решение..., можно быть удивлением с тем, с чем они идут.
В течение этих 2 недель фиксируют. Если это - исходная оценка, сократите его в мелких кусочках. Если Вы сделали более оптимистическую оценку (позвольте, говорят 2-3 дня), проблема должна повыситься как блокировщик в стенде, встречающемся. Возможно, у кого-то еще есть идеи о том, как зафиксировать его. Можно решить сделать некоторое программирование пары для нахождения решения. Когда-то, только чтобы описать ошибку другому программисту помогают много отладить. Можно также задержать его после другой задачи в спринте. Идея для поставки полностью функциональных задач. Если у Вас нет времени, чтобы зафиксировать его полностью и продемонстрировать его, даже если Ваш в сделанных 90% (да! мы знаем то, что это означает), Вы считаете его не сделанным в спринте. В следующем спринте Вы будете в состоянии обратиться к нему с корректной оценкой времени.
Наконец, от того, что я понял, Толпа больше о наличии "инструментов" для улучшения процесса. Вы запускаете с чего-то простого. Вы делаете маленькое повторение. В каждом повторении Вы имеете ЦЕЛЬ FIX для завершения вместо бесконечного списка ошибки. Поскольку Вы выбираете свои задачи из списка в планировании (выступите к тому, чтобы быть, присваивают им), Вы становитесь, больше участвуют для поставки его. Со стендом, встречающимся, Вы встречаете свою пару каждый день с Вашим Списком ожидающих выполнения задач..., Вы хотите уважать свое участие, которое Вы сделали накануне. С повторением Вы не торопитесь, чтобы говорить друг с другом и к определенному, что идет хорошее и что, должен быть, улучшаются. Вы также принимаете меры, чтобы улучшить его и продолжить делать то, что работает. Не бойтесь изменить что-либо, даже что я сказал;) / даже любой основной из самой Толпы... Реальный ключ для адаптации Толпы к тому, что команда должна быть счастливой и продуктивной. Вы не будете видеть его после одного повторения, но многих из них....
Я настоятельно рекомендовал бы взгляд на то, что спринты/повторения значения дадут Вам. Имеет смысл применять их, когда существует достаточно задач сделать это, они должны быть расположены по приоритетам и когда Ваши заинтересованные стороны должны знать примерно, когда что-то будет сделано.
В этом случае я настоятельно рекомендовал бы объединить три подхода:
- расписание как можно больше входящих задач для следующего повторения, самого раннего
- использование Вчерашняя Погода для планирования то, сколько буфера необходимо запланировать иметь дело с задачами, с которыми нужно иметь дело сразу
- , используют очень короткие спринты, чтобы максимизировать количество задач, которые могут ожидать до, по крайней мере, запуск следующего повторения
На самом деле, который является истинным vor каждый Гибкий проекта / Толпа, проекта, как они находятся в режиме техобслуживания - добавляющий к существующей, рабочей системе - от повторения 2.
В случае, если это повторения не обеспечивает достаточно значения, Вы могли бы хотеть смотреть на система массового обслуживания kanban / вместо этого. В основном, когда Вы закончены с задачей, просто вытяните следующую задачу от расположенной по приоритетам очереди задачи.
Рассматривайте все "исправления ошибок", которые не имеют истории как нового кода. Оцените их и работайте их нормальными. Путем обработки их как новых историй Вы создадите библиотеку историй и тестов. Только тогда можете Вы начинать к контакт поведение приложения.
Смотрят на Работа Эффективно с Унаследованным кодом Michael Feathers. Вот ссылка на выборку. http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf
-Jason
На мой взгляд, это зависит от того, как часто бывает «настоящий» релиз. В нашем конкретном случае у нас есть один основной выпуск каждый год и несколько второстепенных выпусков в течение года.
Это означает, что когда спринт завершен, он не развертывается сразу на нашем производственном сервере. В большинстве случаев будет проведено несколько спринтов до того, как мы закончим наш полный «проект». Конечно, мы демонстрируем наши спринты и развертываем наши спринты на нашем тестовом сервере. Проект' в целом он пройдет некоторое сквозное тестирование и, наконец, будет развернут на наших производственных серверах -> это второстепенный выпуск. Мы можем решить, что не будем немедленно развертывать его на нашем производственном сервере, когда он, например, зависит от других продуктов / проектов, которые необходимо обновить в первую очередь. Затем мы развертываем это в нашем основном выпуске.
Но когда возникают проблемы на нашем производственном сервере, могут потребоваться немедленные действия. Итак, некогда спрашивать product owner-а о цели или важности (если у нас есть хотя бы один для решения проблем), потому что это блокирует наших клиентов от работы с нашим приложением. В таких неотложных случаях такие проблемы не будут помещаться в бэклог продукта или спринт, а являются чисто техническими задачами, которые необходимо решить, протестировать и развернуть как можно скорее и как отдельный элемент.
Как нам совместить это с нашим Спринтом? Чтобы члены нашей Команды были сосредоточены на спринте, мы решаем «включить - отказаться» от наших людей в Команде. Это означает, что один или несколько человек не будут частью команды для определенного спринта и могут сосредоточиться на других задачах, таких как эти срочные исправления. В следующем спринте этот человек снова будет частью команды, и кто-то другой будет отвечать за вызовы службы экстренной помощи.
Другой вариант может заключаться в том, что мы предполагаем, что примерно 20% времени в спринте будут выполнять «незапланированные задачи», но это даст неправильное указание на объем работы, которую мы можем сделать в спринте (у нас не будет одинакового количества срочных исправлений во время каждого спринта). Мы также хотим, чтобы члены нашей команды были сосредоточены на спринте, и выполнение этих срочных исправлений в спринте отвлечет членов нашей команды. 'переключение контекста'