对敏捷宣言的一些理解

对敏捷宣言的一些理解:1。工作软件高于详细文档我今天和几个学生讨论了敏捷实践的一些细节，重点讨论了设计文档是否应该实时更新。我知道有必要更新，没有更新，没有视觉上的接受标准，一些同学的意思是，如果一个标点符号要修改，工作量太重，最后讨论，最后，有人提到了经典的问题：敏捷宣言并不是说工作如此。ftware是否高于详细文档？我们为什么要维护这些文件？上述问题是敏捷开发过程中经常遇到的经典问题之一，也是许多团队敏捷转型失败的根本原因之一。接下来，我将解释为什么这种理解是错误的。这个网站是敏捷宣言的官方网站：超链接敏捷宣言如果您访问此网站，可以看到此图片：敏捷宣言敏捷宣言确实明确地说“工作软件比详细的文档更高”，但在敏捷宣言的底部，还有一句话：补充价值表换句话说，尽管正确的术语有价值，我们更看重左边。也就是说，详细的文档并不是不必要的，但是其值没有左边的工作软件那么高。我已经和公司的几位敏捷教练谈过文档是否需要，他们明确的回答是，文档，如一般设计、详细设计等，如传统的瀑布式开发，是不必要的，但文档，如接口文档、DESIGN文件不仅是必要的，而且是正确的。过程和工具上的个人和交互同样的问题也出现在个人和交互的申报过程和工具中，我和多个团队有过类似的情况：测试人员直接发现bug，口头告知开发，然后自己改变，在大多数情况下，这个过程不会是问题，但不会是问题。排除了个人的疏忽，导致在线版的执行有一定的缺陷，但没有修复就被发现了，这种情况很烦人，是测试出的缺陷，但没有修复，测试又没有返回。在团队的后期，我会要求每个人把所有的bug提交给JIRA，但是团队中几乎每个人都会跳出来说：必须记录大的bug，不应该记录小的bug，对吗？在问这个问题时，很多人还接受了敏捷宣言“个人与过程和工具之间的交互”，并认为我的请求违反了敏捷宣言：语言交流缺陷是关于更多交互的，而我使用JIRA的请求强调工具，而不是光。个人理解：个人和过程和工具上的交互的宣言强调交互，但是这里的交互应该是关于需求理解、通信和协作，而不是工作流。一套好的过程和工具可以清楚地知道他们在某个阶段应该拥有什么样的可交付成果，在某个里程碑上应该取得什么样的具体工作成果，等等。作为一个Scrum大师，改进团队的交互、明确团队的目标并带来根据过程找出个人的价值。以下是我们的一位敏捷教练在阅读本文后添加到这份宣言中的内容：工作流不具有非通信性。只需确保团队中的工作进展状态是公平的，而不是每个人都想改变。工作流沟通是关于共识的，而不是每个人在没有共识的情况下按照自己喜欢的方式工作。三。再声明两次事实上，敏捷宣言超越了这两点：过程和工具上的个人和交互工作软件高于详细文档还有两个：合同谈判中的客户协作应对变化总比遵循计划好。我从未听过有人这样说：客户合作高于合同谈判，所以我们没有任何合同谈判，只要客户需要，我们做，客户要多少钱才能收到多少钱！响应变化比遵循计划更重要，所以我们根本就不要制定任何项目计划，我们只是做我们想做的，我们想做的就做！因为当它被说出来的时候，每个人都知道它是错误的。但根据我的经验，公平地说，几乎每个新团队在解释前两个宣言时都存在问题。我被打了很多次，终于明白了以上的道理，我希望能帮助你。对敏捷宣言的一些理解