Недавно у меня была возможность создать плагин с двумя другими разработчиками — Пиппином Уильямсоном и Эндрю Норкроссом . Мы придумали эту идею через Twitter, определили ее по электронной почте и построили ее с помощью GitHub, используя все инструменты до ее выпуска.
Я знаю — название этого поста звучит слишком знакомо, особенно с учетом глобальной экономики, в которой мы все живем сегодня. В конце концов, многие из нас работают из наших домашних офисов, кафе или где-либо еще, в то время как домашняя база нашей компании находится в другом месте.
Но это другой тип распределенной команды.
Во-первых, давайте признаем, что когда речь идет о создании программного обеспечения в пространстве WordPress, нам чрезвычайно повезло, что мы можем сделать это сами, с несколькими друзьями или в рамках команды в корпоративной среде.
Несмотря на то, что сам WordPress создается многими людьми по всему миру, вы не часто сталкиваетесь с тем же опытом и темами или плагинами. Это не значит, что это никогда не делается (потому что это так), но кажется, что это сделано не так.
Теперь цель этого поста не состоит в том, чтобы продвигать вышеупомянутый плагин, но для нас это скорее призыв к действию, чтобы найти более креативные способы создания издательских продуктов с командами, а именно, с нашими «интернет-друзьями» или твипами, с которыми мы возможно, раньше не работал.
Но есть некоторые уроки, извлеченные из этого процесса, которые, я думаю, стоит поделиться, чтобы помочь другим начать экспериментировать с разработкой проектов с другими твитами.
Сфера является ключевым
Проще говоря, блокировка в области является частью определения основных функций вашего плагина. Когда вы только начинаете, важно иметь возможность кратко заявить, что собирается делать ваш продукт.
В нашем случае мы сказали:
Мы хотим, чтобы люди могли легко определить, для каких комментариев нужен ответ автора поста.
Это позволяет вам определить сетку — или область действия — через которую могут быть отфильтрованы все потенциальные объекты. Если он не соответствует основной идее плагина, то он не подходит для первого выпуска.
Тем не менее, это похоже на то, что это немного клише, потому что этого следует ожидать от любого программного проекта: определить область, заблокировать ее, а затем стремиться к ней.
Но когда вы работаете с группой друзей над бесплатным проектом, это может стать все более и более легко игнорируемым.
Наглядный пример: как одинокий разработчик, как часто вы думаете: «Это было бы крутой возможностью для создания!» И затем, потому что у вас не было никого, кто действительно мог бы привлечь вас к ответственности за его создание, вы смогли достичь этого.
Это не значит, что это неправильно — может быть, а может и нет — я не знаю специфики вашего проекта; однако, если вы работаете с командой над проектом, то время, затрачиваемое на работу над чем-то, что выходит за рамки, — это пустая трата времени, которая в конечном итоге может отвлечь внимание от сути плагина. Кроме того, он может задержать время разработки ваших пиров, пока они ждут завершения вашей функции, особенно если есть зависимость от вашей работы.
Наконец, если вы соберете группу разработчиков, чтобы создать что-то для удовольствия, проект может никогда не закончиться, потому что вы взяли идею «разве это не круто» и умножили ее на сколько угодно твоя команда.
Дело в том, что даже если вы работаете с друзьями, вы должны оценить его как можно раньше и раннее; в противном случае, вы никогда не будете сделаны.
Дата доставки имеет значение
И это подводит нас ко второму пункту: несмотря на тот факт, что у вас нет никого «выше вас», который держит вас подотчетными за дату доставки, у вас все еще есть обязательства перед собой, вашими возможностями и теми, кто, возможно, ожидает, что продукт полная разработка.
Конечно, всегда можно привести аргумент, что, поскольку люди не платят, у них нет реального требования, когда что-то должно быть закончено; однако, если вы определили дату, есть уровень целостности, который должен соответствовать при стремлении доставить вашу работу.
https://twitter.com/pippinsplugins/status/301792120266690561
Для этого важно установить дату доставки — какой бы произвольной она ни была — а затем установить этапы, чтобы убедиться, что темп разработки соответствует этой дате.
Например, Пиппин, Эндрю и я определили плагин в феврале и намеревались завершить плагин в апреле к концу одного из событий WordCamp. Конечно, крайний срок был несколько произвольным, но он позволял нам быть честными не только в наших собственных усилиях по развитию, но и позволял нам привлекать друг друга к ответственности за свои конкретные задачи.
Это означает, что если бы я тащил свои ноги, Пиппин или Эндрю могли бы позвонить мне (конечно, это работает вокруг).
Держите это открытым
Наконец, работа с друзьями — это прекрасно, особенно когда вы объединены вокруг одного и того же видения. Это позволяет быстрее выполнять больше задач, поскольку работа может быть распределена между несколькими людьми.
Но хорошая вещь о программном обеспечении — то, что это может быть с открытым исходным кодом. Это означает, что, если другие не только заинтересованы в проекте или вовлечены в видение, они могут даже внести свой вклад в него.
Но вот в чем дело, программное обеспечение неизбежно породит две вещи:
- ошибки
- Запросы функций
Использование таких инструментов, как GitHub, позволяет пользовательской базе плагина — будь то пользователи, разработчики или дизайнеры — централизованно озвучивать свои проблемы и / или запросы функций.
Кроме того, это позволяет основной группе не только назначать каждый набор проблем своим вехам, но и позволяет другим участникам, которые также участвуют в видении, точно знать, как они могут внести свой вклад. Там нет догадок. Там нет «эй, может быть, мы могли бы сделать это! «
Вместо этого есть список проблем и запросов, которые необходимы (разрешив, чтобы список обновлялся), чтобы участники знали, что они в конечном итоге улучшают продукт, а не просто слепо что-то добавляют, потому что думают, что это будет выглядеть хорошо.
Конечно, это не ограничивается GitHub: какую бы систему контроля версий и тикет вы ни выбрали, убедитесь, что это то, что позволяет другим взаимодействовать, а другим просматривать нерешенные вопросы. Последнее, что нужно участникам, — это еще одно препятствие для участия в вашем проекте.
Вывод
Итак, у вас есть это: три точки работы над продуктами с распределенной командой вне типичной организованной среды.
Проще говоря, убедитесь, что вы охватили свой проект, придерживайтесь даты доставки и дайте возможность другим заинтересованным сторонам внести свой вклад. Делая это, вы облегчаете не только вашей текущей команде, но и вашим будущим участникам улучшить продукт.
Наконец, я избегал обсуждать плагин, который Пиппин, Эндрю и я специально создали, потому что я хотел, чтобы этот пост был о процессе, а не о продукте; однако теперь, когда мы рассмотрели первое, вы можете найти второе здесь на GitHub . Если вам интересно, не стесняйтесь оставлять нам вопросы, заметки или даже тянуть запросы!