有些 团队中会要求每个成员每天对自己的工作进度以百分比的形式做汇报，他们以为通过这样的方式可以确实的掌握事情的进展，但实际上并不行，因为软件开发中存在很多不确定因素，有时候我们认为事情已经完成了一大半，但是可能因为技术或者其他的原因发现这一大半工作方向是错的，这时候就要推倒重来，而且人们在汇报工作量的时候总是会有一些感情的因素在里面，这就使那些看似精确的百分比打了个折扣。
所以，我们需要更加实际和细致地划分工作，对目标的完成情况进行度量。这也是迭代周期不能太长的一个原因：如果你把大量有前后关联的工作划分入一个迭代周期，在设定的结束到来时，突然发现只完成了一小部分，这时候虽然亡羊补牢仍然可以，但是中间浪费了大量的人力和物力。
反馈
一个男人在大街上走着，他并没有发现裤子上的拉链已经松开了，虽然看到这个情况的人有很多，但他们有各种各样的担心，比如不想多管闲事，怕让那个男人难堪，或者干脆就是想看笑话。结果就是这个人继续穿着一条敞开拉链的裤子在大街上行走。
这件事情至少带给我们两个启示：1，得到反馈是重要的；2，要想得到正确的，有价值的反馈，你需要其他人的配合。
对于用户需求来说，没有用户及时地反馈，我们就可能把那些不符合需求的开发继续下去，由于软件中各种功能和模块的依赖性，这种不符合最后可能被放大到数倍。越迟得到反馈，问题可能就越大。
软件开发中一个很重要的概念是“可行性”和“合理性”，无论我们做需求，设计还是开发，集成，测试，都会遇到这两个问题。有些事情的可行性和合理性是我们可以通过事前的分析进行判断的，但是有些问题就必须有一定的实践作为基础。这也是一个反馈的问题。譬如说在某项目中技术架构师决定采取一个技术架构，但是经过一些阶段的开发发现它有一些技术上问题不能实现用户的关键需求，这时候就必须放弃它。
“反馈”意味着两个意思，对一件事情的调查和根据调查做出决策。
在意识到反馈的重要性之后，你会要求所有的人都对迭代的成果做出反馈。可能存在的问题是，是不是所有的人都意识到了反馈的重要性并且认真地去做了呢？如果客户认为他们只需要对迭代出来的产品“看看而已”，那么你就很难了解他们一些深层次的想法。再比如一次迭代中某些模块开发的进度比较慢，开发人员可能会抱怨技术方案不能满足要求，而实际的原因可能是设计不合理或者根本就是有人没有认真工作。
中国国家队前主教练米卢曾经说过“态度决定一切”，反馈作为迭代开发中至关重要的一个方面，必须得到足够的重视。
获得反馈的方式和对于反馈信息的分析是另外一个重要的方面。一般来讲，根据软件开发角色的不同，我们非常关注的是两类人的反馈：项目组之外的客户和项目组之内的各种实施人员。
软件项目一般都会要求客户方安排专门的业务人员进行配合，在迭代开发中，这种配合不只是进行需求的整理和发掘，还包括对已经完成软件版本的评测。在这个过程中应该有需求分析师的配合。
在每次迭代完成之后，软件项目组应该有一些总结和分析活动。通过这些总结和分析，找到做得好和做得不好的方面。
在非迭代式的开发中，也有反馈的环节。比如通常在软件交付阶段会有一个试用期让用户提出意见。而软件团队在各种开发中都会有一些总结活动。迭代式开发的独特之处在于尽量早地引入反馈机制；使得反馈机制更加制度化；并且，更加快速和灵活地分析这些反馈，把得到的结论应用到下一阶段的开发中去。
对于一些机制引起的问题，比如组织结构不合理，角色分配不明确之类。最好有一个明确的问题记录表。在每次迭代完成以后将这些问题记录下来，同时在下次迭代中努力改善它。如果相同的问题连续出现在几次迭代中，可能就说明项目管理出了问题。
合作
软件团队中的合作是人们一直都在提倡的。我们在这里提到“合作”的意思并不只包含团队内部的协作，还包括和客户的合作。
文章来源于领测软件测试网 https://www.ltesting.net/
