├── LICENSE ├── README-pt.md ├── README-ru.md └── README.md /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2016 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README-pt.md: -------------------------------------------------------------------------------- 1 |
2 |

O Manifesto Longflow

3 | Versão 1 4 |
5 | 6 | ## Sobre esse manifesto 7 | 8 | O modelo longflow é um fluxo de trabalho centrado na engenharia para desenvolvedores sérios, cansados da besteira de "Agile"/"Scrum". 9 | 10 | ## A questão do Tempo 11 | 12 | ### Tempo e Trabalho 13 | 14 | Na indústria de software, tal como em qualquer indústria, o dono de um negócio não vende tempo. O dono de um negócio vende um produto. 15 | Contudo, um desenvolvedor de software cobra por tempo trabalhado. 16 | 17 | Em algum lugar, tempo deve ser transformado em melhorias ao produto. 18 | A ação de aplicar essa transformação é chamada de trabalho. 19 | 20 | Contudo, a relação entre tempo gasto e trabalho realizado é absolutamente *não* linear. 21 | Otimização prematura, por exemplo, é um bom candidato para uma relação logarítimica, na qual mais e mais tempo é investido em cada vez menos benefícios. 22 | Em contrapartida, boa refatoração pode utilizar uma quantia moderada de tempo para um retorno exponencial sobre um longo período de tempo. 23 | 24 | Esse é o princípio chave da metodologia longflow: **tudo deve ser feito com objetivos de longo-termo em mente**. 25 | 26 | Isso *não* significa prototipação. 27 | Isso *não* significa otimização prematura. 28 | Isso *significa* que qualidade tem um preço: tempo. 29 | 30 | ### Estimativas 31 | 32 | Estimativas devem ser evitadas à todo custo. 33 | Elas criam pressão desnecessária, competição e a participação tóxica na caça-às-bruxas por quem é menos produtivo. 34 | 35 | No mundo do desenvolvimento de software, é impossível produzir estimativas significativas, sem falar de precisas, para qualquer coisa que não seja uma nano-tarefa. 36 | 37 | É frequentemente impossível dividir uma tarefa em tarefas significativas menores, ainda mais *antes* de iniciar a tarefa original. 38 | Tal como pode ser impossível dividir uma função em funções significativas menores, onde essas funções são coerentes e auto-contidas. 39 | 40 | Faça o fluxo de trabalho se ajustar ao projeto, não o inverso. 41 | Isso traça um belo paralelo com o projeto oriendado à dados[1], no qual dados são o núcleo e a lógica deve seguí-lo. 42 | 43 | ### Eventos Baseados em Tempo 44 | 45 | Interações frequentes, baseadas em tempo, entre executivos e engenheiros são um dos melhores jeitos de destruir uma empresa. 46 | Ter uma reunião uma vez por semana/mês ou qualquer outro indicador baseado apenas em tempo é insignificante. Transmite a idéia de que todas as tarefas são iguais, e todo progresso deve ser obtido em um ritmo constante. 47 | Também é um jeito excelente de manter o foco em resultados imediatos ao invés de objetivos à longo-prazo. 48 | 49 | Interações entre executivos e engenheiros devem ser limitadas em termos de quantidade e frequência. 50 | Também é melhor ser o menos intrusivo possível: um email pode ser melhor que uma reunião em muitos casos. 51 | 52 | Micro-gerenciamento deve ser evitado à todo custo, porque cria interferências entre executivos e engenheiros, e reduz criatividade. 53 | 54 | *Maratonas, sprints, etc são tóxicos e perigosos.* 55 | 56 | Qualidade é infinitamente superior à quantidade. Engenheiros de software almejam produzir código legível, bonito e que funciona. 57 | Ao forçar datas de entrega à eles, eles são encorajados à produzir o código "menos pior" ao invés do código "melhor possível". 58 | A metodologia longflow advoca ter tarefas significativas médias ou grandes, auto-definidas sempre que possível, na qual desenvolvedores podem utilizar tanto suas habilidades técnicas quanto resolução de problemas. 59 | Faça desenvolvedores não escrever código primeiro, mas simplesmente pensar em como eles podem resolver o problema. Ou até melhor, faça-os perguntar internamente: 60 | 61 | * Há um problema a ser resolvido? 62 | * Posso melhorar essa parte do código? 63 | * Existem tarefas que eu gostaria de ter resolvido de outra forma? 64 | 65 | Curiosidade e criatividade são habilidades muito importantes para desenvolvedores de software, mas essas habilidades não podem ser desenvolvidas se há pressão para produzir código o mais rápido possível 66 | É prejudicial ter metas longas, sem nem falar das permanentes. 67 | 68 | Desenvolvedores deveriam ser permitidos, até mesmo encorajados, a gastar um tempo aprendendo e brincando com novas coisas e conceitos. 69 | Ter a possibilidade de aplicar uma vasta variedade de soluções e conceitos à um problema é crucial para um bom desenvolvedor de software. 70 | Negar seu direito à aprender vai afetar a habilidade dos desenvolvedores de melhorar e produzir código de qualidade. 71 | 72 | ## A metodologia longflow em simples passos 73 | 74 | ### Gerenciamento 75 | 76 | * Continue pensando em objetivos de longo-prazo. 77 | * Deixe os engenheiros determinarem suas próprias tarefas. 78 | * Valorize qualidade sobre datas de entrega. 79 | * Deixe os engenheiros fazerem a engenharia. 80 | * Não micro-gerencie. 81 | * Não interfira com engenheiros mais do que o estritamente necessário. 82 | * Nunca se apresse, sempre pense e planeje adiante. 83 | * Não tema falhar. 84 | * Evite cultos à carga[2] como se fossem pragas. 85 | 86 | ### Técnico 87 | 88 | * Continue pensando em objetivos de longo-prazo. 89 | * Determine suas próprias tarefas. 90 | * Tente corrigir bugs antes de introduzir novas funcionalidades, até um limite. 91 | * Tente limpar o código antes de introduzir novas funcionalidades, até um limite. 92 | * Tente escrever o melhor código possível. 93 | * Não tenha medo de tentar algo diferente. 94 | * Pense mais, escreva menos. 95 | * Sempre tente aprender, seja curioso. 96 | * Não tenha medo de atrasar. 97 | * Não tema falhar. 98 | * Evite cultos à carga como se fossem pragas. 99 | 100 | ## Uma implementação típica 101 | 102 | Uma típica implementação do manifesto longflow, do ponto de vista de um engenheiro, é algo parecido com isso: 103 | 104 | 1. Eu escolho ou crio uma tarefa. 105 | 2. Eu perco alguns minutos/horas/dias pensando sobre a tarefa. Nós precisamos disso? Eu já fiz algo similar no passado? Que objetivo essa tarefa atinge? 106 | 3. Se a tarefa não for necessária, eu volto pra 1. 107 | 4. Se eu preciso aprender algo para realizar a tarefa, eu aprendo. 108 | 5. Se eu *quero* aprender algo novo, eu aprendo. 109 | 6. Eu penso sobre a tarefa novamente. Eu posso voltar para o 4 ou 1 se as coisas que aprendi mudaram minha opinião sobre a tarefa. 110 | 7. Eu trabalho na tarefa. Eu posso voltar para o item 2 a qualquer momento. 111 | 8. Eu termino a tarefa. 112 | 9. Eu penso sobre a tarefa novamente. Eu posso querer voltar para o 2. 113 | 10. A tarefa agora pode ser considerada terminada, mas eu (ou outra pessoa) posso decidir trabalhar nela a qualquer momento, voltando para o 2. 114 | 115 | Pode parecer confuso à princípio, mas um fluxo de trabalho como esse é tanto possível quanto extremamente bom em termos de qualidade do código produzido, porque qualquer um pode melhorar qualquer parte da base de código sempre que quiser. 116 | 117 | ## Autor 118 | 119 | Esse manifesto foi escrito por [Nax](https://github.com/Nax) e traduzido para Português por [alganet](https://github.com/alganet). 120 | Sinta-se livre para modificá-lo. 121 | 122 | [1]: https://en.wikipedia.org/wiki/Data-oriented_design 123 | [2]: https://pt.wikipedia.org/wiki/Culto_%C3%A0_carga 124 | -------------------------------------------------------------------------------- /README-ru.md: -------------------------------------------------------------------------------- 1 |
2 |

