|
1600| 0
|
软件随想录 |
最新书评 共 5 条
觋祉
最早在<Joel on software> 中看到Joel提到使用Evidence Based Scheduling (EBS) 中的单个的时间估算方式:蒙特卡罗时间估算方式，估算方法的细节要求如下:
1.将任务细分的小时级的工作量。
最大的任务不超过16个小时.这一步让你认真考虑将要完成的工作。细分之后的任务比如像分析一个文件通常是做过的任务。完成这些任务的时间因而比较容易估算
2.记录完成工作的时间。
注意，任务的实际完成时间是包含任务开始到结束的物理工作时间，包含了会议等没有实现计划的时间。因此，完成时间是真实的时间并且反映了意外事件的影响。
3.对真实完成时间的模拟:
你不要将估算值相加得到未来的完成日期。 这种做法看起来简单但是会给出很错误的结果。你应该用Monte Carlo法来模拟,即:对每一项任务，将其估算时间除以一个随机选择的历史工作速度值,达到的结果为蒙特卡罗法估算出的时间。
pope对这个时间估算方式一直很有兴趣，也不知道准确性到底如何，对自己工作改进的帮助是不是会有不小进步,所以就自己动手写了以上3步骤的过程，用python完成的，默认写的是存储本地文件，历史选取默认使用了1000条，现在已经这个步骤本身的内容已经基本完工，代码可以在https://code.google.com/p/montecarlo-time-test/可以看到，有个小问题，code提交时放到http://montecarlo-time-test.googlecode.com/svn/wiki中了 checkout 注意一下路径吧,欢迎试用，由于是自己在写，没有系统测试过，有问题欢迎mail我。
使用说明
1.开发本地的python是2.6.5版本，3.0没有测试过，不太清楚是否支持。
2.源码中两个版本，推荐使用UseDate.py，直接运行就可以，命令行提示：
“'存储TT请输入1,退出为0,T_P未存储处理2，否则为估算蒙式时间:”
其中非2,1,0的输入为默认估算，估算后，给出估算结果，例如：
——————————————————
存储TT请输入1,退出为0,T_P未存储处理2，否则为估算蒙式时间:3
你的估算时间：1000
估算条目:313,取值内容:'1.51739619196'
sTT=659.02366520922499
id=1045
-----------------------------------
其中sTT为估算值，id为输入真实值使用的索引号，在记录自己的真实使用时间时要使用，注意记录啊！[next:这个在想，next改进可能用别的更好的方式代替,但现在还没有想到，先忍忍吧]
如果输入1,为记录真实的使用时间，给出此记录全部内容，例如:
------------------------------------
存储TT请输入1,退出为0,T_P未存储处理2，否则为估算蒙式时间:1
id为:1045
TT为:1000
1045 1000.0 659.023665209 2013-06-06 11:55:14 1000.0 2013-06-06 11:59:01
1045 1000.0 659.023665209 2013-06-06 11:55:14 1000.0 2013-06-06 11:59:01 1.51739619196
------------------------------------
其中TT和id都是你要输入的值，id是之前输入估算时间时给你的id，而TT就是这个内容你真实使用的时间。
##########################################分割线#############################
当前应用选用python主要是近来一直看<Dive into python> 再尝试python和unittest所以顺手选择的。
最后代码为GNU GPL 协议的遵守，如果你有修改，欢迎mail我
thank you for reading
详情
葱花哥
Joker Lee同学推荐的一本书~周末在家读完了这本书，感觉非常好。作者通过一个个的故事，将自己多年软件开发总结出来的经验和教训传达给读者。文中有很多经常的章节，比如《火星人的耳机》，非常生动的将浏览器的发展历史、现在面临的问题讲述给读者。比如《循证式日程规划》建议软件开发者，用循证式的方法讲自己的开发时间统计出来，从而对以后的项目开发能做出准确的时间预测。另外《让错误的代码显而易见》用xss漏洞的例子，讲述了一些好的代码风格。
总的来说，本说篇幅不长，没有条多的信条式的建议，大多数是一些作者自己的亲身经历过的故事。这些事情我们可能不会再遇到，但是读这本书获得的启发在我们未来的软件开发的路上肯定能给我们不少帮助。
详情
菜小卤
有这么几点触动到我的章节，记录于此：
1. P34. 三种管理方法：军事化管理法、经济利益驱动法、认同法。不用说肯定是认同发更会让员工发自肺腑的全力以赴工作，因为在工作中他们能够有存在感，有一种自我价值的体会。但是前两种是目前更多采用的方法，因为更直接，也更符合现实。三种掺杂，应该可以在可实现的范围内达到比较好的程度。毕竟我最热血的时候是经历第三种的时候。
2. P100. 别给用户太多选择。Joel讲了一个 windows vista 关机按钮的例子，我看完有感触就在读书笔记记了一笔。其实用户体验、交互设计方面的原则太多，很多又太虚，这个完全不容易像某个写代码方式一样很容易说服别人，因为这个是纯用数据拼出来的推测。无论怎么设计，好用就是牛逼，结果好就是牛逼。
3. P157。日程规划估计时间每一单项不要超过16小时。具体16小时这个数我不知道是怎么算出来的，但是体会到确实是如果预估计一个项目需要的耗时，想几分钟就说“一个月”这样肯定是不行的，实际结果出来后会和计划差很远，差很远的计划就相当于是没做计划。真的要拿到需求文档出了技术文档（或者已经想过了一遍每一个关键点的大致实现）才有可能估计出靠谱的时间。可能很多牛逼的程序员脱口而出一个数多数都是根据经验以前相似规模的项目出来的。
4. P171。“注意摩尔定律，当硬件飞速发展的时候，需要权衡软件优化的代价是否值得，还是更应该专注开发新产品，坐等硬件将现有软件支持的更加流畅。”看了fb.html5isready.com 了吧，sencha网页版实现的仿facebook native应用效果.iOS我没看，但是samsung galaxy 搭载 4.2.1 运行起来这个demo是完全没问题，真牛逼，体验上完全够用了。
5. P192。匈牙利命名。我忘了当时从尼玛哪里看到了说int 类型变量可以写成iXXX，字符串类型变量可以写成sXXX，干，真粗糙。
6. P252.如何挑选发布日期。1）确定个发布日期，可以根据客观情况也可以根据主观选定；2）列出要实现的功能，然后按照优先级排序；3）当进度落后于预定进程的时候砍掉最后面的功能。
7. P256.在2.0版本之前避免大规模宣传，1.0版本是试水。这样2.0版本会每个人留下一个美好印象。
8. P276.如何定价软件让我想起了大学上的微观经济学，当时上课应该再认真点。
9. P282.服务器出了问题应该问五个为什么，因为不可能规避所有导致问题的漏洞，但是可以有一个解决问题的流程，这样使得产品在一直变好。其中提到的用户可以查看公开网志来查看故障原因以及公司是怎么解决这些故障的真是个好点子，真诚。
10. P288.确定事情的优先级。如果你的办公桌过于整洁，可能你的工作效率不十分高。因为你把精力分散到那些重要的事情之外了（写代码才最重要啊亲！！）
详情
更多书评 我要评论 | ||
网站地图|小黑屋|Archiver|DoThinkings 悦书籍，思人生
GMT+8, 2024-11-27 13:54 , Processed in 0.277946 second(s), 41 queries .
Powered by Discuz! X3.3
© 2001-2017 Comsenz Inc.
窥视卡
雷达卡
发表于 2013-6-3 22:16:27
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
淘帖
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