前两天给头提的新开发方式

这个实在，最重要的是要得到头的支持

ps：gigix貌似在乘机揽业务

敏捷只是一种思想，如果咋们非要打着敏捷的旗号，相信成功的可能性不大。我在项目中推行流程和方法都是根据喜好，如果老板喜欢RUP，我就说这个是RUP，其实他怎么知道RUP是什么？如果你说自己在敏捷，如果站在“长老”们的角度，相信我也会反感你的。
我不知道你们的团队大小，但是可以发现的是，这个流程本身并不能体现敏捷。有些可能犯了基本的管理上的失误。
比如：
D：如果在指定时间内某人没有完成任务，责任不仅仅是任务领取人个人的，也是大家的
这样职责不明，队伍稍大些，就会出现一只老鼠坏锅汤的问题。

E：每天上午9:30，在会议室召开例会（立会）。所有人站立开会，每次时间控制在15分钟左右。
如果有项目经理这样定义，我的第一个想法就是：离开这家公司，至少离开这个项目组。
“所有人站立开会”这个非常诡异。如果我是瘸子，你叫我咋办？
召开例会是没有问题的，但是把“站立开会”写在书面文件中是非常奇怪的事情。
另外，每个人都回答四个问题的做法，即使在一个很小的团队都是很浪费时间的。而且，这种方法应当算是被动式的管理方式。

step 1: 所有人员阅读所有文档，需要熟悉理解所有业务需求。
这个也是很奇怪的做法，实在不知道这样做的意义。

有些东西流行并不是因为它确实合适，而只是因为它迎合了某些人的心理需要。但是心理需要归心理需要，赚钱还是最重要的。有市场的且能够带来盈利的才是最好的。
建议楼主研究一下UP，以及其他的Agile方法，比如FDD，Scrum，水晶等等。江南布衣的观点相对比较中肯，我觉得可以参考。o6z的观点有些超前，可以在深入以后再去理解。其他还有很多有真正的具体经验的朋友意见都不错。当然，这些只是我的看法。不管怎样，千万不可听信一家之言。

你们撼成功了哪些案例？？

呵呵，很高兴与你交流这个问题。
首先声明，我没有敏捷的实践经验，知道的那点东西都是书本和网络上的。




虽然我确实在公司的内部技术交流中专门介绍过敏捷，但是本次提出方案我没有打着敏捷的旗号。只是想针对公司目前存在的问题，从敏捷思想中借鉴一点东西，提出一些新的方式，希望能够解决目前的一些问题。自然这个方案非常幼稚，呵呵，或许正是这种幼稚遭到“长老”们的“反感”。

像我这样只是汲取了敏捷一点点东西，就很难展开了。所以我认为敏捷推广“任重而道远”。


小组一共三个半人，那半个是一名组员只被头分配了50%的时间和精力。
之前小组内部分配任务，一人分配一个或几个模块，从前台一直做到后台（JSP > Action > delegate > accessor > EJB > Bo > Dao）。存在很强的封闭型，这样的代码拿给别的人是很难理解。可能我在那个草稿中的说法不清楚。我想体现的是，第一：代码共享；第二：配对编程。PP非常难以实现，但是代码共享还是可以做到的。所以提出了这样的想法。希望大家互相关注，团结一致。


这个提法是想解决两个问题：
第一，掌握项目进度，控制节奏。以往公司都是要求大家填写project，但是这个东西是静态的，只会写上完成的百分比，无法体现项目和小组成员的真实状况。项目经理只要看到大家完成的百分比，然后就催促进度。

第二：加强沟通。譬如：碰到了什么问题？有什么成功经验？有什么想要告诉大家的？ 现在小组成员之间根本就没有太多交流，每天闷头干活，只不过大家碰巧都在做一个模块里的东西而已。简单几个问题，就能知道大家的状况，更多的交流会后就会在成员之间展开。

第三：说到浪费时间，那我们也来算一算。例会每天召开，每次都控制在15分钟之内。这样每周五天，最多就是75分钟。而目前的例会是每周五召开，每次都是拖拖拉拉，至少要一个半小时才能开完。那么75分钟和90分钟那个更加浪费时间就很明显了。


