CMMI下的Scrum, 如何操作？
45 views
Skip to first unread message
起步停车
Jul 24, 2008, 6:06:51 AM7/24/08
to 敏捷中国
公司一直在搞CMMI这个东西， 今年打算过5了。这些天领导忽然听说有个Scrum挺好， 要我们试一下， 然后任务层层下达......, 轮到我
了， 哎， 谁让咱在公司鼓吹XP 3年了呢？
幸亏前一阵子看完了那个Scrum的书和相关资料， 利用2天时间准备了一个文档, 把从敏捷大会上学的精益思想，华为实践...能想到的都搞在了一起
（其实还没有真正明白Scrum），匆匆的跟各位领导讨论了一下......
结论， 不能Scrum+XP， 在现有框架(CMMI)下实施Scrum（这个命题都有问题吧）。
各位兄弟，我该如何敏捷呢，能敏捷的起来吗？
了， 哎， 谁让咱在公司鼓吹XP 3年了呢？
幸亏前一阵子看完了那个Scrum的书和相关资料， 利用2天时间准备了一个文档, 把从敏捷大会上学的精益思想，华为实践...能想到的都搞在了一起
（其实还没有真正明白Scrum），匆匆的跟各位领导讨论了一下......
结论， 不能Scrum+XP， 在现有框架(CMMI)下实施Scrum（这个命题都有问题吧）。
各位兄弟，我该如何敏捷呢，能敏捷的起来吗？
Jeff Xiong
Jul 24, 2008, 8:07:31 PM7/24/08
to agile...@googlegroups.com
第一，CMMI要求的是软件组织具备成熟过程的*证据*，而诸如XP之类的敏捷方法只要使用得当是能够提供足够的证据来支持CMMI
5级的要求的，所以在CMMI框架下实施敏捷方法是可行的，这是在一些采用CMM多年的国内领先的软件组织中得到验证的。
5级的要求的，所以在CMMI框架下实施敏捷方法是可行的，这是在一些采用CMM多年的国内领先的软件组织中得到验证的。
第二，在这种环境下实施敏捷要注重实效，从影响较小收益较大的实践开始逐步引入，比较忌讳开口提大名词（例如SCRUM或者XP）。我会建议你以CMMI
5级的"自我改进"做旗帜，找到组织中存在浪费的环节，引入最佳实践来消除浪费，没有必要把敏捷挂在嘴边。
第三，一般来说，持续集成是开始这类改进活动的一个好的起点，因为持续集成强迫组织形成快速的反馈机制，从而让很多问题有机会在更短的时间暴露出来。另一方面持续集成也是领导比较容易接受的一个实践。
2008/7/24 起步停车 <tol...@163.com>:
--
Jeff Xiong
Software Journeyman - http://gigix.thoughtworkers.org
Open Source Contributor - http://fluorida.googlecode.com/
Technical Evangelist - http://www.infoq.com/cn/
Liang Qiao
Jul 24, 2008, 9:57:06 PM7/24/08
to agile...@googlegroups.com
+1 按CMMI的初衷行事，而非按CMMI的模式。但要注意找到切入点， 特别是处在可度量级。
+2 没有必要把敏捷挂在嘴边。不要对立，而要谦虚
+2 没有必要把敏捷挂在嘴边。不要对立，而要谦虚
2008/7/25 Jeff Xiong <gigi...@gmail.com>:
徐毅
Jul 24, 2008, 10:41:10 PM7/24/08
to agile...@googlegroups.com
2008/7/24 起步停车 <tol...@163.com>:
公司一直在搞CMMI这个东西， 今年打算过5了。这些天领导忽然听说有个Scrum挺好， 要我们试一下， 然后任务层层下达......, 轮到我
了， 哎， 谁让咱在公司鼓吹XP 3年了呢？
听说scrum好就要用啊。。试一下的说法不错，最好是小范围试用先。
幸亏前一阵子看完了那个Scrum的书和相关资料， 利用2天时间准备了一个文档, 把从敏捷大会上学的精益思想，华为实践...能想到的都搞在了一起
（其实还没有真正明白Scrum），匆匆的跟各位领导讨论了一下......
华为实践？据我了解的一点点华为的开发流程，感觉他们已经可以做到很敏捷，只是具体情况不清楚，不好发表言论。
兄台是华为的么，能否多说两句？
结论， 不能Scrum+XP， 在现有框架(CMMI)下实施Scrum（这个命题都有问题吧）。
推荐去看看Jim Highsmith的那本Agile Software Development Ecosystem，大致翻翻前面两三章就可以了，我觉得回答你这个疑问。
各位兄弟，我该如何敏捷呢，能敏捷的起来吗？
能。
--
- - - - - - - - - -
Xu Yi, Kaverjody
Certified Scrum Master
Blog : http://damianji.spaces.live.com
- - - - - - - - - -
咖啡屋的鼠标
Jul 24, 2008, 10:44:53 PM7/24/08
to agile...@googlegroups.com
Scrum只是一个架构，跟管理更相关。与CMMI里任何一个过程域都是不冲突的。计划会议、晨会、迭代、Backlog等等都不冲突（除非你们过了5级了，组织过程财富库里还没有一个关于迭代的过程模型。）你可以把它描绘成一种更适合CMMI模型的实现。
实践起来CI确实是一个很好的切入点。坚持CI，自动化测试，慢慢的大家都会发现XP实践的价值的。
实践起来CI确实是一个很好的切入点。坚持CI，自动化测试，慢慢的大家都会发现XP实践的价值的。
2008/7/25 Liang Qiao <sagittat...@gmail.com>:
aliang
Jul 24, 2008, 10:23:36 PM7/24/08
to agile...@googlegroups.com
没有必要把敏捷挂在嘴边。不要对立，而要谦虚。
说得很好。
方法论的东西是可以相互借鉴相互融合的，关键是多关注自身工作中存在的实际问题，发现问题，分析问题，找准问题切入点，借鉴敏捷的方法和思想，从小处做起，多实践，多反思，多改进。
说得很好。
方法论的东西是可以相互借鉴相互融合的，关键是多关注自身工作中存在的实际问题，发现问题，分析问题，找准问题切入点，借鉴敏捷的方法和思想，从小处做起，多实践，多反思，多改进。
2008/7/25 Liang Qiao <sagittat...@gmail.com>:
起步停车
Jul 25, 2008, 1:25:19 AM7/25/08
to 敏捷中国
谢谢 Jeff Xiong! 这几点建议很有指导性。我想我还从来没有真正的系统思考（对敏捷的认知还很肤浅）如何实施敏捷。 就像你说的， 扛着
CMMI5的"自我改进"的旗帜，我先从小的地方着手吧，，比如 1）为了部门内部知识的传播， 我在关键（只能有选择的， 否则领导就急了）的业务点
上实施结对，2）每天的stand up meeting, 发现问题，解决问题, 了解下个工作日的工作安排; 3) 迭代周期后的项目
review， 总结经验教训，下次迭代周期努力实践。4）持续集成我还没有深入了解，包括相关的技术和工具，回头研究一下。
非常感谢Jeff.
热切期待你们的open party， 希望有机会跟各位交流。
On 7月25日, 上午8时07分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> 第一，CMMI要求的是软件组织具备成熟过程的*证据*，而诸如XP之类的敏捷方法只要使用得当是能够提供足够的证据来支持CMMI
> 5级的要求的，所以在CMMI框架下实施敏捷方法是可行的，这是在一些采用CMM多年的国内领先的软件组织中得到验证的。
>
> 第二，在这种环境下实施敏捷要注重实效，从影响较小收益较大的实践开始逐步引入，比较忌讳开口提大名词（例如SCRUM或者XP）。我会建议你以CMMI
> 5级的"自我改进"做旗帜，找到组织中存在浪费的环节，引入最佳实践来消除浪费，没有必要把敏捷挂在嘴边。
>
> 第三，一般来说，持续集成是开始这类改进活动的一个好的起点，因为持续集成强迫组织形成快速的反馈机制，从而让很多问题有机会在更短的时间暴露出来。另一方面持-续集成也是领导比较容易接受的一个实践。
CMMI5的"自我改进"的旗帜，我先从小的地方着手吧，，比如 1）为了部门内部知识的传播， 我在关键（只能有选择的， 否则领导就急了）的业务点
上实施结对，2）每天的stand up meeting, 发现问题，解决问题, 了解下个工作日的工作安排; 3) 迭代周期后的项目
review， 总结经验教训，下次迭代周期努力实践。4）持续集成我还没有深入了解，包括相关的技术和工具，回头研究一下。
非常感谢Jeff.
热切期待你们的open party， 希望有机会跟各位交流。
On 7月25日, 上午8时07分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> 第一，CMMI要求的是软件组织具备成熟过程的*证据*，而诸如XP之类的敏捷方法只要使用得当是能够提供足够的证据来支持CMMI
> 5级的要求的，所以在CMMI框架下实施敏捷方法是可行的，这是在一些采用CMM多年的国内领先的软件组织中得到验证的。
>
> 第二，在这种环境下实施敏捷要注重实效，从影响较小收益较大的实践开始逐步引入，比较忌讳开口提大名词（例如SCRUM或者XP）。我会建议你以CMMI
> 5级的"自我改进"做旗帜，找到组织中存在浪费的环节，引入最佳实践来消除浪费，没有必要把敏捷挂在嘴边。
>
糖醋鼻子
Jul 25, 2008, 1:30:48 AM7/25/08
to 敏捷中国
都说CMMI是个万能工具箱，那么我感觉是不是可以把一个CMMI当做一个目标来做（或者一个项目），而具体的实践用scrum来支撑呢？
因为我们这里也有CMMI的要求（不过刚刚到CMMI2，比较落后），所以一直在关注其与敏捷的融合。
因为我们这里也有CMMI的要求（不过刚刚到CMMI2，比较落后），所以一直在关注其与敏捷的融合。
起步停车
Jul 25, 2008, 1:30:54 AM7/25/08
to 敏捷中国
恩, 很有道理。谢谢。 不管怎样， 这个步子一定要迈开了， 先找几个切入点， 先实践一下， 不断改进和调整，希望几次迭代后能有好的收获。
On 7月25日, 上午9时57分, "Liang Qiao" <sagittatius.q...@gmail.com> wrote:
> +1 按CMMI的初衷行事，而非按CMMI的模式。但要注意找到切入点， 特别是处在可度量级。
>
> +2 没有必要把敏捷挂在嘴边。不要对立，而要谦虚
>
> 2008/7/25 Jeff Xiong <gigix1...@gmail.com>:
>
> - 显示引用的文字 -
On 7月25日, 上午9时57分, "Liang Qiao" <sagittatius.q...@gmail.com> wrote:
> +1 按CMMI的初衷行事，而非按CMMI的模式。但要注意找到切入点， 特别是处在可度量级。
>
> +2 没有必要把敏捷挂在嘴边。不要对立，而要谦虚
>
>
>
>
> > 第一，CMMI要求的是软件组织具备成熟过程的*证据*，而诸如XP之类的敏捷方法只要使用得当是能够提供足够的证据来支持CMMI
> > 5级的要求的，所以在CMMI框架下实施敏捷方法是可行的，这是在一些采用CMM多年的国内领先的软件组织中得到验证的。
>
> > 第二，在这种环境下实施敏捷要注重实效，从影响较小收益较大的实践开始逐步引入，比较忌讳开口提大名词（例如SCRUM或者XP）。我会建议你以CMMI
> > 5级的"自我改进"做旗帜，找到组织中存在浪费的环节，引入最佳实践来消除浪费，没有必要把敏捷挂在嘴边。
>
> > 第三，一般来说，持续集成是开始这类改进活动的一个好的起点，因为持续集成强迫组织形成快速的反馈机制，从而让很多问题有机会在更短的时间暴露出来。另一方面持-续集成也是领导比较容易接受的一个实践。
>
>
> > 第一，CMMI要求的是软件组织具备成熟过程的*证据*，而诸如XP之类的敏捷方法只要使用得当是能够提供足够的证据来支持CMMI
> > 5级的要求的，所以在CMMI框架下实施敏捷方法是可行的，这是在一些采用CMM多年的国内领先的软件组织中得到验证的。
>
> > 第二，在这种环境下实施敏捷要注重实效，从影响较小收益较大的实践开始逐步引入，比较忌讳开口提大名词（例如SCRUM或者XP）。我会建议你以CMMI
> > 5级的"自我改进"做旗帜，找到组织中存在浪费的环节，引入最佳实践来消除浪费，没有必要把敏捷挂在嘴边。
>
>
> > 2008/7/24 起步停车 <tol...@163.com>:
> > > 公司一直在搞CMMI这个东西， 今年打算过5了。这些天领导忽然听说有个Scrum挺好， 要我们试一下， 然后任务层层下达......, 轮到我
> > > 了， 哎， 谁让咱在公司鼓吹XP 3年了呢？
>
> > > 幸亏前一阵子看完了那个Scrum的书和相关资料， 利用2天时间准备了一个文档, 把从敏捷大会上学的精益思想，华为实践...能想到的都搞在了一起
> > > （其实还没有真正明白Scrum），匆匆的跟各位领导讨论了一下......
>
> > > 结论， 不能Scrum+XP， 在现有框架(CMMI)下实施Scrum（这个命题都有问题吧）。
>
> > > 各位兄弟，我该如何敏捷呢，能敏捷的起来吗？
>
> > --
> > Jeff Xiong
> > 2008/7/24 起步停车 <tol...@163.com>:
> > > 公司一直在搞CMMI这个东西， 今年打算过5了。这些天领导忽然听说有个Scrum挺好， 要我们试一下， 然后任务层层下达......, 轮到我
> > > 了， 哎， 谁让咱在公司鼓吹XP 3年了呢？
>
> > > 幸亏前一阵子看完了那个Scrum的书和相关资料， 利用2天时间准备了一个文档, 把从敏捷大会上学的精益思想，华为实践...能想到的都搞在了一起
> > > （其实还没有真正明白Scrum），匆匆的跟各位领导讨论了一下......
>
> > > 结论， 不能Scrum+XP， 在现有框架(CMMI)下实施Scrum（这个命题都有问题吧）。
>
> > > 各位兄弟，我该如何敏捷呢，能敏捷的起来吗？
>
> > --
> > Jeff Xiong
> > Software Journeyman -http://gigix.thoughtworkers.org
> > Open Source Contributor -http://fluorida.googlecode.com/
> > Technical Evangelist -http://www.infoq.com/cn/- 隐藏被引用文字 -
> > Open Source Contributor -http://fluorida.googlecode.com/
>
> - 显示引用的文字 -
咖啡屋的鼠标
Jul 25, 2008, 1:36:56 AM7/25/08
to agile...@googlegroups.com
CMMI本身就是一些目标。一些软件开发中应该达到的目标，不含有具体实践。他评估的时候也是看你能不能自圆其说，证明自己实现了各个过程域。而他的一些范例实践以及咨询公司给搞得实践呢。唉，那些东西要是好用，CMMI的名字在开发人员这里就不会这么臭了。
虽然他提出的目标到底好还是不好，是个见仁见智的问题，不过有目标总还是有了个方向么。
虽然他提出的目标到底好还是不好，是个见仁见智的问题，不过有目标总还是有了个方向么。
2008/7/25 糖醋鼻子 <zhmo...@gmail.com>:
pengfei wang
Jul 25, 2008, 1:39:59 AM7/25/08
to agile...@googlegroups.com
CMMI除了 GG, SG,也有GP, SP
起步停车
Jul 25, 2008, 1:44:48 AM7/25/08
to 敏捷中国
谢谢咖鼠！：-）
现在CMMI5正在实施评审中...., 迭代模型还真是没有啊。
关于CI，我研究的比较少，回头去翻翻相关资料！
谢谢啦， 呵呵
On 7月25日, 上午10时44分, "咖啡屋的鼠标" <tj19...@gmail.com> wrote:
> Scrum只是一个架构，跟管理更相关。与CMMI里任何一个过程域都是不冲突的。计划会议、晨会、迭代、Backlog等等都不冲突（除非你们过了5级了，组-织过程财富库里还没有一个关于迭代的过程模型。）你可以把它描绘成一种更适合CMMI模型的实现。
>
> 实践起来CI确实是一个很好的切入点。坚持CI，自动化测试，慢慢的大家都会发现XP实践的价值的。
>
> 2008/7/25 Liang Qiao <sagittatius.q...@gmail.com>:
现在CMMI5正在实施评审中...., 迭代模型还真是没有啊。
关于CI，我研究的比较少，回头去翻翻相关资料！
谢谢啦， 呵呵
On 7月25日, 上午10时44分, "咖啡屋的鼠标" <tj19...@gmail.com> wrote:
> Scrum只是一个架构，跟管理更相关。与CMMI里任何一个过程域都是不冲突的。计划会议、晨会、迭代、Backlog等等都不冲突（除非你们过了5级了，组-织过程财富库里还没有一个关于迭代的过程模型。）你可以把它描绘成一种更适合CMMI模型的实现。
>
> 实践起来CI确实是一个很好的切入点。坚持CI，自动化测试，慢慢的大家都会发现XP实践的价值的。
>
> 2008/7/25 Liang Qiao <sagittatius.q...@gmail.com>:
>
>
>
> > +1 按CMMI的初衷行事，而非按CMMI的模式。但要注意找到切入点， 特别是处在可度量级。
>
> > +2 没有必要把敏捷挂在嘴边。不要对立，而要谦虚
>
> > 2008/7/25 Jeff Xiong <gigix1...@gmail.com>:
>
>
> > +1 按CMMI的初衷行事，而非按CMMI的模式。但要注意找到切入点， 特别是处在可度量级。
>
> > +2 没有必要把敏捷挂在嘴边。不要对立，而要谦虚
>
>
> > 第一，CMMI要求的是软件组织具备成熟过程的*证据*，而诸如XP之类的敏捷方法只要使用得当是能够提供足够的证据来支持CMMI
> >> 5级的要求的，所以在CMMI框架下实施敏捷方法是可行的，这是在一些采用CMM多年的国内领先的软件组织中得到验证的。
>
> >> 第二，在这种环境下实施敏捷要注重实效，从影响较小收益较大的实践开始逐步引入，比较忌讳开口提大名词（例如SCRUM或者XP）。我会建议你以CMMI
> >> 5级的"自我改进"做旗帜，找到组织中存在浪费的环节，引入最佳实践来消除浪费，没有必要把敏捷挂在嘴边。
>
> >> 第三，一般来说，持续集成是开始这类改进活动的一个好的起点，因为持续集成强迫组织形成快速的反馈机制，从而让很多问题有机会在更短的时间暴露出来。另一方面持-续集成也是领导比较容易接受的一个实践。
> > 第一，CMMI要求的是软件组织具备成熟过程的*证据*，而诸如XP之类的敏捷方法只要使用得当是能够提供足够的证据来支持CMMI
> >> 5级的要求的，所以在CMMI框架下实施敏捷方法是可行的，这是在一些采用CMM多年的国内领先的软件组织中得到验证的。
>
> >> 第二，在这种环境下实施敏捷要注重实效，从影响较小收益较大的实践开始逐步引入，比较忌讳开口提大名词（例如SCRUM或者XP）。我会建议你以CMMI
> >> 5级的"自我改进"做旗帜，找到组织中存在浪费的环节，引入最佳实践来消除浪费，没有必要把敏捷挂在嘴边。
>
>
> >> 2008/7/24 起步停车 <tol...@163.com>:
> >> > 公司一直在搞CMMI这个东西， 今年打算过5了。这些天领导忽然听说有个Scrum挺好， 要我们试一下， 然后任务层层下达......, 轮到我
> >> > 了， 哎， 谁让咱在公司鼓吹XP 3年了呢？
>
> >> > 幸亏前一阵子看完了那个Scrum的书和相关资料， 利用2天时间准备了一个文档, 把从敏捷大会上学的精益思想，华为实践...能想到的都搞在了一起
> >> > （其实还没有真正明白Scrum），匆匆的跟各位领导讨论了一下......
>
> >> > 结论， 不能Scrum+XP， 在现有框架(CMMI)下实施Scrum（这个命题都有问题吧）。
>
> >> > 各位兄弟，我该如何敏捷呢，能敏捷的起来吗？
>
> >> --
> >> Jeff Xiong
> >> 2008/7/24 起步停车 <tol...@163.com>:
> >> > 公司一直在搞CMMI这个东西， 今年打算过5了。这些天领导忽然听说有个Scrum挺好， 要我们试一下， 然后任务层层下达......, 轮到我
> >> > 了， 哎， 谁让咱在公司鼓吹XP 3年了呢？
>
> >> > 幸亏前一阵子看完了那个Scrum的书和相关资料， 利用2天时间准备了一个文档, 把从敏捷大会上学的精益思想，华为实践...能想到的都搞在了一起
> >> > （其实还没有真正明白Scrum），匆匆的跟各位领导讨论了一下......
>
> >> > 结论， 不能Scrum+XP， 在现有框架(CMMI)下实施Scrum（这个命题都有问题吧）。
>
> >> > 各位兄弟，我该如何敏捷呢，能敏捷的起来吗？
>
> >> --
> >> Jeff Xiong
> >> Software Journeyman -http://gigix.thoughtworkers.org
> >> Open Source Contributor -http://fluorida.googlecode.com/
> >> Open Source Contributor -http://fluorida.googlecode.com/
咖啡屋的鼠标
Jul 25, 2008, 1:47:25 AM7/25/08
to agile...@googlegroups.com
GP和SP有没错，但个人觉得，他那个实践还是很抽象的，比如需求管理里面的一些特殊实践：获得对需求的理解、获得对需求的承诺。这种东西比起XP里的实践，实在是抽象太多了。说他是一种目标，我觉得还是比较合适的。
2008/7/25 pengfei wang <roc...@gmail.com>:
起步停车
Jul 25, 2008, 1:54:05 AM7/25/08
to 敏捷中国
呵呵,
1） 就是想先试一下， 看看有效果的话在推广。
2） 我不是华为的， 只是在AgailChina上跟周耀辉聊了一会， 听了他的经验介绍；我当时也很想听路宁的那个精益软件开发了， 可惜冲突了。
提华为是为了更有说服力，在建议领导们考虑敏捷的时候。：-）
3） 我回去找这本书看的， 希望真能敏捷起来， 不仅为自己， 也为公司软件开发能有更多的从敏捷受益.
十分感谢， 呵呵
1） 就是想先试一下， 看看有效果的话在推广。
2） 我不是华为的， 只是在AgailChina上跟周耀辉聊了一会， 听了他的经验介绍；我当时也很想听路宁的那个精益软件开发了， 可惜冲突了。
提华为是为了更有说服力，在建议领导们考虑敏捷的时候。：-）
3） 我回去找这本书看的， 希望真能敏捷起来， 不仅为自己， 也为公司软件开发能有更多的从敏捷受益.
十分感谢， 呵呵
Steven Mak
Jul 25, 2008, 2:25:23 AM7/25/08
to 敏捷中国
Ken Schwaber 的 "Agile Project Management with Scrum" 有提到 CMMI 和
Scrum.
對於 "忌讳开口提大名词", Google 提供了一個很好的示範 :)
CI 的確是個好的起點, 特別是帶出自動化測試, TDD 等... 我想, 由自動化測試作為起點也不錯. 還有, 不要忽略你的 SCM.
Scrum.
對於 "忌讳开口提大名词", Google 提供了一個很好的示範 :)
CI 的確是個好的起點, 特別是帶出自動化測試, TDD 等... 我想, 由自動化測試作為起點也不錯. 還有, 不要忽略你的 SCM.
Jacky Li
Jul 25, 2008, 3:15:31 AM7/25/08
to agile...@googlegroups.com
Mak的想法一直都是比较理智成熟的。
想问一下，Mak是什么地区的朋友？做什么方面的工作，接触敏捷有多久了呢？
不知道这些问题是否冒昧了^_^
想问一下，Mak是什么地区的朋友？做什么方面的工作，接触敏捷有多久了呢？
不知道这些问题是否冒昧了^_^
2008/7/25 Steven Mak <stev...@gmail.com>
Steven Mak
Jul 25, 2008, 5:05:43 AM7/25/08
to 敏捷中国
的確有點受寵若驚 ^_^
朋友多數叫我 "Steven". ("Mak" 是姓氏). 我年紀不小, 可能這樣 "成熟" 的, 哈.
接触敏捷方面... 我也不知道從何算起, 大學時候已經對軟件工程感到興趣 (不過當時老師說的都是 CMM), 出來工作之後也有閱讀相關書本,
第一本和敏捷有關的書本是 2000年 Kent Beck 的 <Extreme Programming explained -
embrace change>, 也留意相關網站, 主要以外國網站和書本為主, e.g Yahoo Group list 上有很多大大小小相關
的社區, 直到上年才知道有 AgileChina 討論區. 看的越多, 越發現自己有更多需要認識的事情.
和敏捷有關的實踐就近幾年才開始嘗試實行, 目前工作老闆給我的自由度挺大, 不過始終面對不少實際和基本問題, 所以在實施方面慚愧地還在處理很多基
本的事情上. (e.g. 例如教同事如何正確進行測試, 寫 unit test 之類...), 這些就不便獻醜了 :)
其他的問題, 我會 email 回答你的.
On Jul 25, 3:15 pm, "Jacky Li" <veryfa...@gmail.com> wrote:
> Mak的想法一直都是比较理智成熟的。
>
> 想问一下，Mak是什么地区的朋友？做什么方面的工作，接触敏捷有多久了呢？
>
> 不知道这些问题是否冒昧了^_^
>
> 2008/7/25 Steven Mak <steven...@gmail.com>
朋友多數叫我 "Steven". ("Mak" 是姓氏). 我年紀不小, 可能這樣 "成熟" 的, 哈.
接触敏捷方面... 我也不知道從何算起, 大學時候已經對軟件工程感到興趣 (不過當時老師說的都是 CMM), 出來工作之後也有閱讀相關書本,
第一本和敏捷有關的書本是 2000年 Kent Beck 的 <Extreme Programming explained -
embrace change>, 也留意相關網站, 主要以外國網站和書本為主, e.g Yahoo Group list 上有很多大大小小相關
的社區, 直到上年才知道有 AgileChina 討論區. 看的越多, 越發現自己有更多需要認識的事情.
和敏捷有關的實踐就近幾年才開始嘗試實行, 目前工作老闆給我的自由度挺大, 不過始終面對不少實際和基本問題, 所以在實施方面慚愧地還在處理很多基
本的事情上. (e.g. 例如教同事如何正確進行測試, 寫 unit test 之類...), 這些就不便獻醜了 :)
其他的問題, 我會 email 回答你的.
On Jul 25, 3:15 pm, "Jacky Li" <veryfa...@gmail.com> wrote:
> Mak的想法一直都是比较理智成熟的。
>
> 想问一下，Mak是什么地区的朋友？做什么方面的工作，接触敏捷有多久了呢？
>
> 不知道这些问题是否冒昧了^_^
>
Jacky Li
Jul 25, 2008, 5:13:43 AM7/25/08
to agile...@googlegroups.com
其实，我觉得"处理很多基本的事情"正是很多人所需的呢，脱离了这些基本的东西，可就成了空谈。
你的邮箱是gtalk帐号么？我刚加了好友
你的邮箱是gtalk帐号么？我刚加了好友
2008/7/25 Steven Mak <stev...@gmail.com>
Liang Qiao
Jul 28, 2008, 2:37:43 AM7/28/08
to agile...@googlegroups.com
其实，我觉得"处理很多基本的事情"正是很多人所需的呢，脱离了这些基本的东西，可就成了空谈。
＋1，真正要学习的正是最基本的东西，回头看看各种Agile或非Agile的方法（或类似的东西），都是想解决基本的东西。
起步停车
Jul 28, 2008, 3:42:37 AM7/28/08
to 敏捷中国
大家都建议先引入CI， 我也打算这几天试一下。
我很认可敏捷和精益软件开发的一些思想。
比如消除浪费，我们现在对于文档的处理完全就是一种资源浪费，比如TDD， 但可是， 可但是， 如果我们改进文档处理方式或者实施TDD这些东西的
话，会有人跳出来阻止的。 因为他们认为， 他们看不到相关文档， 就以为缺少了什么东西。
认同Mo Li 说的，如果不能改变的话， 自己先做起来吧，试着慢慢影响其他人吧。
> > 各位兄弟，我该如何敏捷呢，能敏捷的起来吗？- 隐藏被引用文字 -
>
> - 显示引用的文字 -
我很认可敏捷和精益软件开发的一些思想。
比如消除浪费，我们现在对于文档的处理完全就是一种资源浪费，比如TDD， 但可是， 可但是， 如果我们改进文档处理方式或者实施TDD这些东西的
话，会有人跳出来阻止的。 因为他们认为， 他们看不到相关文档， 就以为缺少了什么东西。
认同Mo Li 说的，如果不能改变的话， 自己先做起来吧，试着慢慢影响其他人吧。
>
> - 显示引用的文字 -
Jeff Xiong
Jul 28, 2008, 3:44:49 AM7/28/08
to agile...@googlegroups.com
其实这事情很简单。
继续写文档好了。
继续写文档好了。
2008/7/28 起步停车 <tol...@163.com>:
> 我很认可敏捷和精益软件开发的一些思想。
>
> 比如消除浪费，我们现在对于文档的处理完全就是一种资源浪费，比如TDD， 但可是， 可但是， 如果我们改进文档处理方式或者实施TDD这些东西的
> 话，会有人跳出来阻止的。 因为他们认为， 他们看不到相关文档， 就以为缺少了什么东西。
--
Jeff Xiong
徐毅
Jul 28, 2008, 5:42:17 AM7/28/08
to agile...@googlegroups.com
2008/7/28 起步停车 <tol...@163.com>
大家都建议先引入CI， 我也打算这几天试一下。
我很认可敏捷和精益软件开发的一些思想。
比如消除浪费，我们现在对于文档的处理完全就是一种资源浪费，比如TDD， 但可是， 可但是， 如果我们改进文档处理方式或者实施TDD这些东西的
话，会有人跳出来阻止的。 因为他们认为， 他们看不到相关文档， 就以为缺少了什么东西。
认同Mo Li 说的，如果不能改变的话， 自己先做起来吧，试着慢慢影响其他人吧。
呃，提个醒，CI一般会带出许多问题，涉及到UT/FT/SCM等各方面，建议你们在分析问题的根源的时候别放到CI上去，而是切实地找办法解决那些被暴露出来的问题。
Steven Mak
Jul 28, 2008, 6:51:15 AM7/28/08
to 敏捷中国
如果可以的話, 和跳出來的人了解一下為什麼需要這些文檔. 雖然最後可能繼續要去寫.
如果可以自動生成也不錯.
On Jul 28, 3:44 pm, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> 其实这事情很简单。
> 继续写文档好了。
>
> 2008/7/28 起步停车 <tol...@163.com>:
>
> > 我很认可敏捷和精益软件开发的一些思想。
>
> > 比如消除浪费，我们现在对于文档的处理完全就是一种资源浪费，比如TDD， 但可是， 可但是， 如果我们改进文档处理方式或者实施TDD这些东西的
> > 话，会有人跳出来阻止的。 因为他们认为， 他们看不到相关文档， 就以为缺少了什么东西。
>
> --
> Jeff Xiong
如果可以自動生成也不錯.
On Jul 28, 3:44 pm, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> 其实这事情很简单。
> 继续写文档好了。
>
> 2008/7/28 起步停车 <tol...@163.com>:
>
> > 我很认可敏捷和精益软件开发的一些思想。
>
> > 比如消除浪费，我们现在对于文档的处理完全就是一种资源浪费，比如TDD， 但可是， 可但是， 如果我们改进文档处理方式或者实施TDD这些东西的
> > 话，会有人跳出来阻止的。 因为他们认为， 他们看不到相关文档， 就以为缺少了什么东西。
>
> --
> Jeff Xiong
pipi
Jul 28, 2008, 8:16:22 AM7/28/08
to 敏捷中国
我的建议是，去看看公司有什么问题，为解决问题而引入Agile，而不是为了Agile而Agile。没有问题又何必引入Agile呢。就好像很多世界
顶级软件公司都不需要采用CMMI一样，因为自身的软件开发流程已经很成熟了，不存在问题需要引入CMMI来解决的。
顶级软件公司都不需要采用CMMI一样，因为自身的软件开发流程已经很成熟了，不存在问题需要引入CMMI来解决的。
pipi
Jul 28, 2008, 8:21:46 AM7/28/08
to 敏捷中国
文档是不是浪费，这个有时候也是见仁见智，确实要倾听别人的意见。看看好处在哪里，然后怎么避免不足之处。一棍子打死可就不好了。
我自己对文档有两种看法：
1. 要么不写，要写就写有质量的文档（低质量的文档还不如不写）
2. 提供给客户的文档优先于内部使用的文档（给客户的文档是更有价值的）
但是我觉得这些和Agile关系不大，纯粹是文档相关的工作改进罢了。
我自己对文档有两种看法：
1. 要么不写，要写就写有质量的文档（低质量的文档还不如不写）
2. 提供给客户的文档优先于内部使用的文档（给客户的文档是更有价值的）
但是我觉得这些和Agile关系不大，纯粹是文档相关的工作改进罢了。
yk where
Jul 28, 2008, 8:23:58 AM7/28/08
to agile...@googlegroups.com
个人觉得和TQM一样, CMMI最后将会分解为硬与软两种类型.硬的强调过程控制,软的强调持续改进. 而软的为融合Agile提供了更广阔的空间.
同意楼上说的,从持续改进的角度说事, 看看是否有引进SCRUM的必要和可能.
徐毅
Jul 28, 2008, 9:22:53 AM7/28/08
to agile...@googlegroups.com
做外包的，更看重名字。
做产品的，更看重效果。
CMMI,Agile，各取所需罢了。
做产品的，更看重效果。
CMMI,Agile，各取所需罢了。
起步停车
Jul 28, 2008, 9:45:04 AM7/28/08
to 敏捷中国
公司企业文化里面提倡可见性， 所以，领导们对文档很重视，或者说对流程很重视，而流程是否执行的“标志”就是这些文档（当然， 文档的质量好坏没人去
查，先汗一个）， 有个考评内容尽然是文档的多少（再次鄙视一下这种）。 说实话，对于软件开发而言， 公司做的很外行。 这个问题下面的人看的很清
楚，但一直没有办法去改变。 就如同你说的， 继续写文档就好了，反正有人付钱给我们， 怕啥？
于我来说， 我情愿去找到一些更好的办法， 而不情愿去闷头去些所谓垃圾文档。
屏蔽着领导， 在下面偷偷做了些小动作， 采用了XP的某些原则， 比如小规模发版， 一周2次或者1次； 跟用户说明需要他尽快的review
and feedback, 在关键点上结对。确实取得了比较满意的效果， 至少客户满意度提高了不少哦。
呵呵， 现在终于有机会了， 开始光明正大的尝试了， 不再需要那种“悄悄的进村， 打枪的不要”行为了。
> 2008/7/28 起步停车 <tol...@163.com>:
>
> > 我很认可敏捷和精益软件开发的一些思想。
>
> > 比如消除浪费，我们现在对于文档的处理完全就是一种资源浪费，比如TDD， 但可是， 可但是， 如果我们改进文档处理方式或者实施TDD这些东西的
> > 话，会有人跳出来阻止的。 因为他们认为， 他们看不到相关文档， 就以为缺少了什么东西。
>
> --
> Jeff Xiong
查，先汗一个）， 有个考评内容尽然是文档的多少（再次鄙视一下这种）。 说实话，对于软件开发而言， 公司做的很外行。 这个问题下面的人看的很清
楚，但一直没有办法去改变。 就如同你说的， 继续写文档就好了，反正有人付钱给我们， 怕啥？
于我来说， 我情愿去找到一些更好的办法， 而不情愿去闷头去些所谓垃圾文档。
屏蔽着领导， 在下面偷偷做了些小动作， 采用了XP的某些原则， 比如小规模发版， 一周2次或者1次； 跟用户说明需要他尽快的review
and feedback, 在关键点上结对。确实取得了比较满意的效果， 至少客户满意度提高了不少哦。
呵呵， 现在终于有机会了， 开始光明正大的尝试了， 不再需要那种“悄悄的进村， 打枪的不要”行为了。
> 2008/7/28 起步停车 <tol...@163.com>:
>
> > 我很认可敏捷和精益软件开发的一些思想。
>
> > 比如消除浪费，我们现在对于文档的处理完全就是一种资源浪费，比如TDD， 但可是， 可但是， 如果我们改进文档处理方式或者实施TDD这些东西的
> > 话，会有人跳出来阻止的。 因为他们认为， 他们看不到相关文档， 就以为缺少了什么东西。
>
> --
> Jeff Xiong
起步停车
Jul 28, 2008, 9:46:01 AM7/28/08
to 敏捷中国
谢谢！ 记下徐毅的忠告了！ 呵呵。
On 7月28日, 下午5时42分, "徐毅" <kaverj...@gmail.com> wrote:
> 2008/7/28 起步停车 <tol...@163.com>
>
> > 大家都建议先引入CI， 我也打算这几天试一下。
>
> > 我很认可敏捷和精益软件开发的一些思想。
>
> > 比如消除浪费，我们现在对于文档的处理完全就是一种资源浪费，比如TDD， 但可是， 可但是， 如果我们改进文档处理方式或者实施TDD这些东西的
> > 话，会有人跳出来阻止的。 因为他们认为， 他们看不到相关文档， 就以为缺少了什么东西。
>
> > 认同Mo Li 说的，如果不能改变的话， 自己先做起来吧，试着慢慢影响其他人吧。
>
> 呃，提个醒，CI一般会带出许多问题，涉及到UT/FT/SCM等各方面，建议你们在分析问题的根源的时候别放到CI上去，而是切实地找办法解决那些被暴露出来-的问题。
On 7月28日, 下午5时42分, "徐毅" <kaverj...@gmail.com> wrote:
> 2008/7/28 起步停车 <tol...@163.com>
>
> > 大家都建议先引入CI， 我也打算这几天试一下。
>
> > 我很认可敏捷和精益软件开发的一些思想。
>
> > 比如消除浪费，我们现在对于文档的处理完全就是一种资源浪费，比如TDD， 但可是， 可但是， 如果我们改进文档处理方式或者实施TDD这些东西的
> > 话，会有人跳出来阻止的。 因为他们认为， 他们看不到相关文档， 就以为缺少了什么东西。
>
> > 认同Mo Li 说的，如果不能改变的话， 自己先做起来吧，试着慢慢影响其他人吧。
>
起步停车
Jul 28, 2008, 9:54:55 AM7/28/08
to 敏捷中国
是的。我同意皮皮说的。
文档是在项目中我们互相交流必不可少的一部分， 不管这种文档的格式是什么， 可能是一片WORD文档， 也可能是一段录像视频资料......
其实大家需要的大部分是有一定粒度级的文档， 文档不能太细节化， 否则问题很多，首先， 1） 我们很难保证文档反映当前软件的实际情况， 也就是说
文档很容易过时，不能即使更新的文档，反而会干扰我们的判断。2） 我不会去为了维护或者扩展某些功能， 去看几十页的word的文档， 除非我疯
了， 那些东西也不是金庸的小说，一般都很晦涩难懂， 参考1）， 反而更是让人恶心的不行。
文档是在项目中我们互相交流必不可少的一部分， 不管这种文档的格式是什么， 可能是一片WORD文档， 也可能是一段录像视频资料......
其实大家需要的大部分是有一定粒度级的文档， 文档不能太细节化， 否则问题很多，首先， 1） 我们很难保证文档反映当前软件的实际情况， 也就是说
文档很容易过时，不能即使更新的文档，反而会干扰我们的判断。2） 我不会去为了维护或者扩展某些功能， 去看几十页的word的文档， 除非我疯
了， 那些东西也不是金庸的小说，一般都很晦涩难懂， 参考1）， 反而更是让人恶心的不行。
Jeff Xiong
Jul 28, 2008, 9:56:47 AM7/28/08
to agile...@googlegroups.com
实际上这涉及到过程改进的一个关键问题：持续改进的机制。不管TDD、结对编程还是取消垃圾文档，这都是改进的*手段*。在手段之外更重要的是在组织中建立一种持续改进的*机制*，尤其是发现浪费的机制。如果没有这种机制的存在或者说领导意识不到这种机制的存在，那么你所做的改进都是剃头挑子一头热，领导这两天听这阵风让你搞搞，过两天听另一阵风就可能让你停手不搞。而不管你做了多少的手段，不能把持续改进的机制建立起来，过程还是会逐渐退化，最后很可能你就会发现这个组织干了一段时间敏捷热闹了几个月然后又回到了老样子。
之所以说"继续写文档好了"，是因为你在这个地方已经采取了改进手段，你知道这个地方会出现浪费，所以你就有机会来观察这种浪费，学会度量浪费，学会向领导描述浪费和过程改进，然后你有可能以此为起点建立起发现浪费消除浪费的*机制*，也就是持续改进的机制。这才是你最终能取得效果的关键所在。
2008/7/28 起步停车 <tol...@163.com>:
>
>
> On 7月28日, 下午3时44分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
>> 其实这事情很简单。
>> 继续写文档好了。
>
>
> 公司企业文化里面提倡可见性， 所以，领导们对文档很重视，或者说对流程很重视，而流程是否执行的"标志"就是这些文档（当然， 文档的质量好坏没人去
> 查，先汗一个）， 有个考评内容尽然是文档的多少（再次鄙视一下这种）。 说实话，对于软件开发而言， 公司做的很外行。 这个问题下面的人看的很清
> 楚，但一直没有办法去改变。 就如同你说的， 继续写文档就好了，反正有人付钱给我们， 怕啥？
>
> 于我来说， 我情愿去找到一些更好的办法， 而不情愿去闷头去些所谓垃圾文档。
>
> 屏蔽着领导， 在下面偷偷做了些小动作， 采用了XP的某些原则， 比如小规模发版， 一周2次或者1次； 跟用户说明需要他尽快的review
> and feedback, 在关键点上结对。确实取得了比较满意的效果， 至少客户满意度提高了不少哦。
>
> 呵呵， 现在终于有机会了， 开始光明正大的尝试了， 不再需要那种"悄悄的进村， 打枪的不要"行为了。
>
--
Jeff Xiong
Jacky Li
Jul 28, 2008, 10:03:41 AM7/28/08
to agile...@googlegroups.com
InfoQ中文站近期会发表一篇文章：用数字沟通----来自敏捷精灵的忠告。这里先摘抄其中一段话
~~~~~~~~~~~~~小刀的分割线~~~~~~~~~~~~~~~~~
有趣之处在于管理者喜欢与数字打交道，所以如果你跟Jim谈这个问题的时候，用数字而不是 带有个人情感的方式来表达，他对问题影响的理解会更加清晰和简单。这样你会更有希望获得别人的反应和行动----除非是连傻瓜都能做决定的事情。一个导师告诉 我，很容易做的决定不算是决定！管理者要根据成本和收益来考虑问题----选择'是'和选择'否'，会带来什么样的影响。成本和收益可以用模糊或者明确的方式来 表示。他们喜欢明确的方式，因为它往往基于数字，而不是个人的情感。数字是无可争辩的。如果别人对你提出质疑，通过数字，你可以很容易地获得证明和支持。同时，在进行短期和长期的公司战略规划时，数字也会有帮助。数字的增减可以表示某件事的程度。模糊的方式不好处理，难以判断，更难着手。出错的几率增大，而且个人也很容易做出不同的诠释与质疑。如果需要的话，人们会采取模糊的方式。但是管理者更喜欢具体的方式，如果这些数字足以帮他们做出决定的话。
~~~~~~~~~~~~~小刀的分割线~~~~~~~~~~~~~~~~~
有趣之处在于管理者喜欢与数字打交道，所以如果你跟Jim谈这个问题的时候，用数字而不是 带有个人情感的方式来表达，他对问题影响的理解会更加清晰和简单。这样你会更有希望获得别人的反应和行动----除非是连傻瓜都能做决定的事情。一个导师告诉 我，很容易做的决定不算是决定！管理者要根据成本和收益来考虑问题----选择'是'和选择'否'，会带来什么样的影响。成本和收益可以用模糊或者明确的方式来 表示。他们喜欢明确的方式，因为它往往基于数字，而不是个人的情感。数字是无可争辩的。如果别人对你提出质疑，通过数字，你可以很容易地获得证明和支持。同时，在进行短期和长期的公司战略规划时，数字也会有帮助。数字的增减可以表示某件事的程度。模糊的方式不好处理，难以判断，更难着手。出错的几率增大，而且个人也很容易做出不同的诠释与质疑。如果需要的话，人们会采取模糊的方式。但是管理者更喜欢具体的方式，如果这些数字足以帮他们做出决定的话。
"我给你一些建议，Rick。把模糊的原因变得更明确。你之前告诉Jim的方式就很模糊 ----只谈到一个团队成员的态度和行为，而且非常个人化----都是关于某个人的，这容易导致误解。可以用下面这些明确的数字进行解释：公司成本、返工、完成任 务所需的额外时间、在会议上浪费的时间、公司需要承担的真实成本，这样阐述问题老板就可以理解了。下次，给Jim一些具体的内容，一些他能够向老板汇报的信息，他们做出的决定会让你更开心。"
2008/7/28 起步停车 <tol...@163.com>
Xiaoming Wang
Jul 28, 2008, 10:58:18 AM7/28/08
to agile...@googlegroups.com
One tip:
Make sure that every document has audiences; every practice solves problems.
Make sure that every document has audiences; every practice solves problems.
2008/7/28 Jacky Li <very...@gmail.com>
--
Best Regards
Xiaoming Wang
Web log: http://ossme.com/
Photo album: http://www.flickr.com/photos/satanyork
徐毅
Jul 28, 2008, 12:00:18 PM7/28/08
to agile...@googlegroups.com
2008/7/28 Xiaoming Wang <wxm...@gmail.com>
One tip:
Make sure that every document has audiences; every practice solves problems.
另一个tip，有时候，你需要靠自己跳进麻烦里面去，花上一些时间去解决难题（越是最突出的难题越好），把麻烦在过去造成的时间和资源的数据，与你解决麻烦之后所需要的时间及资源的数据对比，就可以更明显地展示出你所使用的那些（通常属于敏捷的）实践的效果。
这些切切实实做出来的效果，加上你的解释和分析，才能给予领导者或其他同事信心去采用更多的敏捷实践。
CI绝对是一个最好的切入点。
这些切切实实做出来的效果，加上你的解释和分析，才能给予领导者或其他同事信心去采用更多的敏捷实践。
CI绝对是一个最好的切入点。
Anchuan Qian
Jul 28, 2008, 10:28:44 PM7/28/08
to agile...@googlegroups.com
Liang Qiao
Jul 28, 2008, 10:31:48 PM7/28/08
to agile...@googlegroups.com
起步停车
Jul 29, 2008, 1:27:25 AM7/29/08
to 敏捷中国
这句话："这都是改进的*手段*。在手段之外更重要的是在组织中建立一种-持续改进的*机制*，尤其是发现浪费的机制。"， 醍醐灌顶的感觉！兄弟，
说的太棒了！
看了大家的讨论，我现在有了一个初步的想法了， 我想做一个统计， 看看这些文档在最近一个时间段内，那些被下载过（就是有人感兴趣，确实看过）， 然
后统计一下大家在这些文档上的花费时间。 如果最近2个月，我们公司所有人产出了200篇文档， 共计花费了假设1000小时，只有3篇文档被浏览
过， 这中间就明显的存在这一种巨大的浪费。我还会看被浏览的这3篇文档， 是什么类型的文档？ 是SRS，Detail Design， 还是
test case？ 然后在分析我们到底需要什么类型的文档， 这些文档要做成什么粒度才能对我们有真正的指导意义？
On 7月28日, 下午9时56分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> 实际上这涉及到过程改进的一个关键问题：持续改进的机制。不管TDD、结对编程还是取消垃圾文档，这都是改进的*手段*。在手段之外更重要的是在组织中建立一种-持续改进的*机制*，尤其是发现浪费的机制。如果没有这种机制的存在或者说领导意识不到这种机制的存在，那么你所做的改进都是剃头挑子一头热，领导这两天听这阵-风让你搞搞，过两天听另一阵风就可能让你停手不搞。而不管你做了多少的手段，不能把持续改进的机制建立起来，过程还是会逐渐退化，最后很可能你就会发现这个组织-干了一段时间敏捷热闹了几个月然后又回到了老样子。
>
> 之所以说"继续写文档好了"，是因为你在这个地方已经采取了改进手段，你知道这个地方会出现浪费，所以你就有机会来观察这种浪费，学会度量浪费，学会向领导描述-浪费和过程改进，然后你有可能以此为起点建立起发现浪费消除浪费的*机制*，也就是持续改进的机制。这才是你最终能取得效果的关键所在。
>
> - 显示引用的文字 -
说的太棒了！
看了大家的讨论，我现在有了一个初步的想法了， 我想做一个统计， 看看这些文档在最近一个时间段内，那些被下载过（就是有人感兴趣，确实看过）， 然
后统计一下大家在这些文档上的花费时间。 如果最近2个月，我们公司所有人产出了200篇文档， 共计花费了假设1000小时，只有3篇文档被浏览
过， 这中间就明显的存在这一种巨大的浪费。我还会看被浏览的这3篇文档， 是什么类型的文档？ 是SRS，Detail Design， 还是
test case？ 然后在分析我们到底需要什么类型的文档， 这些文档要做成什么粒度才能对我们有真正的指导意义？
On 7月28日, 下午9时56分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> 实际上这涉及到过程改进的一个关键问题：持续改进的机制。不管TDD、结对编程还是取消垃圾文档，这都是改进的*手段*。在手段之外更重要的是在组织中建立一种-持续改进的*机制*，尤其是发现浪费的机制。如果没有这种机制的存在或者说领导意识不到这种机制的存在，那么你所做的改进都是剃头挑子一头热，领导这两天听这阵-风让你搞搞，过两天听另一阵风就可能让你停手不搞。而不管你做了多少的手段，不能把持续改进的机制建立起来，过程还是会逐渐退化，最后很可能你就会发现这个组织-干了一段时间敏捷热闹了几个月然后又回到了老样子。
>
> 之所以说"继续写文档好了"，是因为你在这个地方已经采取了改进手段，你知道这个地方会出现浪费，所以你就有机会来观察这种浪费，学会度量浪费，学会向领导描述-浪费和过程改进，然后你有可能以此为起点建立起发现浪费消除浪费的*机制*，也就是持续改进的机制。这才是你最终能取得效果的关键所在。
>
> 2008/7/28 起步停车 <tol...@163.com>:
>
>
>
>
>
>
>
> > On 7月28日, 下午3时44分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> >> 其实这事情很简单。
> >> 继续写文档好了。
>
> > 公司企业文化里面提倡可见性， 所以，领导们对文档很重视，或者说对流程很重视，而流程是否执行的"标志"就是这些文档（当然， 文档的质量好坏没人去
> > 查，先汗一个）， 有个考评内容尽然是文档的多少（再次鄙视一下这种）。 说实话，对于软件开发而言， 公司做的很外行。 这个问题下面的人看的很清
> > 楚，但一直没有办法去改变。 就如同你说的， 继续写文档就好了，反正有人付钱给我们， 怕啥？
>
> > 于我来说， 我情愿去找到一些更好的办法， 而不情愿去闷头去些所谓垃圾文档。
>
> > 屏蔽着领导， 在下面偷偷做了些小动作， 采用了XP的某些原则， 比如小规模发版， 一周2次或者1次； 跟用户说明需要他尽快的review
> > and feedback, 在关键点上结对。确实取得了比较满意的效果， 至少客户满意度提高了不少哦。
>
> > 呵呵， 现在终于有机会了， 开始光明正大的尝试了， 不再需要那种"悄悄的进村， 打枪的不要"行为了。
>
> --
> Jeff Xiong
> 2008/7/28 起步停车 <tol...@163.com>:
>
>
>
>
>
>
>
> > On 7月28日, 下午3时44分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> >> 其实这事情很简单。
> >> 继续写文档好了。
>
> > 公司企业文化里面提倡可见性， 所以，领导们对文档很重视，或者说对流程很重视，而流程是否执行的"标志"就是这些文档（当然， 文档的质量好坏没人去
> > 查，先汗一个）， 有个考评内容尽然是文档的多少（再次鄙视一下这种）。 说实话，对于软件开发而言， 公司做的很外行。 这个问题下面的人看的很清
> > 楚，但一直没有办法去改变。 就如同你说的， 继续写文档就好了，反正有人付钱给我们， 怕啥？
>
> > 于我来说， 我情愿去找到一些更好的办法， 而不情愿去闷头去些所谓垃圾文档。
>
> > 屏蔽着领导， 在下面偷偷做了些小动作， 采用了XP的某些原则， 比如小规模发版， 一周2次或者1次； 跟用户说明需要他尽快的review
> > and feedback, 在关键点上结对。确实取得了比较满意的效果， 至少客户满意度提高了不少哦。
>
> > 呵呵， 现在终于有机会了， 开始光明正大的尝试了， 不再需要那种"悄悄的进村， 打枪的不要"行为了。
>
> --
> Jeff Xiong
> Software Journeyman -http://gigix.thoughtworkers.org
> Open Source Contributor -http://fluorida.googlecode.com/
> Technical Evangelist -http://www.infoq.com/cn/- 隐藏被引用文字 -
> Open Source Contributor -http://fluorida.googlecode.com/
>
> - 显示引用的文字 -
起步停车
Jul 29, 2008, 1:30:58 AM7/29/08
to 敏捷中国
期待啊！
小刀，文章中会有具体的实际例子或者具体措施吗？
On 7月28日, 下午10时03分, "Jacky Li" <veryfa...@gmail.com> wrote:
> InfoQ中文站近期会发表一篇文章：用数字沟通----来自敏捷精灵的忠告。这里先摘抄其中一段话
>
> ~~~~~~~~~~~~~小刀的分割线~~~~~~~~~~~~~~~~~
>
> *有趣之处在于管理者喜欢与数字打交道，所以如果你跟Jim谈这个问题的时候，用数字而不是
> 你可以很容易地获得证明和支持。同时，在进行短期和长期的公司战略规划时，**数字**
> 也会有帮助。数字的增减可以表示某件事的程度。模糊的方式不好处理，难以判断，更难着手。出错的几率增大，而且个人也很容易做出不同的诠释与质疑。如果需要的话-，人们会采取模糊的方式。但是管理者更喜欢具体的方式，如果这些数字足以帮他们做出决定的话。
> *
>
> *"我给你一些建议，Rick。把模糊的原因变得更明确。你之前告诉Jim的方式就很模糊
> ----只谈到一个团队成员的态度和行为，而且非常个人化----都是关于某个人的，这容易导致误解。可以用下面这些明确的数字进行解释：公司成本、返工、完成-任
> 务所需的额外时间、在会议上浪费的时间、公司**需要**
> 承担的真实成本，这样阐述问题老板就可以理解了。下次，给Jim一些具体的内容，一些他能够向老板汇报的信息，他们做出的决定会让你更开心。"*
>
> - 显示引用的文字 -
小刀，文章中会有具体的实际例子或者具体措施吗？
On 7月28日, 下午10时03分, "Jacky Li" <veryfa...@gmail.com> wrote:
> InfoQ中文站近期会发表一篇文章：用数字沟通----来自敏捷精灵的忠告。这里先摘抄其中一段话
>
> ~~~~~~~~~~~~~小刀的分割线~~~~~~~~~~~~~~~~~
>
> *有趣之处在于管理者喜欢与数字打交道，所以如果你跟Jim谈这个问题的时候，用数字而不是
> 带有个人情感的方式来表达，他对问题影响的理解会更加清晰和简单。这样你会更有希望获得别人的反应和行动----除非是连傻瓜都能做决定的事情。一个导师告诉
> 我，很容易做的决定不算是决定！管理者要根据成本和收益来考虑问题----选择'是'和选择'否'，会带来什么样的影响。成本和收益可以用模糊或者明确的方式来
> 表示。他们喜欢明确的方式，因为它往往基于数字，而不是个人的情感。数字是无可争辩的。如果别人对你提出质疑，**通过数字，**
> 我，很容易做的决定不算是决定！管理者要根据成本和收益来考虑问题----选择'是'和选择'否'，会带来什么样的影响。成本和收益可以用模糊或者明确的方式来
> 你可以很容易地获得证明和支持。同时，在进行短期和长期的公司战略规划时，**数字**
> 也会有帮助。数字的增减可以表示某件事的程度。模糊的方式不好处理，难以判断，更难着手。出错的几率增大，而且个人也很容易做出不同的诠释与质疑。如果需要的话-，人们会采取模糊的方式。但是管理者更喜欢具体的方式，如果这些数字足以帮他们做出决定的话。
> *
>
> *"我给你一些建议，Rick。把模糊的原因变得更明确。你之前告诉Jim的方式就很模糊
> ----只谈到一个团队成员的态度和行为，而且非常个人化----都是关于某个人的，这容易导致误解。可以用下面这些明确的数字进行解释：公司成本、返工、完成-任
> 务所需的额外时间、在会议上浪费的时间、公司**需要**
> 承担的真实成本，这样阐述问题老板就可以理解了。下次，给Jim一些具体的内容，一些他能够向老板汇报的信息，他们做出的决定会让你更开心。"*
>
> 2008/7/28 起步停车 <tol...@163.com>
>
>
>
>
>
>
>
> > On 7月28日, 下午3时44分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> > > 其实这事情很简单。
> > > 继续写文档好了。
>
> > 公司企业文化里面提倡可见性， 所以，领导们对文档很重视，或者说对流程很重视，而流程是否执行的"标志"就是这些文档（当然， 文档的质量好坏没人去
> > 查，先汗一个）， 有个考评内容尽然是文档的多少（再次鄙视一下这种）。 说实话，对于软件开发而言， 公司做的很外行。 这个问题下面的人看的很清
> > 楚，但一直没有办法去改变。 就如同你说的， 继续写文档就好了，反正有人付钱给我们， 怕啥？
>
> > 于我来说， 我情愿去找到一些更好的办法， 而不情愿去闷头去些所谓垃圾文档。
>
> > 屏蔽着领导， 在下面偷偷做了些小动作， 采用了XP的某些原则， 比如小规模发版， 一周2次或者1次； 跟用户说明需要他尽快的review
> > and feedback, 在关键点上结对。确实取得了比较满意的效果， 至少客户满意度提高了不少哦。
>
> > 呵呵， 现在终于有机会了， 开始光明正大的尝试了， 不再需要那种"悄悄的进村， 打枪的不要"行为了。
>
> > > 2008/7/28 起步停车 <tol...@163.com>:
>
> > > > 我很认可敏捷和精益软件开发的一些思想。
>
> > > > 比如消除浪费，我们现在对于文档的处理完全就是一种资源浪费，比如TDD， 但可是， 可但是， 如果我们改进文档处理方式或者实施TDD这些东西的
> > > > 话，会有人跳出来阻止的。 因为他们认为， 他们看不到相关文档， 就以为缺少了什么东西。
>
> > > --
> > > Jeff Xiong
> > > Software Journeyman -http://gigix.thoughtworkers.org
> > > Open Source Contributor -http://fluorida.googlecode.com/
> > > Technical Evangelist -http://www.infoq.com/cn/
>
> --
> Jacky Li
>
> InfoQ China Agile Lead Editor:www.infoq.com/cn
> +86 138 1045 9095- 隐藏被引用文字 -
> 2008/7/28 起步停车 <tol...@163.com>
>
>
>
>
>
>
>
> > On 7月28日, 下午3时44分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> > > 其实这事情很简单。
> > > 继续写文档好了。
>
> > 公司企业文化里面提倡可见性， 所以，领导们对文档很重视，或者说对流程很重视，而流程是否执行的"标志"就是这些文档（当然， 文档的质量好坏没人去
> > 查，先汗一个）， 有个考评内容尽然是文档的多少（再次鄙视一下这种）。 说实话，对于软件开发而言， 公司做的很外行。 这个问题下面的人看的很清
> > 楚，但一直没有办法去改变。 就如同你说的， 继续写文档就好了，反正有人付钱给我们， 怕啥？
>
> > 于我来说， 我情愿去找到一些更好的办法， 而不情愿去闷头去些所谓垃圾文档。
>
> > 屏蔽着领导， 在下面偷偷做了些小动作， 采用了XP的某些原则， 比如小规模发版， 一周2次或者1次； 跟用户说明需要他尽快的review
> > and feedback, 在关键点上结对。确实取得了比较满意的效果， 至少客户满意度提高了不少哦。
>
> > 呵呵， 现在终于有机会了， 开始光明正大的尝试了， 不再需要那种"悄悄的进村， 打枪的不要"行为了。
>
> > > 2008/7/28 起步停车 <tol...@163.com>:
>
> > > > 我很认可敏捷和精益软件开发的一些思想。
>
> > > > 比如消除浪费，我们现在对于文档的处理完全就是一种资源浪费，比如TDD， 但可是， 可但是， 如果我们改进文档处理方式或者实施TDD这些东西的
> > > > 话，会有人跳出来阻止的。 因为他们认为， 他们看不到相关文档， 就以为缺少了什么东西。
>
> > > --
> > > Jeff Xiong
> > > Software Journeyman -http://gigix.thoughtworkers.org
> > > Open Source Contributor -http://fluorida.googlecode.com/
> > > Technical Evangelist -http://www.infoq.com/cn/
>
> --
> Jacky Li
>
> InfoQ China Agile Lead Editor:www.infoq.com/cn
>
> - 显示引用的文字 -
起步停车
Jul 29, 2008, 1:34:14 AM7/29/08
to 敏捷中国
恩， 理解！
打算先拿你说的第一个下手， 确保每篇文章都要有audiences. 消除没有"市场"的文档。
On 7月28日, 下午10时58分, "Xiaoming Wang" <wxm...@gmail.com> wrote:
> One tip:
>
> Make sure that every document has audiences; every practice solves problems.
>
> 2008/7/28 Jacky Li <veryfa...@gmail.com>
>
>
>
>
>
> > InfoQ中文站近期会发表一篇文章：用数字沟通----来自敏捷精灵的忠告。这里先摘抄其中一段话
>
> > ~~~~~~~~~~~~~小刀的分割线~~~~~~~~~~~~~~~~~
>
> > *有趣之处在于管理者喜欢与数字打交道，所以如果你跟Jim谈这个问题的时候，用数字而不是
> Photo album:http://www.flickr.com/photos/satanyork- 隐藏被引用文字 -
>
> - 显示引用的文字 -
打算先拿你说的第一个下手， 确保每篇文章都要有audiences. 消除没有"市场"的文档。
On 7月28日, 下午10时58分, "Xiaoming Wang" <wxm...@gmail.com> wrote:
> One tip:
>
> Make sure that every document has audiences; every practice solves problems.
>
>
>
>
>
>
> > InfoQ中文站近期会发表一篇文章：用数字沟通----来自敏捷精灵的忠告。这里先摘抄其中一段话
>
> > ~~~~~~~~~~~~~小刀的分割线~~~~~~~~~~~~~~~~~
>
> > *有趣之处在于管理者喜欢与数字打交道，所以如果你跟Jim谈这个问题的时候，用数字而不是
> > 带有个人情感的方式来表达，他对问题影响的理解会更加清晰和简单。这样你会更有希望获得别人的反应和行动----除非是连傻瓜都能做决定的事情。一个导师告诉
> > 我，很容易做的决定不算是决定！管理者要根据成本和收益来考虑问题----选择'是'和选择'否'，会带来什么样的影响。成本和收益可以用模糊或者明确的方式来
> > 我，很容易做的决定不算是决定！管理者要根据成本和收益来考虑问题----选择'是'和选择'否'，会带来什么样的影响。成本和收益可以用模糊或者明确的方式来
> > 表示。他们喜欢明确的方式，因为它往往基于数字，而不是个人的情感。数字是无可争辩的。如果别人对你提出质疑，**通过数字，**
> > 你可以很容易地获得证明和支持。同时，在进行短期和长期的公司战略规划时，**数字**
> > 也会有帮助。数字的增减可以表示某件事的程度。模糊的方式不好处理，难以判断，更难着手。出错的几率增大，而且个人也很容易做出不同的诠释与质疑。如果需要的话-，人们会采取模糊的方式。但是管理者更喜欢具体的方式，如果这些数字足以帮他们做出决定的话。
> > *
>
> > *"我给你一些建议，Rick。把模糊的原因变得更明确。你之前告诉Jim的方式就很模糊
> > ----只谈到一个团队成员的态度和行为，而且非常个人化----都是关于某个人的，这容易导致误解。可以用下面这些明确的数字进行解释：公司成本、返工、完成-任
> > 务所需的额外时间、在会议上浪费的时间、公司**需要**
> > 承担的真实成本，这样阐述问题老板就可以理解了。下次，给Jim一些具体的内容，一些他能够向老板汇报的信息，他们做出的决定会让你更开心。"*
> > 你可以很容易地获得证明和支持。同时，在进行短期和长期的公司战略规划时，**数字**
> > 也会有帮助。数字的增减可以表示某件事的程度。模糊的方式不好处理，难以判断，更难着手。出错的几率增大，而且个人也很容易做出不同的诠释与质疑。如果需要的话-，人们会采取模糊的方式。但是管理者更喜欢具体的方式，如果这些数字足以帮他们做出决定的话。
> > *
>
> > *"我给你一些建议，Rick。把模糊的原因变得更明确。你之前告诉Jim的方式就很模糊
> > ----只谈到一个团队成员的态度和行为，而且非常个人化----都是关于某个人的，这容易导致误解。可以用下面这些明确的数字进行解释：公司成本、返工、完成-任
> > 务所需的额外时间、在会议上浪费的时间、公司**需要**
>
> - 显示引用的文字 -
起步停车
Jul 29, 2008, 1:37:26 AM7/29/08
to 敏捷中国
呵呵, 谢谢。
想到了你的PPT！
On 7月29日, 上午10时28分, "Anchuan Qian" <qiananch...@gmail.com> wrote:
> 另一个Tip：把问题分担给你的同事和领导。让大家都是猪的角色，在同一条船上。
>
> 2008/7/29 徐毅 <kaverj...@gmail.com>
>
> - 显示引用的文字 -
想到了你的PPT！
On 7月29日, 上午10时28分, "Anchuan Qian" <qiananch...@gmail.com> wrote:
> 另一个Tip：把问题分担给你的同事和领导。让大家都是猪的角色，在同一条船上。
>
>
>
>
> > 2008/7/28 Xiaoming Wang <wxm...@gmail.com>
>
> >> One tip:
>
> >> Make sure that every document has audiences; every practice solves
> >> problems.
>
> > 另一个tip，有时候，你需要靠自己跳进麻烦里面去，花上一些时间去解决难题（越是最突出的难题越好），把麻烦在过去造成的时间和资源的数据，与你解决麻烦之后-所需要的时间及资源的数据对比，就可以更明显地展示出你所使用的那些（通常属于敏捷的）实践的效果。
>
>
> > 2008/7/28 Xiaoming Wang <wxm...@gmail.com>
>
> >> One tip:
>
> >> Make sure that every document has audiences; every practice solves
> >> problems.
>
>
> > 这些切切实实做出来的效果，加上你的解释和分析，才能给予领导者或其他同事信心去采用更多的敏捷实践。
>
> > CI绝对是一个最好的切入点。
>
> > --
> > - - - - - - - - - -
> > Xu Yi, Kaverjody
> > Certified Scrum Master
> > Blog :http://damianji.spaces.live.com
> > - - - - - - - - - -- 隐藏被引用文字 -
> > 这些切切实实做出来的效果，加上你的解释和分析，才能给予领导者或其他同事信心去采用更多的敏捷实践。
>
> > CI绝对是一个最好的切入点。
>
> > --
> > - - - - - - - - - -
> > Xu Yi, Kaverjody
> > Certified Scrum Master
> > Blog :http://damianji.spaces.live.com
>
> - 显示引用的文字 -
Jacky Li
Jul 29, 2008, 1:49:47 AM7/29/08
to agile...@googlegroups.com
鼠标
Jul 29, 2008, 2:16:54 AM7/29/08
to agile...@googlegroups.com
pipi
Jul 29, 2008, 8:05:50 AM7/29/08
to 敏捷中国
思路是不错，不过你列的做法不算特别好，如果我是老板我的第一感觉是比较牵强。
首先：文档的下载次数 != 文档的质量和用处，这不是一个常人的共识，我想你也很难在理论上证明。
比如我经常看某个文档，但是我只下载一次，又比如说某种总体架构文档，很重要但是也不是每个人要经常去看的。还有客户使用手册，主要是给客户看的，内部
的人自己看的可能也不多。
一般来讲，要列举问题，就事论事就可以了，比如把所有的文档列出来，然后给这些文档排个优先级，哪些是重复工作量的（有重复性质的文档通常可以去掉），
哪些是不重要但是却投入了巨大的工作量的（这个会导致效率低下）。
另外不要单靠自己个人的力量，因为问题不是自己一个人的，而是整个团队（或公司）的，从各个同事处收集反馈，大家都有共鸣的事情，很多时候才是真正的问
题所在。如果大家都觉得文档很好很必要，那其实改进的重要性恐怕就不高了。
larry...@gmail.com
Jul 29, 2008, 10:03:00 AM7/29/08
to 敏捷中国
大部分的策略是 source code + javadoc/ccdoc + one system architecture +
several slides + some guideline
产品文档除外，那是另外的讨论。
开发人员习惯不写文档，一般鼓励写写，要学会表达和总结。
好的程序员: code 写的好，文档写的也好。
差的程序员: code 写的差，文档写的也不好，这样还是先花功夫写 code吧。
several slides + some guideline
产品文档除外，那是另外的讨论。
开发人员习惯不写文档，一般鼓励写写，要学会表达和总结。
好的程序员: code 写的好，文档写的也好。
差的程序员: code 写的差，文档写的也不好，这样还是先花功夫写 code吧。
pipi
Jul 30, 2008, 2:14:58 AM7/30/08
to 敏捷中国
不同公司开发过程不一样，文档也不尽相同了。
比如我公司就有很多文档，而且好多我都觉得挺重要，去掉反而不妥。象Overall System Architecture
Description, Use Case Specification, Non Functional Requirement,
Interface Description, Software Acchitecture Description (Level 3),
Implementation Proposal, Acceptance Test Case Specification, etc
所以还是要自己结合公司的实际进行判断了。
我觉得好的程序员也不一定能写出好的文档，中国人的系统化思维和写文档能力是相对比较弱的，这个和脑子里有想法但是不一定能够很好表达出来是一样的道理
的了。老外就不太一样，很多即使coding一般般，写文档也都挺不错的。
On Jul 29, 10:03 pm, "larry.ca...@gmail.com" <larry.ca...@gmail.com>
wrote:
比如我公司就有很多文档，而且好多我都觉得挺重要，去掉反而不妥。象Overall System Architecture
Description, Use Case Specification, Non Functional Requirement,
Interface Description, Software Acchitecture Description (Level 3),
Implementation Proposal, Acceptance Test Case Specification, etc
所以还是要自己结合公司的实际进行判断了。
我觉得好的程序员也不一定能写出好的文档，中国人的系统化思维和写文档能力是相对比较弱的，这个和脑子里有想法但是不一定能够很好表达出来是一样的道理
的了。老外就不太一样，很多即使coding一般般，写文档也都挺不错的。
On Jul 29, 10:03 pm, "larry.ca...@gmail.com" <larry.ca...@gmail.com>
wrote:
起步停车
Jul 30, 2008, 6:07:54 AM7/30/08
to 敏捷中国
你说的有道理。
对于文档的理解， 有一些争议。 就拿我们公司来说， 文档是否已经完成并且上传的到相关的地方已经成为某个过程是否顺利结束的一个标志，这些文档我们
不能简单的给它定义成浪费。需要有区分。1）组织级别的文档， 比如系统架构，业务架构，高级别的数据流图, 业务处理模式....， 这些是组织的重
要的资产。2）程序员平时接触到的是一些项目文档（公司比较特殊，有无数的大小项目）， 如果要求无论项目大小， 都需要写出所有的文档， 而这些文档
不是用来交流，而仅仅为了满足所谓的过程， 那就是浪费了， 或者这种文档的方式需要改进，比如，按照规定， 程序员需要写SRS，DD，test
case, test case report，还要有人花时间去review SRS，test case, 哪怕我只改了1行代码， 麻雀虽小，
五脏俱全。这样一套流程下来， 文档和review的时间加在一起， 最少也要10多个小时吧？而这些文档对最后软件质量有贡献吗？ 说没有，肯定不
行，说有的话， 有多少呢？ 我看微乎其微。 实际操作过程中， 下面的人对这些文档很不屑，都认为没有用啊，包括测试人员， 在这一点上， 能在公司
找到共鸣的人很多。
仔细想想，就如同你说的，我确实很难证明文档的无效性，而且就是能证明，也不能跟领导直接说这些文档没有用，因为那是领导规定的，除非我想离开了。
哎， 我这真是皇帝不急太监急啊。
> > test case？ 然后在分析我们到底需要什么类型的文档， 这些文档要做成什么粒度才能对我们有真正的指导意义？- 隐藏被引用文字 -
>
> - 显示引用的文字 -
对于文档的理解， 有一些争议。 就拿我们公司来说， 文档是否已经完成并且上传的到相关的地方已经成为某个过程是否顺利结束的一个标志，这些文档我们
不能简单的给它定义成浪费。需要有区分。1）组织级别的文档， 比如系统架构，业务架构，高级别的数据流图, 业务处理模式....， 这些是组织的重
要的资产。2）程序员平时接触到的是一些项目文档（公司比较特殊，有无数的大小项目）， 如果要求无论项目大小， 都需要写出所有的文档， 而这些文档
不是用来交流，而仅仅为了满足所谓的过程， 那就是浪费了， 或者这种文档的方式需要改进，比如，按照规定， 程序员需要写SRS，DD，test
case, test case report，还要有人花时间去review SRS，test case, 哪怕我只改了1行代码， 麻雀虽小，
五脏俱全。这样一套流程下来， 文档和review的时间加在一起， 最少也要10多个小时吧？而这些文档对最后软件质量有贡献吗？ 说没有，肯定不
行，说有的话， 有多少呢？ 我看微乎其微。 实际操作过程中， 下面的人对这些文档很不屑，都认为没有用啊，包括测试人员， 在这一点上， 能在公司
找到共鸣的人很多。
仔细想想，就如同你说的，我确实很难证明文档的无效性，而且就是能证明，也不能跟领导直接说这些文档没有用，因为那是领导规定的，除非我想离开了。
哎， 我这真是皇帝不急太监急啊。
>
> - 显示引用的文字 -
pipi
Jul 30, 2008, 6:28:40 AM7/30/08
to 敏捷中国
有热情是好事! 只是看如何更有效的去推动了。
首先是要获得支持，支持最好是来自老板的，如果你能够清晰地陈述你的想法（私下里），然后让老板觉得你的想法是正确的话，这个做起来就很好办了。下面的
人既然也有意见，是很容易收集建议并且引导事情往你希望的好的方向转变的。
如果你自己拥有一定的权力，这个事情就更好办了，只是你自己如何去调动资源，获取下面人的热心支持罢了。
另外，SRS, DD, Test Case这些文档，说白了细致到什么程度，都是人为的了（其实大部分程序员不懂得如何写这些文档，这也是令人头痛的
原因），也许你只要能够把小项目的文档的模板给简化就可以了，这样大家的空间就很大了。当然这个问题上可能还是让下面的人给建议为好。
首先是要获得支持，支持最好是来自老板的，如果你能够清晰地陈述你的想法（私下里），然后让老板觉得你的想法是正确的话，这个做起来就很好办了。下面的
人既然也有意见，是很容易收集建议并且引导事情往你希望的好的方向转变的。
如果你自己拥有一定的权力，这个事情就更好办了，只是你自己如何去调动资源，获取下面人的热心支持罢了。
另外，SRS, DD, Test Case这些文档，说白了细致到什么程度，都是人为的了（其实大部分程序员不懂得如何写这些文档，这也是令人头痛的
原因），也许你只要能够把小项目的文档的模板给简化就可以了，这样大家的空间就很大了。当然这个问题上可能还是让下面的人给建议为好。
Liang Qiao
Jul 30, 2008, 6:40:17 AM7/30/08
to agile...@googlegroups.com
Anchuan Qian
Jul 30, 2008, 10:27:49 PM7/30/08
to agile...@googlegroups.com
请问您凭什么说：
我觉得好的程序员也不一定能写出好的文档，中国人的系统化思维和写文档能力是相对比较弱的，这个和脑子里有想法但是不一定能够很好表达出来是一样的道理的了。老外就不太一样，很多即使coding一般般，写文档也都挺不错的。
2008/7/30 pipi <lingzh...@ericsson.com>
pipi
Jul 31, 2008, 12:30:59 AM7/31/08
to 敏捷中国
主要是这些年工作所看到的了。
我看到主要有两方面：
一个是逻辑性，比如说写一份系统架构文档或者设计文档，很多人就写的是很非常零碎的，看起来写了很多东西，但是其实整体逻辑性很差，章节之间的串联和推
导都是很不清晰的，这些文档往往读起来都是似是而非，就是写了不少，但是看了之后还是不清晰。
另外一个是全面性，同样是一份设计文档，考虑的问题可能仅仅局限于主要的几个部分，但是从系统全面性来看，是缺少了很多方面的（也许这些方面是非常基本
的，但是写文档的人觉得不需要去关注）
这两个问题在老外写文档时就很少发生了。
On Jul 31, 10:27 am, "Anchuan Qian" <qiananch...@gmail.com> wrote:
> 请问您凭什么说：
> *
>
> 2008/7/30 pipi <lingzhe.p...@ericsson.com>
我看到主要有两方面：
一个是逻辑性，比如说写一份系统架构文档或者设计文档，很多人就写的是很非常零碎的，看起来写了很多东西，但是其实整体逻辑性很差，章节之间的串联和推
导都是很不清晰的，这些文档往往读起来都是似是而非，就是写了不少，但是看了之后还是不清晰。
另外一个是全面性，同样是一份设计文档，考虑的问题可能仅仅局限于主要的几个部分，但是从系统全面性来看，是缺少了很多方面的（也许这些方面是非常基本
的，但是写文档的人觉得不需要去关注）
这两个问题在老外写文档时就很少发生了。
On Jul 31, 10:27 am, "Anchuan Qian" <qiananch...@gmail.com> wrote:
> 请问您凭什么说：
> *
> 我觉得好的程序员也不一定能写出好的文档，中国人的系统化思维和写文档能力是相对比较弱的，这个和脑子里有想法但是不一定能够很好表达出来是一样的道理的了。老外就不太一样，很多即使coding一般般，写文档也都挺不错的。
> *
>
> 2008/7/30 pipi <lingzhe.p...@ericsson.com>
Anchuan Qian
Jul 31, 2008, 3:36:16 AM7/31/08
to agile...@googlegroups.com
我这几年也很很多的国外同事一起工作过，但我到没有这样的体会。
我在工作中遇到过一些技术牛人，他们不技术精湛，而且非常擅长表达。但，更让我佩服的是：专业的工作精神。
个人有很多的切身体会。呵呵，不跑题了。还是继续关于文档方面的讨论。
我在工作中遇到过一些技术牛人，他们不技术精湛，而且非常擅长表达。但，更让我佩服的是：专业的工作精神。
个人有很多的切身体会。呵呵，不跑题了。还是继续关于文档方面的讨论。
2008/7/31 pipi <lingzh...@ericsson.com>
Michael Chen
Jul 31, 2008, 5:23:24 AM7/31/08
to agile...@googlegroups.com
小刀！你的文档估计"写得非常零碎的，看起来写了很多东西，但是其实整体逻辑性很差……"，因为你不是老外！
2008/7/31 pipi <lingzh...@ericsson.com>:
--
Michael Chen
--------------------------------
Blog: http://michael.nona.name
MSN: jzch...@hotmail.com
Jacky Li
Jul 31, 2008, 5:36:42 AM7/31/08
to agile...@googlegroups.com
鼠标
Jul 31, 2008, 5:40:02 AM7/31/08
to agile...@googlegroups.com
逻辑性差其实是一个说不得的普遍现象。我个人觉得这可能是常年教育的问题，天天要背那么多不合逻辑的书本知识，还要学习把不合逻辑的事情说得合逻辑咯。。。
但是程序员这个如此讲究逻辑性的群体里还这样，就不好说是咋回事了。难道又是一出社会造成的悲剧 ：P
但是程序员这个如此讲究逻辑性的群体里还这样，就不好说是咋回事了。难道又是一出社会造成的悲剧 ：P
2008/7/31 Michael Chen <mech...@gmail.com>
徐毅
Jul 31, 2008, 5:47:48 AM7/31/08
to agile...@googlegroups.com
会不会是国人隔得太近，而且平易近人，交流方便快捷，讲求意会，所以不重表达？
而老外似乎彼此不待见，于是喜欢书面交流，而且怕被抓住把柄，于是要逻辑性超强，而且叙事清晰？
哈哈哈~
而老外似乎彼此不待见，于是喜欢书面交流，而且怕被抓住把柄，于是要逻辑性超强，而且叙事清晰？
哈哈哈~
--
- - - - - - - - - -
Xu Yi, Kaverjody
Certified Scrum Practioner
Jeff Xiong
Jul 31, 2008, 5:50:47 AM7/31/08
to agile...@googlegroups.com
徐毅
Jul 31, 2008, 5:53:09 AM7/31/08
to agile...@googlegroups.com
起步停车
Jul 31, 2008, 6:02:56 AM7/31/08
to 敏捷中国
说的准， 这两方面我周围的人还有我基本都是这样的。
一直和我合作的美国人， 是一个很有经验的工程师（15年了），感觉他的文档就比较严谨， 主要的业务逻辑都是以1，2，3这种条目的方式给我的。前后
逻辑较好。但是他也不会考虑文档的全面性。比如性能， 吞吐量， 安全性......
皮皮， 有个问题， 你看到的国外的文档是程序员直接写的， 还是有专业文档人员加工过的？
On 7月31日, 下午12时30分, pipi <lingzhe.p...@ericsson.com> wrote:
> 主要是这些年工作所看到的了。
>
> 我看到主要有两方面：
>
> 一个是逻辑性，比如说写一份系统架构文档或者设计文档，很多人就写的是很非常零碎的，看起来写了很多东西，但是其实整体逻辑性很差，章节之间的串联和推
> 导都是很不清晰的，这些文档往往读起来都是似是而非，就是写了不少，但是看了之后还是不清晰。
>
> 另外一个是全面性，同样是一份设计文档，考虑的问题可能仅仅局限于主要的几个部分，但是从系统全面性来看，是缺少了很多方面的（也许这些方面是非常基本
> 的，但是写文档的人觉得不需要去关注）
>
> 这两个问题在老外写文档时就很少发生了。
>
> On Jul 31, 10:27 am, "Anchuan Qian" <qiananch...@gmail.com> wrote:
>
>
>
> > 请问您凭什么说：
> > *
> > 我觉得好的程序员也不一定能写出好的文档，中国人的系统化思维和写文档能力是相对比较弱的，这个和脑子里有想法但是不一定能够很好表达出来是一样的道理的了。老-外就不太一样，很多即使coding一般般，写文档也都挺不错的。
>
> - 显示引用的文字 -
一直和我合作的美国人， 是一个很有经验的工程师（15年了），感觉他的文档就比较严谨， 主要的业务逻辑都是以1，2，3这种条目的方式给我的。前后
逻辑较好。但是他也不会考虑文档的全面性。比如性能， 吞吐量， 安全性......
皮皮， 有个问题， 你看到的国外的文档是程序员直接写的， 还是有专业文档人员加工过的？
On 7月31日, 下午12时30分, pipi <lingzhe.p...@ericsson.com> wrote:
> 主要是这些年工作所看到的了。
>
> 我看到主要有两方面：
>
> 一个是逻辑性，比如说写一份系统架构文档或者设计文档，很多人就写的是很非常零碎的，看起来写了很多东西，但是其实整体逻辑性很差，章节之间的串联和推
> 导都是很不清晰的，这些文档往往读起来都是似是而非，就是写了不少，但是看了之后还是不清晰。
>
> 另外一个是全面性，同样是一份设计文档，考虑的问题可能仅仅局限于主要的几个部分，但是从系统全面性来看，是缺少了很多方面的（也许这些方面是非常基本
> 的，但是写文档的人觉得不需要去关注）
>
> 这两个问题在老外写文档时就很少发生了。
>
> On Jul 31, 10:27 am, "Anchuan Qian" <qiananch...@gmail.com> wrote:
>
>
>
> > 请问您凭什么说：
> > *
> > *
>
> > 2008/7/30 pipi <lingzhe.p...@ericsson.com>
>
> > > 不同公司开发过程不一样，文档也不尽相同了。
>
> > > 比如我公司就有很多文档，而且好多我都觉得挺重要，去掉反而不妥。象Overall System Architecture
> > > Description, Use Case Specification, Non Functional Requirement,
> > > Interface Description, Software Acchitecture Description (Level 3),
> > > Implementation Proposal, Acceptance Test Case Specification, etc
>
> > > 所以还是要自己结合公司的实际进行判断了。
>
> > > 我觉得好的程序员也不一定能写出好的文档，中国人的系统化思维和写文档能力是相对比较弱的，这个和脑子里有想法但是不一定能够很好表达出来是一样的道理
> > > 的了。老外就不太一样，很多即使coding一般般，写文档也都挺不错的。
>
> > > On Jul 29, 10:03 pm, "larry.ca...@gmail.com" <larry.ca...@gmail.com>
> > > wrote:
> > > > 大部分的策略是 source code + javadoc/ccdoc + one system architecture +
> > > > several slides + some guideline
>
> > > > 产品文档除外，那是另外的讨论。
>
> > > > 开发人员习惯不写文档，一般鼓励写写，要学会表达和总结。
>
> > > > 好的程序员: code 写的好，文档写的也好。
> > > > 差的程序员: code 写的差，文档写的也不好，这样还是先花功夫写 code吧。- 隐藏被引用文字 -
>
> > 2008/7/30 pipi <lingzhe.p...@ericsson.com>
>
> > > 不同公司开发过程不一样，文档也不尽相同了。
>
> > > 比如我公司就有很多文档，而且好多我都觉得挺重要，去掉反而不妥。象Overall System Architecture
> > > Description, Use Case Specification, Non Functional Requirement,
> > > Interface Description, Software Acchitecture Description (Level 3),
> > > Implementation Proposal, Acceptance Test Case Specification, etc
>
> > > 所以还是要自己结合公司的实际进行判断了。
>
> > > 我觉得好的程序员也不一定能写出好的文档，中国人的系统化思维和写文档能力是相对比较弱的，这个和脑子里有想法但是不一定能够很好表达出来是一样的道理
> > > 的了。老外就不太一样，很多即使coding一般般，写文档也都挺不错的。
>
> > > On Jul 29, 10:03 pm, "larry.ca...@gmail.com" <larry.ca...@gmail.com>
> > > wrote:
> > > > 大部分的策略是 source code + javadoc/ccdoc + one system architecture +
> > > > several slides + some guideline
>
> > > > 产品文档除外，那是另外的讨论。
>
> > > > 开发人员习惯不写文档，一般鼓励写写，要学会表达和总结。
>
> > > > 好的程序员: code 写的好，文档写的也好。
>
> - 显示引用的文字 -
起步停车
Jul 31, 2008, 6:04:53 AM7/31/08
to 敏捷中国
是啊。 正是这个情况。
On 7月30日, 下午6时40分, "Liang Qiao" <sagittatius.q...@gmail.com> wrote:
> 还有，这个事情可不是一两个项目就能搞定整个公司的。
> 还要看公司氛围和你及你的推广团队（如果有的话）的能量。
>
> 2008/7/30 pipi <lingzhe.p...@ericsson.com>
> > > 哎， 我这真是皇帝不急太监急啊。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
On 7月30日, 下午6时40分, "Liang Qiao" <sagittatius.q...@gmail.com> wrote:
> 还有，这个事情可不是一两个项目就能搞定整个公司的。
> 还要看公司氛围和你及你的推广团队（如果有的话）的能量。
>
>
> - 显示引用的文字 -
pipi
Jul 31, 2008, 6:12:22 AM7/31/08
to 敏捷中国
哈哈，我只是指相对而言，不是说中国人就做不好。
On Jul 31, 5:23 pm, "Michael Chen" <mechil...@gmail.com> wrote:
> 小刀！你的文档估计"写得非常零碎的，看起来写了很多东西，但是其实整体逻辑性很差......"，因为你不是老外！
>
> 2008/7/31 pipi <lingzhe.p...@ericsson.com>:
>
>
>
> > 主要是这些年工作所看到的了。
>
> > 我看到主要有两方面：
>
> > 一个是逻辑性，比如说写一份系统架构文档或者设计文档，很多人就写的是很非常零碎的，看起来写了很多东西，但是其实整体逻辑性很差，章节之间的串联和推
> > 导都是很不清晰的，这些文档往往读起来都是似是而非，就是写了不少，但是看了之后还是不清晰。
>
> > 另外一个是全面性，同样是一份设计文档，考虑的问题可能仅仅局限于主要的几个部分，但是从系统全面性来看，是缺少了很多方面的（也许这些方面是非常基本
> > 的，但是写文档的人觉得不需要去关注）
>
> > 这两个问题在老外写文档时就很少发生了。
>
> > On Jul 31, 10:27 am, "Anchuan Qian" <qiananch...@gmail.com> wrote:
> >> 请问您凭什么说：
> >> *
> MSN: jzche...@hotmail.com>
>
> > 主要是这些年工作所看到的了。
>
> > 我看到主要有两方面：
>
> > 一个是逻辑性，比如说写一份系统架构文档或者设计文档，很多人就写的是很非常零碎的，看起来写了很多东西，但是其实整体逻辑性很差，章节之间的串联和推
> > 导都是很不清晰的，这些文档往往读起来都是似是而非，就是写了不少，但是看了之后还是不清晰。
>
> > 另外一个是全面性，同样是一份设计文档，考虑的问题可能仅仅局限于主要的几个部分，但是从系统全面性来看，是缺少了很多方面的（也许这些方面是非常基本
> > 的，但是写文档的人觉得不需要去关注）
>
> > 这两个问题在老外写文档时就很少发生了。
>
> > On Jul 31, 10:27 am, "Anchuan Qian" <qiananch...@gmail.com> wrote:
> >> 请问您凭什么说：
> >> *
pipi
Jul 31, 2008, 6:14:55 AM7/31/08
to 敏捷中国
只有用户手册，是需要请Technical Writer加工的，其他都是工程师写的了。
起步停车
Jul 31, 2008, 11:22:23 PM7/31/08
to 敏捷中国
哈哈， 有意思， 经典啊。
On 7月31日, 下午5时36分, "Jacky Li" <veryfa...@gmail.com> wrote:
> faint，你怎么还把我扯出来，我都好久没发言了......
>
> 2008/7/31 Michael Chen <mechil...@gmail.com>
> +86 138 1045 9095- 隐藏被引用文字 -
>
> - 显示引用的文字 -
On 7月31日, 下午5时36分, "Jacky Li" <veryfa...@gmail.com> wrote:
> faint，你怎么还把我扯出来，我都好久没发言了......
>
> 2008/7/31 Michael Chen <mechil...@gmail.com>
>
>
>
>
>
> > 小刀！你的文档估计"写得非常零碎的，看起来写了很多东西，但是其实整体逻辑性很差......"，因为你不是老外！
>
> > 2008/7/31 pipi <lingzhe.p...@ericsson.com>:
>
>
>
>
> > 小刀！你的文档估计"写得非常零碎的，看起来写了很多东西，但是其实整体逻辑性很差......"，因为你不是老外！
>
> > 2008/7/31 pipi <lingzhe.p...@ericsson.com>:
> > > 主要是这些年工作所看到的了。
>
> > > 我看到主要有两方面：
>
> > > 一个是逻辑性，比如说写一份系统架构文档或者设计文档，很多人就写的是很非常零碎的，看起来写了很多东西，但是其实整体逻辑性很差，章节之间的串联和推
> > > 导都是很不清晰的，这些文档往往读起来都是似是而非，就是写了不少，但是看了之后还是不清晰。
>
> > > 另外一个是全面性，同样是一份设计文档，考虑的问题可能仅仅局限于主要的几个部分，但是从系统全面性来看，是缺少了很多方面的（也许这些方面是非常基本
> > > 的，但是写文档的人觉得不需要去关注）
>
> > > 这两个问题在老外写文档时就很少发生了。
>
> > > On Jul 31, 10:27 am, "Anchuan Qian" <qiananch...@gmail.com> wrote:
> > >> 请问您凭什么说：
> > >> *
>
> > 我觉得好的程序员也不一定能写出好的文档，中国人的系统化思维和写文档能力是相对比较弱的，这个和脑子里有想法但是不一定能够很好表达出来是一样的道理的了。老-外就不太一样，很多即使coding一般般，写文档也都挺不错的。
>
> > > 我看到主要有两方面：
>
> > > 一个是逻辑性，比如说写一份系统架构文档或者设计文档，很多人就写的是很非常零碎的，看起来写了很多东西，但是其实整体逻辑性很差，章节之间的串联和推
> > > 导都是很不清晰的，这些文档往往读起来都是似是而非，就是写了不少，但是看了之后还是不清晰。
>
> > > 另外一个是全面性，同样是一份设计文档，考虑的问题可能仅仅局限于主要的几个部分，但是从系统全面性来看，是缺少了很多方面的（也许这些方面是非常基本
> > > 的，但是写文档的人觉得不需要去关注）
>
> > > 这两个问题在老外写文档时就很少发生了。
>
> > > On Jul 31, 10:27 am, "Anchuan Qian" <qiananch...@gmail.com> wrote:
> > >> 请问您凭什么说：
> > >> *
>
> > >> *
>
> > >> 2008/7/30 pipi <lingzhe.p...@ericsson.com>
>
> > >> > 不同公司开发过程不一样，文档也不尽相同了。
>
> > >> > 比如我公司就有很多文档，而且好多我都觉得挺重要，去掉反而不妥。象Overall System Architecture
> > >> > Description, Use Case Specification, Non Functional Requirement,
> > >> > Interface Description, Software Acchitecture Description (Level 3),
> > >> > Implementation Proposal, Acceptance Test Case Specification, etc
>
> > >> > 所以还是要自己结合公司的实际进行判断了。
>
> > 我觉得好的程序员也不一定能写出好的文档，中国人的系统化思维和写文档能力是相对比较弱的，这个和脑子里有想法但是不一定能够很好表达出来是一样的道理
> > >> > 的了。老外就不太一样，很多即使coding一般般，写文档也都挺不错的。
>
> > >> > On Jul 29, 10:03 pm, "larry.ca...@gmail.com" <larry.ca...@gmail.com>
> > >> > wrote:
> > >> > > 大部分的策略是 source code + javadoc/ccdoc + one system architecture +
> > >> > > several slides + some guideline
>
> > >> > > 产品文档除外，那是另外的讨论。
>
> > >> > > 开发人员习惯不写文档，一般鼓励写写，要学会表达和总结。
>
> > >> > > 好的程序员: code 写的好，文档写的也好。
> > >> > > 差的程序员: code 写的差，文档写的也不好，这样还是先花功夫写 code吧。
>
> > --
> > Michael Chen
> > --------------------------------
> > Blog:http://michael.nona.name
> > MSN: jzche...@hotmail.com
>
> > >> 2008/7/30 pipi <lingzhe.p...@ericsson.com>
>
> > >> > 不同公司开发过程不一样，文档也不尽相同了。
>
> > >> > 比如我公司就有很多文档，而且好多我都觉得挺重要，去掉反而不妥。象Overall System Architecture
> > >> > Description, Use Case Specification, Non Functional Requirement,
> > >> > Interface Description, Software Acchitecture Description (Level 3),
> > >> > Implementation Proposal, Acceptance Test Case Specification, etc
>
> > >> > 所以还是要自己结合公司的实际进行判断了。
>
> > 我觉得好的程序员也不一定能写出好的文档，中国人的系统化思维和写文档能力是相对比较弱的，这个和脑子里有想法但是不一定能够很好表达出来是一样的道理
> > >> > 的了。老外就不太一样，很多即使coding一般般，写文档也都挺不错的。
>
> > >> > On Jul 29, 10:03 pm, "larry.ca...@gmail.com" <larry.ca...@gmail.com>
> > >> > wrote:
> > >> > > 大部分的策略是 source code + javadoc/ccdoc + one system architecture +
> > >> > > several slides + some guideline
>
> > >> > > 产品文档除外，那是另外的讨论。
>
> > >> > > 开发人员习惯不写文档，一般鼓励写写，要学会表达和总结。
>
> > >> > > 好的程序员: code 写的好，文档写的也好。
> > >> > > 差的程序员: code 写的差，文档写的也不好，这样还是先花功夫写 code吧。
>
> > --
> > Michael Chen
> > --------------------------------
> > Blog:http://michael.nona.name
> +86 138 1045 9095- 隐藏被引用文字 -
>
> - 显示引用的文字 -
Reply all
Reply to author
Forward
0 new messages