Модель Longflow - это инженерно-ориентированный рабочий процесс для серьезных разработчиков, уставших от "Agile"/"Scrum" ерунды.
В индустрии программного обеспечения, как и в любой другой, владелец бизнеса не продает время. Владелец продает продукт. Однако доход разработчика зависит от отработанного времени.
По-хорошему, время должно быть преобразовано в улучшения для продукта. Процесс применения этого преобразования называется работа.
Однако, отношение между потраченным временем и выполненной работой абсолютно нелинейно. Преждевременная оптимизация - это хороший пример log-like зависимости, когда постоянное увеличение вложенного времени ведет к уменьшению получаемых преимуществ. С другой стороны, хороший рефакторинг, отняв небольшое количество времени, может достичь экспоненциального роста выгоды на длительном периоде.
Это ключевой принцип методологии longflow: всего можно достичь с фокусированием на долгосрочных целях.
Это не означает отсутствие прототипирования. Это не означает преждевременную оптимизацию. Это означает, что качество имеет цену: время.
Оценок следует избегать любой ценой. Они создают ненужное давление, конкуренцию, а также являются частью вредной "охоты на ведьм", что малопродуктивно.
В мире разработки программного обеспечения невозможно производить значимые оценки для чего угодно кроме нано-задач, не говоря уже о каких-то точных из них.
Часто невозможно разбить задачу на более мелкие значимые операции, даже далеко до начала работы над исходной задачей. Так же, как часто невозможно разделить функцию на маленькие части, когда такая функция уже когерентная и обеспечивает автономный сервис.
Рабочий процесс должен соответствовать проекту, а не наоборот. Так строится хорошая параллельность с data-ориентированным дизайном, где данные - это основа, и логика должна им соответствовать.
Часто запланированные взаимодействия между руководителями и инженерами являются одним их лучших способов разрушить компанию. Собрания раз в неделю/месяц или другой показатель, основанный исключительно на времени, не имеют смысла. Они выражают идею, что все задачи одинаковы, что весь прогресс должен двигаться в устойчивом темпе. Это хороший пример, чтобы больше сосредоточиться на немедленных результатах, а не на долгосрочных целях.
Взаимодействия между руководителями и инженерами должны быть ограничены с точки зрения количества и частоты. Отличный вариант - быть настолько ненавязчивыми, насколько это возможно: почта лучше чем встреча в большинстве случаев.
Следует избегать микроменеджмента любой ценой, потому что он создает помехи между руководителями и инженерами, а также снижает творческий потенциал.
Спешка, спринты, авралы и т.д. являются вредными и опасными.
Качество бесконечно превосходит количество. Разработчики стремятся создавать рабочий, красивый, читаемый код. Заставляя выполнять работу раньше срока, от них требуется производить "наименее недоделанный" код вместо "наилучшего" кода. Сторонники методологии Longflow работают с важными задачами средних и больших размеров, самоназначенных всякий раз при необходимости, когда разработчики могут использовать технические способности и навыки решения проблем. Разработчики не пишут никакого кода поначалу, а просто думают о том, как они могут решить эту проблему. Или, еще лучше, задают себе такие вопросы, как:
- Есть ли здесь проблема, требующая решения?
- Могу ли я улучшить эту часть кода?
- Есть ли задачи, которые я хотел бы сделать по-другому?
Любопытство и творчество - очень важные навыки для разработчиков программного обеспечения, но эти навыки не могут развиваться, если присутствует давление, желание выпустить код как можно быстрее. Это очень вредно на длительных промежутках времени, не говоря уже о постоянных.
Разработчикам должно быть разрешено, и даже поощряться, проводить время за изучением и экспериментами с новыми вещами и понятиями. Быть способным применять большое разнообразие решений и концепций к проблеме имеет решающее значение для хорошего разработчика программного обеспечения. Отказ от своего права на обучение препятствует развитию способностей улучшать и производить качественный код.
- Думайте о долгосрочных целях.
- Пусть инженеры самостоятельно ставят задачи.
- Качество стоимости важнее сроков.
- Пусть инженеры занимаются проектированием.
- Никакого микроменеджмента.
- Не мешает инженерам чаще, чем это действительно необходимо.
- Никогда не спешите, всегда думайте и планируйте заранее.
- Не бойтесь провала.
- Избегайте cargo-культов программирования, как чумы.
- Думайте о долгосрочных целях.
- Выбирайте свои собственные задачи.
- Попробуйте исправлять ошибки, прежде чем вводить новые функции, в некоторой степени.
- Попробуйте чистить кодовую базу перед введением новых функций, в некоторой степени.
- Старайтесь писать наилучший код.
- Не бойтесь пробовать что-то новое.
- Думайте больше, пишите меньше.
- Всегда старайтесь изучать вещи, быть любопытным.
- Не бойтесь опаздывать.
- Не бойтесь провала.
- Избегайте cargo-культов программирования, как чумы.
Типичная реализация манифеста longflow , с точки зрения инженера, это что-то вроде этого:
- Я выбираю или создаю задачу.
- Я провел несколько минут/часов/дней думая о задаче. Нам это нужно? Я делал что-то подобное раньше? Как достичь решения задачи?
- Если задача оказывается ненужной, вернуться к п. 1.
- Если мне нужно узнать что-то, чтобы выполнить задачу, я иду учиться.
- Если я хочу узнать что-то новое, я также иду учиться.
- Я думаю о задаче снова. Я могу вернуться к п. 4 или п. 1, если есть вещи, которые я узнал, и я изменил свое мнение о задаче.
- Я работаю над этой задачей. Я могу вернуться к п. 2 в любой момент.
- Я завершил задачу.
- Я думаю о задаче снова. Я, возможно, захочу вернуться к п. 2.
- Задача теперь считается сделанной, но я (или кто-то другой) может принять решение работать над ней в любое время, возвращаясь к п. 2.
Это может показаться на первый взгляд беспорядком, но такой рабочий процесс чрезвычайно гибкий и очень хорош с точки зрения качества полученного кода, потому что каждый может улучшить любую часть кодовой базы всякий раз, когда он этого хочет.
Этот манифест был написан Nax.
Не стесняйтесь, если хотите его изменить.
Перевел на русский язык Midwain.