浩存 - 面向数据库，虚拟机等海量数据可同时提供NFS/iSCSI访问的集群存储系统

Solaris12

原帖由 "yftty" 发表：


工程管理方面我们准备使用 PSP/TSPi and XP , 欢迎大家就这方面探讨  

恕本人无知，PSP/TSPi是什么？

XP是指极限编程吗？
根据我的理解，XP比较适合开发人员少，以客户需求为导向的项目。FS的产品不必要套用XP。

当然，在软件开发中确实有很多best practice，我们可以根据自己的实际情况作出相应的调整，找到效率和流程的平衡点：

1. 关于SCM：

要做好一个产品，必须制定关于SCM的一系列政策和标准，主要在一下几方面：

版本控制管理
变化跟踪管理
   

2.关于process

需要制定代码集成的一些标准。

开发：概念性文档-->;开发-->;code review->;代码集成
测试：测试计划-->;测试开发-->;测试->;测试报告


对于比较小和资源有限的开发团队，SCM和process不宜搞得复杂，尽量减少开发文档，强化配置管理和code review
测试方面，最好能找到开源的测试工具，但这就要求，FS的编程接口不能是专有的，应尽量符合某种标准

yftty

(13:43:29) j-fox: 不管用什么管理模式，作好计划（各种计划，特别是风险应对计划）和状态监控是最主要的，先先开始拿一个小任务去尝试找到适用的方法

(13:45:45) j-fox: 先准备好开发文档
(13:46:04) yftty -- A dream makes a team, and the team builds the dream !: 好,我先把你的贴上

xuediao

原帖由 "Solaris12" 发表：

XP比较适合开发人员少，以客户需求为导向的项目。

如同Solaris12所说，XP是一个强调快速灵活，而PSP和TSPi是CMMi的一个延伸，强调计划和过程控制。

虽然说这是一个大型的工程项目，又以分布式开发为主，但同时实施这两个方法难度很大啊。

在这两个方法中取得平衡点，说不定即将开创一个新式的软件工程学，呵呵  

xuediao

原帖由 "yftty" 发表：
(13:43:29) j-fox: 不管用什么管理模式，作好计划（各种计划，特别是风险应对计划）和状态监控是最主要的，先先开始拿一个小任务去尝试找到适用的方法

(13:45:45) j-fox: 先准备好开发文档
(13:46:04) yftty -- ..........

我比较赞同j-fox的观点，开发状态监控和风险应对是最重要的，如果单纯公司内部开发可能实施TSP要容易得多，对于国内的分布式开发，这算是一个尝试和学习的过程吧。

mozilla121

嚴格使用這套流程在執行上會比較難. 只有一個非常認同這種流程的團對才有可能執行下去.

yftty

[quote]原帖由 "xuediao" 发表：

如同Solaris12所说，XP是一个强调快速灵活，而PSP和TSPi是CMMi的一个延伸，强调计划和过程控制。

虽然说这是一个大型的工程项目，又以分布式开发为主，但同时实施这两个方法难度很大啊。

在这两个方法中取得

yftty

[quote]原帖由 "mozilla121"]嚴格使用這套流程在執行上會比較難. 只有一個非常認同這種流程的團對才有可能執行下去.[/quote 发表：


"自知","自胜";"知足","强行". -- <<道德经>;>;

xuediao

呵呵，这也是中庸之道，抑或是新式的洋务运动吧

小平哥说得好，管他黑猫白猫，能逮老鼠就是好猫！

Solaris12

原帖由 "xuediao" 发表：

如同Solaris12所说，XP是一个强调快速灵活，而PSP和TSPi是CMMi的一个延伸，强调计划和过程控制。

虽然说这是一个大型的工程项目，又以分布式开发为主，但同时实施这两个方法难度很大啊。

在这两个方法中取得?.........

其实CMM这类东西非常适合外包公司做的。
我所在的开发团队，即不是XP，也不是CMM，但是却非常有效。
而且，你会在里面找到其他软件工程方法的影子，
所以，任何流程部重要，最重要的是和你拥有的资源匹配，
在我看来，很多国内软件公司最大的问题主要是以下几点：

1. SCM(软件配置管理)方面

没有称职的release engineer.
无法做到真正的版本管理
没有变化跟踪管理系统，无法捕捉系统的每一个变化
没有daily build，没有automatic 的 sanity test
和system test.

更重要的是，很多公司建立项目之初，就没有统一的
SCM的政策，比如code integreate criteria

2. 开发流程方面

没有民主权威机构来控制市场和软件体系结构的需求及功能改变
没有code review
没有automatic的regression test对应每一个daily build

不过任何软件工程和方法都是要占用额外资源的，
关键是每一个软件公司都能认识并且投入。

其实仔细看很多知名的开源项目的开发模式，
以上这些东西都能很好的满足，比如说：
你可以随时拿到它的daily build或者snapshot,
看到该build是否通过测试。还有bugtraq系统，
记录到了每一次的改动，包括bugfix,和新功能

yftty

To Solaris12,

现在也是按照你所说的思路去一步步实施的,但还没有建立起来.

1.SCM, 现在仅仅是简单的Commit Rules (参照的是Lustre的流程).也是为了和现有的资源相匹配.

2. 开发流程, 现在仅有设计Rivew.其它的需要人员去建立.

另: 现在突然觉得有点丢掉了那曾经熟悉的东西.