有本关于敏捷开发方面的书非常不错《高效程序员的45个习惯-敏捷开发修炼之道》，Venkat Subramaniam和Andy Hunt著，该书简短、易读、精炼、深入，深刻且实用。对于想要采用敏捷方法的人很有价值。此书通过常理和经验，阐述了为什么应该在项目中实用敏捷方法。更难得的是，这些行之有效的实战经验，竟然从一本书中得到了。如果能拿这些习惯在项目中一以贯之，肯定会受益匪浅。下本罗列该书这45个习惯，一并列出其中的Key Point.
态度决定一切
【习惯01】做事
问题出来了，重点放在解决问题上，而不是在指责犯错者上纠缠。
动机要明确，重点是做事，不是为了自己的面子，也不是为了指责，也无意个人智力决斗。
过程符合标准并不意味着结果是正确的。敏捷团队重结果胜于重过程。
指责不会修改bug.把矛头对准解决问题的办法，而不是人。这是真正有用处的正面效应。
一个重大的错误应该被当是一次学习而不是指责他人的机会。团队应该互帮互助，而不是指责。
【习惯02】欲速则不达
千里之堤毁于蚁穴，大灾难是逐步演化来的。一次又一次快速修复每一次都不探究问题的根源，久而久之就形成了一个危险的沼泽地，最终会吞噬整个项目的生命。
在工作压力下，不去深入了解真正的问题以及可能的后果，就快速修改代码，这样只能解决表面问题，最终会引发大问题。
重构代码之前必须彻底理解它，否则就不能进行有效的改变！
实行代码复审，不仅有助于代码更好理解，而且是发现bug最有效的方法之一。
不要坠入快速的简单修复之中。要投入时间和精力来保持代码的整洁、敞亮。
【习惯03】对事不对人
面对一个明显的错误最好的反应:询问你的队友并提出你的顾虑。–没有谴责，没有评判，只是简单的表达自己的观点。整个团队要关注真正有价值的问题，而不是勾心斗角，误入歧途。
好的软件产品和好的软件设计，都需要大量的创造力和洞察力。分享并融合各种不同的想法和观点，远远胜于单个想法为项目。带来的价值。负面的评论和态度会扼杀创新。
把问题重点放在解决问题上，而不是去极力证明谁的主意更好。
经常提出自己的观点和建议，记住，任何一个专家都是这么开始的。你不需要很出色才起步，但必须起步才能变得很出色
让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好。
【习惯04】排除万难，奋勇前进
有时，绝妙的计划会因为勇气不足而最终失败。尽管前方很危险，你必须有勇气向前冲锋，做你认为对的事情。
践行良好的习惯。
做正确的事。要诚实，要有勇气去说出实情。有时,这样做很困难，所以我们要有足够勇气。
有时候勇气是扫除障碍的唯一途径，否则问题会一直恶化下去。鼓起勇气从克服恐惧开始。
如果没有理解那段代码，不要轻易地否定和重写它们。那不是勇气，而是鲁莽。
学无止境
【习惯05】跟踪变化
唯有变化是永恒的
迭代和增量式的学习
了解最新的行情
参加本地的用户组活动
参加研讨会议
如饥如渴地阅读
不需要精通所有的技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。
你不可能精通每一项技术，也没有必要这样做。
只要你在某些方面成为专家，就能使用同样的方法，很容易成为新领域的专家。
【习惯06】对团队投资
一个学习型的团队才是较好的团队
午餐会议是在团队中分享知识非常好的方式。
总是要成为你所在的团队中最差的一位。这样才有动力超越他们。
坚持有计划有规律地举行讲座。持续、小步前进才是敏捷。稀少、间隔时间长的会议非敏捷也。
通过午餐会议可以增进每个人的知识和技能，并能帮助大家聚集在一起进行沟通交流。
【习惯07】懂得丢弃
敏捷的根本之一就是拥抱变化。既然变化是永恒的，你有可能一直使用相同的技术和工具吗?
相比而言，开发者的时间才是紧缺和昂贵的资源。
需要耗费10人年开发的J2EE项目已经从辉煌走向下坡路。PHP,Ruby on Rails这样的框架越来越受到关注。
只有更少被旧习惯牵绊，才容易养成新习惯。
学习新的东西，丢弃旧的东西。在学习一门新技术的时候，要丢弃会阻止你前进的旧习惯。
毕竟汽车要比马车车厢强得多。【习惯08】打破砂锅问到底
在理解一个问题的时候，需要渐次地问5个以上的为什么。
不停地问为什么。不能只满足于别人告诉你的表面现象。要不停地提问直到你明白问题的根源。
好比是从矿石中采掘贵重的珠宝。要不停的筛选无关的物质，一次比一次深入，直到找到发光的宝石。
你要能感觉到真正地理解了问题，而不是只直到表面的症状。
在提问之前，想好你提问的理由，这会有助于你问出恰当的问题。
【习惯09】把握开发节奏
要养成这样的习惯，在那时就准备好一切参加站立会议。
不管你的一个迭代是多长，都应该坚持–确保每个迭代周期的时间相同很重要。
解决任务在事情变得一团糟之前。保持事件稳定重复的间隔，更容易解决常见的重复任务。
项目开发需要有一致和稳定的节奏。如果知道什么时候开始下一个节拍，跳舞就会更加容易。
交付用户想要的软件
【习惯10】让客户做决定
在设计方面，做决定的时候必须有开发者参与。
开发者能做的一个最重要的决定就是:判断哪些是自己决定不了的，应该让企业主做决定。
让你的客户做决定。开发者、经理或者业务分析师不应该做业务方面的决定。
用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。
业务应用需要开发者和业务负责人相互配合来开发。
【习惯11】让设计指导而不是操纵开发
设计是软件开发过程不可缺少的步骤。
设计满足实现即可，不必过于详细。
做到精确，如果你自己都不清楚所谈论的东西，就根本不可能精确地描述它。
战略级别的设计不应该具体说明程序方法、参数、字段和对象交互精确顺序的细节。那是战术设计的任务。
不要一开始就进行战术设计，它的重点是集中在单个的方法或数据类型上。
这时，更适合讨论如何设计类的指责。因为这仍然是一个高层次、面向目标的设计。
好设计是一张地图，它也会进化。设计指引你向正确的方向前进，它不是殖民地，它不应该标识具体的路线。
你不要被设计操纵。
好的设计应该是正确的，而不是精确的。
计划是没有价值的，但计划的过程是必不可少的。
【习惯12】合理地使用技术
盲目地为项目选择技术框架，就好比是为了少交税而生孩子。
代码写的越少，需要维护的东西就越少。
不要开发你能下载到的东西。
要考虑:这个技术框架真能解决这个问题吗? 你将会被它栓住吗? 维护成本是多少。
根据需要选择技术。首先决定什么是你需要的，接着为这些具体的问题评估使用技术。
对任何要使用的技术，多问一些挑剔的问题，并真实地作出回答。
【习惯13】保持可以发布
任何时候只要你没有准备好，那就是敌人进攻你的最佳时机。
已提交的代码应该随时可以行动。
简单流程。在本地进行测试->检出最新的代码->提交代码.
最好的办法，应该有一个持续集成系统，可以自动集成并报告集成结果。
保持你的项目时刻可以发布。保证你的系统随时可以编译、运行、测试并立即部署【习惯14】提早集成，频繁集成
敏捷的一个主要特点就是持续开发。
你能一边进行集成，一边进行独立开发。使用mock对象，编写独立的单元测试，而不需要立刻就集成和测试。
绝不需要做大瀑布式的集成
代码集成是主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律地进行集成。
成功的集成就意味着所有的单元测试不停地通过。【习惯15】提早实现自动化部署
质量保证人员应该测试部署过程。
如果现在还是手工帮助质量保证人员安装应用，花一些时间，考虑如何将安装过程自动化。
一开始就进行全面部署，而不是等项目的后期，这会有很多好处。
使用部署系统安装你的应用，在不同的机器上用不同的配置文件测试以来的关系。
质量保证人员要像测试应用一样测试部署。【习惯16】使用演示获得频繁反馈
需求就像是流动着的油墨
应该定期地，每隔一段时间，比如说一个迭代，就与客户会晤，并且演示你已经完成的功能特性。
要频繁地获得反馈
清晰可见的开发。在开发的时候，要保持应用可见。
每隔一周或两周，邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。
演示是用来让客户提出反馈的，有助于驾驭项目的方向。【习惯17】使用短迭代，增量开发
统一过程和敏捷方法都使用迭代和增量开发。
迭代开发是，在小而重复的周期里完成各种开发任务:分析、设计、实现、测试和获得反馈，所以叫迭代。
给我一份详细的长期计划，我就会给你一个注定完蛋的项目。
对付大项目，最理想的办法就是小步前进，这也是明捷方法的核心。
发布带有最小却可用功能块的产品。每个增量开发中，使用1`4周左右迭代周期。
短迭代让人感觉非常专注且具效率。你能看到一个实际并且确切的目标。
严格的最终期限迫使你做出一些艰难的决策，没有遗留下长期悬而未决的问题。【习惯18】固定的价格就意味着背叛承诺
固定的价格就是保证要背叛承诺。
基于真实工作的评估。
让团队和客户一起，真正地在当前项目中工作，做具体实际的评估。由客户控制他们要的功能和预算。
如果你对答案不满意，那么看看你是否可以改变问题。
如果你现在别无选择，你不得不提供一个固定的价格，那么你需要学到真正好的评估技巧。
敏捷反馈
【习惯19】守护天使
敏捷就是管理变化的，而且，代码可能是变化最频繁的东西。
编写能产生反馈的代码。
确保测试是可以重复的。
测试你的边界条件。
不要放过任何一个失败的测试。
使用自动化的测试。好的单元测试能够为你的代码问题提供及时的警报。
如果没有到位的单元测试，不要进行任何设计和代码修改。
单元测试时优质股，值得投资。
人们不编写单元测试的很多借口是因为代码中的设计缺陷。
单元测试只有在达到一定测试覆盖率的时候，才能真正地发挥作用。
【习惯20】先用它再实现它
编码之前，先写测试。
先写测试，你就会站在代码用户的角度去思考，而不仅仅是一个单纯的实现者。
先写测试有助于消除过度复杂的设计，让你可以专注于真正需要完成的工作。
一些不必要的过于复杂的事情，测试优先会帮助我们，防止我们走偏。
好的设计并不意味着需要更多的类。
TDD有机会让你编写之前，可以深思熟虑将如何用它。
这会迫使你去思考它的可用性和便利性，并让你的设计更加注重实效。
将TDD作为设计工具，它会为你带来更简单更有实效的设计。
这种感觉就是，只有在具体理由的时候才开始编码。你可以专注于设计接口，而不会被很多实现的细节干扰。
【习惯21】不同环境，就有不同问题
在不同的操纵系统及操作系统的不同版本都进行测试
利用自动化会节省时间
不同环境，就有不同问题。使用持续集成工具，在每一种支持的平台和环境中运行单元测试。
软件在很多平台上出现bug很可能只是因为栈布局的差异、机器子大小端的不同所致。
硬件比开发人员的时间便宜。但如果你有很多配置，要支持大量的平台，可以选择哪些平台需要内部测试。
【习惯22】自动验收测试
关键业务逻辑必须要独立进行严格测试，并且最后需要通过用户的审批。
应该让用户在不必学习编码的情况下，根据自己的需要进行添加、更新和修改数据。
FIT(集成测试框架)，它很实用，可以更容易地使用HTML表格定义测试用例，并比较测试结果数据。
使用FIT，客户可以定义带有新功能的使用样本。
如果领域专家提供了业务的算法、运算或方程式，为他们实现一套可以独立运行的测试。
为核心的业务逻辑创建测试。让客户单独验证这些测试，要让它们像一般的测试一样可以自动运行。
【习惯23】度量真实的进度
判断工作进度最好是实际花费的时间而不是估计的时间。
专注于你的方向。
如果能一直让下一步是可见的，会有助于进度度量。最好的做法就是使用代办事项(backlog).
代办事项就是等待完成的列表。
清楚项目的真实进度，是一项强大的技术。
度量剩下的工作量。不要用不恰当的度量来欺骗自己或者团队。要评估那些需要完成的代办事宜。【习惯24】倾听用户的声音
当出了错误，你要尽可能地提供详细信息。
黑屏和含义不明的“退出”按钮是很不友好的行为。
不管是产品bug,还是文档bug，或者用户理解bug，那都是团队行为，而不是用户问题。
每一个抱怨的背后隐藏了一个事实。找出真相，修复真正的问题。
对客户的愚蠢抱怨，即不要生气，也不要轻视。
没有愚蠢的用户，只有愚蠢，自大的开发人员。
敏捷编码 <<<
【习惯25】代码要清晰地表达意图
设计软件有两种方式。一种是设计得尽量简单，明显没有缺陷。另一种是设计复杂，没有明显的缺陷。
开发代码时，应该更注重可读性，而不是只图自己方便。
要编写清晰的而不是讨巧的代码。
向代码阅读者明确表明你的意图。可读性差的代码一点都不聪明。
应该让自己或团队任何人，可以读懂自己一年前写的代码，而且只读一遍就知道它的运行机制。
【习惯26】用代码沟通
建立代码文档无外乎两种方式:利用代码本身；利用注释来沟通代码之外的问题。
变量名运用正确、空格使用得当、逻辑分离清晰，以及表达式非常简洁。
如何命名很主要，使用精心挑选的名称和清晰的执行路径，代码几乎不需要注释。
为代码中的每个类或模块添加一个短小的描述，说明其目的以及是否有任何特别需求。
用注释沟通。使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能替代优秀的代码。
注释就好像是你的朋友，可以先阅读注释，然后快速浏览代码，从而完全理解它做了什么，以及如何做。
【习惯27】动态评估取舍
没有最佳解决方案
动态评估权衡。考虑性能、便利性、生产力、成本和上市时间。
如果性能表现足够了，就将注意力放在其他因素上。
不要为了感觉上的性能提升或者设计上的优雅，而将设计复杂化。
即使不能面面俱到，你也应该觉得得到了最重要的东西-客户认为有价值的特性。
过早的优化是万恶之源。
真正的高性能系统，从一开始设计时就在向这个方向努力。
【习惯28】增量式编程
如果不对自己编写的代码进行测试，保证没有问题，就不要连续几个小时，甚至连续几分钟进行编程。
应该采用增量式的编程方式。增量式编程可以精炼并结构化你的代码。
采用增量式编程和测试，会倾向于创建更小的方法和更具内聚性的类。
在编写代码时，要经常留心可以改进的微小部分。
在很短的编辑/构建/测试循环中编写代码。这要比花费长时间仅仅做编写代码的工作好得多。可以创建更加清晰、简单、易于维护的代码。
在写了几行代码之后，你会迫切地希望进行一次构建/测试循环。在没有得到反馈时，你不想走得太远。【习惯29】保持简单
简单不是简陋
优雅的代码第一眼看上去，就知道它的用处，而且很简洁。
开发可以工作的、最简单的解决方案。
除非不可辩驳的原因，否则不要使用模式、原则和高难度技术之类的东西。
当你感觉代码没有一行是多余的，并且仍能交付全部的功能，这种感觉就对了。这样的代码容易理解和改正。
要将目标牢记于心:简单、可读性高的代码。强行让代码变得优雅与过早优化类似，同样会产生恶劣的影响。【习惯30】编写内聚的代码
类也要遵循内聚性。如果一个类的方法和属性共同完成一个功能，这个类就是内聚的。
让类的功能尽量集中，让组件尽量小。要避免创建很大的类或组件，也不要创建无所不包的大杂烩类。
感觉类和组件的功能很集中:每个类或组件只做一件事，而且做的很好。bug很容易跟踪，代码也容易修改，因为类和组件的责任都很清晰。
有可能会把一些东西拆成很多微小的部分，而使其失去了实用价值。
具有良好内聚性的代码，可能会根据需求的变化，而成比例地进行变更。【习惯31】告知，不要询问
面向过程的代码取得信息，然后做出决策。面向对象的代码让别的对象去做事情。
作为代码的调用者，开发人员绝对不应该基于被调用对象的状态做出任何决策，更不能去改变改对象的状态。这样的逻辑应该是逻辑应该是被调用对象的责任，而不是你的。在该对象之外替它做决策，就违反了封装的原则，而且为bug提供了滋生的土壤。
命令与查询相分离模式。就是将功能和方法分为命令和查询两类，并在源码中记录下来。
告知，不要询问。不要抢了别的对象或组件的工作。告诉它做什么，然后盯着你自己的职责就好了。
绝对不允许以个看起来无辜的查询去修改对象的状态。【习惯32】根据契约进行替换
针对is-a关系使用继承；针对has-a或uses-a关系使用委托。
通过替换代码来扩展系统。通过替换遵循接口契约的类，来添加并改进功能特性。要多使用委托而不是继承。
相对于继承来说，委托更加灵活，适应力也更强。
继承不是魔鬼，只是长久以来被大家误解了。
如果你不确定一个接口做出了什么样的承诺，或是有什么样的需求，那就很难提供一个对其有意义的实现了。
敏捷调试 <<<
【习惯33】记录解决问题的日志
好的日志格式:问题发生日期|简述|解决方案|引用文章或网址|代码、设置或对话框的截屏。
要将日志保存为可供计算机搜索的格式，就可以进行关键字搜索以快速查找细节。
维护一个问题及其解决方案的日志。保留解决方案是修复问题过程的一部分，以后发生相同或类似问题时，就可以很快找到并使用了。
记录问题的时间不能超过在解决问题上花费的时间。
找到以前的解决方法非常关键。
如果通过搜索web，发现没人曾经遇到同样的问题，也许搜索的方式有问题。
要记录团队做出一个重要决策的原因。【习惯34】警告就是错误
在Eclipse中将警告做为错误处理的设置:Windows->Preferences->Java->Compiler->Errors/Warnings.
将警告视为错误。签入有警告的代码，就跟签入有错误或者没通过测试的代码一样，都是极差的做法。
签入构建工具中代码不应该产生任何警告信息。
由于编译器的bug或第三方工具或代码的原因，有些警告无法消除。
弃用的方法被弃用是有原因的。不要再使用它们了。至少，安排一个迭代来将它们安全地移除掉。
【习惯35】对问题各个击破
如果代码依赖其他模块，就应该使用mock对象，来把它从其他模块中分离开。这样做不但让代码更加健壮，且在发生问题时，也更容易定位来源。
用原型进行分离。
对问题各个击破。在解决问题时，要将问题域与其周边隔离开，特别是在大型应用中。
面对必须要隔离的问题时，感觉就像在一个茶杯中寻找一根针，而不是大海捞针。
如果将代码从其运行环境中分离后，问题消失不见了，这有助于隔离问题。
另一方面，如果将代码从其运行环境中分离后，问题还在，这同样有助于隔离问题。
在向问题发起攻击之前，先查找你的问题解决日志。
以二分查找的方式来定位问题是很有用的。也就是说，将问题空间分为两半，看看哪一半包含问题。再讲包含问题的一半进行二分，并不断重复这个过程。
【习惯36】报告所有的异常
捕捉到异常后，为了不看到编译器的提示，就把异常忽略掉–这种做法是危险的。
处理或是向上传播所有的异常。不要将它们压制不管，就算是临时这样做也不行，在写代码时要估计到会发生的问题。
当出现问题时，心里知道能够得到抛出的异常。而且没有空的异常处理方法。
决定由谁来负责处理异常是设计工作的一部分。
不是所有的问题都应该抛出异常。
报告的异常应该在代码的上下文中有实际意义。
要传播不能处理的异常。
【习惯37】提供有用的错误信息
要区分错误类型。程序缺陷 | 环境问题 | 用户错误
展示有用的错误信息。提供更易于查找错误细节的方式。发生问题时，要展示出尽量多的支持细节，不过别让用户陷入其中。
错误信息有助于问题的解决。当发生问题时，可以详细研究问题的细节描述和发生上下文。
像“无法找到文件”这样的错误信息，就其本身而言无助于问题的解决。“无法打开/project/file以供提取”这样的信息更加有效。
没有必要等待抛出异常来发现问题。在代码关键点使用断言以保证一切正常。当断言失败时，要提供与异常同样详细的信息。
在提供更多信息的同时，注意保密。
提供给用户的信息可以包含一个主键，以便于在日志文件或审核记录中定位相关内容。
敏捷协作
【习惯38】定期安排会面时间
只有开发团队可以参与scrum例会。
站立开发，回答三个问题: 昨天收获 | 今天计划 | 面临问题
使用立会。立会可以让团队达成共识。保证会议短小精悍不跑题。
大家都盼着立会。希望彼此了解各自的进度和手上的工作，而且不怕把各自遇到的问题拿出来公开讨论。
会议会占用开发时间，所以要尽量保证投入的时间有较大的产出。时间10-15分钟比较理想。
提前预定时间。
要注意报告的细节。会议中给出具体的进度，但不要陷入细节中。
迅速地开始可以保证会议短小。不要浪费时间等着会议开始。
【习惯39】架构师必须写代码
不可能在PowerPoint幻灯片中进行编码。
新系统的设计者必须要亲自投入到实现中去。
鼓励程序员参与设计，程序员在拒绝设计的同时，也就放弃了思考。
优秀的设计从积极的程序员那里开始演化。积极的编程可以带来深入的理解。不要使用不愿意编码的架构师-不知道系统的真实情况，是无法展开设计的。
不要允许任何人单独进行设计，特别是你自己。
【习惯40】实行代码集体所有制
相比找出谁的主意更好、谁的代码实现很烂而言，解决问题，并让应用满足用户的期望更为重要。
有好几双眼睛盯着一段代码，这样可以提升代码的整体质量，使其易于维护和理解，并降低出错率。
要强调代码的集体所有制。让开发人员轮换完成系统不同模块中的不同任务。
项目中的绝大部分的代码都必须能轻松应对。
如果不向整个团队分享知识，反而增加了丧失知识的风险。
【习惯41】成为指导者
教学相长-与团队其他人一起共事是很好的学习机会。
通过详细解释自己知道的东西，可以使自己的理解更深入。
与别人共事，激励他们变得更出色，同时可以提升团队的整体实力。
我们要成为指导别人的人，而不是折磨别人的人。
成为指导者。分享自己的知识很有趣-付出的同时便有收获。还可以激励别人活得更多的成果，而且提升了整个团队的实力。
如果一直在就同一个主题向不同的人反复阐述，不妨记录笔记，此后就此问题发一篇文章，甚至是一本书。
成为指导者是向团队进行投资的一种极佳的方式。
结对编程是一种进行高效指导的、很自然的环境。
【习惯42】允许大家自己想办法
授人以鱼，三餐之需；授人以渔，终生之用。
作为指导者，应该鼓励、引领大家思考如何解决问题。
给别人解决问题的机会。指给他们正确的方向，而不是直接提供解决方案。每个人都能从中学到东西。
用问题来回答问题，可以引导提问的人走上正确的道路。
如果有人真的陷入胶着状态，就不要折磨他么了。告诉他们答案，再解释为什么是这样。
【习惯43】准备好后再共享代码
完成一项任务后，应该马上ga代码，不应该让代码在开发机器上多停留一分钟。如果代码不能被别人集成使用，那又有什么用处呢？
通常情况下，提交的文件应该与一个特定的任务或是一个bug的解决相关。
要保证在提交代码之前，所有的单元测试都是可以通过的。使用持续集成是保证源代码控制系统中代码没有问题的一种良好方式。
准备好后再共享代码。绝不要提交尚未完成的代码。故意签入编译未通过，或没有通过单元测试的代码，对项目来说，应被视为玩忽职守的犯罪行为。
仍然应该频繁提交代码。
【习惯44】做代码复查
代码刚完成时，是寻找问题的最佳时机。
要寻找深藏不露的程序bug,正式地进行代码检查，其效果是任何已知形式测试的两倍，而且是移除80%缺陷的唯一已知方法。
复查所有代码。对于提升代码质量和降低错误率来说，代码复查是无价之宝。
不进行思考，类似于橡皮章一样的代码复查没有任何价值
代码复查需积极评价代码的设计和清晰程度，而不只是考量变量名和代码格式是否符合组织的标准。
如果不及时跟进讨论中给出的建议，代码复查时没有实际意义的。
要确保代码复查人员得到每次复查活动的反馈。
【习惯45】及时通报进展与问题
及时通报进展与问题。发布进展状况、新的想法和目前正在关注的主题。不要等别人来问项目状态如何。
当经理或同事来询问工作进度、最新的设计或研究状况时，不会感到头疼。
每日立会可以让每个人都能明确了解最新的进展和形势。
别花费太多的时间在进展与问题通报上面，还是应该保证开发任务的顺利完成。
经常抬头看看四周，而不是只埋头于自己的工作。