Проект

Недавно мой друг спросил, не было бы мне интересно написать музыку для его выпускного проекта по курсу анимации.

Я большой сторонник создания мотивации путем установления сроков, особенно если вы привлекаете третью сторону. Привлечение кого-то другого делает проект больше, чем просто внутренней борьбой (которую можно постоянно откладывать). На карту поставлено больше, например, ваша репутация и даже ваши отношения с другими.

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

Мой подход

Когда я приступил к проекту, у меня был четкий набор парадигм, взятых из моего опыта работы программистом в командах Agile Development.

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

Это три основные категории:

1. Оставаться здоровым

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

Agile Development точно ничего не говорит о здоровье, но в нем есть определенные меры, такие как ограничение времени и оценки, которые защищают людей от нереалистичных ожиданий, которые затем могут вызвать нагрузку на личное здоровье.

Вот на чем я сосредоточился, чтобы оставаться здоровым:

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

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

2. Общение

Хорошая коммуникация необходима в любом проекте. Agile Development пытается предоставить рекомендации и облегчить общение, создавая встречи, такие как стендапы и другие повторяющиеся встречи, которые имеют четкую и ясную цель.

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

В этом проекте была уникальная проблема: мой друг жил в Новой Зеландии, а я был в Берлине, из-за чего разница во времени составляла десять часов.

Вот на чем я сосредоточился для общения:

  • Предпочтение голосовому общению текстовым сообщениям, так как оно, как правило, более эффективно и менее вероятно, что ключевые моменты будут упущены.
  • Часто общаемся, и не только по поводу проекта. Разговоры на темы, не связанные с проектом, могут дать контекст и тонко передать настроение. Хорошо синхронизироваться, как это делает стендап для Agile-команд.

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

3. Предоставление последовательной обратной связи

Возможно, одной из лучших особенностей Agile Development является идея о том, что продукт всегда можно использовать. Если приоритеты сместятся или ресурсы изменятся, технически вы все равно сможете опубликовать продукт, хотя, вероятно, с более низким качеством, чем хотелось бы.

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

Вот на чем я сосредоточился для постоянной обратной связи:

  • Часто отправляйте миксы обратно для обратной связи, чтобы оставаться в курсе и сообщать о прогрессе.
  • Попытка достичь стабильного состояния как можно раньше, чтобы учесть любые проблемы позже в проекте.
  • Сосредоточение внимания на горизонтальных срезах вместо физических срезов, т.е. все доделано но со средним качеством, в отличие от первых секунд сделано отлично, а остальное недоделано. Это делает его постоянно готовым к выпуску.

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

Вывод

В последнее время я читал много критики в адрес Agile Development — и это правильно. Выбор рабочего процесса — одно из основных решений, которое повлияет на то, как вы работаете и планируете на протяжении всего проекта, поэтому имеет смысл проанализировать его как можно тщательнее.

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

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

Гибкая разработка не подходит для создания музыки и, вероятно, не лучшее решение для многих других творческих проектов.