How XDSD Is Different

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

eXtremely Distributed Software Development, или XDSD вкратце, – методология, существенно отличающаяся от работы в традиционных командах разработки программного обеспечения. Большинство методов XDSD настолько различны (и важны), что многие новички оказываются запутанными. Эта статья поможет вам начать работу при присоединении к проекту, управляемому принципами XDSD, будь то в качестве разработчика или спонсора проекта.

В отличие от многих других проектов, в XDSD мы платим только за закрытые задачи и согласованный бюджет времени. Позвольте мне объяснить на примере. Допустим, вы являетесь программистом Ruby и получаете новую задачу, требующую исправления неисправного модульного теста. Большинство задач обычно имеют бюджет времени в 30 минут. Иногда, однако, бюджет времени может составлять 15 минут или 1 час.

В нашем примере мы соглашаемся на ставку контракта в размере $50 в час. За исправление теста вы получите $25 за выполнение задачи — 30 минут задачи по ставке $50 в час.

Не имеет значения, сколько времени на самом деле вам потребуется для исправления теста. Фактическое время, затраченное вами на проект, может составлять пять минут или пять часов. Тем не менее, вы получите компенсацию только за 30 минут работы. Если вы исправите неисправный тест за 5 минут, вы получите $25. Если задача займет у вас час или даже месяц, вы все равно получите только $25.

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

Вы можете просмотреть более подробные сведения об этом принципе в следующих статьях: Принцип без обязательств или Определение готовности.

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

Поскольку большинство наших задач занимают полчаса, мы поощряем разработчиков представлять незавершенные компоненты. Подробнее об этой концепции можно прочитать в статье ниже: Puzzle Driven Development.

В отличие от многих других проектов или команд, с которыми вы могли работать, XDSD не использует неформальные каналы коммуникации. Другими словами, мы никогда не пользуемся электронной почтой, не общаемся в Skype и не проводим совещания или телефонные звонки. Кроме того, XDSD не поддерживает списки рассылки. Наш единственный способ общения - система отслеживания задач (которая в большинстве проектов представлена в виде GitHub Issues).

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

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

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

Поскольку у нас нет формальных коммуникаций, участникам проектных команд не требуется работать в определенное время. Вместо этого участники команды работают в удобное для них время в своих часовых поясах. Это включает в себя как будние дни, так и выходные.

В отличие от многих других команд разработчиков, XDSD приветствует сообщения об ошибках во всех наших проектах. Поэтому мы открыто просим о них и ожидаем, что участники команды сообщат о них. Ознакомьтесь с этой статьей для получения полной информации о сообщении об ошибках в XDSD: “Bugs Are Welcome”.

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

XDSD выплачивает вознаграждение за сообщенные ошибки, потому что мы считаем, что чем больше ошибок мы можем найти, тем выше качество конечного продукта. Некоторые новые разработчики удивляются, получая задачи вроде “вам нужно найти 10 ошибок в классе A”. Часто естественной реакцией является вопрос “а если ошибок нет?”. Однако мы считаем, что любой программный продукт может содержать неограниченное количество ошибок; это лишь вопрос времени и усилий, необходимых для их обнаружения.

Мы никогда не предоставляем доступ участникам команды к ветке master, независимо от того, сколько времени вы работаете над проектом. Следовательно, вы всегда должны вносить свои изменения через запросы на объединение (большинство наших проектов выполняются на GitHub).

Мы придерживаемся этой политики не потому, что мы не доверяем нашим разработчикам, а просто потому, что мы никому не доверяем. Это шутка, конечно. Прочитайте эту статью: Ветка Master должна быть только для чтения.

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

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

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-17 at 15:29

sixnines availability badge   GitHub stars