如何停止匆忙抓鸡蛋，同时缩短截止日期？ 选择哪个工具链一次销毁多个任务？ 我们将在文章中揭示所有这些内容。
试图抓住所有的鸡蛋
那时，我们公司刚好在办公室里充满阳光的玻璃子宫中兴起，而团队只有三名员工（一名经理和两名开发人员），热情而富有咖啡，我们绝对没有项目管理方法，而是直觉地采取行动，按照“一个人，一个项目”的原则开展工作。 同时，开发人员在同一个任务中进行交互，在他们之间持有单独的代码，而开发环境的整个格局都挂在开发人员的机器上，这甚至不是事实。 然后，作为存储库和版本控制系统，我们使用了
SVN ，它当时更像是带有zip归档程序的文件夹。 尽管SVN是最大的版本控制系统之一，并且拥有适当的社区，但其功能仅在保存代码方面适合我们，否则一切都有些糟糕：没有本地版本，也没有合并代码的能力。 因此，我们开始寻找更适合自己胃口的东西-开始开发工作流程。 需要解决的第一件事是任务的计划和设置，以及任务之间的相互分配，以便摆脱单射性，共同制定和维护期限。 当时，唯一的计划类型是与笔记本会议。 通过这种方法，在效率和效率之前，就像哥萨克的月亮一样，有人设法记下了一切，有人忘记了或忘记了。 结果，人们离开会议时并不清楚自己的操作方式和方法，头脑中堆砌了很多信息，笔记本中还夹了几个涂鸦。
我们选择一个工具链
减少工作流程熵的第一步是创建一个正常的存储库，以便在项目上一起工作并连接代码的各个部分。 我们扔掉了一个旧的SVN，并在我们首席执行官的本地计算机上提高了
GIT 。 要查看和连接代码，请使用简单的控制台实用程序。 它不是很方便，但是至少它可以保持项目变更的顺序和透明性。
我们仍然在规划方面存在问题，因此，在截止日期之前仍然存在问题。 为此，有必要找到一种分解任务并显示其执行状态的方法。 解决该问题的尝试是使用RedMine项目管理应用程序，从此开始对工具链进行主动基准测试。 该实用程序非常适合开发人员（项目管理功能，论坛，错误跟踪），但是不幸的是，这对管理人员来说非常困难。 开发人员必须不断处理来自SUV的所有信息（merzhrekvesta，pullrekvesta等），并将其输入
RedMine程序，以便管理人员可以跟踪任务的完成程度。 除此之外，项目管理功能还不够多，因此我们开始
关注FengOffice 。
该工具具有相当广泛的功能，可以梦想将甘特图之类的交流和计划工具组合到单个工作系统中。 但是，使用该产品的所有设备，开发人员必须手动关闭任务，同时自行编辑统计信息，因为没有自动同步执行的任务。 此外，内部聊天的实现更像是类似于ICQ的旧版本，而不是普通的公司聊天，但是对我们而言，这一刻非常重要。
我们知道，为了使整个机制和谐地工作，简单的会议显然是不够的。 有必要选择用于建立短通信的操作工具，即使在同一房间内彼此相邻的人也需要这种工具。 这里有两点：第一-如果您以通常的方式进行简短的交谈，那么它们将占用太多的工作时间，这意味着所有截止日期的崩溃和时间表的严重滞后；第二-如果您进行的短暂互动最少，这将导致损失团队成员之间的密切沟通，他们的行为不一致，代码重复以及其他麻烦。 因此，我们想到了一个简单的解决方案-将微会议转移到团队聊天中，这使您能够持续进行交流而不会从工作流中分散注意力，协调开发人员的行动并避免重复执行相同的任务，以及避免谁更好地执行任务的争议。 解决方案看起来似乎很简单，但问题不在于交互方式，而在于工具的使用方法和质量。 问题是如何将聊天室从充斥和烧毁的地方变成部分替代会议和个人对话的地方。
同时，普通的GIT还远远不够，因为缺少Web界面。 菜单上有两个选项：GitHub上的私有存储库和GitLab上的存储库。 GitLab是免费的-他们接受了它。 他还有一个很酷，友善的社区。 此外，GitLab已经具有内置的任务计划系统，并为merzhrekvest提供了方便的界面。 如果您是团队合作者，那么您可能知道快速获得批准的Merzhrekvest的重要性。 最终，我们掩埋了FengOffice，并选择了GitLab。 而且，那时我们已经将Slack用作团队聊天，并且考虑到GitLab计划与Slack相互集成，而且所有这些东西都是免费的，因此对我们的选择比以往更加明显。
书没有说谎
然后是时候，有必要为我们的灵活项目管理选择最合适的方法了。 我们选择了两种最发达和最受欢迎的方法：看板和Scrum。 该倡议完全来自我们的首席执行官Ilya Bykoni，他眼中的普罗米修斯之火向团队介绍了即将发生的变化。 但是令他大吃一惊的是，团队最初遇到了创新，因为斯巴达人遇到了保守派的顽固顽强的Xerxes。 幻想，幻象，你能做什么，因为他们在书中警告。。。一个有趣的事实立即被注意到：对新方法的消极态度与人们的工作能力和能力无关。 即使是本应轻松掌握所有这些内容的年轻六月，他们也拒绝说：“他们的节目安排比他们第二天的时间要好15分钟”，“如果最后期限仍然存在，您为什么需要计划？没有执行或正在执行，但有偏差“，”前端开发人员为什么要听后端”等。 事实是，敏捷方法论蕴含着一种工作风格，在这种工作风格中，就像许多人已经习惯了那样，不可能坐在一个强大的开发人员的亚特兰蒂斯肩膀上去学习他的技能项目，所以这种改变对他们来说痛苦的。
当我们开始将敏捷引入工作中时，我们充分感受到了简短和高质量通信的价值。 经常发生这样的情况：当类似的任务来自RnD部门从多个来源输入的信息时，项目经理无法捕获重复项。 在这里，通过确定不同团队的开发人员之间的共同点，可以完全避免此类问题的短期互动和日常集会开始发挥非常重要的作用。 还有一个有趣的观点-大多数程序员都是性格内向的人，也就是说，任何交流都是微不足道的，尤其是在大型团队的集会中，一个人必须与各种各样的专家交流。 而且，许多人由于担心这种不适而没有意识到，举行这种简短会议的替代方法比每天召开的会议更加令人不快。 这将被全天不断的交流所代替，试图将工作带入受控流程。 就我们自己而言，我们得出的结论是，敏捷考虑了开发人员的内向性，并将与沟通需求相关的不适感降至最低。 当然，在任何情况下，对于公司的年轻员工而言，这将在一段时间内给他带来压力，直到他深入研究自己的工作细节并更深入地了解团队为止，因此，敏捷文化在公司中越友好和高效，适应过程就会越快结束。
一棍伤人，许多棍伤人
灵活方法的主要动机之一是使人们习惯于最小化其fakapy和bug。 事实是，如果您采用标准的垂直管理结构，则开发人员应对直属上司的错误负责，如果上司f脚，则由上司惩罚并“用头顶击打”；如果一切都做得清楚，则““头”。 也就是说，在垂直结构中，一个人可以选择由于个人关系或“美味饼干”反弹。 在敏捷中，团队互动是水平构建的，这意味着一个人必须每天聚会时向整个团队报告。 他只是愚蠢地没有足够的钱来买这么多饼干。 因此，您必须习惯于这样的事实，即您的错误将由同事进行审查，或者您会骑马，他们会因对您的专业水平的赞美而向您浇灌玫瑰花瓣，或者您会骑马下...无论如何，这都是一个人的个人技能的强大体现，并且如果公司中的气氛足够温暖，那么这个人就会开始慢慢地开放，从而为他的部门和整个公司的生态系统做出越来越大的贡献。 我们还从经验中体验了敏捷的过滤效果，不止一次地遇到客观弱小的开发人员无法忍受对错误进行持续分析的情况，并且如果他们意识到自己缺乏内在的动力和力量，最终只能合并。从Bagodel状态切换为Bogacode状态。
总结一下
我必须说，搭建敏捷机器的过程非常漫长且充满压力，``没有暴力就不可能做到''-最初，人们实际上必须坚持集会和日常活动，以使人们以某种方式开始对自己要解决的任务表达自己的立场。 尽管我们经常需要“爬到引擎盖下”并修理“引擎”，让我们的双手沾上燃油，但当车队加快速度并向前冲，为检查点收集检查点时，这是值得的。 我们甚至不会停止发展，我们始终处于永恒的货运代理地位，不断研究新知识并修改现有的管理模式以及员工之间的互动。 我们绝对可以肯定的一件事-没有运动和斗争，就没有生命。 正如禅宗僧侣所说：“我到达了山顶，继续攀登……”祝您攀登中的每个人都好运，无论如何，让每个人都登上山顶！
PS：
以下是示例列表和我们执行步骤的时间：
- 计划形成〜4个月
- 短时间沟通〜1个月
- 寻找合适的工具链和工作流程开发〜2个月
- 选择方法〜2个月
- 将Scrum引入工作流程〜8个月
以下是我们首席执行官的一小部分选择：
- 理解敏捷-Andrew Stellman和Jennifer Green
- “ Scrum-Master的方式”-Zuzan Shokhov
- “ Scrum A Revolutionary Project Management Method”-杰夫·萨瑟兰（Jeff Sutherland）
- “看板替代敏捷方法”-David Anderson
- “处于变革的顶端。 敏捷和DevOps原理在整个公司中的应用“-Harry Gruver和Tommy Mauser