法则二十七：
Be like the doctors 用医生的方法
当病人已经药石罔效时，医生通常会对病情有所保留，避免病人太过悲观或恐惧，并且尽量鼓励病人保持希望，最好能让病人有个期望完成的目标。
医生绝对不会斩钉截铁地断言什么医疗行为一定会有什么样的结果，反而是以
一种自在且充满信心的口吻说：“试试看吧，一切都还没有确定呢。
另外一件应该向医生学习的事情是，即使是再小再简单的医疗行为，都带着几分风险，所以医生会说：“当然，任何情况都是有可能的，治愈率再高我都不能跟你说百分之百没问题。
法则二十八：
Remember the triangle:features, resources, times 软件开发金三角：特色、资源和时间
作为一位软件开发的领导人，你得集中注意力在三件事情：资源（人和钱）、特色（产品与其品质）和时间。这三件事是软件开发的核心，其他的都是外围。
资源、特色和时间是三角形的三个边，任何一边的变化，都会影响到另外一边或两边。所以如果时间落后了，去看你的三角形，看看对特色和资源的影响；当有人谈到可以增加什么功能特色时，你得立刻谈起时间和资源，以显得你思虑周
详反应敏捷。所以，管理者的第一要务是把这个三角形放在心里，随时利用这个模式来思考问题，你会发现答案都在这个三角形内。
法则二十九：
Don't know what you don't know 不懂别装懂
法则三十：
Don't go dark 建立适当的检查点
法则三十一：
Beware of a guy in a room 留心没有检查点的组员
法则三十二：
If you build it, it will ship 软件要经常建构，就能顺利推出
法则三十三：
Get a known state and stay there 掌握实际情况
法则三十四：
Use ZD milestones 零缺点里程碑
零缺点不代表软件中没有错虫，也不表示没有遗漏的功能，而是指团队的成品达到了事先规划的品质水准，也经过测试验证，就是零缺点里程碑。
法则三十五：
Nobody reaches the ZD milestone until everybody does 所有组员一起到达零缺点里程碑
法则三十六：
Every milestone deserves a no-blame postmortem 完成每个里程碑后，心平气和地检讨
法则三十七：
Stick to both the letter and the spirit of the milestones 把握里程碑的实质意义与精神
法则三十八：
Get a handle on "normal" 培养正常的团队运作
法则三十九：
A handful of milestones is a handful 里程碑不宜太多，才好掌握
法则四十：
Every little milestone has a meaning (story) all its own 每一个里程碑应有专属的宗旨
法则四十一：
Look for the natural milestones 寻找自然出现的里程碑
以下是六种自然出现的里程碑：
1. 产品设计趋于稳定。
2. 中间产品被明确定义。
3. 团队真正了解要花多少时间和努力才能完成目标（通常这会发生很多次，而且多半是进度落后的时候）。
4. 产品设计被删减，或是资源增加，或是进度延误，
或是三者同时发生。
5. 开发活动停止。
6. 产品进入除错或稳定阶段。
法则四十二：
When you slip, don't fall 如果滑了一跤，别就此倒地不起
- 进度落后与道德无关，请切记！
- 不要隐瞒事实。
- 化阻力为助力，利用进度落后来激发效率。
进度落后不是问题，被进度落后吓倒才是问题。进度落后并不代表产品的难度太高而无法开发。但是如果进度已经落后却未被察觉，那表示组员们不思考、不观察、不讨论，此时组织可说是濒临瓦解了。
善用你的迟延，这是最能看出你领导能力的时候，此时也是组员最脆弱也最需要你的时候，在这个时候组员最能把你的话听进去，此时组员的学习能力最强。如果你在办公室内激动得大喊大叫，指天骂地，那就错失了赢得组员的心的大好机会。你必须说：“O K，进度落后了，让我们来看看问题出在那里？⋯⋯今天下午五点在会议室，我们要检讨每一个细节，问题一定要设法解决！”当组员了解到你不是企图卸责或算帐，而是真诚地想解决问题，就会乐意把一切开诚布公地摊开来谈，大家一起研究问题，从各种角度去设法克服问题。“进度落后”反而变成大家宝贵的成长经验。
法则四十三：
Don't trade a bad date for an equally bad date 不要因为进度落后而更改最后期限
进度落后的程度是与计划的不确定性成正比。
法则四十四：
After a slip, hit the next milestone, no matter what延误了这个里程碑，就一定要如期到达下一个里程碑
我们必须明白，每一次的延误，就是你和团队信心的一次受挫，所以，延误这个里程碑时，最好的补救办法就是无论如何绝不延误下一个里程碑。团队必须挽回对自己的信心和对理想的承诺；因此，下一个任务必须准时完成的意义更重大，团队需要重建信心。
法则四十五：
A good slip is a net positive 把延误当作宝贵的学习机会
法则四十六：
See the forest 见树亦见林
如果本项目有六个模块，各有9 0 %的部分已经完成，那么你已经完成了5 4 %。每个模块完成了九成，听起来是个挺不错的成绩，但不能当成整个项目完成了百分之九十，它们之间不是相加的关系。你必须“见树亦见林”。如果任何一个模块完成比率是零，那么整个项目的完成率也是零。
法则四十七：
The world changes, so should you 世界在变，所以你也得跟着改变
虽然你想做些改变，你未必有勇气实行。
伟大的软件必定只有一个中心思想，至于品质能够实现到什么程度，依赖领导者能否带领团队融合无数个小而重要的改变。如果你能在混乱中辨识出对项目最有意义的改变，并且引导团队去适应它，将它融入团队的精神中，将来就会在产品中表现出这项改变，呈现在顾客眼前。
法则四十八：
Violate at least one sacred cow 关怀多于要求
法则四十九：
Beta is not the time to change Beta测试版不是修改功能的时候
法则五十：
The Beta is for spin development Beta测试是暖身活动
法则五十一：
Triage ruthlessly 急救术
法则五十二：
Don't shake the Jell-0 小心保持软件的稳定
法则五十三：
Compete with the superior story 伟大的软件应该有一个伟大的故事
法则五十四：
Create a winning image 建立赢家形象
我讨论的进度条主要是JFace的进度条，RCP已经提供了完善的Job组件，为什么还要用JFace的进度条呢？原因是我要在登陆界面上做进度处理，也就是使用Eclipse3.3提供的AbstractSplashHandler特性，可以将原有的启动画面替换成为一个登陆界面，启动这个登陆界面时，Eclipse的Platform此时还没有启动，所以不能使用RCP本身的Job组件了。
由于是一个检测服务器是否联通的测试，所以并不知道测试的真实时间，所以就是要使用“傻瓜进度条”了，也就是反复走的进度条陈刚的代码如下：
| button.addSelectionListener(new SelectionAdapter() {
private boolean stopFlag;// 停止标志 private void go() {
for (int i = 0; i < 10; i++) {// 循环10次，每次间隔一秒
System.out.println("第" + (i + 1) + "个任务执行完毕");
if (stopFlag) {// 监控是否要让停止后台任务
System.out.println("被中断了");
return;
}
try {
Thread.sleep(1000);
} catch (Throwable t) {}
}
stopFlag = true;// 执行完毕后把标志位设为停止，好通知给进度框
System.out.println("全部任务执行完毕");
} public void widgetSelected(SelectionEvent e) {
stopFlag = false;// 每次都设初值为false
new Thread() {// 把后台任务放到一个新开线程里执行
public void run() {
go();
}
}.start();
showProgressDialog();// 打开一个进度框
} private void showProgressDialog() {
IRunnableWithProgress runnable = new IRunnableWithProgress() {
public void run(IProgressMonitor monitor) {
monitor.beginTask("正在执行中......", 30);
int i = 0;
while (true) {
// 监听是否单击了进度框的“取消”按钮，stopFlag则是监听后台任务是否停止
if (monitor.isCanceled() || stopFlag) {
stopFlag = true; // 单击了“取消”按钮要设标志位为停止，好通知后台任务中断执行
break;// 中断处理
}
// i到30后清零。并将进度条重新来过
if ((++i) == 30) {
i = 0;
monitor.beginTask("正在执行中......", 30);
}
// 进度条每前进一步体息一会，不用太长或太短，时间可任意设。
try {
Thread.sleep(99);
} catch (Throwable t) {}
monitor.worked(1);// 进度条前进一步
}
monitor.done();// 进度条前进到完成
}
};
try {
new ProgressMonitorDialog(s).run(true, true, runnable);
} catch (Exception e) {
e.printStackTrace();
}
}
}); |
主要是使用两个线程交替使用，第一个线程处理业务，第二个线程监控第一个线程查看它是否结束，如果结束或者被点击cancele则停止进度条的进程，如果一直没有关闭的指令，则反复开始---累加---结束---开始---累加---结束。
我们几乎是把陈刚的代码原原本本的抄袭了一下，仅仅是替换了go()中的内容，但是发现一个问题
new ProgressMonitorDialog(s).run(true, true, runnable);
使用此句的话，JFace的线程永远不会启动；
替换为
new ProgressMonitorDialog(s).run(false, true, runnable);
使用此句的话，JFace的线程可以启动，运行正常，但是cancele不能响应，UI界面完全卡死！
第一个参数的名字fork~乍看去，什么意思都没有，但是看看API才发现内藏很大的玄机，如果为true则此线程为一个非UI线程，大家知道非UI线程是不会阻塞UI的；如果为false则此线程为一个UI线程，大家也知道UI线程如果使用不当很容易阻塞UI的。
关键的问题是我们和陈刚的代码几乎一摸一样他的进度条就启动，我的进度条就不启动！为什么？（这点至今不明白!）
详查API发现如果fork为false的时候还是另有洞天的：
| This implementation of IRunnableContext#run(boolean, boolean, IRunnableWithProgress) runs the given IRunnableWithProgress using the progress monitor for this progress dialog and blocks until the runnable has been run, regardless of the value of fork. The dialog is opened before the runnable is run, and closed after it completes. It is recommended that fork is set to true in most cases. If fork is set to false, the runnable will run in the UI thread and it is the runnable's responsibility to call Display.readAndDispatch() to ensure UI responsiveness. |
API中说的很明白，如果fork为false时需要在线程中调用Display.readAndDispatch()方法，以避免UI被阻塞！
大家如果在JFace的开发中如果使用了进度条，发现UI被阻塞的话，就想想我哦！！！呵呵只用在进程中调用一下Display.readAndDispatch()就解决了！
设计
软件的设计─每一位团队成员都必须参与─这表示团队整体对功能需求的了解程度。
软件设计的第一要诀是：将全团队中最好的想法组织起来，去满足顾客内心最深处的需要。（带领团队做案例研讨，带领大家思考如何解决一切的疑难，让每一件事都在该做的时候做好。）
法则十九：
Go for greatness 追求卓越
法则二十：
State your theme 设定主题
重点是产品的功能特色不能像是一袋子随便抓过来的东西，应该把与主题无关的东西都删掉，而且你的目标也必须符合统一性（unity of purpose）才行，这一点是与主题互为一体的两面。将资金投注在这个目标上，让所有的人都完全明白这个目标，并且为这个目标努力，做得到这些的话，你的产品就会完全包含这个目标。
法则二十一：
Minimize dependencies 不要倚赖不确定的事
法则二十二：
Propitiate the gods 平息顾客的愠怒
法则二十三：
Portability is for canoes. 软件的可移植性
法则二十四：
Design time at design time 在设计时将时间因素考虑在内
开发
法则二十五：
Don't accept dictation 拒绝不合理的命令
千万不要一味的唯命是从，在必要的时候拒绝！敢于拒绝！
如果在上位者不让真正执行任务的人来估计所需的进度，那就是专制。
开发进度表应该由下而上来拟定，每一个人负责自己的工作，也负责设定它的时间表，负责准时完成工作。责任和充分授权是一体的两面，二者兼备才能拟出合理的开发计划。一种非常有趣的进度估算方法！
法则二十六：
Now go play 把工作当作游戏吧