一篇文章同我最近考虑的东西很类似，只不过我对问题分了类，并且有些内容更加详细。而它之中也有一些是我没有考虑到的，所以很有参考价值。想当初CMM也是来自这样一个类似的问题列表，通过逐步的深化和系统化，从而形成一个大的体系。无疑标准有好有坏，而标准造成的后果也有好有坏。一个标准化的敏捷是否还是敏捷，这个问题需要我们去研究。而我相信不同的标准化的策略，会造成敏捷的后果不同。关键不在于是否需要标准，而在于这个标准应该如何建立，以及如何划分与组织其内容，同时还要明确指定出应用的范围。比如在一个成熟的领域，一个成熟的团队更加可能有优势。而在一个快速发展的领域，团队的成熟性是否能够带来能力的优势就不好说了。 ...
rails A
cd A
rake db:create:all
ruby ruby script\generate scaffold A B:string C:text
rake db:migrate
你认为我刚才做了什么？没有了名称的提示，只有A、B、C这样的变量名似的东西，那么这个程序就没意义了吗？给大家充分的讨论时间，然后我说我的看法。做个提示，这个讨论是关于产品化设计，程序结构与需求，也许还可以包括平台设计。可以将这个帖子看作我在最近参加的几个讨论挖的坑，现在开始种树了。
DSL这个概念如果真的能够被广泛应用，一个最重要的前提是——能够建立从需求到程序的联系，也就是说可以使用一套DSL描述需要同时描述程序代码。
我的经验，5人似乎是一个阀值。也就是说一个组织在2-5人的时候，管理所付出的资源同6人会有巨大的差距。当然有的人会感觉这个阀值是6或者7，不过经过我的调查，更多的还是5，而4基本很少被人提到。
同时时间的也是有阀值的，多数的情况下阀值在6周至8周。当然也有很多人认为是在1个月到3个月之间，而我发现越是开发环境比较人性化，这个阀值越是靠近6周以至于更长久。
大量统计数据表明，一个项目的开发人员在5-15人之间占80%以上，估计国内这个数字还会高。而又由于rails的高效率，我认为绝大多数的组织会在8人左右，而项目相关人员则会在100-10万之间，而相关人员角色估计会在20左右，细分大概也就是30。
而设计一个5-15人的方法论看来是合适的。
将scm中诸多概念进行分析后，我发现其核心概念只有三个——提交，检出，标记。其他任何的操作都是基于这三点及其扩展和组合，这是一个最小的概念环。
而由此可以建立自己的scm哲学，也可以建立自己的scm工具。
scm、test、Integration。
我们不能说没有这个三个保障项目不可能成功，但是我们可以说成功的可能性就大幅度的减小。
我们也不能说有了它们项目就必然成功，但是我们可以说成功的机会就大幅度提高。
而另外一个问题是，并不是投入越多的资源就说明它们越受到重视，更不能说明它们就更有效。实际上它们越是不经常被开发者所感受到（自动运行，自动记录，自动提示），越是说明它们接近成功。
这个概念很好，其本身强调了两个方面的问题。首先是一个产品的实际生产时间，实际在这个产品上花费了的生产时间——也就是有效生产时间，做对比，就可以看出其生产效率。
而另外一面，一个设备在其运转过程中，实际的用来生产产品的时间，这个对比，也很说明其生产流程的效率。
而无论从那一个方面来说，测定这个时间，都很重要。这也是现代现场管理的一个最重要参数。同时提高这个参数的数值水平，也是检验一个方法改进的最重要指标。另外这个参数本身也可以用来确定其生产流程的具体状况。
问题在于如何把这个工具引入软件开发的过程中，这确实是一个问题。
首先不管是从那个方面来说，测试这个时间都有法 ...
ozzzzzz
- 浏览: 81931 次
- 性别:
- 详细资料
搜索本博客
最近加入圈子
最新评论
-
FDD方法讲座普及篇完成
:idea: 好东西，快快开讲吧
-- by 憨老汉 -
几个主题的准备
一直想看FDD的实例
-- by 憨老汉 -
几个主题的准备
o6z啊，这个什么时候出来呀，我都等你好几年了
-- by 憨老汉 -
《JAVA将死？》之后续
别忘了java还有个script，星星之火可以燎原
-- by KKFC -
送一句话
嗯，说的通俗些，就是要多实践：）上面说的那个“五不”人员应该再加一条——“不世出 ...
-- by springhill
评论排行榜