Одна только Толпа = гибкий? [закрытый]
Я нашел простое решение.
Вместо
load_qry = """SELECT <real_col1> as reg_plate, <real_col2> as model_num
FROM s3_table WHERE partition_datetime LIKE '2019-01-01-14' limit 10 """
df1 = spark.read.parquet("<s3:path to my data>")
df1.createOrReplaceTempView("s3_table")
я использовал
load_qry = """SELECT <real_col1> as reg_plate, <real_col2> as model_num
FROM <my_athena_db>.table WHERE partition_datetime LIKE '2019-01-01-14'
df1 = spark.sql(load_qry)
, что работает, потому что Клей знает, как добраться до «my_athena_db.table»
10 ответов
Гибкий большое, неопределенное понятие. Много вещей является Гибким.
Толпа является определенным набором методов для того, чтобы сделать спринты и выпуски. Это является гибким, потому что это соответствует Гибкому Манифесту.
Существует много других определенных Гибких методов (весь xDD's, например.)
Когда в сомнении, сравните компании фактические методы с Гибким Манифестом.
Да, я согласился бы с частью чувства здесь. Будьте Гибкими, следует манифесту и гарантирует, что у Вас есть выравнивание по правому краю приоритетов. ТОЛПА является просто другим вариантом с определенными записанными частями. Это, если что-либо управление "инструмент".
После этих слов помните, инструменты вторичны, Ваши люди являются Вашим приоритетом. Не сверхфокусируйтесь на стиле управления, фокусе вместо людей и продукта.
Толпа предоставляет Вам платформу для фиксирования/улучшения процесса разработки. Это нужно рассмотреть как начальную точку "превращенной в желе команды" и более продуктивной команды. Скорее всего, Вы скоро пойдете вне стандартных методов Толпы, но как начальная точка это имеет некоторые привлекательные свойства:
- Очень легко понять
- К этому можно относиться почти любой проект и команда
- Существуют вполне многие люди, которые делают деньги и помогают компаниям с принятием Толпы
Также там действительно не настолько важно знать ли Толпа = гибкий. Это лучше сфокусировать на лучшей производительности и не беспокоит себя такими вопросами.
Я заметил, что просто использование одних только встреч Толпы является довольно ясным знаком, что компания правильно не реализовала Гибкие понятия.
Думайте о том, как легкие встречи Толпы, просто разжигают Outlook и дают всем ежедневную 15-минутную встречу. Но, разрезание всего в быстрые повторения и проверка нового функционально быстро тестируются конечными пользователями, берет намного больше работы.
Я предположил бы, который большинство менеджеров прекращает читать прямо после того, как часть Толпы и они теряют интерес. Но, их ежедневные приглашения на встречу живут на навсегда.
Толпа является методологией управления проектами, прежде всего. Да, при выполнении Толпы Вы, вероятно, начинаете думать больше о том, чтобы быть гибким, и предоставляющий значение Вашему клиенту. Но это не обязательно делает Вас гибкими. Для начала, Толпа не говорит о том, КАК Вы делаете разработку программного обеспечения. Это - то, где вещи как XP входят - другие методологии и идеи, которые вынуждают Вас рассмотреть и изменить свои трудовые навыки для становления более эффективными и продуктивными.
Так, вместо выяснения "делают Вы делаете Толпу / XP / безотносительно", я спросил бы эти компании об их полных процессах и получил бы целостное представление. Компания фокусируется на доставке максимальной бизнес-возможности и управляемая идеалом непрерывного совершенствования? Если так, затем они являются, вероятно, намного более гибкими, чем тот, который говорит, что делает Толпу.
Используя одну только ТОЛПУ не обязательно оправдание получить больше встреч. Способность отследить работу это делало каждый день и принимает решения о том, как изменить (путем вырезания или изменения баланса работы), остальная часть спринта довольно полезна на своем собственном и звуковом, гибком мне.:-)
Конечно, если у Вас не будет других компонентов гибкого процесса, то у Вас будет более трудное время для измерения успеха работы, таким образом, Вы могли бы думать, что на правильном пути со спринтом, но на самом деле нигде не быть около точки, в которой необходимо быть поставить качественный продукт по графику.
Обновление: Вы не должны распускать такую компанию по одной только той предпосылке. Однако во время интервью, необходимо использовать шанс понять, почему они используют только ТОЛПУ. Если это - вопрос не наличия людей для поддержки вещей как TDD или CI, чем это могло бы быть подходящим вариантом для Вас, если Вы готовы стать техническим руководителем. Если это - потому что они отклоняют эти процессы как "служебные" или "глупые" или "ненужные", то необходимо опасаться компании.
Плохие менеджеры будут outed прозрачностью, которую способствует Толпа. Компании, действительно охватывающие Толпу, определенно достойные внимания.
"Я слышу о большом количестве компаний, что действуют как, они являются гибкими, но единственная гибкая вещь> они делают процесс Толпы. Этого достаточно, чтобы считаться гибким"
Короткий ответ - да. По-моему, так или иначе :-)
Конечно - они должны на самом деле делать Толпу - вместо того, чтобы просто прикрепить имя на стену. Существует намного больше к Толпе, чем ежедневные стоять-взлеты... и если это - все, что они делают, они не делают ее правильно.
Сделанный правильно Толпа вынуждает компании определить узкие места в том, как организация работает. Путем установки регулярных спринтов timeboxed, получения достойной обратной связи и разделения ответственности через владельца продукта и команду соответственно Вы на самом деле получаете полезную базовую информацию о том, как улучшить Ваш процесс.
Организация должна слушать ту обратную связь - и действие на нем.
Это - конечно, не единственный способ сделать гибкий. Это даже не мог бы быть лучший способ представить гибкий в организацию. Я - больше поклонника XP сам - и нахожу, что дополнительные методы служат полезной основой для запуска тех усовершенствований процесса.
Это сказало - для многих организаций - самой большой проблемой является плохое разделение обязанностей и полное отсутствие нормальной и быстрой обратной связи. Толпа фиксирует это из логического элемента.
Встречи являются очень небольшой частью этого :-)
Невозможно определить, является ли команда гибкой, только потому, что кто-то говорит, что они проводят схватку.
Существуют хорошие и плохие реализации схватки, но ключевыми моментами гибкости являются:
- способность проекта и команды мыслить гибко
- , насколько самоорганизованной является команда (есть ли у них «архитектор» или менеджер, помешанный на контроле? Или существует ли значительное количество консенсусных решений для принятия решений?)
Слишком легко соответствовать минимальным требованиям того, что команда должна делать, чтобы выполнять схватку, не будучи по-настоящему гибкой. Эти минимальные требования нужны только для того, чтобы вызвать определенное отношение и образ работы.
Принятие решений в проекте может быть жестко негибким и контролируемым сверху вниз, но при этом соответствовать минимальным требованиям схватки. К сожалению, когда я ищу контрактные обязательства, я обнаруживаю, что реализации только scrum-in-name значительно превосходят по численности реальные.
Лично я бы предпочел реализовать экстремальное программирование в рамках scrum. (Фактически, Джефф Сазерленд говорит, что никогда не видел высокопроизводительной scrum-команды, которая не выполняла бы практики XP.) Тем не менее, я вполне уверен, что люди тоже могут очень плохо внедрять XP ... ;-) Это действительно сводится к минимуму. на отношение к коллективу.
Организации, практикующие только Scrum, скорее всего, видят достижения на фронте управления программным обеспечением и видимости проекта. Однако, скорее всего, они не достигают более высокого качества разработки и потенциала производительности, не внедряя принципы XP, такие как модульное тестирование, непрерывная интеграция, парное программирование и т.д., в результате чего их продукт в конце спринта НЕ "потенциально пригоден для отправки".