Манифест Longflow

3 | Version 1 4 |
5 | 6 | ## Об этом манифесте 7 | 8 | Модель Longflow - это инженерно-ориентированный рабочий процесс для серьезных разработчиков, уставших от "Agile"/"Scrum" ерунды. 9 | 10 | ## Вопрос времени 11 | 12 | ### Время и Работа 13 | 14 | В индустрии программного обеспечения, как и в любой другой, владелец бизнеса не продает время. Владелец продает продукт. Однако доход разработчика зависит от отработанного времени. 15 | 16 | По-хорошему, время должно быть преобразовано в улучшения для продукта. 17 | Процесс применения этого преобразования называется работа. 18 | 19 | Однако, отношение между потраченным временем и выполненной работой абсолютно *нелинейно*. 20 | Преждевременная оптимизация - это хороший пример log-like зависимости, когда постоянное увеличение вложенного времени ведет к уменьшению получаемых преимуществ. 21 | С другой стороны, хороший рефакторинг, отняв небольшое количество времени, может достичь экспоненциального роста выгоды на длительном периоде. 22 | 23 | Это ключевой принцип методологии longflow: **всего можно достичь с фокусированием на долгосрочных целях**. 24 | 25 | Это *не* означает отсутствие прототипирования. 26 | Это *не* означает преждевременную оптимизацию. 27 | Это *означает*, что качество имеет цену: время. 28 | 29 | ### Оценивание 30 | 31 | Оценок следует избегать любой ценой. 32 | Они создают ненужное давление, конкуренцию, а также являются частью вредной "охоты на ведьм", что малопродуктивно. 33 | 34 | В мире разработки программного обеспечения невозможно производить значимые оценки для чего угодно кроме нано-задач, не говоря уже о каких-то точных из них. 35 | 36 | Часто невозможно разбить задачу на более мелкие значимые операции, даже далеко *до* начала работы над исходной задачей. 37 | Так же, как часто невозможно разделить функцию на маленькие части, когда такая функция уже когерентная и обеспечивает автономный сервис. 38 | 39 | Рабочий процесс должен соответствовать проекту, а не наоборот. 40 | Так строится хорошая параллельность с data-ориентированным дизайном, где данные - это основа, и логика должна им соответствовать. 41 | 42 | ### Запланированные события 43 | 44 | Часто запланированные взаимодействия между руководителями и инженерами являются одним их лучших способов разрушить компанию. 45 | Собрания раз в неделю/месяц или другой показатель, основанный исключительно на времени, не имеют смысла. Они выражают идею, что все задачи одинаковы, что весь прогресс должен двигаться в устойчивом темпе. 46 | Это хороший пример, чтобы больше сосредоточиться на немедленных результатах, а не на долгосрочных целях. 47 | 48 | Взаимодействия между руководителями и инженерами должны быть ограничены с точки зрения количества и частоты. 49 | Отличный вариант - быть настолько ненавязчивыми, насколько это возможно: почта лучше чем встреча в большинстве случаев. 50 | 51 | Следует избегать микроменеджмента любой ценой, потому что он создает помехи между руководителями и инженерами, а также снижает творческий потенциал. 52 | 53 | *Спешка, спринты, авралы и т.д. являются вредными и опасными.* 54 | 55 | Качество бесконечно превосходит количество. Разработчики стремятся создавать рабочий, красивый, читаемый код. Заставляя выполнять работу раньше срока, от них требуется производить "наименее недоделанный" код вместо "наилучшего" кода. 56 | Сторонники методологии Longflow работают с важными задачами средних и больших размеров, самоназначенных всякий раз при необходимости, когда разработчики могут использовать технические способности и навыки решения проблем. 57 | Разработчики не пишут никакого кода поначалу, а просто думают о том, как они могут решить эту проблему. Или, еще лучше, задают себе такие вопросы, как: 58 | 59 | * Есть ли здесь проблема, требующая решения? 60 | * Могу ли я улучшить эту часть кода? 61 | * Есть ли задачи, которые я хотел бы сделать по-другому? 62 | 63 | Любопытство и творчество - очень важные навыки для разработчиков программного обеспечения, но эти навыки не могут развиваться, если присутствует давление, желание выпустить код как можно быстрее. 64 | Это очень вредно на длительных промежутках времени, не говоря уже о постоянных. 65 | 66 | Разработчикам должно быть разрешено, и даже поощряться, проводить время за изучением и экспериментами с новыми вещами и понятиями. 67 | Быть способным применять большое разнообразие решений и концепций к проблеме имеет решающее значение для хорошего разработчика программного обеспечения. 68 | Отказ от своего права на обучение препятствует развитию способностей улучшать и производить качественный код. 69 | 70 | ## Методология Longflow шаг-за-шагом 71 | 72 | ### Управляющим 73 | 74 | * Думайте о долгосрочных целях. 75 | * Пусть инженеры самостоятельно ставят задачи. 76 | * Качество стоимости важнее сроков. 77 | * Пусть инженеры занимаются проектированием. 78 | * Никакого микроменеджмента. 79 | * Не мешает инженерам чаще, чем это действительно необходимо. 80 | * Никогда не спешите, всегда думайте и планируйте заранее. 81 | * Не бойтесь провала. 82 | * Избегайте cargo-культов программирования, как чумы. 83 | 84 | ### Инженерам 85 | 86 | * Думайте о долгосрочных целях. 87 | * Выбирайте свои собственные задачи. 88 | * Попробуйте исправлять ошибки, прежде чем вводить новые функции, в некоторой степени. 89 | * Попробуйте чистить кодовую базу перед введением новых функций, в некоторой степени. 90 | * Старайтесь писать наилучший код. 91 | * Не бойтесь пробовать что-то новое. 92 | * Думайте больше, пишите меньше. 93 | * Всегда старайтесь изучать вещи, быть любопытным. 94 | * Не бойтесь опаздывать. 95 | * Не бойтесь провала. 96 | * Избегайте cargo-культов программирования, как чумы. 97 | 98 | ## Типичная реализация 99 | 100 | Типичная реализация манифеста longflow , с точки зрения инженера, это что-то вроде этого: 101 | 102 | 1. Я выбираю или создаю задачу. 103 | 2. Я провел несколько минут/часов/дней думая о задаче. Нам это нужно? Я делал что-то подобное раньше? Как достичь решения задачи? 104 | 3. Если задача оказывается ненужной, вернуться к п. 1. 105 | 4. Если мне нужно узнать что-то, чтобы выполнить задачу, я иду учиться. 106 | 5. Если я *хочу* узнать что-то новое, я также иду учиться. 107 | 6. Я думаю о задаче снова. Я могу вернуться к п. 4 или п. 1, если есть вещи, которые я узнал, и я изменил свое мнение о задаче. 108 | 7. Я работаю над этой задачей. Я могу вернуться к п. 2 в любой момент. 109 | 8. Я завершил задачу. 110 | 9. Я думаю о задаче снова. Я, возможно, захочу вернуться к п. 2. 111 | 10. Задача теперь считается сделанной, но я (или кто-то другой) может принять решение работать над ней в любое время, возвращаясь к п. 2. 112 | 113 | Это может показаться на первый взгляд беспорядком, но такой рабочий процесс чрезвычайно гибкий и очень хорош с точки зрения качества полученного кода, потому что каждый может улучшить любую часть кодовой базы всякий раз, когда он этого хочет. 114 | 115 | ## Автор 116 | 117 | Этот манифест был написан [Nax](https://github.com/Nax). 118 | Не стесняйтесь, если хотите его изменить. 119 | 120 | *Перевел на русский язык [Midwain](https://github.com/Midwain).* 121 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 |
2 |

