├── README.md ├── agile_lite_for_developers.md ├── agile_lite_for_managers.md ├── chinese ├── README.md ├── agile_lite_for_developers.md ├── agile_lite_for_managers.md └── faq.md ├── faq.md ├── german ├── README.md ├── agile_lite_for_developers.md ├── agile_lite_for_managers.md └── faq.md ├── japanese ├── README.md ├── agile_lite_for_developers.md ├── agile_lite_for_managers.md └── faq.md ├── korean ├── README.md ├── agile_lite_for_developers.md ├── agile_lite_for_managers.md └── faq.md ├── portuguese ├── README.md ├── agile_lite_for_developers.md ├── agile_lite_for_managers.md └── faq.md ├── russian ├── 01.jpg ├── README.md ├── agile_lite_for_developers.md ├── agile_lite_for_managers.md └── faq.md └── spanish ├── README.md ├── agile_lite_for_developers.md └── agile_lite_for_managers.md /README.md: -------------------------------------------------------------------------------- 1 | # Agile Lite: Agile without all the burnout 2 | 3 | "Agile software development" is a great idea that's been overcomplicated by the publishing and consulting industries. Agile Lite is an attempt to simplify the situation. You do not need a book or a workshop to explain Agile Lite. You just need a text file with several paragraphs. This is that text file. 4 | 5 | Agile Lite is pretty simple. It can be applied to any project with people working on it, assuming that the work can be broken into smaller component tasks that we'll just call Issues. Like other agile methodologies, it utilizes short development cycles called Sprints. Somewhat uniquely, Agile Lite explicitly acknowledges the prevalence of burnout in the software development industry and attempts to mitigate it directly via a 3 weeks on/1 week off development cycle. 6 | 7 | The basic setup is this: 8 | 9 | * The first week of each cycle is spent with project leads, developers, and other stakeholders defining the upcoming `sprint`. Despite a week being allocated, a sprint planning session should take no more than 2 hours and probably about 45 minutes if done correctly. It is an intentionally light week and many people may simply take the time off to paint or surf or whatever. 10 | 11 | * The `sprint` takes place during the remaining 3 weeks of the cycle. During this period, engineers will work on the Issues that were allocated to them during the sprint planning sessions. Because the team may be fully remote and distributed over time-zones, "live" meetings happen infrequently and most communication happens through the `issue tracking system` (which is faster to work with than e-mail). A shared kanban board like Trello is a sufficient issue tracking system, but a spreadsheet is probably not. Daily standups are discouraged; a basic pulse on the project can be obtained by reviewing issue tracking system updates. 12 | 13 | * Once a `sprint` has begun, Issues may not be added to the sprint, but they can be removed. This reduces context switching and that is a good thing. 14 | 15 | * Issues that are not completed during the sprint are reviewed at the next sprint planning session and it's decided whether to move the Issue forward into the next sprint, put it back in the Backlog, or reassign it to a different developer. 16 | 17 | * An issue is either in the `backlog` or in the `current sprint`. 18 | 19 | * As mentioned, developers are encouraged to take it easy during the planning week to allow their brain time to recover from the previous sprint. There are no death marches. Developers don't work on the weekends. This all helps avoid burnout. Avoiding burnout is good for everyone. 20 | 21 | While most work in a given sprint can be planned, sometimes things do happen unexpectedly. These unexpected issues are called `Support Issues`. 22 | 23 | We suggest allocating time for unplannable Support Issues to certain members of the team during sprint planning. For instance, "Dave has 12 hours during the next sprint that can be allocated to support issues (the specifics of which will be defined later)." It is often beneficial to have a rotation where the developer(s) in charge of support during a given sprint will change each rotation. 24 | 25 | To increase estimate accuracy, at each sprint planning session, the amount of support work that was actually done in the previous sprint is reviewed and it's decided whether *more* time or *less* time is needed for support work in the next sprint. 26 | 27 | In practice, different teams have different definitions for support work. Perhaps it means to support the customer/clients. Perhaps it means to support other developers. It is up to you to pick and choose which elements of this general methodology apply best to your team. 28 | 29 | That's pretty much it. Agile Lite is a better, more sustainable way to develop software. It empowers software developers while delivering a consistently solid level of productivity to project stakeholders. 30 | 31 | To learn more about Agile Lite, I encourage you to read: 32 | 33 | [Agile Lite for developers](agile_lite_for_developers.md) 34 | 35 | [Agile Lite for managers](agile_lite_for_managers.md) 36 | 37 | [Frequently Asked Questions](faq.md) 38 | 39 | 40 | --- 41 | If you would like to see more workplaces implement a system such as this, please star this repo on github and share on social media to increase visibility. 42 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 43 | -------------------------------------------------------------------------------- /agile_lite_for_developers.md: -------------------------------------------------------------------------------- 1 | # Agile Lite for developers 2 | 3 | If you've been working in the software industry for more than a few years, you've quite possibly experienced burnout. There are many reasons for burnout, but it can most simply be described as the result of working too much, under too much stress, for too long. 4 | 5 | It starts with a project. That project has a detailed specification and a deadline. When the specification changes, the deadline does not. Eventually the deadline comes and goes and the spec has turned into something different from where it started. Of course, this is seen as your fault, and you are asked to stay late or to commit to "stretch goals". Eventually you're coming in every weekend and no matter how hard you work, your manager is never happy and the project is perpetually "behind schedule". 6 | 7 | Wanting time off or vacation makes you seem like a slacker. It makes you seem like you're the one holding up your team. Perhaps you work in an open office environment; everyone knows when you get there, everyone knows when you leave, and everyone signs an unspoken contract to not be the person that's not working the hardest. So people get good at looking busy, and whenever someone asks you how you're doing, you just reply, "Busy! I'm SO busy!" 8 | 9 | But eventually something gives. Maybe you change jobs, but it's more of the same at other companies in the software industry. Maybe you stick through it until there's nothing left and then the company lets you go because you're just "not a culture fit". Maybe you quit and take a job selling cars because programming is just too damned frustrating. As they say, if you want to kill the joy in a hobby, try doing it for a living. 10 | 11 | I'm proposing a solution. It's a form of agile that's explicitly designed to help avoid burnout. I call it Agile Lite. 12 | 13 | * The most basic rule is this: Every cycle includes a 3 week sprint and 1 week "off" where sprint planning is done. 3 weeks on/1 week off. 14 | 15 | * A sprint contains Issues and engineers solve Issues, logging pertinent questions and updates to the Issue Tracker. 16 | 17 | * Once a sprint has begun, Issues may not be added to the sprint, but they can be removed. This reduces context switching and that is a good thing. 18 | 19 | * An Issue is any unit of work that should take 4-8 hours of engineering effort. An Issue is either in the current sprint or in the backlog. 20 | 21 | * Any Issues in the current sprint that are not completed by the end of the sprint are reviewed during the 1 week of sprint planning. 22 | 23 | * There is no working overtime. There can be no death marches. Engineers are put on a regular cadence of work and allowed sufficient time to recharge their brains. Management overhead is minimal. 24 | 25 | That's pretty much the whole system. It can be modified to suit your purposes. But if there's one differentiator to Agile Lite I'd like to point out, it's that we are explicitly saying, "Hey, agile teams are burning out just as much as other development methodologies, maybe we need to build explicit rules in to prevent overheating the engine that is the engineering team." 26 | 27 | Let's stop overheating our engines. There's plenty of work to do out there. A pit without bottom, in fact. But life is too short to spend it all working, stressed, and ultimately burned out. 28 | 29 | --- 30 | If you would like to see more workplaces implement a system such as this, please star this repo on github and share on social media to increase visibility. 31 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 32 | -------------------------------------------------------------------------------- /agile_lite_for_managers.md: -------------------------------------------------------------------------------- 1 | # Agile Lite for managers 2 | 3 | Has working with software developers been a challenge at your company? Have you seen projects that consistently miss deadlines? Have you worked with developers that start out great and then slowly decline and then disappear? You may simply be dealing with a talented developer that experienced burnout on your project. 4 | 5 | Burnout is extremely common in the software industry and is a key reason many software projects fail. Burnout can maybe best be described as symptoms of Post Traumatic Stress Disorder that are connected to a given project or organization. For instance, your brain might shut off and you might become extremely anxious at the mere mention of a certain project. This is burnout. A developer in such a state will likely be unable to continue working on that project and may experience diminished productivity on their next several projects as well. Burnout can cripple careers. 6 | 7 | There are many reasons for burnout, but the most basic reason is that it is the result of working too much, under too much stress, for too long. 8 | 9 | It is like running a car engine at high RPMs for a very long time without adding oil or gas. Eventually that engine will break and it will be hard to put it back together. 10 | 11 | I'm proposing a solution. It's a form of agile that's explicitly designed to help avoid burnout. I call it Agile Lite. 12 | 13 | * The most basic rule is this: Every cycle includes a 3 week sprint and 1 week "off" where sprint planning is done. 3 weeks on/1 week off. 14 | 15 | * A sprint contains Issues and engineers solve Issues, logging pertinent questions and updates to the Issue Tracker. 16 | 17 | * An issue is any unit of work that should take 4-8 hours of engineering effort. An issue is either in the current sprint or in the backlog. 18 | 19 | * Once a sprint has begun, Issues may not be added to the sprint, but they can be removed. This reduces context switching and that is a good thing. 20 | 21 | * Any Issues in the current sprint that are not completed by the end of the sprint are reviewed during the 1 week of sprint planning. 22 | 23 | * There is no working overtime. There can be no death marches. Engineers are put on a regular cadence of work and allowed sufficient time to recharge their brains. Management overhead is minimal. 24 | 25 | That's pretty much the whole system. It can be modified to suit your purposes. But if there's one differentiator to Agile Lite I'd like to point out, it's that we are explicitly saying, "Hey, agile teams are burning out just as much as other development methodologies, maybe we need to build explicit rules in to prevent overheating the engine that is the engineering team." 26 | 27 | Let's stop overheating our engines. There's plenty of work to do out there. A pit without bottom, in fact. But life is too short to spend all of it working, stressed, and ultimately burned out. 28 | 29 | --- 30 | If you would like to see more workplaces implement a system such as this, please star this repo on github and share on social media to increase visibility. 31 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 32 | -------------------------------------------------------------------------------- /chinese/README.md: -------------------------------------------------------------------------------- 1 | # 精简版敏捷：敏捷而不会有丝毫倦怠 2 | 3 | 「敏捷软件开发」是个很好的主意，但是被出版商和咨询机构过度复杂化了。精简版敏捷（Agile Lite）旨在简化这种情况。你不需要一本书或者开一个研讨会才能解释清楚精简版敏捷。你只需要一个包含几个段落的文档文件，而这就是那个文档文件。 4 | 5 | 精简版敏捷是相当简单的。它能够被应用到任何工作项目上，只要这个工作能够被拆成更小的任务组件，我们将这些任务组件称为事项（Issues）。像其它敏捷方法论一样，精简版敏捷也使用较短的开发周期，我们称之为冲刺（Sprints）。有点独特的是，精简版敏捷明确承认软件开发行业普遍存在职业倦怠，并且试图通过 3 周开发／1 周不开发的周期来缓解这种情况。 6 | 7 | 基本步骤如下： 8 | 9 | * 每个周期的第一周用于项目负责人、开发者和其它业务方定义即将到来的`冲刺`。尽管分配了一周，但是如果顺利的话，冲刺计划会议不应该超过 2 小时，可能只需要 45 分钟左右。这是故意轻松的一周，许多人可能会抽出时间去画画、冲浪或者其他什么事情。 10 | 11 | * `冲刺`在周期的后三周里面进行。在这期间，工程师完成在冲刺计划会议上分配给自己的事项。因为团队可能是完全远程的，成员分布在各个时区，「实时」会议可能不会经常进行，大多数沟通可能通过`事项跟踪系统`（它用起来比电子邮件系统更快）来进行。一个类似于 Trello 的共享看板就是一个很好的事项跟踪系统，而电子表格就不是。不鼓励每日站会；通过查看事项跟踪系统的更新，就能获得项目的基本进度。 12 | 13 | * 一旦`冲刺`开始，就不能往里面新增事项，但是可以移除事项。这减少了上下文切换，是一件好事情。 14 | 15 | * 在冲刺期间未完成的事项，将在下一个冲刺计划会议中进行审核，并决定是将它加入到下一个冲刺，还是将其重新放回 Backlog，还是将其重新分配给其他开发者。 16 | 17 | * 一个事项要么在 `backlog` 里面，要么在`当前冲刺`里面。 18 | 19 | * 如上所述，我们鼓励开发者在计划周的期间里放松一下，让他们的大脑从之前的冲刺中恢复过来。这里没有死亡竞赛。开发者在周末不工作。这一切都有助于避免倦怠，而避免倦怠对每个人都有好处。 20 | 21 | 虽然大部分工作可以在给定冲刺里面被安排好，但有时确实会发生意外。这些意外事项称为`支持事项`。 22 | 23 | 我们建议在冲刺计划期间为团队中的某些成员分配属于不可预期的支持事项的时间。例如，「戴维在下一个冲刺期间有 12 个小时可以被用于支持事项（具体内容将在后面定义）。」轮流在冲刺期间承担支持事项同时对整个团队是有益的。 24 | 25 | 为了提高估计的准确性，在每个冲刺计划会议中，都会检查在上一个冲刺中实际完成的支持工作量，并确定在下一个冲刺中是否需要*增加*还是*减少*用于支持工作的时间。 26 | 27 | 在实践中，不同的团队对支持工作有不同的定义。也许这意味着支持客户。也许这意味着支持其他开发人员。您可以从这种通用方法论中选择那些和你的团队最合适的元素。 28 | 29 | 这就是精简版敏捷。它是一种更好的、更可持续的软件开发方式。它为软件开发人员提供支持，同时为项目利益相关者提供始终如一的可靠生产力。 30 | 31 | 想了解有关精简版敏捷的更多信息，我建议您阅读： 32 | 33 | [写给开发者的精简版敏捷](agile_lite_for_developers.md) 34 | 35 | [写给经理的精简版敏捷](agile_lite_for_managers.md) 36 | 37 | [经常被问到的问题](faq.md) 38 | 39 | --- 40 | 如果你想让更多的工作场所去实现这样的系统，请在 github 上为这个仓库加注星标并在社交媒体上分享 41 | 42 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 43 | -------------------------------------------------------------------------------- /chinese/agile_lite_for_developers.md: -------------------------------------------------------------------------------- 1 | # 写给开发者的精简版敏捷 2 | 3 | 如果你已经在软件行业里面工作了几年，那你很可能已经经历过职业倦怠。有很多原因会导致职业倦怠，最简单地说起来就是长期的每天长时间、大压力工作。 4 | 5 | 这开始于某个项目。这个项目有详细的说明文档和截止日期。当说明文档改变时，截止日期没有变。最终接近截止日期时，说明文档变得和它最初的模样不一样了。这当然这被认为是你的过错，你也总是被要求呆到很晚或者对这个「变形的目标」进行承诺。最终无论你工作有多努力，你周末也得加班、你的经理也一直不高兴、项目永远「落后于预期」。 6 | 7 | 想休假或者度假会让你看起来是一个懒鬼。这让你看起来是团队的支持者。也许你在一个开放的办公环境工作：每个人都知道你什么时候到和什么时候离开，每个人都对潜规则心知肚明————不能成为那个工作最不努力的人。所以大家都很擅长装作很忙，无论何时别人问你在干什么，你都是回答：“忙啊，我真的很忙！” 8 | 9 | 但是最终会有事情发生。也许你会换工作，但这很可能是软件行业的另一家公司。也许你会坚持下去，直到公司让你离开，因为你「和公司文化不匹配」。也许你会离开这个行业，找了个汽车销售的工作，因为编程太有挫败感了。正如某句话所说，扼杀业余爱好最好的办法，就是以此谋生。 10 | 11 | 我正提出一个解决方案。它是某种精心设计的，避免倦怠的敏捷形式，我称之为精简版敏捷。 12 | 13 | * 最基本的规则是：每个周期包含 3 周的冲刺和 1 周的冲刺计划后的「休息」。3 周开发／1 周不开发。 14 | 15 | * 一个冲刺会包含许多事项，工程师解决事项、记录相关问题并且在事项跟踪系统上更新。 16 | 17 | * 一旦冲刺启动，事项不可以再往里面添加，但可以从里面移出。这能减少上下文切换，是一件好事。 18 | 19 | * 事项是所有工作的基本单位，它需要工程师花 4~8 个小时的精力去完成。一个事项要么在当前冲刺中，要么在 backlog 里面。 20 | 21 | * 任何在当前冲刺结束时还未完成的事项，需要在下 1 周的冲刺计划会上进行检查回顾。 22 | 23 | * 没有任何加班费。没有死亡竞赛。工程师定时工作，并且有充足的时间给大脑充电。最小化的管理开销。 24 | 25 | 这就是这个系统的所有东西。它能够按你的目的修改。但是如果要说精简版敏捷的一大特点的话，那就是我们明确地说，“敏捷和许多其它开发方法一样，正在燃烧殆尽，也许我们需要建立明确的规则来防止工程团队的引擎过热。” 26 | 27 | 让我们停止过度加热我们的引擎。有许多工作需要做，但这是一个深不见底的坑。短暂的人生如果全用来在压力下工作，那最终我们就会倦怠。 28 | 29 | --- 30 | 如果你想让更多的工作场所去实现这样的系统，请在 github 上为这个仓库加注星标并在社交媒体上分享 31 | 32 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 33 | -------------------------------------------------------------------------------- /chinese/agile_lite_for_managers.md: -------------------------------------------------------------------------------- 1 | # 写给经理的精简版敏捷 2 | 3 | 在你的公司里面，和软件开发者合作是一个挑战吗？你是否看到过一直延期的项目？你是否曾与那些一开始很好然后慢慢热情降低，最后消失的开发人员合作过？你可能只是在这个项目中和一个经历倦怠的天才开发者打交道。 4 | 5 | 职业倦怠在软件行业中非常普遍，这是许多软件项目失败的关键原因。对于职业倦怠可能最好的描述是，它是一种和特定项目或组织有关的创伤后应激障碍的症状。例如，只要一提到某个项目，你就会大脑宕机，变得非常焦虑。这是倦怠。处于这种状态的开发者可能无法继续从事该项目，并且可能会在接下来的几个项目中降低生产力。职业倦怠会对职业生涯造成伤害。 6 | 7 | 有很多种原因会导致职业倦怠，但是最基本地来说就是每天工作时间太长、工作压力太大，而且是长期这样。 8 | 9 | 这就像在高转速下运行，而且长时间不加油或不加气的汽车引擎。最终，引擎会破裂，并且很难将它重新组合在一起。 10 | 11 | 我正提出一个解决方案。它是某种精心设计的，避免倦怠的敏捷形式，我称之为精简版敏捷。 12 | 13 | * 最基本的规则是：每个周期包含 3 周的冲刺和 1 周的冲刺计划后的「休息」。3 周开发／1 周不开发。 14 | 15 | * 一个冲刺会包含许多事项，工程师解决事项、记录相关问题并且在事项跟踪系统上更新。 16 | 17 | * 事项是所有工作的基本单位，它需要工程师花 4~8 个小时的精力去完成。一个事项要么在当前冲刺中，要么在 backlog 里面。 18 | 19 | * 一旦冲刺启动，事项不可以再往里面添加，但可以从里面移出。这能减少上下文切换，是一件好事。 20 | 21 | * 任何在当前冲刺结束时还未完成的事项，需要在下 1 周的冲刺计划会上进行检查回顾。 22 | 23 | * 没有任何加班费。没有死亡竞赛。工程师定时工作，并且有充足的时间给大脑充电。最小化的管理开销 24 | 25 | 这就是这个系统的所有东西。它能够按你的目的修改。但是如果要说精简版敏捷的一大特点的话，那就是我们明确地说，“敏捷和许多其它开发方法一样，正在燃烧殆尽，也许我们需要建立明确的规则来防止工程团队的引擎过热。” 26 | 27 | 让我们停止过度加热我们的引擎。有许多工作需要做，但这是一个深不见底的坑。短暂的人生如果全用来在压力下工作，那最终我们就会倦怠。 28 | 29 | --- 30 | 如果你想让更多的工作场所去实现这样的系统，请在 github 上为这个仓库加注星标并在社交媒体上分享 31 | 32 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 33 | -------------------------------------------------------------------------------- /chinese/faq.md: -------------------------------------------------------------------------------- 1 | # 精简版敏捷：经常被问到的问题 + 断言 2 | 3 | > 关于敏捷，唯一达成一致的是每个人都做错了。@fwip 4 | 5 | ## 经常被问到的问题 6 | 7 | > 所以你告诉我工程师每年可以休息 12 周去冲浪和画画？在一个 996 正在成为常态的世界里，它会有用吗？ 8 | 9 | 我认为你的团队应该尽可能多地休假。 10 | 11 | 我要指出，每周工作 40 小时曾被认为是一个激进的想法。谷歌已经尝试只将其中的 80％ 用于工作，我们在这里只是将其设置为 75％，我想在 21 世纪 20 年代末将其降低到 10％（Ferris 方法） 12 | 13 | 996（早上 9 点到晚上 9点，一周 6 天）完全是另一个方向，它想把每周 40 小时工作延长到每周 72 小时。我认为这会有一个回归，人们应该停止长时间工作的迷恋。它实际上并没有更高效。 14 | 15 | 也是由你决定「休假」的一周是用来度假还是做轻松的工作或其他任何事情。答案可能取决于具体的一周。 16 | 17 | 也许「轻松周」比「休息周」更对某些人的胃口。使用你更喜欢的一个就好。 18 | 19 | 冲浪和画画绝不是必需的，它们仅仅被用来作为例子。事实上，我既不冲浪也不画画。 20 | 21 | > 人们在冲刺中对事项进行*承诺*还是他们*预测*事项在这个冲刺中将会由他完成？ 22 | 23 | 他们只是预测。如果你估计得太短而实际没完成，那不是道德上的失败。这是整个过程的一部分，每个人都在同一个团队里面。 24 | 25 | > 我们能将冲刺称之为迭代吗？ 26 | 27 | 当然可以！我只是自己使用「冲刺」这个词。 28 | 29 | > 我们可以进行看板式滚动迭代，其中开始日期和结束日期根据具体情况各不相同吗？ 30 | 31 | 我非常重视工作周期的概念，它具有规定的开始日期和停止日期，并由单个任务块定义。滚动迭代不能和特定日期同步会使其混乱。 32 | 33 | > 为什么冲刺是 3 周？ 34 | 35 | 因为开发工作加上恢复时间要和每年 13 个插槽匹配。当周期结束时，开始新的周期。「休息周」允许在新冲刺开始之前重置。它和实现节奏、清晰且一致的间隔有关。 36 | 37 | > 这是否意味这冲刺的开始日期和结束日期经常在一个月的中间？ 38 | 39 | 是的。 40 | 41 | > 开发人员是否参与冲刺计划会议？ 42 | 43 | 他们没有被禁止参加会议。他们只是不需要参加，特别是如果他们保持关注当前的问题跟踪系统，并且团队已经在上一个冲刺过程中讨论了一些下一个冲刺的东西时。 44 | 45 | 我只是为了减少会议。你是一个稀少的喜欢开会的人吗？只要我没必要参加，但是不要因为我而阻止你参加。 46 | 47 | > 它是否真的需要一种去计划一个冲刺？ 48 | 49 | 不，不是这个意思。它是轻松的一周。 50 | 51 | > 站会真的是个问题吗？ 52 | 53 | 根据我的经验，是的。通常每个人都站成一个圈，听一个人讲 20 分钟。当然，这是「错误的站会做法」，但我没有看到任何团队做得对，而且我很快就不会这样做了。当你拥有地理位置分散的团队时，这样做也会更难（至少更不方便）。但是如果站会是你的事情并且你从它身上获得了很多价值，那就不要让我阻止你。 54 | 55 | > 我们只能按这样做吗？ 56 | 57 | 不。没有人能强迫你做任何事。这只是指导指南，而不是教条规则。 58 | 59 | 这不是宗教。 60 | 61 | 只有在提倡每周工作 40 小时时才是政治性的。 62 | 63 | > 你是否意识到这个方法对你有用，但是可能对别人没用？ 64 | 65 | 当然我知道。 66 | 67 | ## 常见的断言 68 | 69 | > 你不应该估计时间，因估计时间永远也不可能。 70 | 71 | 估计应该被视为估计，而不是保证书。因此，如果超过了预估时间，那没关系。尽力而为，并且以 4 小时为增量进行估算。 72 | 73 | > 不应该相信开发人员，而且必须统计他们的所有时间，因为就这是工作的方式。 74 | 75 | 我真的不同意但没法很快地解释。我们在世界观方面存在根本差异。 76 | 77 | > 这不是敏捷。 78 | 79 | 这当然是敏捷，名字里面的敏捷也是名副其实的。 80 | 81 | > 这不会有用。 82 | 83 | 不做的话那确实不会有用。 84 | 85 | > 你正在做一个错误的敏捷。 86 | 87 | 不幸的是，敏捷存在的问题就是不可能被正确地实践。 88 | -------------------------------------------------------------------------------- /faq.md: -------------------------------------------------------------------------------- 1 | # Agile Lite: FAQ + Assertions 2 | 3 | > The only thing consistent about Agile is that everyone is doing it wrong. @fwip 4 | 5 | ## Frequently Asked Questions 6 | 7 | > So you're telling me that engineers get 12 weeks off per year to surf and paint? How would that ever work in a world where 996 is becoming the norm? 8 | 9 | I think your team should take as much time off as it's comfortable with. 10 | 11 | I will point out that the 40 hour work week was once considered a radical idea. Google started 80% time, we're at 75% time here, I'd like to get that down to 10% time (the Ferris method) by the end of the 2020s. 12 | 13 | 996 (9am-9pm 6 days per week) is working on the other side of that, seeking to extend the 40 hour work week to a 72 hour work week. I see this as a regression and think people should stop fetishizing long hours. It's not actually more productive. 14 | 15 | It's also up to you whether the "week off" is a week for vacation or for a lighter work load or for whatever else. The answer might depend on the particular week. 16 | 17 | Maybe "light week" is easier for people to stomach than "week off". Use whichever you're more comfortable with. 18 | 19 | Surfing and painting are in no way required, they were merely cited as examples. In fact, I don't even surf OR paint. 20 | 21 | > Are people *committing* to issues in a sprint or are they *forecasting* the issues they'll get to in a sprint? 22 | 23 | They are forecasting. It is not a moral failing if your estimates are off. It's all part of the process and everyone's on the same team. 24 | 25 | > Can we call them iterations instead of sprints? 26 | 27 | Sure! I'm going to stick with "sprint" myself. 28 | 29 | > Can we do a kanban style rolling iteration where start dates and end dates vary and depend on circumstances? 30 | 31 | I really value the concept of the work cycle having a defined start date and stop date and being defined by a single block of tasks. Rolling iterations not synced to a specific cycle would mess that up. 32 | 33 | > Why 3 week sprints? 34 | 35 | Because development work plus recovery time then fits into 13 slots per year. When the cycle is over, a new cycle begins. The "week off" allows a reset before the new sprint begins. It's about achieving a cadence and having clear and consistent intervals. 36 | 37 | > Does this mean sprint start dates and end dates will often fall in the middle of the calendar month? 38 | 39 | Yes. 40 | 41 | > Are developers included in sprint planning? 42 | 43 | Yes. They are not banned from the meeting. They just don't need to attend, especially if they've kept the Issue Tracking System current and the team has discussed some of the items for the next sprint during the course of the previous sprint. 44 | 45 | I'm all for less meetings. Are you a rare person that enjoys meetings? As long as I don't have to attend, don't let me stop you. 46 | 47 | > Does it really take a week to plan a sprint? 48 | 49 | No, that's the point. It's a light week. 50 | 51 | > Are standups really a problem? 52 | 53 | In my experience, yes. It's usually everyone standing in a circle listening to one person talk for 20 minutes. Of course, this is "doing standups wrong", but I haven't seen any teams that do them right and I'd just as soon not do them at all. It is also harder (or at least more inconvenient) to do them when you have a geographically distributed team. But if standups are your thing and you get a ton of value from them, don't let me stop you. 54 | 55 | > Do we have to do it this way? 56 | 57 | No. Nobody is forcing you to do anything. They're guidelines, not rules. 58 | 59 | This is not a religion. 60 | 61 | It is political only in the sense that advocating a 40 hour work week was political. 62 | 63 | > Are you aware that what works for you might not work for others? 64 | 65 | I sure am! 66 | 67 | 68 | ## Frequent Assertions 69 | 70 | > You shouldn't estimate because estimates are impossible. 71 | 72 | Estimates are regarded as estimates, not as blood contracts. Therefore, if they are off, that's ok. Do the best you can and estimate in increments of 4 hours. 73 | 74 | > Developers cannot be trusted and must account for all their time because that's how work works. 75 | 76 | I really disagree but can't explain why quickly. We have a fundamental difference in world views. 77 | 78 | > This isn't agile. 79 | 80 | Sure it is, it's right there in the name. 81 | 82 | > This will never work. 83 | 84 | And yet it does. 85 | 86 | > You're doing agile wrong. 87 | 88 | Unfortunately the problem with agile is that it cannot be done correctly. 89 | -------------------------------------------------------------------------------- /german/README.md: -------------------------------------------------------------------------------- 1 | # Agile Lite: Agil ohne auszubrennen 2 | 3 | "Agile Softwareentwicklung" ist eine großartige Idee, die leider von vielen Autoren und Beratern zu kompliziert dargestellt wird. Mit `Agile Lite` soll versucht werden dieses Prinzip wieder einfacher zu gestalten. Du brauchst weder ein Buch noch einen Workshop um Agile Lite zu erklären. Du benötigst nur einen kurzen Text mit ein paar Paragraphen - diesen Text. 4 | 5 | Agile Lite ist ein simples Prinzip. Es kann auf auf jedes Projekt angewendet werden, an dem Personen gemeinsam arbeiten, vorausgesetzt die Arbeit kann ich kleinere Aufgabenblöcke unterteilt werden ("Issues"). Wie andere agile Methoden benutzt Agile Lite kurze Entwicklungszyklen, so genannte "Sprints". Dabei wird ausdrücklich berücksichtigt, dass in der Softwareindustrie die Gefahr eines Burn-out besteht. Es wird versucht diesem Problem mit einem Entwicklungszyklus zu begegnen, der drei aktive Projektwochen und eine Woche ohne direkten Projektbezug vorsieht. 6 | 7 | Die grundlegenen Prinzipien sind: 8 | 9 | * Die erste Woche jedes Entwicklungszyklus wird damit verbracht dass sich Projektleiter, Entwickler und andere am Projekt beteiligte Personen damit auseinandersetzen welche Ziele für den nächsten `Sprint`definiert werden. Obwohl eine ganze Woche dafür reserviert wird, sollte diese Sprintplanung nicht mehr als zwei Stunden in Anspruch nehmen (vermutlich ca 45 Minuten, wenn es richtig gemacht wird). Die Woche ist absichtlich ohne Ziele geplant und viele Menschen nutzen sie einfach als Auszeit um zu Malen, Wandern oder für anderen Aktivitäten. 10 | 11 | * Der eigentliche `Sprint`wird in den verbleibenden drei Wochen des Zyklus durchgeführt. Während dieser Zeitspanne arbeiten Entwickler an den Aufgaben, die ihnen während der Planungsphase zugewiesen wurden. Da das Team auf verschiedene Standorte in verschiedenen Zeitzonen verteilt sein könnte, kann es schwierig sein gemeinsamen Meetings zu organisieren. Aus diesem Grund finden Meetings eher unregelmäßig statt und der Großteil der Kommunikation erfolgt durch das `Issue Tracking System` (welches eine schnellere Verständigung erlaubt als durch E-Mails). Ein geteiltes Kanban-Board wie Trello kann als Tracking System ausreichend sein, ein Tabellenblatt ist es vermutlich nicht. Tägliche Standups sind nicht mehr zwingend nötig, da der aktuelle Status des Projekts schnell durch das Tracking System ermittelt werden kann. 12 | 13 | * Sobald ein `Sprint`begonnen hat, dürfen keine weiteren Issues zum Sprint hinzugefügt werden - es dürfen aber bestehende Issues entfernt werden. Dieses Vorgehen reduziert das Wechseln des Kontext und das ist eine gute Sache. 14 | 15 | * Issues, die nicht während des geplanten Sprints erledigt wurden, werden in der nächsten Planungsrunde einem Review unterzogen, um zu entscheiden, ob die Aufgabe für den nächsten Sprint eingeplant, in den Backlog verschoben oder einem anderen Entwickler zugeordnet wird. 16 | 17 | * Ein Issue ist entweder im `Backlog`oder im `aktuellen Sprint`. 18 | 19 | * Wie bereits erwähnt sollen Entwickler ermutigt werden es während der Planungswoche leichter angehen zu lassen. Dadurch soll dem Gehirn die Möglichkeit gegeben werden sich vom vorherigen Sprint zu erholen. Es gibt keine Todesmärsche. Es wird nicht am Wochenende gearbeitet. All diese Festlegungen sollen dabei helfen die Teammitglieder vor einem Burn-out zu bewahren - was am Ende gut für das ganze Team ist. 20 | 21 | Zwar kann der Großteil der Arbeit in einem Sprint geplant werden, trotzdem kommt es immer wieder zu unerwarteten Zwischenfällen. Diese ungeplanten Aufgaben werden `Support Issues`genannt. 22 | 23 | Wir empfehlen für einige Teammitglieder feste Zeitspannen während des Sprints zu planen, in denen sie sich diesen unplanbaren Support Issues widmen können. Beispielsweise kann festgelegt sein: "Dave hat während des nächsten Sprints 12 Stunden Zeit für Support Issues, die erst später definiert werden." Meist ist es von Vorteil, wenn diese Verantwortung mit jedem Sprint an andere Teammitglieder weitergegeben wird. 24 | 25 | Für die Planungsrunde werden Aufwandsschätzungen für die Support Issues benötigt. Um die Genauigkeit dieser Schätzungen zu erhöhen, wird in jeder Planungsrunde rekapituliert wie viel Arbeit im letzten Sprint tatsächlich für diese Aufgaben aufgewendet wurde. Anhand dieses Werts wird entschieden, ob im nächsten Sprint *mehr* oder *weniger* Zeit für Support Issues eingeplant wird. 26 | 27 | In der Realität haben unterschiedliche Teams verschiedene Definitionen für "Support Issue". Vielleicht bedeutet es Support für Kunden. Vielleicht heißt es einen anderen Entwickler zu unterstützen. Es liegt an Ihnen zu entscheiden welche Definition dieser generellen Methode am besten für ihr Team angewendet werden kann. 28 | 29 | Das war's. Agile Lite ist ein besserer, nachhaltigerer Weg um Software zu entwickeln. Es bietet den Entwicklern mehr Freiheiten und liefert dabei trotzdem einen konstanten Level an Produktivität. 30 | 31 | Um mehr über Agile Lite zu lernen, empfehle ich Ihnen folgende Texte: 32 | 33 | [Agile Lite für Entwickler](agile_lite_for_developers.md) 34 | 35 | [Agile Lite für Manager](agile_lite_for_managers.md) 36 | 37 | [Frequently Asked Questions](faq.md) 38 | 39 | 40 | --- 41 | Wenn du mehr Teams dabei helfen willst dieses System kennenzulernen und umzusetzen, gib diesem Repo bitte einen Stern auf Github und teile es in den sozialen Medien um die Sichtbarkeit zu erhöhen. 42 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 43 | -------------------------------------------------------------------------------- /german/agile_lite_for_developers.md: -------------------------------------------------------------------------------- 1 | # Agile Lite für Entwickler 2 | 3 | Wenn du bereits ein paar Jahre in der Softwareindustrie gearbeitet hast, hast du vermutlich schon Erfahrungen mit einem Burn-out gemacht. Es gibt viele Gründe für einen Burn-out, meist steht es aber in Verbindung mit zu viel Arbeit unter zu viel Stress über einen zu langen Zeitraum. 4 | 5 | Es beginnt mit einem Projekt. Das Projekt hat detaillierte Spezifikationen und eine Deadline. Wenn sich die Spezifikation ändert, ändert sich nicht die Deadline. Irgendwann kommt und geht die Deadline und die Spezifikation verwandelt sich langsam in etwas völlig anderes als ursprünglich geplant war. Natürlich wird das als dein Fehler gesehen, du wirst aufgefordert länger zu bleiben oder sich zu "Stretch goals" zu verpflichten. Früher oder später arbeitest du auch an den Wochenenden, aber völlig egal wie viel Arbeit du investierst, dein Manager ist niemals zufrieden und das Projekt ist immer "hinter dem Zeitplan." 6 | 7 | Nach Urlaub zu fragen lässt dich wie einen Faulpelz aussehen. Es scheint dann, als würdest du das ganze Team aufhalten. Vielleicht arbeitest du in einem "Open Office", sodass jeder weiß wann du kommst und gehst. Es gibt eine unausgesprochene Vereinbarung, niemand will die Person sein die "am wenigsten" arbeitet. Deine Kollegen werden gut darin beschäftigt auszusehen und immer wenn dich jemand fragt wie es läuft, antwortest du: "Ok, aber ich bin so unglaublich viel zu tun!" 8 | 9 | Bis irgendwann irgendetwas nachgibt. Vielleicht wechselst du den Job, aber bei den anderen Firmen in der Softwareindustrie läuft es genauso. Vielleicht hälst du durch bis du einfach nicht mehr weiter kommst und die Firma entlässt dich, weil du "einfach nicht zur Firmenkultur passt". Vielleicht kündigst du und wechselst den Beruf, weil Entwicklung so unglaublich frustrierend ist. Wie die Leute immer sagen, wenn den Spaß aus deinem Hobby entfernen willst, mach es zu deinem Beruf. 10 | 11 | Ich schlage dir eine Lösung vor. Eine Form von agiler Entwicklung, die explizit dafür entworfen wurde Burn-out zu verhindern. Ich nenne es "Agile Lite": 12 | 13 | * Die Grundregel ist: Jeder Zyklus enthält drei Wochen Sprint und eine Woche "Auszeit", in der die Sprintplanung erledigt wird. Drei Wochen Arbeit, eine Woche Auszeit. 14 | 15 | * Ein Sprint enthält Issues. Entwickler arbeiten an diesen Issues, hinterlegen auftretende Fragen und verzeichnen Aktualisierungen im Issue Tracker. 16 | 17 | * Sobald ein Sprint begonnen hat, dürfen keine weiteren Issues zum Sprint hinzugefügt werden - es dürfen aber bestehende Issues entfernt werden. Dieses Vorgehen reduziert das Wechseln des Kontext und das ist eine gute Sache. 18 | 19 | * Ein Issue ist eine Arbeitseinheit und sollte 4 bis 8 Stunden an Aufwand erfordern. Ein Issue ist entweder im Backlogoder im aktuellen Sprint. 20 | 21 | * Jeder Issue der im aktuellen Sprint geplant ist aber nicht beendet wird, wird in nächsten Sprintplanung noch einmal analysiert und einem Review unterzogen. 22 | 23 | * Es gibt keine Überstunden. Es gibt keine Todesmärsche. Entwickler leisten ihre Arbeit in der regulären Arbeitszeit und bekommen die Möglichkeit den Kopf wieder freizukriegen. Die Mehrarbeit durch das Management wird minimal gehalten. 24 | 25 | Das ist eigentlich schon das ganze System. Es kann natürlich so angepasst werden, dass es deinen Bedürfnissen genügt. Es gibt allerdings ein Alleinstellungsmerkmal in "Agile Lite", das ich gern noch einmal betonen würde: wir sagen explizit: "Hey, agile Teams brennen genauso schnell aus wie mit anderen Entwicklungsmethoden, wir brauchen konkrete Regeln um zu verhindern, dass die Maschine - das Team - überhitzt!" 26 | 27 | Wir sollten aufhören unsere Maschinen zu überhitzen. Es gibt mehr als genug Arbeit, die auf uns wartet. Unendlich viel, wenn man es genau nimmt. Aber das Leben ist zu kurz um es nur mit Arbeit und Stress zu füllen und davon krank zu werden. 28 | 29 | --- 30 | Wenn du mehr Teams dabei helfen willst dieses System kennenzulernen und umzusetzen, gib diesem Repo bitte einen Stern auf Github und teile es in den sozialen Medien um die Sichtbarkeit zu erhöhen. 31 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 32 | -------------------------------------------------------------------------------- /german/agile_lite_for_managers.md: -------------------------------------------------------------------------------- 1 | # Agile Lite für Manager 2 | 3 | Ist die Arbeit mit Softwareentwicklern eine Herausforderung in deiner Organisation? Beobachtest du immer wieder wie Projekte ihre Deadlines verfehlen? Hast du mit Entwicklern gearbeitet, die vielversprechend angefangen haben, mit der Zeit immer weniger produktiv wurden und irgendwann verschwunden sind? Vielleicht hattest du es einfach mit einem talentierten Entwickler zu tun, der an deinem Projekt Burn-out erlitten hat. 4 | 5 | Burn-out ist keine Seltenheit in der Softwareindustrie und einer der Hauptgründe, warum Projekte scheitern. Burn-out kann am besten als Symptome einer posttraumatischen Belastungsstörung beschrieben werden, die mit einem bestimmten Projekt oder einer Organisation verknüpft sind. Beispielsweise schaltest du mental sofort ab oder bekommst leichte Panik bei der bloßen Erwähnung des Projektnamens. Das ist Burn-out. In einem solchen Zustand ist ein Entwickler nicht mehr in der Lage produktiv am Projekt zu arbeiten, eventuell wird sogar seine Produktivität für nachfolgende Projekte beeinträchtigt. Burn-out kann Karrieren beenden. 6 | 7 | EEs gibt viele Gründe für einen Burn-out, meist steht es aber in Verbindung mit zu viel Arbeit unter zu viel Stress über einen zu langen Zeitraum. 8 | 9 | Es lässt sich mit einem Motor vergleichen, der über lange Zeit in einem Bereich mit hohen Drehzahlen gehalten wird, ohne Öl zuzugeben. Irgendwann wird der Motor brechen und dann ist es schwierig ihn wieder zusammenzusetzen. 10 | 11 | Ich schlage dir eine Lösung vor. Eine Form von agiler Entwicklung, die explizit dafür entworfen wurde Burn-out zu verhindern. Ich nenne es "Agile Lite": 12 | 13 | * Die Grundregel ist: Jeder Zyklus enthält drei Wochen Sprint und eine Woche "Auszeit", in der die Sprintplanung erledigt wird. Drei Wochen Arbeit, eine Woche Auszeit. 14 | 15 | * Ein Sprint enthält Issues. Entwickler arbeiten an diesen Issues, hinterlegen auftretende Fragen und verzeichnen Aktualisierungen im Issue Tracker. 16 | 17 | * Ein Issue ist eine Arbeitseinheit und sollte 4 bis 8 Stunden an Aufwand erfordern. Ein Issue ist entweder im Backlogoder im aktuellen Sprint. 18 | 19 | * Sobald ein Sprint begonnen hat, dürfen keine weiteren Issues zum Sprint hinzugefügt werden - es dürfen aber bestehende Issues entfernt werden. Dieses Vorgehen reduziert das Wechseln des Kontext und das ist eine gute Sache. 20 | 21 | * Jeder Issue der im aktuellen Sprint geplant ist aber nicht beendet wird, wird in nächsten Sprintplanung noch einmal analysiert und einem Review unterzogen. 22 | 23 | * Es gibt keine Überstunden. Es gibt keine Todesmärsche. Entwickler leisten ihre Arbeit in der regulären Arbeitszeit und bekommen die Möglichkeit den Kopf wieder freizukriegen. Die Mehrarbeit durch das Management wird minimal gehalten. 24 | 25 | Das ist eigentlich schon das ganze System. Es kann natürlich so angepasst werden, dass es deinen Bedürfnissen genügt. Es gibt allerdings ein Alleinstellungsmerkmal in "Agile Lite", das ich gern noch einmal betonen würde: wir sagen explizit: "Hey, agile Teams brennen genauso schnell aus wie mit anderen Entwicklungsmethoden, wir brauchen konkrete Regeln um zu verhindern, dass die Maschine - das Team - überhitzt!" 26 | 27 | Wir sollten aufhören unsere Maschinen zu überhitzen. Es gibt mehr als genug Arbeit, die auf uns wartet. Unendlich viel, wenn man es genau nimmt. Aber das Leben ist zu kurz um es nur mit Arbeit und Stress zu füllen und davon krank zu werden. 28 | 29 | --- 30 | Wenn du mehr Teams dabei helfen willst dieses System kennenzulernen und umzusetzen, gib diesem Repo bitte einen Stern auf Github und teile es in den sozialen Medien um die Sichtbarkeit zu erhöhen. 31 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 32 | -------------------------------------------------------------------------------- /german/faq.md: -------------------------------------------------------------------------------- 1 | # Agile Lite: FAQ + Behauptungen 2 | 3 | > "Das einzige was sich an Agile nicht ändert ist, das es alle falsch machen." @fwip 4 | 5 | ## Häufig gestellte Fragen 6 | 7 | > Du willst mir also erklären, dass Entwickler 12 Wochen im Jahr bekommen um zu wandern und zu malen? Wie sollte das jemals funktionieren in einer Welt, in der 996 zur Normalität wird? 8 | 9 | Ich finde, ein Team sollte sich so viel Auszeit nehmen, wie sie mit sich vereinbaren können. 10 | 11 | Ich möchte darauf hinweisen, dass die 40-Stunden-Woche früher als radikale Idee abgetan wurde. Google hat angefangen auf 80%-Zeit zu setzen, wir arbeiten mit 75%-Zeit, ich würde es sogar gern bis 2030 auf 10% (die Ferris-Methode) senken. 12 | 13 | 996 ( 9-21 Uhr, 6 Tage pro Woche) setzt auf der anderen Seite dieser Idee an, mit dem Ziel die 40-Stunden-Woche auf 72 Stunden pro Woche zu erhöhen. Ich betrachte das als Rückschritt, wir sollten aufhören lange Arbeitszeiten zu fetischisieren. Es ist nicht produktiver. 14 | 15 | Es liegt außerdem bei dir, ob die Woche Auszeit eine Urlaubswoche ist, oder eine Woche für leichtere Arbeiten oder für was auch immer. Die Antwort kann sich auch von Woche zu Woche unterscheiden. 16 | 17 | Vielleicht ist es einfacher von einer "leichten Woche" zu sprechen, statt von einer "Auszeit". Benutze was auch immer dir lieber ist. 18 | 19 | Malen und Wandern sind keine Notwendigkeiten, sondern wurden nur als Beispiel genutzt. In Wahrheit mache ich weder das eine NOCH das andere. 20 | 21 | > Gehen die Teammitglieder für die Issues in einem Sprint eine Verpflichtung ein, oder ist es eher eine Ankündigung, dass sich diesen Themen im Sprint widmen möchten? 22 | 23 | Sie machen Ankündigungen. Es ist kein moralisches Versagen, wenn deine Schätzungen daneben liegen. Das ist alles Teil des Prozesses und alle sind im gleichen Team. 24 | 25 | > Können wir die Zyklen "Iterationen" anstelle von "Sprints" nennen? 26 | 27 | Natürlich! Für mich persönlich bleibe ich bei "Sprints". 28 | 29 | > Können wir im Kanban-Stil dynamische Iterationen verwenden, bei denen das Startdatum und das Enddatum je nach Umständen variieren? 30 | 31 | Ich lege sehr viel Wert auf das Konzept eines Arbeitszyklus mit fest definiertem Start und Ende, sowie einem festgelegten Blick an Aufgaben. Dynamische Iterationen, die nicht fest mit einem spezifischen Zyklus synchronisiert sind, würden das behindern. 32 | 33 | > Warum 3-Wochen-Sprints? 34 | 35 | Weil die Entwicklungsarbeit mitsamt der Auszeit dann in 13 Blöcke pro Jahr passt. Wenn ein Zyklus vorbei ist, beginnt ein neuer Zyklus. Die "Auszeit" erlaubt einen Neustart bevor der neue Sprint beginnt. Es geht darum einen Rythmus zu schaffen, mit klaren und konsistenten Intervallen. 36 | 37 | > Bedeutet das, dass die Start- und Endzeiten eines Sprints oft in die Mitte eines Kalendermonats fallen? 38 | 39 | Ja. 40 | 41 | > Werden Entwickler in die Sprintplanung einbezogen? 42 | 43 | Ja. Sie werden von diesem Meeting nicht ausgeschlossen. Sie werden allerdings auch nicht gezwungen teilzunehmen, besonders wenn sie ihren Status im Issue Tracker-System auf dem aktuellen Stand gehalten haben und das Team bereits einige der anstehenden Aufgaben des nächsten Sprints im Verlauf des letzten Sprints besprochen hat. 44 | 45 | Ich bin dafür die Anzahl an Meetings zu reduzieren. Bist du eine der wenigen Personen, die Meetings als Spaß empfindet? Dann lass dich von mir nicht aufhalten, so lange ich nicht am Meeting teilnehmen muss. 46 | 47 | > Braucht es wirklich eine Woche um einen Sprint zu planen? 48 | 49 | Nein, das ist genau der Punkt. Es ist eine leichte Woche. 50 | 51 | > Sind Standups wirklich ein Problem? 52 | 53 | Meiner Erfahrung nach: ja. Üblicherweise stehen alle in einem Kreis und hören einer Person zu, die für 20 Minuten redet. Selbstverständlich ist das "die falsche Art einen Standup durchzuführen", aber ich habe noch kein Team gesehen, das es richtig gemacht hat und dann kann ich es auch lassen. Es ist außerdem schwieriger (oder zumindest unpraktischer) wenn du ein geografisch verstreutes Team has. Aber wenn Standups dein Ding sind und du dabei eine Menge gewinnst, lass dich von mir nicht aufhalten. 54 | 55 | > Müssen wir das so machen? 56 | 57 | Nein. Niemand zwingt dich irgendetwas zu machen. Das sind Richtlinien, keine Regeln. 58 | 59 | Das ist keine Religion. 60 | 61 | Es ist nur in der Hinsicht politisch, dass die Befürwortung der 40-Stunden-Woche politisch ist. 62 | 63 | > Bist du dir im Klaren darüber, dass das was für dich funktioniert vielleicht nicht für andere funktioniert? 64 | 65 | Das bin ich! 66 | 67 | 68 | ## Häufige Behauptungen 69 | 70 | > Du solltest nichts schätzen, denn Schätzungen sind unmöglich. 71 | 72 | Schätzungen werden als Schätzungen betrachtet, nicht als Blutverträge. Daher ist es in Ordnung, wenn sie daneben liegen. Gib dein Bestes und schätze in Schritten von 4 Stunden. 73 | 74 | > Entwicklern kann nicht vertraut werden, sie müssen für ihre Zeit Rechenschaft ablegen, so funktioniert Arbeit. 75 | 76 | Ich bin völlig anderer Meinung, aber ich kann nicht in ein paar Sätzen erklären, warum. Wir haben fundamental verschiedene Weltanschauungen. 77 | 78 | > Das ist nicht agil. 79 | 80 | Natürlich ist es das, es steht doch im Namen. 81 | 82 | > Das wird niemals funktionieren. 83 | 84 | Und trotzdem funktioniert es. 85 | 86 | > Du benutzt Agile falsch. 87 | 88 | Unglücklicherweise ist das Problem mit Agile, dass es nicht korrekt gemacht werden kann. 89 | -------------------------------------------------------------------------------- /japanese/README.md: -------------------------------------------------------------------------------- 1 | # アジャイル ライト: 燃え尽きないアジャイル 2 | 3 | 「アジャイルソフトウェア開発」は非常に良い概念であるが、出版業界やコンサルティング業界によって過度に複雑にされてきた。 4 | アジャイル ライトはこの状況をシンプルにしようという試みである。 5 | アジャイル ライトを説明するのに、本やワークショップはいらない。必要なのはこのようなテキストファイルだけである。 6 | 7 | アジャイル ライトは非常にシンプルである。この概念は作業がイシューと呼ばれる小さな構成要素に分割できるようなものであれば、どのようなプロジェクトにでも適用することができる。 8 | 他のアジャイル手法と同様に、アジャイル ライトはスプリントと呼ばれる短い開発サイクルを用いる。 9 | 多少独特な点としては、アジャイル ライトはソフトウェア開発に燃え尽き症候群はつきものであるということを明確に認め、3週間の稼働と1週間の休憩という開発サイクルを通して、直接的にその疲労を軽減しようと試みる点である。 10 | 11 | 基本的なステップは次の通りである: 12 | 13 | * 各開発サイクルの最初の週はプロジェクトリーダー、開発者、その他関係者で、直近の`スプリント`を定義する。 14 | このプランニングの週は一週間が割り当てられているものの、スプリントプランニングはたかだか2時間、適切に実行されれば、およそ45分で終わるものである。この最初の1週目は意図的に軽くしており、多くの人にとって絵を書くなりサーフィンをするなり、休憩の一週間となるかもしれない。 15 | 16 | * `スプリント`は開発サイクルの残りの三週間で行われる。この期間中、エンジニアはスプリントプランニングで割り当てられたイシューに取り組む。チームが完全にリモートだったり、別のタイムゾーンに散らばっていたりする場合もあるので、顔を合わせたミーティングというのは滅多に行われず、ほとんどのコミュニケーションは`イシュートラッキングシステム`によって行われることになる。（メールでコミュニケーションするより速い。）Trelloのような共有カンバンボードは十分なイシュートラッキングシステムと言えるが、一方でスプレッドシートは十分とは言えないだろう。また、デイリースタンドアップなどはお勧めできない。肝心なことはイシュートラッキングシステムの更新をレビューすることである。 17 | 18 | * 一度`スプリント`が始まったら、基本的にはイシューはスプリントに追加されることはないだろうが、取り除かれることはあり得る。これはコンテキストの切り替えを減らすので、良いことと言える。 19 | 20 | * そのスプリントで完了されなかったイシューは次のスプリントプランニングでレビューされ、次のスプリントで引き続き行うか、バックログに戻すか、あるいは他の開発者に割り当てらられるかが決定される。 21 | 22 | * イシューは`バックログ`か`現在のスプリント`にあるものとする。 23 | 24 | * 先に述べたように、開発者はプランニングの週に関しては、スプリントの疲れから脳を回復させるために、気軽に過ごすことが推奨される。そのため、死人の行進のようなことは起きないし、開発者は週末に働くこともない。これら全ては燃え尽き症候群を防ぐのに役に立つ。そして燃え尽き症候群を防ぐことは全ての人にとって良いことである。 25 | 26 | スプリント期間内の仕事のほとんどは事前に計画することができるものであるが、時には予期せぬ割り込みの作業も発生する。これらの予期せぬ割り込みは`サポートイシュー`と呼ばれる。 27 | 28 | 事前に計画することはできないサポートイシューは、スプリントプラニングの時点で、誰かチームの特定のメンバーに割り当てることを提案している。例えば「daveは次のスプリント期間中12時間はサポートイシューに使うことができる(そのサポートイシューの詳細については後々決まる)」というようにである。 29 | スプリント期間中にサポートイシューを担当する開発者を、ローテーションで変えていくという運用もしばしば効果的である。 30 | 31 | 見積もりの精度をあげるために、各スプリントプランニングでは、前のスプリントで実際に行われたサポートイシューの量がレビューされ、次のスプリントでは、サポートイシューに対して*より多くの*時間が必要なのか、あるいは*より少ない*時間が必要なのかが決定される。 32 | 33 | 実際の現場では、チーム毎にサポートイシューの定義は異なる。 34 | ユーザ/顧客をサポートする業務かもしれないし、他の開発者をサポートする業務かもしれない。 35 | この汎用的なサポートイシューの定義のどれをチームに適用するかを選ぶのは、チーム次第である。 36 | 37 | だいたいそんなところである。アジャイル ライトはソフトウェア開発をよりよく、より持続可能にするための手段である。 38 | そしてアジャイル ライトはソフトウェア開発者を支援しながら、継続的に安定したレベルの生産性をプロジェクトの関係者に提供するのである。 39 | 40 | アジャイル ライトをもっと学びたい場合は場合は下記のページも読むことを勧める。 41 | 42 | [開発者のためのアジャイル ライト](agile_lite_for_developers.md) 43 | 44 | [マネージャーのためのアジャイル ライト](agile_lite_for_managers.md) 45 | 46 | [よくある質問](faq.md) 47 | 48 | --- 49 | もしより多くの職場がこのような仕組みを実践することを願うのなら、このリポジトリにスターをつけて、SNSで拡散することで、多くの人の目につくようにしてください。 50 | 51 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 52 | -------------------------------------------------------------------------------- /japanese/agile_lite_for_developers.md: -------------------------------------------------------------------------------- 1 | # 開発者のためのアジャイル ライト 2 | 3 | もしあなたがソフトウェア開発業界で数年以上働いているのなら、きっと燃え尽き症候群を経験したことがあるだろう。 4 | 燃え尽き症候群には多くの原因があるが、多くの場合過度なストレスの下、長時間、莫大な仕事をこなした結果であると考えられる。 5 | 6 | 燃え尽き症候群はプロジェクトとともに始まる。プロジェクトには詳細な仕様と期限がある。たとえ仕様が変わったとしても、期限は変わらない。 7 | やがて期限は近づき、過ぎていって、当初の思惑とは異なるものが出来上がる。当然これはあなたの失敗とみなされ、遅くまで残業を求められたり、ちょっとやそっとのことでは達成できないような目標を約束させられる。 8 | ついには、あなたは毎週末職場に来て、どれだけ懸命に仕事をしたとしても、あなたの上司が満足することは決してなく、プロジェクトは永久に予定より遅れることとなる。 9 | 10 | 休憩や休暇が欲しい人は怠け者のように思える。あなたこそがチームを支える存在であるように思える。 11 | ひょっとするとあなたはこんなオープンな職場環境で働いているかもしれない。誰もがあなたが何時に出社し、何時に退勤しているかを知っていて、誰もが「もっともハードワークしない人にならない」という暗黙の契約書にサインしているような。 12 | そのため、皆忙しそうに見せるのはとてもうまく、いつ誰に何をしているのか聞かれても、ただ『忙しい！めっちゃ忙しい！』と返答するだけなのだ。 13 | 14 | しかし、やがては何かがおきるだろう。転職するかもしれないが、ソフトウェア業界においては他の多くの会社でも同様である。 15 | あなたは燃え尽きるまでやり抜くかもしれませんが、会社は「カルチャーフィットしなかった」という理由であなたを手放すのである。 16 | そして、あなたは会社を辞め、プログラミングはストレスが大きすぎるという理由で、車を売る仕事につくかもしれない。 17 | よく言われるように、もし趣味の楽しさを殺したいなら、それを生計を立てるためにやってみるとよいだろう。 18 | 19 | 私はここで解決策を提案する。それはアジャイルのようなものであり、明示的に燃え尽き症候群を防ぐように設計されたものである。 20 | 私はそれをアジャイル ライトと呼ぶ。 21 | 22 | * もっとも基本的なルールは次の通りである。： それぞれの開発サイクルは、3週間のスプリントと、スプリントプランニングが行われる一週間の休憩から構成される。 23 | つまり、3週間の稼働と1週間の休憩である。 24 | 25 | * スプリントにはイシューがあり、エンジニアはそのイシューを解決し、適切な疑問を記録してイシュートラッキングシステムを更新する。 26 | 27 | * 一旦スプリントが始まったら、基本的にはイシューはスプリントに追加されることはないが、取り除かれることはあり得る。これは頭の切り替えを減らすので、良いことである。 28 | 29 | * 一つのイシューは開発者が4-8時間かかる単位の作業である。イシューはバックログか現在のスプリントのどちらかにあるものとする。 30 | 31 | * スプリントの終わりまでに完了しなかったイシューは全て、一週間のスプリントプランニングの間にレビューされる。 32 | 33 | * アジャイル ライトにおいては残業はない。そのため、死人の行進のようなことは起こり得ない。開発者は同じペースで開発し、脳を回復させる十分な時間が与えられる。管理コストも最小になる。 34 | 35 | だいたいそんなところである。これはそれぞれのチームの目的に合うように修正され得るものである。しかし、もしアジャイル ライトの差別化要因を一つあげるとするならば、それは私たちが明示的に言っている 36 | 「アジャイルなチームも他の開発手法と同様に燃え尽きることがある。私たちはエンジニアチームにあるエンジンを加熱し過ぎないように、明示的なルールを作る必要があるかもしれない。」ということである。 37 | 38 | エンジニアチームのエンジンを加熱しすぎはやめよう。どうせやることはいっぱいある。底なしの地獄なのである。 39 | 働いて、ストレスを感じて、やがて燃え尽きるのに時間を使うのには、人生は短すぎる。 40 | 41 | --- 42 | もしより多くの職場がこのような仕組みを実践することを願うのなら、このリポジトリにスターをつけて、SNSで拡散することで、多くの人の目につくようにしてください。 43 | 44 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 45 | -------------------------------------------------------------------------------- /japanese/agile_lite_for_managers.md: -------------------------------------------------------------------------------- 1 | # マネージャーのためのアジャイル ライト 2 | 3 | あなたの会社ではソフトウェア開発者と仕事することは大変だっただろうか。 4 | 常に期限を守れないプロジェクトを見たことがあるだろうか。 5 | 最初は素晴らしかったが、徐々に衰退し、やがて消えた開発者と働いたことはあるだろうか。 6 | マネジメントしているプロジェクトで、能力があるのに燃え尽きてしまったエンジニアの対応に迫られているのではないだろうか。 7 | 8 | 燃え尽き症候群というものはソフトウェア業界では非常によくあることで、これは多くのソフトウェアプロジェクトが失敗する主な理由である。 9 | 燃え尽き症候群はプロジェクトや組織に関係している心的外傷後ストレス障害の症状として考えられるかもしれない。例えば、思考が停止したりするかもしれないし、あるプロジェクトにちょっとでも触れることで、とても不安になってしまうかもしれない。これが燃え尽き症候群である。そのような状態に陥った開発者はそのプロジェクトで開発し続けることはできなくなり、その先いくつかのプロジェクトでも同様に生産性の低下を経験するかもしれない。燃え尽き症候群はキャリアをぶち壊し得るのである。 10 | 11 | 燃え尽き症候群には多くの原因があるが、多くのよくある原因は、過度なストレスの下、長時間、莫大な仕事をこなした結果であると考えられる。 12 | 13 | それは長時間オイルやガスが加えられることなく、高いRPM（クランクシャフトが1分間あたりに何回転するか）で車のエンジンを稼働させるようなものである。やがてエンジンは壊れ、元に戻すことは困難になるだろう。 14 | 15 | 私はここで解決策を提案する。それはアジャイルのようなものであり、明示的に燃え尽き症候群を防ぐように設計されたものである。 16 | 私はそれをアジャイル ライトと呼ぶ。 17 | 18 | * もっとも基本的なルールは次の通りである。： それぞれの開発サイクルは、3週間のスプリントと、スプリントプランニングが行われる一週間の休憩から構成される。 19 | つまり、3週間の稼働と1週間の休憩である。 20 | 21 | * スプリントにはイシューがあり、エンジニアはそのイシューを解決し、適切な疑問を記録してイシュートラッキングシステムを更新する。 22 | 23 | * 一つのイシューは開発者が4-8時間かかる単位の作業である。イシューはバックログか現在のスプリントのどちらかにあるものとする。 24 | 25 | * 一旦スプリントが始まったら、基本的にはイシューはスプリントに追加されることはないが、取り除かれることはあり得る。これはコンテキストの切り替えを減らすので、良いことである。 26 | 27 | * スプリントの終わりまでに完了しなかったイシューは全て、一週間のスプリントプランニングの間にレビューされる。 28 | 29 | * アジャイル ライトにおいては残業はない。そのため、死人の行進のようなことは起こり得ない。開発者は同じペースで開発し、脳を回復させる十分な時間が与えられる。管理コストも最小になる。 30 | 31 | だいたいそんなところである。これはそれぞれのチームの目的に合うように修正され得るものである。しかし、もしアジャイル ライトの差別化要因を一つあげるとするならば、それは私たちが明示的に言っている 32 | 「アジャイルなチームも他の開発手法と同様に燃え尽きることがある。私たちはエンジニアチームにあるエンジンを加熱し過ぎないように、明示的なルールを作る必要があるかもしれない。」ということである。 33 | 34 | エンジニアチームのエンジンを加熱しすぎはやめよう。どうせやることはいっぱいある。底なしの地獄なのである。 35 | 働いて、ストレスを感じて、やがて燃え尽きるのに時間を使うのには、人生は短すぎる。 36 | 37 | --- 38 | もしより多くの職場がこのような仕組みを実践することを願うのなら、このリポジトリにスターをつけて、SNSで拡散することで、多くの人の目につくようにしてください。 39 | 40 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 41 | -------------------------------------------------------------------------------- /japanese/faq.md: -------------------------------------------------------------------------------- 1 | # アジャイル ライト: よくある質問 + 意見 2 | 3 | > アジャイルに関して唯一一貫して言えることは、誰も正しいやり方をしている訳ではないということだ。 @fwip 4 | 5 | ## よくある質問 6 | 7 | > エンジニアは1年間の間に12週間もサーフィンをしたり、絵を描いたりするために休暇をとれと言っているのでしょうか？996が標準になりつつある中で、どうやってそんなことができるのでしょうか。 8 | 9 | あなたのチームが満足するだけの休みを取るべきだと考えています。 10 | 11 | かつては週40時間労働でさえ、過激な考えとされていたのです。グーグルは80%ルールを始め、私たちは75%ルールを行なっています。さらに私は2020年までにこれを10%ルールにまでしたいと思っています。 12 | 13 | 996（朝9時から夜9時まで週6日労働）は全く逆の試みで、週40時間労働を週72時間労働に拡張しようとしています。私はこれは後退だと考えていますし、長時間働くことに執着することをやめるべきだと思っています。実際にはそれほど生産性が高いわけではないのです。 14 | 15 | この「1週間の休み」を休暇とみなすのも、仕事量を減らす1週間とみなすのも、なんでも良いですが、それはあなた次第です。その答えは週によって異なるでしょう。 16 | 17 | もしかしたら、「軽い一週間」という方が「1週間の休暇」よりも胃に優しいかもしれません。より合っている方を選んでください。 18 | 19 | サーフィンやお絵かきはもちろん必須ではありません。単に例として挙げただけです。実際、私はサーフィンもお絵かきもしません。 20 | 21 | > チームメンバーはスプリントの中で行われるイシューを*約束するもの*なのでしょうか。それとも行えるイシューを*見積もっている*だけなのでしょうか。 22 | 23 | 見積もっているだけです。もし見積もりが間違っていて、完了しなかったとしてもそれは個人が責められるべき失敗ではありません。それら失敗も全てプロセスの一部であり、全員で一つのチームです。 24 | 25 | > スプリントの代わりにイテレーションと呼んでも良いでしょうか。 26 | 27 | もちろんです！私個人としては「スプリント」と呼んでいきます。 28 | 29 | > 開始日と終了日が状況によって変化するような場合でも、カンバンスタイルでイテレーションを行えるでしょうか。 30 | 31 | 私は、開始日と終了日、そしてひとかたまりのタスクによって定義されるワークサイクルというコンセプトをとても大事にしています。特定のワークサイクルに従っていないようなイテレーションな破綻するでしょう。 32 | 33 | > なぜスプリントは3週間なのでしょうか。 34 | 35 | それは開発と休息の期間がちょうど年間13スロットに収まるからです。サイクルが終了すると、また新しいサイクルが始まります。「1週間の休息」は新しいスプリントが始まる前にリフレッシュさせてくれます。リズムと、明確かつ一貫したインターバルを保つためです。 36 | 37 | > つまり、スプリントの開始日や終了日はしばしば月の真ん中に来るということがあるということですか。 38 | 39 | そういうことです。 40 | 41 | > 開発者はスプリントプランニングに参加しますか。 42 | 43 | 参加します。彼らはミーティングに参加できないということはありません。ただ彼らは参加する必要はないということです。特にイシュートラッキングシステムを最新の状態に保てていて、チームがすでに前のスプリントで次のスプリントで行うことについて話し合っている場合は、参加する必要はありません。 44 | 45 | 私はほとんどミーティングをしません。ミーティングが楽しいと思う珍しいタイプの人ですか。 46 | 私が参加する必要がないのであれば、自由にしてください。 47 | 48 | > スプリントプランニングに本当に1週間もかかりますか。 49 | 50 | かかりませんし、そこが本質ではありません。その週が軽い週というだけです。 51 | 52 | > 本当にスタンドアップミーティングは問題でしょうか。 53 | 54 | 私の経験では、問題です。だいたいの場合、席を立ち円を作って、1人が20分くらい話すのを聞きます。もちろん、これは「間違ったスタンドアップミーティングをしている」というだけですが、私は正しく行われているところを見たことはありませんし、すぐにやめるのがオチです。そしてこれは地理的に分散しているようなチームでは困難です。（少なくとも不便です） 55 | しかし、もしあなたがスタンドアップミーティングから多くの価値を得ているのならば、自由にしてください。 56 | 57 | > このガイドラインに従わなければなりませんか。 58 | 59 | いいえ、誰もあなたに何かを強いるということはありません。これらはガイドラインであり、ルールではありません。 60 | 61 | 宗教ではないのです。 62 | 63 | 週40時間労働を提唱することが政治的であるという意味において、政治的ではあります。 64 | 65 | > あなたにとってうまくいくことが、他の人にとってもうまくいくわけではないということに気づいていますか。 66 | 67 | もちろん！ 68 | 69 | ## よくある意見 70 | 71 | > 見積もるということは不可能なので、見積りはするべきではありません。 72 | 73 | 見積もりは見積もりで、血の契約ではありません。つまり、見積もりは失敗してもかまいません。 74 | 最善を尽くして、4時間刻みの見積もりをするだけです。 75 | 76 | > 開発者は信頼されることはないですし、彼らの全ての時間を費やすべきです。それが仕事というものです。 77 | 78 | 私はその意見には本当に賛成し兼ねますが、すぐには説明できません。 79 | 私たちは根本的に異なる世界観をもっているのでしょう。 80 | 81 | > これはアジャイルじゃないです。 82 | 83 | アジャイルですよ。名前にそうあるじゃないですか。 84 | 85 | > これがうまくいくはずがありません。 86 | 87 | そう思うかもしれませんが、うまくいくのです。 88 | 89 | > あなたはアジャイルを間違えています。 90 | 91 | 残念ながらアジャイルの問題は、正しく行われることがないということなのです。 92 | -------------------------------------------------------------------------------- /korean/README.md: -------------------------------------------------------------------------------- 1 | # Agile Lite: Agile without all the burnout 2 | 3 | "애자일 소프트웨어 개발"은 훌륭한 아이디어이지만 출판 및 컨설팅 산업에서 지나치게 복잡해져왔습니다. Agile Lite는 그러한 상황을 단순화하려는 시도입니다. Agile Lite를 설명하기 위해 책이나 워크샵은 더이상 필요하지 않습니다. 다만 여러 단락으로 구성된 텍스트 파일만 있으면 됩니다. 이것이 그 텍스트 파일입니다. 4 | 5 | Agile Lite는 매우 간단합니다. "전체 작업"을 우리가 이슈라고 부르는 "소규모 작업"으로 나눌 수 있는 모든 프로젝트에 적용 할 수 있습니다. Agile Lite는 다른 에자일 방법론과 마찬가지로 Sprints라는 짧은 개발주기를 이용합니다. 다소 독특하게도 Agile Lite는 소프트웨어 개발 업계에서 번아웃 현상이 널리 퍼져있다는 것을 인정하고 이러한 현상을 완화하기 위해 3주 일하고 1주 쉬는 개발주기를 이용합니다. 6 | 7 | 기본 설정은 다음과 같습니다: 8 | 9 | * 각 주기의 첫 번째 주에는 프로젝트 리더, 개발자 및 기타 이해 관계자와 함께 다가오는 `sprint`를 정의합니다. 일주일이 주어지지만 스프린트 계획에 사용하는 시간은 최대 2시간을 넘지 않아야하며, 올바르게 완료되는데는 대체로 약 45 분이 소요됩니다. 의도적으로 가벼운 일주일을 구성하여 많은 사람들이 여유롭게 쉴 수 있게 합니다. 10 | 11 | * `sprint`는 나머지 3주 동안 진행됩니다. 이 기간 동안 엔지니어는 스프린트 계획 세션에서 그들에게 할당된 이슈에 대해 작업합니다. 팀 구성원들이 아마 원격으로 분산되어 전혀 다른 시간대에 있어 실시간으로 미팅을 자주 할 수 없을 수도 있습니다. 이럴 때, 대부분의 커뮤니케이션은 이슈 추적 시스템을 통해 이루어집니다 (이메일보다 작업 속도가 빠릅니다). 스프레드 시트는 이슈 추적 시스템으로 사용하기에는 아마 적합하지 않을테지만 Trello와 같은 공유 보드는 이슈 추적 시스템으로써 충분히 이용할 만 합니다. 매일 완료한 목록을 따로 정리하는 것은 권장하지 않습니다. 대신, 이슈 추적 시스템 업데이트를 검토하여 프로젝트가 얼마나 진행되었는 지를 얻을 수 있습니다. 12 | 13 | * `sprint`가 시작되면 이슈가 추가되지 않고 오직 제거 할 수 있습니다. 이것은 현재 스프린트에 들어온 이슈에만 집중하는 좋은 효과를 줍니다. 14 | 15 | * 스프린트 동안 완료되지 않은 이슈는 다음 스프린트 계획 세션에서 검토되며 해당 이슈를 다음 스프린트에서 진행할 것인지, 백로그에 다시 넣을 것인지 또는 다음 스프린트에서 다른 개발자에게 재할당 할 것인지를 결정합니다. 16 | 17 | * 이슈는 백로그 또는 현재 스프린트에만 존재합니다. 18 | 19 | * 언급 한 바와 같이 개발자는 계획하는 첫 번째 주 동안 이전 스프린트에서 사용한 본인의 역량을 복구할 수 있도록 충분히 쉬는 것이 좋습니다. 더 이상 죽음의 행진은 없습니다. **주말에는 개발자가 근무하지 않습니다.** 이 모든 것이 번아웃되지 않도록 도와줍니다. 번아웃을 피하는 것은 모든 사람에게 좋습니다. 20 | 21 | 스프린트에서 대부분의 해야할 일들은 계획되어 지지만 때로는 예기치 않은 일이 발생합니다. 이러한 예기치 않은 문제를 `Support Issues`라고 합니다. 22 | 23 | 스프린트를 계획할 때, 팀의 특정 구성원들에게 계획 불가능한 `Support Issues`를 처리하기 위한 시간대를 할당하는 것이 좋습니다. 예를 들어 "Dave가 다음 스프린트 동안 `Support Issues`를 처리하기 위해 12시간을 할당한다 (자세한 내용은 나중에 정의 할 것입니다)" 스프린트 동안 `Support Issues`를 담당하는 개발자(들)을 회전시켜서 분산시켜 처리하는 것이 유리합니다. 24 | 25 | 각 스프린트 계획 세션에서 추정한 것들의 정확도를 높이기 위해, 이전 스프린트에서 실제로 수행된 지원 작업량을 검토하고 다음 스프린트의 지원 작업에 더 많은 시간이 필요한지 여부를 결정합니다. 26 | 27 | 실제로, 팀마다 지원 작업에 대한 정의가 다릅니다. 아마도 고객을 지원한다는 의미일 것입니다. 또는 아마 다른 개발자를 지원한다는 의미 일 것입니다. 이 중 어떤 정의가 당신의 팀에 가장 적합한 지 선택하는 것은 당신의 책임입니다. 28 | 29 | 거의 다 됐습니다. Agile Lite는 소프트웨어를 개발하는 더 좋고 지속 가능한 방법입니다. 이 방법은 소프트웨어 개발자가 프로젝트 이해 관계자에게 일관된 수준의 생산성을 제공 할 수 있게 합니다. 30 | 31 | Agile Lite에 대한 자세한 내용은 다음을 읽어보십시오: 32 | 33 | [개발자를 위한 Agile Lite](agile_lite_for_developers.md) 34 | 35 | [매니저를 위한 Agile Lite](agile_lite_for_managers.md) 36 | 37 | [자주 묻는 질문](faq.md) 38 | 39 | 40 | --- 41 | If you would like to see more workplaces implement a system such as this, please star this repo on github and share on social media to increase visibility. 42 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 43 | -------------------------------------------------------------------------------- /korean/agile_lite_for_developers.md: -------------------------------------------------------------------------------- 1 | # Agile Lite for developers 2 | 3 | 만약 당신이 소프트웨어 업계에서 몇 년 이상 일해왔다면 당신은 아마 번아웃 현상을 겪었을 가능성이 큽니다. 번아웃에는 여러 가지 이유가 있지만, 간단하게는 당신이 너무 많은 스트레스를 너무 오랫동안 일하면서 받았기 때문이라고 설명할 수 있습니다. 4 | 5 | 이것은 프로젝트로 시작합니다. 이 프로젝트에는 자세한 사양과 마감일이 있습니다. 사양이 변경 되더라도 마감일은 변경되지 않습니다. 결국 마감일이 왔다가 사양이 시작했던 것과는 전혀 다르게 바뀌어 있습니다. 물론 이것은 당신의 잘못으로 여겨지며, 늦게까지 회사에 있거나 "도전적인 목표"위해 노력할 것을 요구받습니다. 결국 당신은 매주 주말에 출근하고 아무리 열심히 일하든 상관없이 당신의 관리자는 결코 행복하지 않으며 프로젝트는 항상 "계획보다 뒤쳐져"있습니다. 6 | 7 | 휴가를 원하는 것 그 자체가 당신이 게으름뱅이인 것처럼 보이게 만듭니다. 그리고 이런 사실이 당신만이 그 팀을 유지하는 사람처럼 보이게 합니다. 아마도 당신은 열린 사무실 환경에서 일할 것입니다. 그래서 모두가 그들이 거기에 도착할 때, 그들이 떠날 때를 알 수 있습니다. 그래서 모두는 엄청나게 열심히 일하는 사람이 되겠다는 암묵적인 계약에 동의한 꼴이 됩니다. 그래서 사람들은 바쁘게 보이며, 누군가가 당신이 어떻게 지내냐고 물을 때마다, 당신은 "바쁨! 너무 바빠요!"라고 대답합니다. 8 | 9 | 그러나 결국 무언가가 일어납니다. 아마도 직업을 바꿀 수도 있지만 소프트웨어 산업의 다른 회사에서도 마찬가지입니다. 아마도 당신은 아무 것도 남지 않을 때까지 이 상황을 헤쳐 나갈 것이고 결국 회사는 "문화에 맞지 않다"고 당신을 내보낼 것입니다. 아마도 당신이 프로그래밍이 당신을 너무 좌절시키기 때문에 이 직업을 그만두고 자동차 판매업에 종사할 수도 있습니다. 그들이 말하는 것처럼, 당신이 이 취미에서 더 이상 흥미를 느끼기 싫다면 생계수단으로써 이 일을 하도록 하십시오. 10 | 11 | 저는 해결책을 제안하고 있습니다. 이것은 에자일의 한 형태로 직접적으로 번아웃을 피하기 위해 설계되었습니다. 나는 그것을 Agile Lite라고 부릅니다. 12 | 13 | * 가장 기본적인 규칙은 다음과 같습니다. 모든 주기에는 스프린트 개발을 하는 3주와 다음 스프린트 계획을 하면서 쉬는 1주로 구성됩니다. 3주 일하고 1주 쉰다. 14 | 15 | * 스프린트에는 이슈가 포함되며 엔지니어는 이 이슈를 해결하고 관련 질문과 이슈 트래커를 업데이트합니다. 16 | 17 | * 스프린트가 시작되면 스프린트에 문제를 추가할 수는 없으며 오직 제거 할 수 있습니다. 이것은 스프린트에 포함된 이슈에만 집중할 수 있게 되는 좋은 효과를 가져옵니다. 18 | 19 | * 이슈는 4-8시간의 엔지니어링 노력이 필요한 작업 단위입니다. 이슈는 현재 스프린트 또는 백로그에 있습니다. 20 | 21 | * 스프린트가 끝날 때까지 완료되지 않은 현재 스프린트의 이슈는 다음 스프린트 계획 주에서 검토됩니다. 22 | 23 | * 초과 근무는 없습니다. 더 이상 죽음의 행진은 없습니다. 엔지니어는 규칙적인 업무 시간을 정하고 뇌를 재충전 할 수 있는 충분한 시간을 가지게 됩니다. 관리 오버 헤드가 최소화됩니다. 24 | 25 | 이것이 거의 전체 시스템입니다. 당신의 목적에 맞게 수정할 수 있습니다. 다만 Agile Lite가 가지는 차별화된 요소는, "애자일 팀들은 다른 개발 방법론만큼이나 구성원들을 번아웃으로 몰고 있다. 따라서, 엔지니어링 팀의 번아웃을 막기 위해 명확한 규칙을 세워야 할 것이다."라고 지적한다는 것입니다. 26 | 27 | 우리의 엔진 과열을 멈춥시다. 엔진을 돌리는 것 외에도 우리는 다른 할 일이 많이 있습니다. 사실 개발이란 건 바닥이 없는 구덩이와 같습니다. 그러나 인생은 일을 하고 스트레스를 받고 결국 번아웃 현상을 겪어야 할 만큼 길지 않습니다. 28 | 29 | --- 30 | If you would like to see more workplaces implement a system such as this, please star this repo on github and share on social media to increase visibility. 31 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 32 | -------------------------------------------------------------------------------- /korean/agile_lite_for_managers.md: -------------------------------------------------------------------------------- 1 | # Agile Lite for managers 2 | 3 | 당신이 당신 회사에서 소프트웨어 개발자와 함께 일하는 것이 어려웠습니까? 프로젝트의 마감일이 계속 지켜지지 않는 프로젝트를 봐왔습니까? 시작은 좋았지만 점차 천천히 의욕을 잃고 결국엔 사라지는 개발자들과 함께 일해 보셨습니까? 그렇다면 당신은 당신의 프로젝트에서 유능한 개발자를 번아웃시키고 있을 가능성이 큽니다. 4 | 5 | 번아웃은 소프트웨어 산업에서 매우 일반적이며 많은 소프트웨어 프로젝트가 실패하는 주요 이유입니다. 번아웃은 주어진 프로젝트나 조직과 관련된 외상 후 스트레스 장애 증상으로 가장 잘 설명될 수 있습니다. 예를 들어, 특정 프로젝트에 머리를 너무 많이 써서 그것에 대한 언급만으로 극심한 불안감을 느낄 수 있습니다. 이것은 번아웃입니다. 그러한 상태에있는 개발자는 해당 프로젝트에서 계속 작업할 수 없으며 다음 프로젝트에서도 생산성이 저하 될 수 있습니다. 번아웃은 그들의 직업을 망칠 수 있습니다. 6 | 7 | 번아웃에는 여러 가지 이유가 있지만 가장 기본적인 이유는 너무 많은 스트레스를 받고 너무 오래 일한 결과이기 때문입니다. 8 | 9 | 저렇게 일하는 것은 오일이나 가스를 추가하지 않고 오랜 시간 동안 높은 RPM으로 자동차 엔진을 가동하는 것과 같습니다. 결국 엔진이 고장 나서 다시 조립하기가 어려울 것입니다. 10 | 11 | 저는 이것에 대한 해결책을 제안하고 있습니다. 이것은 에자일의 한 형태로 명시적으로 번아웃을 피하기 위한 것입니다. 저는 그것을 Agile Lite라고 부릅니다. 12 | 13 | * 가장 기본적인 규칙은 다음과 같습니다. 모든 주기에는 스프린트 개발을 하는 3주와 다음 스프린트 계획을 하면서 쉬는 1주로 구성됩니다. 3주 일하고 1주 쉰다. 14 | 15 | * 스프린트에는 이슈가 포함되며 엔지니어는 이 이슈를 해결하고 관련 질문과 이슈 트래커를 업데이트합니다. 16 | 17 | * 이슈는 4-8시간의 엔지니어링 노력이 필요한 작업 단위입니다. 이슈는 현재 스프린트 또는 백로그에 있습니다. 18 | 19 | * 스프린트가 시작되면 스프린트에 문제를 추가할 수는 없으며 오직 제거 할 수 있습니다. 이것은 스프린트에 포함된 이슈에만 집중할 수 있게 되는 좋은 효과를 가져옵니다. 20 | 21 | * 스프린트가 끝날 때까지 완료되지 않은 현재 스프린트의 이슈는 다음 스프린트 계획 주에서 검토됩니다. 22 | 23 | * 초과 근무는 없습니다. 더 이상 죽음의 행진은 없습니다. 엔지니어는 규칙적인 업무 시간을 정하고 뇌를 재충전 할 수 있는 충분한 시간을 가지게 됩니다. 관리 오버 헤드가 최소화됩니다. 24 | 25 | 이것이 거의 전체 시스템입니다. 당신의 목적에 맞게 수정할 수 있습니다. 다만 Agile Lite가 가지는 차별화된 요소는, "애자일 팀들은 다른 개발 방법론만큼이나 구성원들을 번아웃으로 몰고 있다. 따라서, 엔지니어링 팀의 번아웃을 막기 위해 명확한 규칙을 세워야 할 것이다."라고 지적한다는 것입니다. 26 | 27 | 우리의 엔진 과열을 멈춥시다. 엔진을 돌리는 것 외에도 우리는 다른 할 일이 많이 있습니다. 사실 개발이란 건 바닥이 없는 구덩이와 같습니다. 그러나 인생은 일을 하고 스트레스를 받고 결국 번아웃 현상을 겪어야 할 만큼 길지 않습니다. 28 | 29 | --- 30 | If you would like to see more workplaces implement a system such as this, please star this repo on github and share on social media to increase visibility. 31 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 32 | -------------------------------------------------------------------------------- /korean/faq.md: -------------------------------------------------------------------------------- 1 | # Agile Lite: FAQ + Assertions 2 | 3 | > 에자일의 일관성은 모든 사람이 에자일을 잘못하고 있다는 것입니다. @fwip 4 | 5 | ## Frequently Asked Questions 6 | 7 | > 엔지니어들이 매년 서핑과 페인트칠을 하기 위해 12주를 쉬게 하라는 건가요? 996(9시 출근, 9시 퇴근, 매주 6일)이 표준인 이 세상에서 이 방법이 어떻게 작동할 수 있을까요? 8 | 9 | 저는 당신의 팀이 편하다고 느낄 만큼 충분히 쉬어야만 한다고 생각합니다. 10 | 11 | 저는 주 40시간의 노동이 한때 굉장히 급진적인 아이디어라고 생각할 때가 있었다는 점을 짚고 넘어가고 싶습니다. Google은 이것을 80% 정도 적용하기 시작했으며, 우리는 75% 시간입니다. 2020년대 말까지는 10% (페리스의 기법)로 줄이려고 합니다. 12 | 13 | 996은 정확히 우리의 반대편에서 주당 40시간을 주당 72시간으로 연장하려고 합니다. 저는 이 996을 퇴보하는 것이라고 보고 사람들이 오랜 노동시간에 집작하는 것을 중단해야 한다고 생각합니다. 이 방법은 실제로 더 생산적이지 않습니다. 14 | 15 | 또한 "한 주 오프"를 완전히 쉴 것인지 가벼운 업무로 구성할 것인지 아니면 기타 다르게 구성할 것인지 여부는 당신에게 달려 있습니다. 그 답은 그 특정 주에 따라 달라질 수 있습니다. 16 | 17 | 어쩌면 "한 주 오프"보다 "가벼운 한 주" 많은 사람들이 받아들이기 더 편할 것 같습니다. 더 편한 것을 사용하십시오. 18 | 19 | 서핑과 페인팅은 그저 편하게 보낸다는 것들 중의 예로 들었습니다. 사실, 나는 서핑이나 페인트조차하지 않습니다. 20 | 21 | > 사람들이 스프린트에서 이슈를 만들어내는 건가요 아니면 스프린트에서 해야할 것 같은 이슈를 예측하는 건가요? 22 | 23 | 그들은 예측합니다. 당신의 추정치가 벗어나더라도 도덕적으로 잘못된 건 아닙니다. 프로세스의 모든 부분이며 모두 같은 팀에 속해 있습니다. 24 | 25 | > 이걸 스프린트 대신에 이터레이션이라고 불러도 되나요? 26 | 27 | 네! 저는 "스프린트"라고 계속 부를 거긴 하지만요. 28 | 29 | > 시작 날짜와 끝 날짜가 상황에 따라 변하는 칸반 스타일 롤링 이터레이션을 해도 되나요? 30 | 31 | 저는 시작 날짜와 끝 날짜가 정의되고 단일 작업 블록으로 정의되는 작업주기의 개념을 정말로 중요하게 생각합니다. 롤링 반복이 특정주기와 동기화되지 않으면 문제가 발생합니다. 32 | 33 | > 왜 스프린트를 3주로 하나요? 34 | 35 | 개발 작업과 복구 시간이 연간 13개 슬롯에 적합하기 때문입니다. 사이클이 끝나면 새로운 사이클이 시작됩니다. "한 주 오프"는 새 스프린트가 시작되기 전에 개발자를 리프레시 시킬 수 있습니다. 이로써 우리는 명확하고 일관된 간격을 기반으로 일에 리듬을 얻을 수 있습니다. 36 | 37 | > 이것은 스프린트 시작 날짜와 종료 날짜가 종종 월의 중순에 해당한다는 것을 의미합니까? 38 | 39 | 네. 40 | 41 | > 스프린트를 계획할 때 개발자도 참가하나요? 42 | 43 | 예. 그들은 회의에서 금지되어서는 안됩니다. 만약 개발자가 이슈 트래킹 시스템을 최신 상태로 유지하고 팀이 이전 스프린트 과정에서 다음 스프린트에 대한 일부 항목을 논의했을 때는 따로 참석할 필요는 없습니다. 44 | 45 | 나는 회의가 적은 게 모두에게 좋다고 생각합니다. 당신은 회의를 즐기는 아주 드문 형태의 사람 중 한 명인가요? 그렇다면 가서 즐기세요. 46 | 47 | > 진짜 스프린트 계획할 때 한 주를 써야되나요? 48 | 49 | 아니요, 한 주를 쉬는 게 핵심입니다. 그 주는 가벼운 한 주 거든요. 50 | 51 | > 스탠드업이 진짜 문제인가요? 52 | 53 | 제 경험으로는 그렇습니다. 이건 보통 모두 모여 원을 이루고 한 사람의 이야기를 20분 정도 듣는 것이죠. 물론, 이렇게 묘사하는 것이 "스탠드업을 잘못하고 있다"고 지적할 수도 있겠지만, 저는 이것 이상으로 스탠드업을 올바르게 하는 팀을 보지 못했고 저는 이걸 전혀하지 않을 것입니다. 또한, 이건 지리적으로 팀이 분산되어 있다면 더 하기 어렵거나 적어도 불편할 겁니다. 그러나 스탠드업이 당신의 일이고 그것으로부터 많은 가치를 얻는다면, 저는 당신을 막을 이유가 없네요. 54 | 55 | > 이걸 꼭 이렇게 해야 할까요? 56 | 57 | 아니요. 아무도 당신이 뭔가를 하는 것을 강제할 수는 없습니다. 이건 그냥 가이드라인이지 규칙이 아니에요. 58 | 59 | 종교도 아니구요. 60 | 61 | 주당 40시간의 노동을 옹호하는 것이 정치적이라는 의미에서만 정치적입니다. 62 | 63 | > 자신에게 효과가있는 것이 다른 사람에게는 효과가 없을 수도 있다는 것을 알고 있습니까? 64 | 65 | 그럼요! 66 | 67 | 68 | ## Frequent Assertions 69 | 70 | > 할 일은 추정이 불가능하기 때문에 당신은 그 일을 추정해서는 안됩니다. 71 | 72 | 추정하는 것은 피로 맺는 계약처럼 반드시 지켜야되는 것이 아니고 그냥 추정치로 간주됩니다. 따라서 그들이 틀렷다해도 괜찮습니다. 최선을 다하고 4시간 정도 증가시켜서 다시 추정하십시오. 73 | 74 | > 개발자는 신뢰할 수 없으며 그들의 노동시간을 고려해야만 합니다. 그것이 일이 동작하는 방식이거든요. 75 | 76 | 나는 정말 동의하지 않지만 그 이유를 빨리 설명 할 수는 없습니다. 우리는 세계관에 근본적인 차이가 있습니다. 77 | 78 | > 이건 에자일이 아닙니다. 79 | 80 | 네 그렇습니다. 이건 그냥 이름에 있는 말입니다. 81 | 82 | > 이건 동작 안할 겁니다. 83 | 84 | 네 그리고 되겠죠. 85 | 86 | > 당신은 에자일을 잘못 하고 있어요. 87 | 88 | 불행히도 에자일이 가진 문제는 그것이 올바르게 수행될 수 없다는 것이죠. 89 | -------------------------------------------------------------------------------- /portuguese/README.md: -------------------------------------------------------------------------------- 1 | # Agile Lite: Agile sem todo o burnout 2 | 3 | "Desenvolvimento ágil de software" é uma ótima idéia que foi supercomplicada pelas editoras e consultorias. Agile Lite é uma tentativa de simplificar a situação. Você não precisa de um livro ou de um workshop para explicar o Agile Lite. Você só precisa de um arquivo de texto com vários parágrafos. Este é o arquivo de texto. 4 | 5 | O Agile Lite é bem simples. Ele pode ser aplicado a qualquer projeto com pessoas trabalhando nele, supondo que o trabalho possa ser dividido em tarefas integrantes menores que chamaremos de Problemas. Como outras metodologias ágeis, utiliza ciclos curtos de desenvolvimento chamados Sprints. De forma relativamente única, o Agile Lite reconhece explicitamente a prevalência de burnout na indústria de desenvolvimento de software e tenta mitigá-lo diretamente por meio de um ciclo de desenvolvimento de 3 semanas de atividade por uma semana de inatividade. 6 | 7 | A configuração básica é esta: 8 | 9 | * A primeira semana de cada mês é gasta com os líderes e partes interessadas do projeto definindo a próxima `sprint`. Apesar de uma semana ser alocada, uma sessão de planejamento de sprint não deve levar mais de 2 horas e, provavelmente, cerca de 45 minutos, se feita corretamente. É uma semana intencionalmente leve e muitas pessoas podem simplesmente tirar um tempo para pintar, surfar ou qualquer outra coisa. 10 | 11 | * A `sprint` ocorre durante as 3 semanas restantes do mês. Durante esse período, os engenheiros trabalharão nos problemas que foram alocados a eles durante as sessões de planejamento da sprint. Uma vez que a equipe pode ser totalmente remota e estar distribuída em diferentes fusos horários, as reuniões "ao vivo" acontecem com pouca frequência e a maioria das comunicações acontece por meio do `sistema de rastreamento de problemas` (que é mais rápido de se trabalhar do que de e-mail). Um quadro kanban compartilhado como o Trello é um sistema de rastreamento de problemas suficiente, mas uma planilha provavelmente não é. Reuniões Diárias em pé são desencorajadas; uma tomada de pulso básica do projeto pode ser obtida revisando as atualizações do sistema de rastreamento de problemas. 12 | 13 | * Depois que uma `sprint` é iniciada, Problemas não podem ser adicionados à sprint, mas podem ser removidos. Isso reduz a mudança de contexto e isso é bom. 14 | 15 | * Os problemas que não são concluídos durante a sprint são revisados ​​na próxima sessão de planejamento da sprint e é decidido se o problema deve ser encaminhado para a próxima sprint, colocado de volta no Backlog ou transferido para outro desenvolvedor. 16 | 17 | * Um Problema está no `backlog` ou na `sprint atual`. 18 | 19 | * Como mencionado, os desenvolvedores são encorajados a tirar a semana de planejamento para permitir que seu cérebro se recupere da sprint anterior. Não há marchas da morte. Os desenvolvedores não trabalham nos finais de semana. Isso tudo ajuda a evitar o esgotamento profissional. Evitar o esgotamento profissional é bom para todos. 20 | 21 | É basicamente isso. O sistema realmente não prescreve práticas de engenharia e acho que está tudo bem. As práticas de engenharia podem ser definidas em nível de projeto. 22 | 23 | O trabalho de suporte é feito rotativamente porque às vezes as coisas acontecem inesperadamente e precisam ser resolvidas, mas um número surpreendente de problemas pode esperar até mais tarde. 24 | 25 | O Agile Lite é uma maneira melhor e mais sustentável de desenvolver software. Ele capacita os desenvolvedores de software, ao mesmo tempo em que fornece um nível consistentemente sólido de produtividade para as partes interessadas do projeto. 26 | 27 | 28 | Para aprender mais sobre Agile Lite, Eu encorajo você a ler: 29 | 30 | [Agile Lite para desenvolvedores](agile_lite_for_developers.md) 31 | 32 | [Agile Lite para gerentes](agile_lite_for_managers.md) 33 | 34 | 35 | --- 36 | Se você quiser ver mais locais de trabalho implementando um sistema como este, por favor, marque este repositório no github e compartilhe nas redes sociais para aumentar a visibilidade. 37 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 38 | -------------------------------------------------------------------------------- /portuguese/agile_lite_for_developers.md: -------------------------------------------------------------------------------- 1 | # Agile Lite para desenvolvedores 2 | 3 | 4 | Se você trabalha na indústria de software há mais de alguns anos, provavelmente já experimentou esgotamento profissional. Há muitas razões para o esgotamento profissional, mas pode ser simplesmente descrito como o resultado de trabalhar muito, sob muito estresse, por muito tempo. 5 | 6 | Começa com um projeto. Esse projeto tem uma especificação detalhada e um deadline. Quando a especificação muda, o deadline não. Eventualmente, o deadline chega e vai e a especificação se transformou em algo diferente de como começou. Claro, isso é visto como sua culpa, e você é solicitado a ficar até tarde ou a se comprometer com "esticar objetivos". Eventualmente você trabalha todo final de semana e não importa quão duro você trabalhe, seu gerente nunca fica feliz e o projeto está perpetuamente "atrasado". 7 | 8 | Querer folga ou férias faz você parecer um preguiçoso. Faz parecer que você é o único atrasando sua equipe. Talvez você trabalhe em um ambiente de escritório aberto; todo mundo sabe quando você chega lá, todo mundo sabe quando você sai, e todo mundo assina um contrato não dito para não ser a pessoa que não está trabalhando duro. Então as pessoas ficam boas em parecer ocupadas, e sempre que alguém lhe pergunta como você está, você responde: "Ocupado! Estou TÃO ocupado!" 9 | 10 | Mas eventualmente alguma coisa quebra. Talvez você mude de emprego, mas é mais do mesmo em outras empresas do setor de software. Talvez você continue até que não haja mais nada restante em você e, em seguida, a empresa te demite porque você simplesmente "não está ajustado à cultura da empresa". Talvez você se demita e aceite um emprego vendendo carros porque a programação é frustrante demais. Como se costuma dizer, se você quiser matar a alegria em um hobby, tente fazer isso para ganhar a vida. 11 | 12 | Estou propondo uma solução. É uma forma de agilidade que é explicitamente projetada para ajudar a evitar o esgotamento profissional. Eu chamo de Agile Lite. 13 | 14 | * A regra mais básica é a seguinte: todo mês inclui um sprint de 3 semanas e uma semana "off", onde o planejamento de sprint é feito. 3 semanas de atividade por uma semana de inatividade. 15 | 16 | * Um sprint contém Problemas e engenheiros resolvem Problemas, registrando questões pertinentes e atualizando o Rastreador de Problemas. 17 | 18 | * Uma vez iniciada a sprint, os Problemas podem não ser adicionados à sprint, mas podem ser removidos. Isso reduz a mudança de contexto e isso é bom. 19 | 20 | * Um Problema é qualquer unidade de trabalho que deve levar de 4 a 8 horas de esforço de engenharia. Um Problema está no sprint atual ou no backlog. 21 | 22 | * Todos os Problemas no sprint atual que não são concluídos até o final do sprint são revisados ​​durante a semana de planejamento da sprint. 23 | 24 | * Não há horas extras de trabalho. Não pode haver marchas da morte. Os engenheiros são colocados em uma cadência de trabalho mensal e têm tempo suficiente para recarregar seus cérebros. A sobrecarga de gerenciamento é mínima. 25 | 26 | Isso é praticamente todo o sistema. Pode ser modificado para atender às suas finalidades. Mas se há um diferenciador para o Agile Lite, que eu gostaria de salientar, é que estamos explicitamente dizendo: "Ei, equipes ágeis estão se esgotando tanto quanto outras metodologias de desenvolvimento, talvez precisemos criar regras explícitas para evitar superaquecer o motor que é a equipe de engenharia". 27 | 28 | Vamos parar de superaquecer nossos motores. Há muito trabalho a fazer por aí. Um buraco sem fundo, na verdade. Mas a vida é muito curta para gastar tudo trabalhando, estressado e, finalmente, esgotado. 29 | 30 | 31 | --- 32 | Se você quiser ver mais locais de trabalho implementando um sistema como este, por favor, marque este repositório no github e compartilhe nas redes sociais para aumentar a visibilidade. 33 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com -------------------------------------------------------------------------------- /portuguese/agile_lite_for_managers.md: -------------------------------------------------------------------------------- 1 | # Agile Lite para gerentes 2 | 3 | Trabalhar com desenvolvedores de software tem sido um desafio em sua empresa? Você já viu projetos que consistentemente perdem prazos? Você já trabalhou com desenvolvedores que começam bem e depois declinam lentamente e então desaparecem? Você pode simplesmente estar lidando com um desenvolvedor talentoso que experimentou o esgotamento profissional em seu projeto. 4 | 5 | O esgotamento profissional é extremamente comum na indústria de software e é um dos principais motivos pelos quais muitos projetos de software falham. Esgotamento profissional pode ser melhor descrito como sintomas de Transtorno de Estresse Pós-Traumático que estão conectados a um determinado projeto ou organização. Por exemplo, seu cérebro pode se desligar e você pode ficar extremamente ansioso com a simples menção de um certo projeto. Isso é esgotamento profissional. Um desenvolvedor em tal estado provavelmente não conseguirá continuar trabalhando nesse projeto e poderá ter uma produtividade reduzida em seus próximos projetos também. O esgotamento profissional pode prejudicar carreiras. 6 | 7 | Há muitas razões para o esgotamento, mas a razão mais básica é que ele é o resultado de trabalhar demais, sob estresse em demasia, por tempo demais. 8 | 9 | É como operar um motor de carro em altas rotações por um longo tempo sem adicionar óleo ou gasolina. Eventualmente esse motor vai quebrar e será difícil fazê-lo funcionar novamente. 10 | 11 | Estou propondo uma solução. É uma forma de agilidade que é explicitamente projetada para ajudar a evitar o esgotamento profissional. Eu chamo de Agile Lite. 12 | 13 | * A regra mais básica é a seguinte: todo mês inclui um sprint de 3 semanas e uma semana "off", onde o planejamento de sprint é feito. 3 semanas de atividade por uma semana de inatividade. 14 | 15 | * Um sprint contém Problemas e engenheiros resolvem Problemas, registrando questões pertinentes e atualizando o Rastreador de Problemas. 16 | 17 | * Um Problema é qualquer unidade de trabalho que deve levar de 4 a 8 horas de esforço de engenharia. Um Problema está no sprint atual ou no backlog. 18 | 19 | * Uma vez iniciada a sprint, os Problemas podem não ser adicionados à sprint, mas podem ser removidos. Isso reduz a mudança de contexto e isso é bom. 20 | 21 | * Todos os Problemas no sprint atual que não são concluídos até o final do sprint são revisados ​​durante a semana de planejamento da sprint. 22 | 23 | * Não há horas extras de trabalho. Não pode haver marchas da morte. Os engenheiros são colocados em uma cadência de trabalho mensal e têm tempo suficiente para recarregar seus cérebros. A sobrecarga de gerenciamento é mínima. 24 | 25 | Isso é praticamente todo o sistema. Pode ser modificado para atender às suas finalidades. Mas se há um diferenciador para o Agile Lite, que eu gostaria de salientar, é que estamos explicitamente dizendo: "Ei, equipes ágeis estão se esgotando tanto quanto outras metodologias de desenvolvimento, talvez precisemos criar regras explícitas para evitar superaquecer o motor que é a equipe de engenharia". 26 | 27 | Vamos parar de superaquecer nossos motores. Há muito trabalho a fazer por aí. Um buraco sem fundo, na verdade. Mas a vida é muito curta para gastar tudo trabalhando, estressado e, finalmente, esgotado. 28 | 29 | --- 30 | Se você quiser ver mais locais de trabalho implementando um sistema como este, por favor, marque este repositório no github e compartilhe nas redes sociais para aumentar a visibilidade. 31 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com -------------------------------------------------------------------------------- /portuguese/faq.md: -------------------------------------------------------------------------------- 1 | # Agile Lite: FAQ + Asserções 2 | 3 | > A única coisa consistente sobre o Agile, é que todos estão fazendo errado. @fwip 4 | 5 | ## Perguntas Frequentes 6 | 7 | > Então, quer dizer que engenheiros tem 12 semanas livres, por ano, pra surfar e pintar? Como isso funcionaria em um mundo onde 996 está se tornando a norma? 8 | 9 | Eu acho que seu time deveria ter quanto tempo livre ele achar confortável. 10 | 11 | Eu não vou nem fazer referência ao fato de que 48 horas de trabalho por semana já foi considerado uma ideia radical. Google começou com 80% do tempo, nós estamos com 75% do tempo aqui. Eu gostaria de baixar pra 10% do tempo (o método Ferris) até o final da década de 2020. 12 | 13 | 996 (9am-9pm 6 dias por semana) está trabalhando no outro lado disto, com a intenção de aumentar às 40 horas de trabalho por semana para 72 horas por semana. Eu vejo isto como um retrocesso e acredito que as pessoas deveriam parar de tratar muitas horas como fétiche. Na verdade, nem é mais produtivo. 14 | 15 | Também, depende de você se a "semana livre" é uma semana de férias ou uma semana com trabalhos mais leves, ou qualquer outra coisa. A resposta pode depender da semana em particular. 16 | 17 | Talvez uma "semana leve" seja mais fácil para as pessoas engolirem que "semana livre". Use o que deixar você mais confortável. 18 | 19 | Surfar e pintar não são de forma alguma necessários, eles foram citados apenas como exemplos. Pra falar a verdade, eu nem surfo, nem faço pintura. 20 | 21 | > As pessoas se *comprometem* com os problemas numa sprint ou eles estão *prevendo* os problemas que elas vão ter na sprint? 22 | 23 | Eles estão prevendo. Não é uma falha moral se você falhar na estimativa. É tudo parte do processo e todos estão no mesmo time. 24 | 25 | > Podemos chamá-las de iterações ao invés de sprints? 26 | 27 | Claro! Eu vou continuar com *sprint*. 28 | 29 | > Podemos usar uma rotação na iteração estilo kanban, onde datas de início e fim variam e dependem da circunstância? 30 | 31 | Eu realmente valorizo o conceito do ciclo de trabalho tendo uma data de início e fim definidas, e sendo definida por um único bloco de tarefas. Rotação na iteração que não são sincronizadas com um ciclo específico atrapalhariam isto. 32 | 33 | > Por que sprints de 3 semanas? 34 | 35 | Porque trabalho no desenvolvimento mais tempo de recuperação cabem em 13 partes por ano. Quando o ciclo termina, um novo começa. A "semana livre" permite um reinício antes da nova sprint começar. É sobre manter um ritmo e ter intervalos consistentes e claros. 36 | 37 | > Isso significa que as datas de início e fim de uma sprint vão cair frequentemente no meio do mês? 38 | 39 | Sim. 40 | 41 | > Os desenvolvedores participam do planejamento da sprint? 42 | 43 | Sim. Eles não estão banidos da reunião. Eles só não precisam participar, especialmente se eles mantêm o Sistema de Tracking dos Problemas atualizado e o time discutiu alguns dos itens para a próxima sprint ao decorrer da sprint anterior. 44 | 45 | Eu sou completamente a favor de menos reuniões. Você é uma dessas raras pessoas que gostam de reuniões? Desde que eu não precise participar, não deixe que eu interrompa você. 46 | 47 | > Realmente demora uma semana pra planejar uma sprint? 48 | 49 | Não, este é o ponto. É uma semana leve. 50 | 51 | > Standups são realmente um problema? 52 | 53 | Na minha experiência, sim. É comumente todos em pé em um círculo, escutado uma pessoa falar por 20 minutos. Claro, isto é "fazendo standup errado", mas não vi até hoje qualquer time que o fazem certo, e eu ligeiramente não faria eles em absoluto. Também é mais difícil (ou pelo menos inconveniente) fazer eles quando você tem um time distribuído geograficamente. Mas se standups são importantes para você e você tem bastantes benefícios com eles, não deixe que eu interrompa você. 54 | 55 | > Nós temos que fazer isto desse jeito? 56 | 57 | Não. Ninguém está forçando você a fazer nada. Eles são guias, não regras. 58 | 59 | Isto não é uma religião. 60 | 61 | É político só no sentido de que incentivar 40 horas de trabalho por semana foi político. 62 | 63 | > Você está ciente que, o que pode funcionar pra você pode não funcionar para os outros? 64 | 65 | Eu com certeza estou! 66 | 67 | 68 | ## Asserções Frequentes 69 | 70 | > Você não deve estimar porque estimativas são impossíveis. 71 | 72 | Estimativas são tratadas como estimativas, não como contratos de sangue. Consequentemente, se elas não estiverem certas, tudo bem. Faça o melhor que você puder e estime em incrementos de 4 horas. 73 | 74 | > Não se pode confiar em Desenvolvedores, eles devem relatar todo o seu tempo porque é assim que trabalho funciona. 75 | 76 | Eu discordo totalmente, mas não posso explicar o porquê rapidamente. Nós temos uma diferença fundamental na forma de ver o mundo. 77 | 78 | > Isto não é Agile. 79 | 80 | Claro que é, está ali, no nome. 81 | 82 | > Isto nunca vai funcionar. 83 | 84 | E mesmo assim funciona. 85 | 86 | > Você está fazendo Agile errado. 87 | 88 | Infelizmente o problema com agile é que ele não pode ser feito de forma correta. 89 | -------------------------------------------------------------------------------- /russian/01.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/davebs/AgileLite/65ea84f14feb4d900bda67e39bac01db90e8dde5/russian/01.jpg -------------------------------------------------------------------------------- /russian/README.md: -------------------------------------------------------------------------------- 1 | # Agile Lite: Agile без перегрева 2 | 3 | "Agile методология разработки программного обеспечения" это отличная идея, которая переусложненна умными дядьками из мира таймменеджемента и консалтинга в сфере разработки ПО. Представленный в данной статье подход `Agile Lite` призван упростить ситуацию. Вам не нужны книги или семинары, чтобы понять, что такое `Agile Lite`. Вам достаточно иметь текстовый файл с несколькими параграфами описывающими этот подход. Это и есть этот текстовый файл. 4 | 5 | `Agile Lite` очень прост. Он может быть применен к любому проекту с людьми работающими над ним в команде, и если эта работа может быть разбита на мелкие части, которые в дальнейшем мы будем называть задачами (Issues). Как и другие Agile методологии `Agile Lite` использует короткие циклы разработки именуемые `Спринты` (Sprints). Что уникально в данном подходе, дак это то, что `Agile Lite` учитывает тенденцию команды к выгоранию при усиленной и продолжительной работе над проектом и призвана уменьшить, или даже исключить данный фактор, путем разбиения цикла разработки на **3-х недельный период спринта и 1-но недельный период разгрузки** (**3 weeks on/1 week off**). 6 | 7 | 8 | Базовое использование методологии состоит в следующем: 9 | 10 | * Первая неделя каждого цикла тратится на работу проджект-менеджеров и владельцев проекта на выработку задач на предстоящий `спринт`. В независимости от того, что на это выделена неделя, ежедневные сессии планирования не должны занимать более 2 часов в день, а вообще в идеале достаточно 45 минут в день. Эта неделя разгруки для команды разработчиков и в течении нее они могут просто отдыхать и разгружать свои мозги, занимаясь различной интересной для себя работой, например своими хобби-проектами, самообучением или чем-то другим, в общем, по максимуму расслабляться в эту неделю. 11 | 12 | * Далее начинается период 3-х недельного цикла спринта. В этот период разработчики работают над Задачами (Issues), которые были определены в первой неделе на сессиях планирования. Т.к. команда может быть удаленной и распределенной по часовым зонам, то живые митинги проводятся не часто и в основном вся коммуникация происходит через систему трекинга задач (issue tracking system), т.к. это более быстрый способ общения нежели по e-mail. Системой трекинга в данном случае может выступать Trello, не используйте для этого эксель таблицы гуглдокс, они для этого не годятся. Ежедневные стендапы не приветствуются; текущее состояние хода работы можно смотреть в системе трекинга тасков по мере обновления статусов задач разработчиками. 13 | 14 | * Как только начался период спринта, новые задачи не могут быть добавлены в текущий спринт, но могут удаляться из него. Тем самым мы уменьшаем переключения разработчиков между контектсами задач и не нарушаем их текущий настрой (не отвлекаем их от решения текущего потока задач), что есть хорошо. 15 | 16 | * Задачи, которые не были завершены в период спринта, пересматриваются на следующий спринт, в последующей неделе планирования, где по ним принимается решение продолжать ли их выполнение в следующем спринте, или положить обратно в беклог (Backlog), или переназначить на другого разработчика. 17 | 18 | * Задачи, которые предстоит выполнить могут располагаться либо в беклоге (планируемые на будущее), либо в текущем спринте. 19 | 20 | * Как вы уже наверное поняли неделя планирования после спринта предназначена для разгрузки мозгов разработчиков и подготовки их к следующему периоду спринта. Здесь нет гонок на выживание. Разработчики не должны работать сверхурочно и в выходные дни. Все это призвано исключить выгарание команды. А исключение выгорания и стрессов полезно для всех. 21 | 22 | Вот и все. Данный подход не предписывает какие-то конкретные инструкции по разработке программного обеспечения, и это хорошо. 23 | 24 | Работа по поддержке проекта выполняется на ежедневной основе, т.к. всегда могут случаться какие-то сбои или форсмажеры и разработчики должны быть готовы их устарнить. Если такое происходит, то текущие задачи откладываются и решается возникшая проблема, после чего разработчик продолжает выполнять свои задачи. 25 | 26 | `Agile Lite` лучше обычного Agile и более подходящий способ разработки программного обеспечения. Он дает возможность разработчикам иметь более высокую производительность, а владельцам проекта иметь стабильную и эффективную комманду для развития своего продукта и получения прибыли. 27 | 28 | 29 | Чтобы узнать больше о `Agile Lite`, рекомендую вам прочитать также эти небольшие статьи: 30 | 31 | * [Agile Lite для разработчиков](agile_lite_for_developers.md) 32 | * [Agile Lite для менеджеров](agile_lite_for_managers.md) 33 | * [Часто Задаваемые Вопросы (FAQ)](faq.md) 34 | 35 | 36 | --- 37 | 38 | Original Source: [Agile Lite: Agile without all the burnout](https://github.com/davebs/AgileLite) 39 | 40 | --- 41 | If you would like to see more workplaces implement a system such as this, please star this repo on github and share on social media to increase visibility. 42 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 43 | -------------------------------------------------------------------------------- /russian/agile_lite_for_developers.md: -------------------------------------------------------------------------------- 1 | # Agile Lite для разработчиков 2 | 3 | Если вы уже достаточно давно работаете разработчиком в сфере IT, то вы, наверняка, хоть бы раз испытывали состояние выгорания. У такого эмоционального состояния найдется множество причин, но все они могут быть описаны как результат напряженной работы под большим стрессом достаточно продолжительное время. 4 | 5 | Все начинается вместе с проектом. Вначале проект имеет подробное описание требований и сроки дедлайна. По ходу его активной разработки требования постоянно изменяются, а сроки окончания остается на месте. И вот наступает дедлайн, в который вы, естественно, не укладываетесь. Взглянув на начало проекта вы осознаете, что требования к проекту теперь совершенно отличается от тех, что были изначально. 6 | Конечно, вы считаете себя виноватым в том, что не уложились в эти сроки, и вы все чаще начинаете работать сверхурочно, чтобы что-то доделать или исправить. И вот к концу очередной напряженной рабочей недели, неважно как усердно вы ее отработали, менеджер проекта вами по-прежнему не доволен, т.к. проект постоянно не укладвается в установленные сроки разработки. 7 | 8 | Отдыхая после работы или находясь в отпуске вы постоянно считаете, что вы бездельник и моглибы потратить свое свободное время на доработку проекта. 9 | Со временем вы все больше начинаете считать, что весь проект и поддержка команды лежит только на вас. 10 | В офисе к вам так часто обращаются с разными просьбами, что ваше вынужденное отсутсвие на рабочем месте воспринимается как прогул, почти все сотрудники знают когда вы уходите и приходите и вы не можете незаметно отлучиться даже на 5 минут. 11 | И всегда когда кто-то у вас спрашивает как дела, вы постоянно повторяете одно и тоже: "Я занят! Я очень занят!". 12 | 13 | И наконец наступает момент когда вы говорите самому себе: "Да пошло оно все...". 14 | Возможно, вы меняете свою работу и устраиваетесь в другую IT компанию, но там все тоже самое повторяется снова и снова. 15 | Возможно, вы все-таки остаетесь, но теперь становитесь пофигистом, при любом обращении к вам хамите и посылаете людей подальше и в конце-концов вас увольняют за неподобавющее поведение или оскарбление кого-то из менеджеров. 16 | Возможно вы решаете просто кардинально сменить область своей деятельности и уйти из сферы IT разводить кроликов или продавать фрукты. 17 | 18 | > Вобщем, как в той поговорке: если хочешь убить свое увлечение или хобби - сделай его своей работой. 19 | 20 | У меня есть решение. Это гибкая форма [Agile разработки](https://ru.wikipedia.org/wiki/Гибкая_методология_разработки), которая пожет вам избежать выгорания. Я называю ее `Agile Lite` (Agile без перегрева). 21 | 22 | Ее оснонвые правила следующие: 23 | * Каждый цикл разработки включает 3 недели спринта и 1 неделю разгрузки, в которую выполняется планирование спринта на следующий период. Мантра: **3 недели спринт / 1 неделя разгрузки**. 24 | * Сприн включает в себя решение задач (`Issues`), и разработчики их решают, и регистрируют их выполнение в специальной системе трекинга. 25 | * Как только начался 3-х недельний сприн, в этот период никакие новые задачи не могут быть добавлены в данный спринт, только удалены/закрыты. Это исключает частые переключения разработчиков между контектсами задач и это хорошо. 26 | * Задачей (`Issue`) является любой блок работы, который занимает от 4 до 8 часов рабочего времени разработчика и который прописан в виде описанной задачи (таска) в систему трекинга. 27 | * Любые задачи в текущем спринте, которые не были завершены по окончанию очердного периода спринта, пересматриваются в течении периода недельной разгрузки и планирования, и переносятся в следующий 3-х недельний спринт. 28 | * Мы отказваемся от такого понятия как переработки. У нас нет гонок на выживание. Разработчики на постоянной основе получают новые порции задач и получают необходимое время на их выполнение, а также время на разгрузку своих мозгов. Менеджерские затраты на управление при этом минимальны. 29 | 30 | Это и есть описание методологии разработки по `Agile Lite`. Естественно вы можете подкорректировать эти описания под свои нужды. Но есть один отличительный признак Agil Lite, который я хотел бы отметить - это то, что мы явно говорим: "Эй, команды работающие по методологии agile тоже могут выгорать также как и команды работающие по другим методологиям, возможно нам надо добавить еще некоторых правил, чтобы уменьшить вероятность выгорания нашего движка, которым явялется наша команда". 31 | 32 | Давайте прекратим перегревать наши движки! У нас итак много работы, которую мы должны сделать. По сути бездонная яма работы. Но жизнь коротка, чтобы тратить ее всю на работу, стресс и выгорание. 33 | 34 | ---- 35 | 36 | If you would like to see more workplaces implement a system such as this, please star this repo on github and share on social media to increase visibility. 37 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 38 | 39 | ---- 40 | 41 | Источник: [Agile_Lite_for_Developers](https://github.com/davebs/AgileLite/blob/master/agile_lite_for_developers.md) 42 | 43 | ![01](01.jpg) 44 | 45 | -------------------------------------------------------------------------------- /russian/agile_lite_for_managers.md: -------------------------------------------------------------------------------- 1 | # Agile Lite для менеджеров 2 | 3 | Работать с командой разработчиков не простая задача в вашей компании? Встречались ли вам проекты, которые постоянно не укладываются в оговоренные сроки выполнения? Работали ли вы с разработчиками, которые активно начинали разработку какого-либо проекта, а потом медленно охладевали к нему или, вовсе, покидали проект? Возможно вы просто имели дело с талантливыми разработчиками, испытывающими состояние выгорания при работе над проектом. 4 | 5 | Выгорание это довольно частое эмоциональное состояние команд разработчиков в IT сфере, приводящее к краху проекта над которым они работают. Выгорание может быть описано как симптомы посттравматического стрессового расстройства, свзянного с работой над проектом или в конкретной организации. Например, мозг человека находящегося в таком состоянии может отключаться и он может испытывать сильную тревогу при одном лишь упоминании названия проекта. Разработчик в таком состоянии, скорее всего, не сможет продолжать работу над таким проектом и будет испытывать снижение производительности при работе над другими проектами. Также выгорание может нанести серьезный вред карьере. 6 | 7 | У состояния выгорания, существует множество причин, но все они могут быть описаны как результат напряженной работы под большим стрессом достаточно продолжительное время. 8 | 9 | Это как ездить постоянно на машине на повышенных оборотах без остановки. В итоге рано или поздно двигатель выйдет из строя и его будет сложно или уже не возможно починить. 10 | 11 | Я предлагаю решение данной проблемы. Это форма agile методологии созданная специально для исключения выгорания команды. Я называю эту методологию `Agile Lite` (Agile без перегрева). 12 | 13 | Ее оснонвые правила следующие: 14 | * Каждый цикл разработки включает 3 недели спринта и 1 неделю разгрузки, в которую выполняется планирование спринта на следующий период. Мантра: **3 недели спринт / 1 неделя разгрузки**. 15 | * Сприн включает в себя решение задач (`Issues`), и разработчики их решают, и регистрируют их выполнение в специальной системе трекинга. 16 | * Как только начался 3-х недельний сприн, в этот период никакие новые задачи не могут быть добавлены в данный спринт, только удалены/закрыты. Это исключает частые переключения разработчиков между контектсами задач и это хорошо. 17 | * Задачей (`Issue`) является любой блок работы, который занимает от 4 до 8 часов рабочего времени разработчика и который прописан в виде описанной задачи (таска) в систему трекинга. 18 | * Любые задачи в текущем спринте, которые не были завершены по окончанию очердного периода спринта, пересматриваются в течении периода недельной разгрузки и планирования, и переносятся в следующий 3-х недельний спринт. 19 | * Мы отказваемся от такого понятия как переработки. У нас нет гонок на выживание. Разработчики на постоянной основе получают новые порции задач и получают необходимое время на их выполнение, а также время на разгрузку своих мозгов. Менеджерские затраты на управление при этом минимальны. 20 | 21 | Это и есть описание методологии разработки по `Agile Lite`. Естественно вы можете подкорректировать эти описания под свои нужды. Но есть один отличительный признак Agil Lite, который я хотел бы отметить - это то, что мы явно говорим: "Эй, команды работающие по методологии agile тоже могут выгорать также как и команды работающие по другим методологиям, возможно нам надо добавить еще некоторых правил, чтобы уменьшить вероятность выгорания нашего движка, которым явялется наша команда". 22 | 23 | Давайте прекратим перегревать наши движки! У нас итак много работы, которую мы должны сделать. По сути бездонная яма работы. Но жизнь коротка, чтобы тратить ее всю на работу, стресс и выгорание. 24 | 25 | ---- 26 | 27 | If you would like to see more workplaces implement a system such as this, please star this repo on github and share on social media to increase visibility. 28 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 29 | 30 | ---- 31 | 32 | Источник: [Agile_Lite_for_Managers](https://github.com/davebs/AgileLite/blob/master/agile_lite_for_managers.md) 33 | 34 | ![01](01.jpg) 35 | 36 | 37 | -------------------------------------------------------------------------------- /russian/faq.md: -------------------------------------------------------------------------------- 1 | # Agile Lite: FAQ + Замечания 2 | 3 | > Только одно утверждение верно на счет методологии Agile: "Все понимают ее неверно". @fwip 4 | 5 | 6 |
7 | 8 | ## Часто задаваемые вопросы 9 | 10 | > Значит вы мне говорите, что у разработчиков есть 12 свободных недель в году, которые они могут потратить на что угодно, например, рисование, серфинг и прочие развлечения? Как это вообще может быть возможно в мире, где доминирует 8 часовой рабочий день, а в Китае вообще существует система [12 часового рабочего дня (72 часовая рабочая неделя - 996 working hour system)](https://en.wikipedia.org/wiki/996_working_hour_system). 11 | 12 | Я считаю что ваша команда должна иметь столько разгрузочных дней, сколько ей комфортно и необходимо. 13 | 14 | Напомню, что когда-то, на заре 20 века, внедрение системы 40 часовой рабочуй недели, тоже считалась радикальным решением. Напирмиер, компания Google, сравнительно недавно стала использовать идею, когда ее сотрудники работают 80% времени, а остальные 20% тратят на свои личные увлечения (хобби). 15 | 16 | [Китайская система 996 (работа с 9:00 до 21:00 6 дней в неделю)](https://en.wikipedia.org/wiki/996_working_hour_system), наоборот, пытается внедрить 72 часовую рабочую неделю. Я считаю это откатом в прошлое средневековье и считаю, что люди должны перестать пытаться ее внедрять и использовать, т.к. это не ведет к увеличению продуктивности работы. 17 | 18 | Так же это зависит от вас, как вы будете понимать неделю разгрузки, возможно в эту неделю работники должны работать не в полную меру или вообще отдыхать, это уже вы решайте сами. Суть в том что должна быть неделя разгрузки для них. Можете включить ее в счет части отпусков или еще как-нибудь. 19 | 20 | Просто ваша команда должна понимать, что у нее после трех недельного спринта есть неделя разгрузки. А что они будут делать в этот период вы решите сами. 21 | 22 |
23 | 24 | > Если в период спринта разработчик приступеает к решению назначенной на него задачи, значит ли это что он должен ее обязательно закрыть в текущем спринте? 25 | 26 | Нет это не обязательно и зависит от степени сложности задачи. Если он не укладвается в период спринта, то на следующем этапе недельного плнанировани эта задача персматривается и проджект менеджер принимает решение о необходимости переноса ее в следующий спринт, или возврат в беклог, либо назначение на другого разработчика. 27 | 28 | 29 |
30 | 31 | > Можем ли мы понимать трехнедельные спринты, как очередные итерации разработки проекта? 32 | 33 | Да, конешно. Просто в данном описании мы придерживаемся понятия спринт. 34 | 35 | 36 |
37 | 38 | > Почему 3-х недельные спринты? 39 | 40 | Потому что работа по разработке плюс время на восстановление должно укладываться в 13 частей (интервалов) в год. Когда закончивается очередной цикл и начинается новый. Разгрузочная неделя обеспечивает моральную разгрузку перед началом нового периода очередного спринта. 41 | 42 | 43 |
44 | 45 | > Заничит ли это, что начало спринта и его окончание зачастую будут находится в середине календарного месяца? 46 | 47 | Да. 48 | 49 | 50 |
51 | 52 | > Должны ли разработчики привлекаться к планированию очередного спринта? 53 | 54 | Да. Разаработчикам не воспрещается посещять митинги по планированию очередного спринта. Просто зачастую им это не требуется, т.к. они итак видят свои задачи в системе трекинга и команда возможно уже обсуждала эти задачи на предыдыщем спринте. 55 | 56 | Вообще я за минимизацию митингов. Вам нравятся митинги? Я сторонник того чтобы митинги собирались по острой необходимости и чтобы на них присутвовали только необходимые для обсуждения задач люди. 57 | 58 | 59 |
60 | 61 | > Нужно ли проводить ежедневные стендапы? 62 | 63 | По моему опыту в этом нет необходимости. Обычно все кто стоит в кругу, слушают разговор одного человека 20 минут. Конечно, это вариант "как не нужно проводить стендапы", но я не видел пока ни одной команды, которая бы их проводила правильно, поэтому я бы просто рекомендовал их вообще не проводить. Такж нет смысла их проводить, если ваша команда распределена географически. Но если же вы считается что стендапы вам необходимы, то не буду вас от них отговариавть. Делайте как считаете лучше для своей команды. 64 | 65 | 66 |
67 | 68 | > Должны ли мы делать все в точности как описано в данных статьях по Agile Lite? 69 | 70 | Нет, конечно. В статьях указаны рекомендации, а не беспрекословные требования. 71 | 72 | 73 |
74 | 75 | > Согласны ли вы с тем, что то, что работает для вас, может не работать для остальных? 76 | 77 | Конечно, да. 78 | 79 | 80 |
81 | 82 | ## Замечания 83 | 84 | > Вы не должны точно оценивать сроки выполнения задач, т.к. точные оценки невозможны. 85 | 86 | Все наши оценки задач мы должны рассматривать как приблизительные. Поэтому, зачастую, от оценок луше отказаться. Просто делайте качественно свою работу и оценивайте ее в интервале 4 часов своего рабочего времени. Например, успею ли я сделать это за 4 часа и т.д. 87 | 88 | 89 |
90 | 91 | > Разработчикам нельзя доверять, за ними нужно следить, и они должны постоянно отчитываться о проделанной работе. Потому что только так делается работа. 92 | 93 | Абсолютно не согласен с данным утверждением. Я не смогу вам быстро объяснить почему это утверждение неверно, но скажу, что если вы так действительно считаете, то у нас с вами разные точки зрения на то, как должна быть организована работа команды разработки. 94 | 95 | 96 |
97 | 98 | > То что вы описали здесь это не Agile 99 | 100 | Нет, не верно. Все что тут описано, это и есть методология Agile. 101 | 102 | 103 |
104 | 105 | > Это никогда не будет работать 106 | 107 | Но это работает. 108 | 109 | 110 |
111 | 112 | > Вы неправильно трактуете и используете методологию Agile 113 | 114 | К сожалению, проблема методологии Agile в том, что она не может быть сделана правильно =) 115 | Каждый ее делает по-своему. 116 | -------------------------------------------------------------------------------- /spanish/README.md: -------------------------------------------------------------------------------- 1 | # Agile Lite: ágil, sin todo el agotamiento 2 | 3 | El "desarrollo de software ágil" es una gran idea que ha sido complicada por las industrias de publicación y consultoría. Agile Lite es un intento de simplificar la situación. No necesita un libro o un taller para explicar Agile Lite. Solo necesitas un archivo de texto con varios párrafos. Este es ese archivo de texto. 4 | 5 | Agile Lite es bastante simple. Se puede aplicar a cualquier proyecto con personas que trabajan en él, asumiendo que el trabajo se puede dividir en tareas de componentes más pequeños que solo llamaremos Issues. Al igual que otras metodologías ágiles, utiliza ciclos de desarrollo cortos llamados Sprints. De manera un tanto única, Agile Lite reconoce explícitamente la prevalencia de agotamiento en la industria de desarrollo de software e intenta mitigarla directamente a través de un ciclo de desarrollo de 3 semanas / 1 semana fuera. 6 | 7 | La configuración básica es esta: 8 | 9 | * La primera semana de cada mes se pasa con los líderes del proyecto y las partes interesadas que definen el próximo `sprint`. A pesar de que se asigna una semana, una sesión de planificación de sprint no debe tomar más de 2 horas y probablemente unos 45 minutos si se realiza correctamente. Es una semana intencionalmente ligera y muchas personas simplemente pueden tomarse el tiempo para pintar o surfear o lo que sea. 10 | 11 | * El `sprint` tiene lugar durante las 3 semanas restantes del mes. Durante este período, los ingenieros trabajarán en los Issues que se les asignaron durante las sesiones de planificación de sprint. Debido a que el equipo puede estar totalmente remoto y distribuido en zonas horarias, las reuniones "en vivo" ocurren con poca frecuencia y la mayoría de las comunicaciones se realizan a través del `issue tracking system` (que es más rápido para trabajar que el correo electrónico). Un tablero kanban compartido como Trello es un sistema de seguimiento de problemas suficiente, pero probablemente no lo sea una hoja de cálculo. Se desalientan las reuniones diarias; se puede obtener un impulso básico en el proyecto revisando las actualizaciones del sistema de seguimiento de problemas. 12 | 13 | * Una vez que ha comenzado un `sprint`, los Issues no se pueden agregar al sprint, pero se pueden eliminar. Esto reduce el cambio de contexto y eso es algo bueno. 14 | 15 | * Los Issues que no se completaron durante el sprint se revisan en la próxima sesión de planificación del sprint y se decide si se avanza el Issue al próximo sprint, se vuelve a poner en el Backlog o se vuelve a asignar a un desarrollador diferente. 16 | 17 | * Un problema está en el `backlog` o en el `sprint actual`. 18 | 19 | * Como se mencionó, se recomienda a los desarrolladores que tomen la semana de planificación para permitir que su cerebro se recupere del sprint anterior. No hay marchas de la muerte. Los desarrolladores no trabajan los fines de semana. Todo esto ayuda a evitar el agotamiento. Evitar el agotamiento es bueno para todos. 20 | 21 | Eso es practicamente todo. El sistema no prescribe realmente prácticas de ingeniería y creo que eso está bien. Las prácticas de ingeniería se pueden definir a nivel de proyecto. 22 | 23 | El trabajo de soporte se realiza de forma rotativa porque a veces las cosas suceden de forma inesperada y deben tratarse, pero un número sorprendente de problemas puede esperar hasta más tarde.. 24 | 25 | Agile Lite es una forma mejor y más sostenible de desarrollar software. Empodera a los desarrolladores de software al tiempo que ofrece un nivel de productividad consistente y sólido a los interesados en el proyecto. 26 | 27 | Para obtener más información sobre Agile Lite, te animo a leer: 28 | 29 | [Agile Lite para desarrolladores](agile_lite_for_developers.md) 30 | 31 | [Agile Lite para gerentes](agile_lite_for_managers.md) 32 | 33 | 34 | --- 35 | Si desea ver más lugares de trabajo implementando un sistema como este, dele una estrella a este repositorio en github y compártalos en las redes sociales para aumentar la visibilidad. 36 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 37 | -------------------------------------------------------------------------------- /spanish/agile_lite_for_developers.md: -------------------------------------------------------------------------------- 1 | # Agile Lite para desarrolladores 2 | 3 | Si ha estado trabajando en la industria del software durante más de unos pocos años, posiblemente haya experimentado agotamiento. Hay muchas razones para el agotamiento, pero puede describirse simplemente como el resultado de trabajar demasiado, bajo mucho estrés, durante demasiado tiempo. 4 | 5 | Comienza con un proyecto. Ese proyecto tiene una especificación detallada y una fecha límite. Cuando la especificación cambia, la fecha límite no lo hace. Finalmente, la fecha límite llega y se va y la especificación se ha convertido en algo diferente de donde comenzó. Por supuesto, esto se considera su culpa y se le pide que se quede tarde o que se comprometa a "cumplir los objetivos". Eventualmente, llegará todos los fines de semana y no importa cuánto trabaje, su gerente nunca está contento y el proyecto está perpetuamente "atrasado". 6 | 7 | Querer tiempo libre o vacaciones te hace parecer un vago. Te hace parecer como si fueras quien sostiene a tu equipo. Quizás trabajas en un entorno de oficina abierta; todos saben cuándo llegas allí, todos saben cuándo te vas y todos firman un contrato tácito para no ser la persona que no está trabajando más duro. Así que la gente se ve bien ocupada, y cada vez que alguien te pregunta cómo te va, simplemente respondes: "¡Ocupado! ¡Estoy tan ocupado!" 8 | 9 | Pero al final algo da. Quizás cambie de trabajo, pero es más de lo mismo en otras compañías en la industria del software. Tal vez lo mantengas hasta que no quede nada y luego la compañía te deje ir porque simplemente "no encajas en cultura". Tal vez renuncies y tomes un trabajo vendiendo autos porque la programación es demasiado frustrante. Como dicen, si quieres matar la alegría en un pasatiempo, trata de hacerlo para vivir. 10 | 11 | Estoy proponiendo una solución. Es una forma de ágil que está diseñada explícitamente para ayudar a evitar el agotamiento. Yo lo llamo Agile Lite. 12 | 13 | * La regla más básica es esta: cada mes incluye un sprint de 3 semanas y una semana "off" donde se realiza la planificación del sprint. 3 semanas de desarrollo / 1 semana de descanso. 14 | 15 | * Un sprint contiene Issues y los ingenieros resuelven Issues, registran las preguntas pertinentes y actualizan el Rrastreador de Problemas(Issue Tracker). 16 | 17 | * Una vez que el sprint ha comenzado, los Issues no se pueden agregar al sprint, pero se pueden eliminar. Esto reduce el cambio de contexto y eso es algo bueno. 18 | 19 | * Un Issue es cualquier unidad de trabajo que deba tomar entre 4 y 8 horas de esfuerzo de ingeniería. Un Issue está en el sprint actual o en el backlog. 20 | 21 | * Cualquier Issues en el sprint actual que no se haya completado al final del sprint se revisará durante la semana de planificación del sprint. 22 | 23 | * No hay horas extras de trabajo. No puede haber marchas de la muerte. A los ingenieros se les asigna una cadencia mensual de trabajo y se les da tiempo suficiente para recargar sus cerebros. La sobrecarga de gestión es mínima. 24 | 25 | Eso es prácticamente todo el sistema. Puede ser modificado para adaptarse a sus propósitos. Pero si hay un diferenciador de Agile Lite que me gustaría señalar, es que estamos diciendo explícitamente: "Oye, los equipos ágiles se están agotando tanto como otras metodologías de desarrollo, tal vez necesitamos construir reglas explícitas para evitar el sobrecalentamiento. El motor que es el equipo de ingeniería ". 26 | 27 | Dejemos de sobrecalentar nuestros motores. Hay mucho trabajo que hacer por ahí. Un pozo sin fondo, de hecho. Pero la vida es demasiado corta para gastarla trabajando, estresada y, finalmente, agotada. 28 | 29 | --- 30 | Si desea ver más lugares de trabajo implementando un sistema como este, dele una estrella a este repositorio en github y compártalos en las redes sociales para aumentar la visibilidad. 31 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 32 | -------------------------------------------------------------------------------- /spanish/agile_lite_for_managers.md: -------------------------------------------------------------------------------- 1 | # Agile Lite para gerentes 2 | 3 | ¿Trabajar con desarrolladores de software ha sido un desafío para su empresa? ¿Has visto proyectos que constantemente faltan plazos? ¿Ha trabajado con desarrolladores que comienzan bien y luego declinan lentamente y luego desaparecen? Puede que simplemente esté tratando con un desarrollador talentoso que haya experimentado agotamiento en su proyecto. 4 | 5 | El agotamiento es extremadamente común en la industria del software y es una razón clave por la que muchos proyectos de software fallan. El agotamiento se puede describir mejor como síntomas del trastorno por estrés postraumático que están conectados a un proyecto u organización en particular. Por ejemplo, su cerebro podría apagarse y podría sentirse extremadamente ansioso por la mera mención de un determinado proyecto. Esto es agotamiento. Un desarrollador en tal estado probablemente no podrá continuar trabajando en ese proyecto y también puede experimentar una disminución de la productividad en sus próximos proyectos. El agotamiento puede paralizar las carreras. 6 | 7 | Hay muchas razones para el agotamiento, pero la razón más básica es que es el resultado de trabajar demasiado, bajo mucho estrés, durante demasiado tiempo. 8 | 9 | Es como hacer funcionar un motor de automóvil a altas RPM durante mucho tiempo sin agregar aceite o gasolina. Eventualmente, el motor se romperá y será difícil volver a armarlo. 10 | 11 | Estoy proponiendo una solución. Es una forma de ágil que está diseñada explícitamente para ayudar a evitar el agotamiento. Yo lo llamo Agile Lite. 12 | 13 | * La regla más básica es esta: cada mes incluye un sprint de 3 semanas y una semana "off" donde se realiza la planificación del sprint. 3 semanas de desarrollo / 1 semana de descanso. 14 | 15 | * Un sprint contiene Issues y los ingenieros resuelven Issues, registran las preguntas pertinentes y actualizan el Rrastreador de Problemas(Issue Tracker). 16 | 17 | * Un Issue es cualquier unidad de trabajo que deba tomar entre 4 y 8 horas de esfuerzo de ingeniería. Un Issue está en el sprint actual o en el backlog. 18 | 19 | * Una vez que el sprint ha comenzado, los Issues no se pueden agregar al sprint, pero se pueden eliminar. Esto reduce el cambio de contexto y eso es algo bueno. 20 | 21 | * Cualquier Issues en el sprint actual que no se haya completado al final del sprint se revisará durante la semana de planificación del sprint. 22 | 23 | * No hay horas extras de trabajo. No puede haber marchas de la muerte. A los ingenieros se les asigna una cadencia mensual de trabajo y se les da tiempo suficiente para recargar sus cerebros. La sobrecarga de gestión es mínima. 24 | 25 | Eso es prácticamente todo el sistema. Puede ser modificado para adaptarse a sus propósitos. Pero si hay un diferenciador de Agile Lite que me gustaría señalar, es que estamos diciendo explícitamente: "Oye, los equipos ágiles se están agotando tanto como otras metodologías de desarrollo, tal vez necesitamos construir reglas explícitas para evitar el sobrecalentamiento. El motor que es el equipo de ingeniería". 26 | 27 | Dejemos de sobrecalentar nuestros motores. Hay mucho trabajo que hacer por ahí. Un pozo sin fondo, de hecho. Pero la vida es demasiado corta para gastarla trabajando, estresada y, finalmente, agotada. 28 | 29 | --- 30 | Si desea ver más lugares de trabajo implementando un sistema como este, dele una estrella a este repositorio en github y compártalos en las redes sociales para aumentar la visibilidad. 31 | Dave Sullivan 2019 dave.brian.sullivan@gmail.com 32 | --------------------------------------------------------------------------------