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

前些日子头说要新的ABL小组探索一些新的开发方式，我满心欢喜，提出了一个结合公司实际的方案。 可惜，在现实的压力面前他们退缩了，回到了老路。 心有不甘，记录在此，凭吊之~~~~

[quote]

ABL工作流程和方式
      （草稿）
    
业务：
  1、请一位测试组成员加入ABL小组，为ABL小组业务负责人。
  2、所有的业务需求的收集、变化、确认，都集中于此业务人员。
    技术人员在业务上的精力可以适量减少。
  3、开发人员有业务问题需要首先咨询业务人员。在业务人员依然不清楚地情况下，可以由业务人员发起同美国同事的讨论。
  4、所有的需求变化和确认状况需要通知全组人员。
  
技术：
  
  开发原则  
   A：进行单元测试。
      后台主要测试BO和DAO，测试工具为JUnit（DBUnit）工具；
      前台主要使用Selenium测试。
      单元测试没有通过的代码不可以提交到CVS。
   B：每完成一小步就集成测试，间隔时间尽量缩短。具体时间可以根据实际开发状况调整。
     集成测试自动化。
   C：在完成任务后，可以到组长处领取新任务或者帮助他人完成任务，可以自己选择。
   D：如果在指定时间内某人没有完成任务，责任不仅仅是任务领取人个人的，也是大家的。
   E：每天上午9:30，在会议室召开例会（立会）。所有人站立开会，每次时间控制在15分钟左右。
     每个人回答四个问题：
      1〉昨天开会之后作了什么？
      2〉今天要做什么？
      3〉碰到了什么障碍？
      4〉有什么要同大家共享的？
     会上提出问题，会后解决问题。
     
  开发步骤：
    step 1: 所有人员阅读所有文档，需要熟悉理解所有业务需求。
    step 2: 前台与后台分开走。
        两人负责前台delegate之前；两人负责后台从delegate到DAO。
        delegate接口双方共同协商。
        后台是模拟实现，前台是全部实现。
    step 3：集成测试，跑通流程，业务人员确认主流程正确。
    step 4：实现业务逻辑（单元测试）
    step 5：集成测试（频密）
    step 6：将step4与step5循环，一直到项目结束。

[/quote]

说实话，我不觉得这是一个特别好的方案。
姑且不论这样的测试和开发方式是否会带来一个高效的项目，我看到的最大问题是项目里面充满了责任，但是缺少机制让人去履行责任。

dada说的对，这确实不是一个很好的方案。是我写的一个初稿，很多东西考虑的确实不全面。 对于敏捷我只有书上和论坛上的知识，具体的实践确实没有，所以也一直渴望能实践一把。但在一个早就习惯了瀑布式的环境中推动敏捷必须一步一步走，所谓摸着石头过河。

提出一个实践草稿，然后逐渐在实际中验证和寻找更佳的解决方式，我想最重要的就是要“开始”。

流程不要太复杂，尽量简单
尽量常规时间结束战斗，
  少加班，多拿钱是正道

首先要集体总结过去.
哪些是好的,要保持.
哪些是不好的,要改正.

只有大家都觉得有些东西是问题以后,
再讨论出针对这些问题的一些处理方式.

如果是你个人提出,容易出抵触情绪.

低调,低调.

有道理！

不过我现在面对的问题是：我向大家展示了自己的想法之后，年轻的普通的开发者表示赞同的比较多，年长的开发者和头却不是特别认同。
也就是说抵触情绪来自于上层。

我在敏捷方面目前只是个爱好者，没有实践经验，资历浅薄。为了推动公司的能够接受敏捷，年前我甚至请来了TW的马X给我们头讲解。 呵呵，高级咨询师呀，照样没撼动。

一句话：推动敏捷，任重而道远啊~~

对于上层，你需要告诉他们：这样做了以后能带来哪些价值。让他们清楚看到做这些事情的利益所在，他们会比较容易接受。
有机会的话，可以找我们再去帮你撼一撼。

ahuaxuan 写道：

 

可能我们的情况不太一样吧

我们做的东西都是从美国总部那边拿过来了，初始时只有一个概念化的文档，告诉你要做一件什么事情。

然后需要北京这边与美国那边不断的研究和讨论。逐渐逐渐理清楚、想明白，形成一个完善的需求文档。（这里没有敏捷中的现场业务人员引领）

然后再到概要设计，详细设计。等到详细设计和开发的时候才会各自管各自的模块。

 

基于这样的现实，我提出了要在测试人员中抽取一个人作为ABL组的业务人员，先于我们了解需求；但是所有的组员应该整体了解才行，否则的话如何对别人做的事情也有概念？

好，合适的时候一定请你们再帮忙撼一撼！