The Longflow Manifesto

3 | Version 1 4 |
5 | 6 | ## About this manifesto 7 | 8 | The longflow model is an engineering-centric workflow for serious software developers, tired of the "Agile"/"Scrum" bullshit. 9 | 10 | ## The question of Time 11 | 12 | ### Time and Work 13 | 14 | In the software industry, like in every industry, a business owner does not sell time. A business owner sells a product. 15 | However, a software developer bills time worked. 16 | 17 | Somewhere, time must be transformed into improvements to the product. 18 | The action of applying this transformation to time is called work. 19 | 20 | However, the relation between time spent and work done is absolutely *not* linear. 21 | Premature optimization, for example, is a good candidate for a log-like relation, where more and more time is being invested for less and less benefits. 22 | On the other hand, good refactoring can use a moderate amount of time for exponential returns over a long period of time. 23 | 24 | This is the key principle of the longflow methodology: **everything has to be done with long-term goals in mind**. 25 | 26 | That does *not* mean no prototyping. 27 | That does *not* mean premature optimization. 28 | That *does* mean quality has a price: time. 29 | 30 | ### Estimates 31 | 32 | Estimates are to be avoided at all cost. 33 | They create needless pressure, competition, and participate in a toxic witch-hunt of who is the less productive. 34 | 35 | In the software development world, it is impossible to produce meaningful estimates, let alone precise ones, for anything but nano-tasks. 36 | 37 | It is often impossible to split a task into meaningful smaller ones, even more so *before* starting the original task. 38 | Just like it may be impossible to split a function into meaningful smaller ones, when such function is already coherent and provides a self-contained service. 39 | 40 | Have the workflow match the project, not the other way around. 41 | This draws a nice parallel with data-oriented design, where the data is the core and the logic has to match it. 42 | 43 | ### Time-based events 44 | 45 | Frequent, time-based interactions between executives and engineers are one of the best way to crash a company. 46 | Having a meeting once in a week/month or other indicator based solely on time is meaningless. It conveys the idea that all the tasks are the same, that all progress must be at a steady pace. 47 | It's also an excellent way to focus more on immediate results than on the long term goals. 48 | 49 | Interactions between executives and engineers must be limited in terms of number and frequency. 50 | It's also best to be as unintrusive as possible : a mail may be better than a meeting in a lot of cases. 51 | 52 | Micro-management should be avoided at all costs, because it creates interferences between executives and engineers, and reduces creativity. 53 | 54 | *Rushes, sprints, crunch-time, etc. are toxic and dangerous.* 55 | 56 | Quality is infinitely superior to quantity. Software engineers aim to produce working, beautiful, readable code. 57 | By forcing deadlines upon them, they are encouraged to produce "the least dysfunctional" code instead of "the best possible" code. 58 | The longflow methodology advocates having medium to large sized meaningful tasks, self-assigned whenever possible, where developers can leverage both technical and problem-solving skills. 59 | Have developers write no code at first, but simply think about how they can solve the problem. Or, better yet, asking themselves questions like: 60 | 61 | * Is there a problem to solve? 62 | * Can I improve this part of the code? 63 | * Are there tasks I wish I had done differently? 64 | 65 | Curiosity and creativity are very important skills for software developers, but these skills can't develop if there is pressure to release code as fast as possible. 66 | It is very detrimental to have long, let alone permanent, deadlines. 67 | 68 | Developers should be allowed, and even encouraged, to spend some time learning and toying with new things and concepts. 69 | Being able to apply a large variety of solutions and concepts on a problem is crucial for a good software developer. 70 | Denying their right to learn will hinder the ability of developers to improve and produce quality code. 71 | 72 | ## The longflow methodology in simple steps 73 | 74 | ### Management 75 | 76 | * Keep thinking about long term goals. 77 | * Let engineers self-assign tasks. 78 | * Value quality over deadlines. 79 | * Let the engineers do engineering. 80 | * Don't micro-manage. 81 | * Don't interfere with engineers more than strictly required. 82 | * Never rush, always think and plan ahead. 83 | * Don't fear failure. 84 | * Avoid cargo-cults like the plague. 85 | 86 | ### Technical 87 | 88 | * Keep thinking about long term goals. 89 | * Pick up your own tasks. 90 | * Try to fix bugs before introducing new features, to an extent. 91 | * Try to clean the codebase before introducing new features, to an extent. 92 | * Try to write the best possible code. 93 | * Don't fear trying something different. 94 | * Think more, write less. 95 | * Always try to learn things, be curious. 96 | * Don't fear running late. 97 | * Don't fear to fail. 98 | * Avoid cargo-cults like the plague. 99 | 100 | ## A typical implementation 101 | 102 | A typical implementation of the longflow manifesto, from the point of view of an engineer, is something like this: 103 | 104 | 1. I pick or create a task. 105 | 2. I spent a few minutes/hours/days thinking about the task. Do we need it? Have I done something similar before? What does the task achieve? 106 | 3. If the task turns out to be unneeded, go back to 1. 107 | 4. If I need to learn something to do the task, I go learn it. 108 | 5. If I *want* to learn something new, I go learn it too. 109 | 6. I think about the task again. I may go back to 4 or 1 if the things I learned changed my mind about the task. 110 | 7. I work on the task. I may go back to 2 at any point. 111 | 8. I finish the task. 112 | 9. I think about the task again. I may want to go back to 2. 113 | 10. The task is now considered done, but I (or someone else) can decide to work on it at any time, going back to 2. 114 | 115 | It may seem messy at first, but a workflow like this is both extremely flexible and extremely good in terms of quality of the code produced, because everyone can improve any part of the codebase whenever they want. 116 | 117 | ## Author 118 | 119 | This manifesto was written by [Nax](https://github.com/Nax). 120 | Feel free to modify it. 121 | --------------------------------------------------------------------------------