前边我回答过这个问题。呵呵，实际上我们现在只有几个文档，量很小。而且正处于需求收集阶段，在这个阶段要求大家熟悉理解所有的业务（也只是概要的），不过分吧？否则怎么实现代码共享？怎么能够知道别人在做什么？



javaeye上我最关注的就是项目管理和敏捷了，o6z应该是实干者和理论者，我非常佩服。白衣的很多东西更接近我的状况。顺便说一句，他在springside上提的对service的单元测试可真的不算是纯正的单元测试了。  

http://www.iteye.com/topic/66559

基本上每一个公司都有自己公司一套的,主要就是看头了,原来的PM蛮推崇域建模及XP的,基本都是从一个一个的user story开始,但后来的PM就不喜欢了,还是走原来的老路,整个team又回到了从前。

呵呵，敢于实践就是值得鼓励的，人类发展的过程就是一部战争史，个人也是一样，每个人的发展其实也是一个不断犯错的过程。大家一同讨论，然后进行修正。



这个小组规模非常小，流程只会降低效率，但是定义基本的策略还是有必要性的，这是为了消减人力上的风险。比如人员退出（离职，生病，乃至死亡），新进人员等等。
这个策略是把你们团队的价值观进行强化。


我说说我的做法，每天下午17：00（17：30下班）有1-5分钟的例会，用于解决项目共性的问题，上次进度的总结，以及决定及决策。
项目个人的问题，开始时每天会例行巡查，了解项目问题，待成员养成习惯后，鼓励员工主动汇报，然后再辅以随机巡查。
每周末，或者相对重要的日子，比如迭代检核点，有例会，这个时候是要一起讨论解决问题，花费时间长些，但是由于绝大部分问题都在平时解决掉，这个例会就很轻松，倒有点像是供大家偷懒用的。
之所以不在日会议上让每个人都发言，是因为，我们国家是有开会陋习的，而且，过程中绝大部分问题都不是非常复杂，但是大家一讨论就会越来越复杂，所以，把解决问题放在会议以外，这样也能为团队的高效协作创造机会。


这点我的看法是，如果不知道为什么要共享代码，那么就不去共享。知道别人做什么不那么重要，解决开发中的问题是重要的。当然，因为你们的团队较小，所以如果是另外一个原因，就是因为没有架构师，所以，要求大家了解业务也是有可以的。虽然说架构师不是要了解所有业务，但是业务是影响你们使用的技术的，在没有架构师来全局考察技术架构的情况下，使大家都了解业务从而能够交流设计，这也是解决的方法。


呵呵，一起学习

没有什么实际经验，怎么能照搬书上的东西呢.
如果目前的开发方式有问题的话，尽量完善目前的开发方式，而不是另搞一套。
说话比较直率，请谅解.

1.关于测试人员加入到项目中的问题：一两年前和dreamhead一起做过一个项目，虽然项目的类型和你的项目不同，那个时候有个测试强人在项目启动阶段就加入到我们组，从需求开始做，一样的做需求的分析，做用例，做架构，做设计。。。都是从测试人员的角度出发的，当时这种方式给我们冲击很大，在开发中不断感觉到测试人员眼中的项目开发，能感觉很多时候测试对于项目的开发有很大的推动力量。一直给人留下深刻影响。如果有机会，建议尝试，很不错的。
2.我们项目一直在用wiki作为共享的平台，每个开发人员或者测试人员都可以写很多东西，开会的小结，个人的想法，共享出来的文档，小的设计，大的架构，各个阶段的经验，业务的模型，还有大家经常可以写一些鼓舞士气的话，很不错。现在正在推广到项目组以外呢。搭建一个wiki平台很容易，当然你要带头写很多东西，慢慢积累了大家觉得都不错，都开始写了，而且可以搜索，可以分享，甚至开发人员离去了，但是他／她曾经的想法还在那儿呢。
3.我们项目组的想法一直就是迭代迭代，事情一步一步的做，慢慢的积累，一两年下来发现已经形成了很多好的习惯。