Толпа [закрытые] проблемы Burndown
Из стандарта, раздел 11 (Контроль доступа элемента):
Член класса может быть - private; то есть его имя может использоваться только членами и друзьями класса, в котором он объявлен. - защищенный; то есть его имя может использоваться только членами и друзьями класса, в котором он объявлен, классами, полученными из этого класса, и их друзьями (см. 11.4). - общественность; т. е. его имя можно использовать в любом месте без ограничения доступа.
Таким образом, управление доступом применяется к именам.
В
auto b = A().getB();вы не используете частные имена, поэтому он является законным, в соответствии со стандартом
9 ответов
Некоторые подсказки относительно сглаживания вещей.
1), Поскольку другие сказали - пытаются сломать задачи в меньшие блоки. Более очевидный способ сделать это состоит в том, чтобы попытаться сломать технические задачи более подробно. Где возможный я поощрил бы Вас говорить с владельцем продукта и видеть, можно ли уменьшить объем или "разбавить" историю вместо этого. Я нахожу последнего более эффективным. Манипулирование приоритетами и оценками легче, если и команда и владелец продукта понимают то, что обсуждается.
Мое общее эмпирическое правило является любой оценкой, больше, чем половина идеального дня является, вероятно, неправильной :-)
2) Попытка, делающая более короткие спринты. Если Вы делаете, спринты месяца - пробуют две недели. Если Вы делаете, две недели - пробуют тот.
- Это действует ограничитель на размер истории - поощрение владельца продукта и команды для работы над меньшими историями, которые легче оценить точно
- , Вы получаете обратную связь чаще о Ваших оценках - и легче видеть соединения между решениями, которые Вы приняли в начале спринта и что на самом деле произошло
- , Все поправляется с практикой :-)
3) Использование взлеты стенда и ретроспективы, чтобы немного больше посмотреть на причины взлетов и падений. Это, когда Вы проводите время с конкретными областями кодовой базы? Это вызывается народом, неправильно понимающим владельца продукта? Случайные чрезвычайные ситуации, которые устраняют время разработки из команды? После того как у Вас есть больше понимания, куда взлеты и падения прибывают от Вас, может часто решать те проблемы конкретно. Снова - более короткие спринты могут помочь сделать это более очевидным.
4) Верят Вашей истории. Вы, вероятно, знаете этого..., но я скажу это так или иначе :-) Если бы игра с тем ужасным наследием, пакет Foo взял 3 x дольше, чем Вы, думала, что это продлилось бы спринт - затем также потребуется 3 x, пока Вы думаете следующий спринт. Неважно, сколько еще эффективный Вы думаете, что будете на этот раз ;-) Доверяйте истории и используйте вещи как Вчерашняя Погода для руководства оценок следующей пружиной.
Hope это помогает!
Я рад услышать, что толпа была в основном успешна для Вас - который более важен, чем наличие спринта burndown диаграмма выглядит идеальным. Спринт burndown является просто инструментом для команды, чтобы помочь ему знать, на правильном пути ли это для целей спринта. если бы команда удовлетворяла целям спринта, я не волновался бы слишком много, что диаграмма похожа на американские горки. Несколько предложений
- Во время ретроспективы спринта спрашивают команду, куда дополнительная работа прибывает от
- , Дополнительная работа может прибыть из не наличия хороших приемочных испытаний рано в спринте
- , Дополнительная работа может прибыть из не наличия хорошо ухоженного отставания. Хорошее эмпирическое правило состоит в том, чтобы потратить по крайней мере 5% времени команды, думая об историях следующего спринта заранее.
- происходящая работа Монитора - команда делает слишком много параллельно?
- Во время планирования спринта - как команда чувствует о разбивке задач, которые составляют истории?
, Если Вы не удовлетворяли целям спринта - используют установленную скорость команды для принятия меньше во время следующего спринта. Необходимо стать хорошими в обходе, прежде чем можно будет работать.
По моему опыту, Толпа определенно приспособлена больше к новой разработке, чем это находится к обслуживанию. Новая разработка намного более предсказуема, чем поддержание старой, большой кодовой базы.
После этих слов одна возможная проблема состоит в том, что Вы не разбиваете задачи в достаточно маленькие блоки. Типичная проблема, которую люди имеют с программным обеспечением, планирующим в целом, состоит в том, что они думают, "о, эта задача должна взять меня 2 дня", действительно не думая о том, что входит в выполнение той задачи. Часто, Вы найдете что, если Вы будете садиться и будете думать об этом, что задача состоит из выполнения A, B, C, и D и завершает то, чтобы быть больше чем 2 днями работы.
Как другие сказали, я ожидал бы, что burndown будет вверх и вниз. Материал происходит! Необходимо использовать "вверх и вниз по" битам как фураж для ретроспектив.
Удостоверяются, что все ясны на том, что "означает быть сделанным", и используйте то соединение, понимающее, чтобы помочь управлять Вашими сессиями планирования. Часто наличие списка того, что составляет сделанный доступный (a) поможет Вам помнить вещи, которые Вы могли бы забыть и (b) вероятно, инициирует больше идей для задач, которые иначе появились бы позже.
Еще одна точка для размышления о - если бы Вы работаете месяц над месяцем с непредсказуемой кодовой базой я все еще ожидал бы, что Ваша скорость нормализует к довольно устойчивому уровню. Просто отследите свой успех по Вашей запланированной работе и только используйте завершенные объекты в качестве максимума при планировании. Затем сфокусируйтесь на своих незапланированных задачах и посмотрите, существуют ли какие-либо шаблоны, которые предполагают, что существуют вещи, которые можно сделать по-другому для включения тех вещей в запланированную работу.
У меня были подобные проблемы. Моя предыдущая команда (на нем больше года) была многочисленной, и мы поддержали очень большую, быстро изменяющуюся кодовую базу для ряда начальных выпусков продукта. Наши burndowns были позорным взглядом, но было лучше, чтобы мы могли когда-либо делать.
Одна вещь, которая может помочь (заставляют Ваш график выглядеть лучше), придерживаются числа часов/точек, преданных постоянными. Если Вы недооценили задачу, и должны удвоить часы, вытащить что-то из спринта. Если Вы вытягиваете в новой задаче, это имеет, очевидно, более высокий приоритет, чем что-то Ваша команда, преданная, так вытащите ту другую вещь.
Мы попробовали разбивание задачи во многие задачи в и перед планированием, и это никогда, казалось, не помогло. На самом деле это просто дало нам больше проклятых билетов для отслеживания во время спринта. Требования начали мигрировать на билеты, и (не удивительно) потерялся во всей перестановке.
В моей новой команде мы проявили довольно радикальный подход и начали создавать крупногабаритные электробытовые товары (приблизительно более чем одна неделя длиной), которые говорят вещи как "реализация v1.2 функции в ProjectX". Требования/списки функций для ProjectX (включенная версия 1.2) сохранены на Wiki, таким образом, билет является очень чистым и только отслеживает выполненную работу. Это помогло нам много - мы имеем путь меньше билетов для отслеживания и смогли закончить все наши спринты даже при том, что мы продолжаем осуществляться наши задачи спринта помочь другим командам или потушить пожары.
Мы продолжаем продвигать объекты из спринта, если (и только если) мы вынуждены (человеком) ввести новые объекты.
Другая простая подсказка, которая помогла нам: добавьте "общие часы в спринте" к Вашему burndown. Это должно быть суммой всех оценок. Работа над хранением этой плоской строки может помочь и увеличивает видимость проблем, с которыми может сталкиваться Ваша команда (предполагающий, что это не понизит Вас...)
-ab
У меня были подобные проблемы в моем burndown также. Я "зафиксировал" его путем совершенствования того, что было включено в burndown.
SiKeep прокомментировал:
Его прогресс против отставания, выбранного для того спринта, который может или не может закончиться как выпуск.
, Так как Вы выбрали определенные вещи для спринта и это - то, что находится на burndown, я не знаю, что вся "новая работа" должна появиться в burndown. Я видел бы, что он идет на отставание (не влияющий на burndown), если не достаточно важно переместиться в Ваш текущий спринт (который затем обнаружился бы как восходящая тенденция в burndown).
Тем не менее незначительный up's и down's нормальны , если линия тренда в основном следует за Вашей ожидаемой скоростью. Я был бы обеспокоен тенденцией "американских горок", которую Вы упоминаете. Однако идея изолировать burndown, только добавляя высокоприоритетные объекты к текущему спринту может помочь ослабить их и холмы на Вашем burndown.
, Поскольку другие сказали, планирование, прежде чем запуски спринта должны будут быть короткими... ( не больше, чем 4 часа ).
Можно интегрировать новую работу над датой начала спринта, чтобы иметь большое выглядящую диаграмму Burndown.
можно отметить с определенным маркером дополнительную работу и оценить в конце спринта, почему Вы не имеете смочь определить те задачи прежде.
Это - как это должно быть. Если Ваша диаграмма burndown похожа на образцовую диаграмму, Вы в беде. Диаграмма поможет видеть, сможете ли Вы сделать Вас обязательством и закончить все истории.
истории Обнаружения во время спринта будут всегда происходить. Идеально Вы смогли бы разработать и узнать задачи впереди, но если бы они работали, почему большое заранее разработало бы не, работают? Для ответа на Вас последний вопрос планирование спринта должно взять самое большее четыре часа .
Мы используем задачу с временными рамками для незапланированных задач. Всякий раз, когда приближается высокоприоритетная работа или внезапно появляются ошибки, мы можем использовать временной интервал (но мы никогда не сможем опуститься ниже нуля). Этот метод имеет дополнительное преимущество в том, что мы можем легко отслеживать, какие задачи были непредвиденными, и учитывать это при планировании следующего спринта.