【原】敏捷开发沉思(真实对话)

郁闷，到目前为止我还在搞作坊式编程。但是我决定不了这个现状。悲苦中。

对RUP的理解有问题吧，RUP和敏捷也不是对立的，而且RUP的一个特点应该就是可以让各个团队根据自己的情况对其方法进行裁剪

听起来是挺好的.不过觉得每个团队都有自己的特性,不能一概而论吧...
敏捷开发不是万金油 个人理解

敏捷管理相对来说`对团队成员的要求也比传统方式要高`

对管理人员的管理艺术要求更高`

开发团队中，是不是每个人都尽心尽力，这个问题有待大家思考。搞产品设计人有时候一个想法，会搞死一大堆人，这也是个问题。管理也很重要，这是毋庸置疑的。每个人遇到的问题都不一样。找到合适的解决办法，有时候放弃也是一种好的选择。

恩，貌似奔走在两个极端

无语...
还是花点钱请咨询公司吧，别有桥不走非得摸着石头过河。

这些问题我的回答是这样。
A. 敏捷是不是站立式会议，是不是把项目切分成几个小阶段就是迭代了？

肯定不是你说的这样
B. 敏捷的团队规模要多大？10个人还是4，5个人？
理论上是7加减2，包括所有角色，product owner，scrum master，开发，测试等人员

C. 敏捷团队中的人员如何配置？是不是要水平相当，经验相当？

最理想情况是需要水平相当，经验相当的，但现实中几乎不可能。人员配置，1个product owner，1个scrum master，1-2个测试，3-4个开发。
D 当团队中出现短板时，敏捷的结对编程会不会变成致命的缺陷？
肯定是致命缺陷，但是经验浅的人更加需要主动，人人都从没经验过来的，关键看你是否全身心主动投入。
E 敏捷团队中全功能团队和去角色化(尤其是没有PM这个角色)，会不会让项目失控？
优秀的scrum master起着监督和引导作用。如果scrum master不行，项目不失控是不可能的
F. 敏捷不是完全抛弃文档，但是文档要去到什么级别？ 和传统的文档又有什么区别？
这个有很多说法，还是根据项目实际情况来看。我个人觉得这方面敏捷做的相当不好。
G. 敏捷开发扁平化的结构，如何保证不会出现扯皮和纠缠不休？
听大多数的人的意见。如果出现难以定论的事情，可以让每个坚持已见的人做一件事情。老外说法是“时间窗”或“小石子”，其实就是中国人说的投石问路，花少量时间，比如半天，让每位按自己的想法实现，如果到了时间没有完全实现或者实现效果很垃圾，那么就找其中最好的一种想法去做，其他人都统统闭嘴吧。
H. 站立式会议如果避免沦为流水账汇报，如果让大家清楚得知道你在干什么，遇到什么问题？
stand meeting中，每人只说三件事。昨天做了什么，今天要做什么，昨天碰到哪些问题。如果大家听了还是不清楚，那只能说明平日互相之间沟通太少或这个人表达能力太差了，时间长了，他在项目里就是短板，就可以自行淘汰。
I. 敏捷开发究竟适合哪些业务场景？项目or产品？(同行倾向于项目，说是产品经常要改，可是敏捷的宣言不就是拥抱变化吗)
敏捷我认为不适合产品。其实项目也经常要改。所以说拥抱变化这句话是没错的。但是产品管理和项目管理看似一样，其实大不同。最早我看到的资料都称之为敏捷项目开发管理。为啥现在就说敏捷开发了，我也纳闷。
J. 敏捷开发中，成员分工要如何进行？横向划分或者纵向划分？
分工和之前说的一个问题中人员配置很相同。不过我不清楚你说的横向，纵向是指前后端和模块划分吗？好像敏捷中开发的task都是每位项目成员自己认领的呀。其实说task不好，应该说userstory，如何划分用户故事可是大学问。这个可以找mike cohn写的一本书看看。
K. 敏捷开发和管理中，如何让后进来的新人尽快熟悉产品和架构？
首先后进的新人一定要对敏捷有概念。不可能要人培训他一些基本敏捷的管理理论。其次对于项目情况，个人认为每位老成员有责任去告诉他。还有刚开始进入项目，最好可以先和测试人员做结对。老实说，老外说的结对编程是XP里提出的，后来scrum里更加明确结对不应该仅仅指开发，也应该有设计，测试，写文档等等项目中需要的工作。

我对敏捷的看法是它不是银弹。有时候我们在运用这些老外提出的理论到实际中时候，还必须根据项目本身情况进行一些创新。可惜现在天朝大多数搞敏捷的人都是依葫芦画瓢，生搬硬套，当作解决任何项目中发生的问题的万能药。这种做法和想法实在是太可笑了。另外18摸也响应形式，搞了个agile RUP的。如果有兴趣可以去看看相关资料。

个人感觉这种需求都确定了的项目用敏捷不太合适

一个大公司做本领域的产品，应该有很多的积累的，还要用2年的时间来RUP，这个绝对是有问题的

可以根据需求的分级，一部分功能的往上加

敏捷在国内的大部分公司都很难实施

学其神而非学其形。再好的管理方式也要结合实际。