回顾2011：敏捷的过去与将来 zz

[张克强]

2011年8月，敏捷在盐湖城庆祝了它10岁的生日，也同时庆祝了敏捷被更为广泛地使用。SD Times宣称“敏捷”这个属于已死，并不是因为他们认为敏捷不是一项有效的策略，而是因为他们觉得敏捷的应用范围太广了。
 
工具发生了一点变化，一些制造商开始引入了精益工业制造的原理Kanban中的一些规则，这套方法使同时制造软件和硬件的制造商能够有效地管理项目中的软件以及硬件部分。
 
ALM集成框架发布了可以让敏捷团队把现有的软件合并到新的软件套件里面的工具，这是2011年的大趋势。我们也有理由相信，在2012年越来越多的公司会朝着这个方向前进。CollabNet和HP也在11月发布了使团队能够将他们所用的所有工具集成到一个独立的开发系统中的产品。
 
开发人员正在尝试各种新方法来给项目做计划和找出一个特定的sprint所需要的时间。敏捷游戏帮助开发人员更加投入，以及从不同的角度思考问题。有些游戏，例如计划扑克，帮助开发人员了解每个特性所需要的时间。其他的，例如Speed Boat，帮助开发人员了解流程。
 
在2011敏捷大会上，敏捷宣言的支持者们发现，在刚开始的时候工具似乎不是很重要，但是，现在是需要软件工具来帮助团队扩展他们的敏捷流程的时候了。在大会上的演讲者们说：“随着敏捷越来越成熟，对工具的需求也越来越强烈。”
 
在敏捷大会的参与者都认为他们并不会改变敏捷宣言的任何部分，虽然有人建议他们在所有文档的顶部加上全大写的“我们是认真的”。他们都同意现在是敏捷需要扩张的时候了，然后在如何才能扩张和应该怎么扩张上面却出现了分歧。有的人认为应该为传统的敏捷流程引入新的思想，如Kanban和精益；而有的人却认为敏捷不应该只局限于IT，而应该深入到企业的各个领域当中去。
 
但是总的来说，好消息是分析师在敏捷大会上表示“敏捷”已经不是一个个默默无闻的术语，它代表着如何简单地完成一件事的方法。

 

zz from http://www.scrumcn.com/news/html/?394.html

 

 

[Jeff Xiong]

简单说就是光靠Scrum唬不到人了呗。

2012/2/18 张克强 <zhangk...@gmail.com>:

> --
> 敏捷中国 http://www.agilechina.net 邮件列表
> 如果想发起讨论，请发送邮件到 agile...@googlegroups.com
> 如欲退订请发送邮件到 agilechina-...@googlegroups.com
> 更多选项，请访问 http://groups.google.com/group/agilechina

--
Jeff Xiong
www.Gigix.me

[Steven Mak]

這能算是原創文章嗎？如果翻譯的話也至少注明原文出處吧：
http://www.sdtimes.com/LOOK_WHAT_2011_WASHED_IN_AGILE_S_PAST_AND_FUTURE/By_Victoria_Reitano/About_AGILE_and_KANBAN_and_LEAN/36213

"網路資源" 是不專業也不尊重原文作者的造法。

至於要抽水的話，還是 no silver bullet 好了。

On Feb 18, 7:19 am, 张克强 <zhangkeqi...@gmail.com> wrote:
> 2011年8月，敏捷在盐湖城庆祝了它10岁的生日，也同时庆祝了敏捷被更为广泛地使用。SD
> Times宣称"敏捷"这个属于已死，并不是因为他们认为敏捷不是一项有效的策略，而是因为他们觉得敏捷的应用范围太广了。
>
> 工具发生了一点变化，一些制造商开始引入了精益工业制造的原理Kanban中的一些规则，这套方法使同时制造软件和硬件的制造商能够有效地管理项目中的软件以及 硬件部分。
>

> ALM集成框架发布了可以让敏捷团队把现有的软件合并到新的软件套件里面的工具，这是2011年的大趋势。我们也有理由相信，在2012年越来越多的公司会朝着 这个方向前进。CollabNet和HP也在11月发布了使团队能够将他们所用的所有工具集成到一个独立的开发系统中的产品。
>
> 开发人员正在尝试各种新方法来给项目做计划和找出一个特定的sprint所需要的时间。敏捷游戏帮助开发人员更加投入，以及从不同的角度思考问题。有些游戏，例 如计划扑克，帮助开发人员了解每个特性所需要的时间。其他的，例如Speed
> Boat，帮助开发人员了解流程。
>
> 在2011敏捷大会上，敏捷宣言的支持者们发现，在刚开始的时候工具似乎不是很重要，但是，现在是需要软件工具来帮助团队扩展他们的敏捷流程的时候了。在大会上 的演讲者们说："随着敏捷越来越成熟，对工具的需求也越来越强烈。"
>
> 在敏捷大会的参与者都认为他们并不会改变敏捷宣言的任何部分，虽然有人建议他们在所有文档的顶部加上全大写的"我们是认真的"。他们都同意现在是敏捷需要扩张的 时候了，然后在如何才能扩张和应该怎么扩张上面却出现了分歧。有的人认为应该为传统的敏捷流程引入新的思想，如Kanban和精益；而有的人却认为敏捷不应该只 局限于IT，而应该深入到企业的各个领域当中去。

[皮宇]

相比起方法来，工具对生产力的提升效果更佳显著。
但是市面上好工具大多都是收费的，免费或开源的工具品质还有待提升。

[Xu Yi]

不妨列一列你心目中的收费版好工具，也许有朋友知道一些效果等同的好的免费、开源工具呢

--
- - - - - - - - - -
Xu Yi, Kaverjody
Senior Agile Consultant @ HP Enterprise Services
Blog : http://blog.sina.com.cn/kaverjody
Sina Weibo : http://weibo.com/kaverjody
Skype : kaverjody
- - - - - - - - - -

[泥泥]

呵呵，我最近给人项目组的同学们讲Scrum的ABC，算内部普及了，有同学上手就问有没有系统支撑，刚好会议室墙上有其他Team的看板，于是拍拍墙，故作潇洒状：“这就是系统。“

工具比如衣服，原始目标当然是保护好身体，次生目标是让人看起来与众不同点或与众一致的，比如佛要镀金，培训师要穿正装。

说到工具，我比较希望给工程师的劳保工具多一些，在这个前提下可以有兴趣的老板们搞点装点门面的工具也是必要的。

在 2012年2月21日 下午1:27，皮宇 <ds3...@gmail.com>写道：

[Joseph Tseng]

在中国，门面工具还真不可小觑。

2012/2/21 泥泥 <nijp...@gmail.com>

--
Joseph Tseng

[Xiaoming Wang]

多数创业公司，中小型公司还是关注实效多余形式。只要good enough就好了

Joseph也可以把你们的经验分享下哦。呵呵

Many thanks!

Best Regards
Xiaoming Wang

http://Aaladdin.com  -- Agile organization transition framework
http://blog.aaladdin.com  -- Professional project management
LinkedIn Profile: http://www.linkedin.com/in/wangxiaoming

Weibo(In Chinese): http://weibo.com/mmxw

2012/2/21 Joseph Tseng <air...@gmail.com>

[李建业]

˵ʵ�����һ��治�����ж����շѹ��ߺ�ʹ�������� trello.com + github.com + bitbucket.com ��������ǰװ���

�� 2012��02��21�� 13:38, Xu Yi �:

������һ������Ŀ�е��շѰ�ù��ߣ�Ҳ��������֪��һЩЧ���ͬ�ĺõ���ѡ���Դ������

�� 2012��2��21�� ����1:27��Ƥ�� <ds3...@gmail.com>д ����

����𷽷��������߶������������Ч��������
���������Ϻù��ߴ�඼���շѵģ���ѻ�Դ�Ĺ���Ʒ�ʻ��д�����

�� 2012��2��19�� ����8:22��Steven Mak <stev...@gmail.com> ���

> �@������ԭ�����†᣿����g��ԒҲ����ע��ԭ�ij�̎�ɣ�
> http://www.sdtimes.com/LOOK_WHAT_2011_WASHED_IN_AGILE_S_PAST_AND_FUTURE/By_Victoria_Reitano/About_AGILE_and_KANBAN_and_LEAN/36213
>
> "�W·�YԴ" �Dz����IҲ������ԭ�����ߵ��취��
>
> ���Ҫ��ˮ��Ԓ��߀�� no silver bullet ���ˡ�
>
> On Feb 18, 7:19 am, �ſ�ǿ <zhangkeqi...@gmail.com> wrote:
>> 2011��8�£��������κ�����ף����10������գ�Ҳͬʱ��ף�����ݱ���Ϊ�㷺��ʹ�á�SD
>> Times���"����"���������������������Ϊ������Ϊ���ݲ���һ����Ч�IJ��ԣ�������Ϊ���Ǿ������ݵ�Ӧ�÷�Χ̫���ˡ�
>>
>> ���߷�����һ��仯��һЩ�����̿�ʼ�����˾��湤ҵ�����ԭ��Kanban�е�һЩ�������׷���ʹͬʱ���������Ӳ�����������ܹ���Ч�ع�����Ŀ�е��� ���Լ� Ӳ�����֡�
>>
>> ALM���ɿ�ܷ����˿����������ŶӰ����е�����ϲ����µ�����׼�����Ĺ��ߣ�����2011��Ĵ����ơ�����Ҳ���������ţ���2012��Խ��Խ��Ĺ�˾ �ᳯ�� �������ǰ��CollabNet��HPҲ��11�·�����ʹ�Ŷ��ܹ����������õ����й��߼��ɵ�һ�������Ŀ���ϵͳ�еIJ�Ʒ��
>>
>> ������Ա���ڳ��Ը����·���������Ŀ���ƻ����ҳ�һ���ض���sprint����Ҫ��ʱ�䡣������Ϸ������Ա���Ͷ�룬�Լ��Ӳ�ͬ�ĽǶ�˼�����⡣��Щ�� Ϸ���� ��ƻ��˿ˣ�������Ա�˽�ÿ����������Ҫ��ʱ�䡣����ģ�����Speed
>> Boat��������Ա�˽����̡�
>>
>> ��2011���ݴ���ϣ��������Ե�֧�����Ƿ��֣��ڸտ�ʼ��ʱ�򹤾��ƺ����Ǻ���Ҫ�����ǣ���������Ҫ��������������Ŷ���չ���ǵ��������̵�ʱ���ˡ��� ����� ���ݽ�����˵��"��������Խ��Խ���죬�Թ��ߵ�����ҲԽ��Խǿ�ҡ�"
>>
>> �����ݴ��IJ����߶���Ϊ���Dz�����ı��������Ե��κβ��֣���Ȼ���˽��������������ĵ��Ķ�������ȫ��д��"�����������"�����Ƕ�ͬ��������������Ҫ ���ŵ� ʱ���ˣ�Ȼ������β������ź�Ӧ����ô��������ȴ�����˷��硣�е�����ΪӦ��Ϊ��ͳ���������������µ�˼�룬��Kanban�;��棻���е���ȴ��Ϊ���ݲ� Ӧ��ֻ ������IT����Ӧ�����뵽��ҵ�ĸ���������ȥ��
>>
>> �����ܵ���˵������Ϣ�Ƿ���ʦ�����ݴ���ϱ�ʾ"����"�Ѿ�����һ����ĬĬ���ŵ������������μ򵥵����һ���µķ�����
>>
>> zz fromhttp://www.scrumcn.com/news/html/?394.html
>
> --
> �����й� http://www.agilechina.net �ʼ��б�
> ����뷢�����ۣ��뷢���ʼ��� agile...@googlegroups.com
> �����˶��뷢���ʼ��� agilechina-...@googlegroups.com
> ���ѡ������ http://groups.google.com/group/agilechina

--
�����й� http://www.agilechina.net �ʼ��б�
����뷢�����ۣ��뷢���ʼ��� agile...@googlegroups.com
�����˶��뷢���ʼ��� agilechina-...@googlegroups.com
���ѡ������ http://groups.google.com/group/agilechina

--
- - - - - - - - - -
Xu Yi, Kaverjody
Senior Agile Consultant @ HP Enterprise Services
Blog : http://blog.sina.com.cn/kaverjody
Sina Weibo : http://weibo.com/kaverjody
Skype : kaverjody
- - - - - - - - - -

--
�����й� http://www.agilechina.net �ʼ��б�
����뷢�����ۣ��뷢���ʼ��� agile...@googlegroups.com
�����˶��뷢���ʼ��� agilechina-...@googlegroups.com
���ѡ������ http://groups.google.com/group/agilechina

-- 
-----------------

Best Regard��

�ҵ

[皮宇]

一直想找一个或者一系列工具帮助我完成以下工作：
1.记录每一个story.
2.记录每个task，并维护task对story是个多对一关系。
3.每个story和task都有一个input 人和output 人，task的input人默认是其story的output人。
4.每个story或者task都有其详细的变更记录，无论是状态变迁还是修改。
5.每个story会关联0～n个附件，每个task会关联0～n个文件提交版本记录。
6.我可以选择性的将已经完成的m个task中的n(n<=m)个task合并到beta分支。
7.如果t1和t2两个task对同一个文件f1都产生变更分别形成r1.r2两个版本，如果我要合并t2那么程序可以要求我必须合并t1
8.每个task都有计划耗时和实际耗时，task的input可以设置计划耗时，output可以添加实际耗时
9.有关于人日的统计
10.廉价或免费

不知道这样的东东有没有




在 2012年2月21日星期二，李建业 <li.j...@gmail.com> 写道：
> 说实话，我还真不觉得有多少收费工具好使，现在是 trello.com + github.com + bitbucket.com ，其它就是白板了

>
> 于 2012年02月21日 13:38, Xu Yi 写道:
>
> 不妨列一列你心目中的收费版好工具，也许有朋友知道一些效果等同的好的免费、开源工具呢
>
> 在 2012年2月21日 下午1:27，皮宇 <ds3...@gmail.com>写 道：
>>
>> 相比起方法来，工具对生产力的提升效果更佳显著。
>> 但是市面上好工具大多都是收费的，免费或开源的工具品质还有待提升。
>>
>> 在 2012年2月19日 下午8:22，Steven Mak <stev...@gmail.com> 写道：
>> > 這能算是原創文章嗎？如果翻譯的話也至少注明原文出處吧：
>> > http://www.sdtimes.com/LOOK_WHAT_2011_WASHED_IN_AGILE_S_PAST_AND_FUTURE/By_Victoria_Reitano/About_AGILE_and_KANBAN_and_LEAN/36213
>> >
>> > "網路資源" 是不專業也不尊重原文作者的造法。
>> >
>> > 至於要抽水的話，還是 no silver bullet 好了。
>> >
>> > On Feb 18, 7:19 am, 张克强 <zhangkeqi...@gmail.com> wrote:
>> >> 2011年8月，敏捷在盐湖城庆祝了它10岁的生日，也同时庆祝了敏捷被更为广泛地使用。SD
>> >> Times宣称"敏捷"这个属于已死，并不是因为他们认为敏捷不是一项有效的策略，而是因为他们觉得敏捷的应用范围太广了。
>> >>
>> >> 工具发生了一点变化，一些制造商开始引入了精益工业制造的原理Kanban中的一些规则，这套方法使同时制造软件和硬件的制造商能够有效地管理项目中的软 件以及 硬件部分。
>> >>

>> >> ALM集成框架发布了可以让敏捷团队把现有的软件合并到新的软件套件里面的工具，这是2011年的大趋势。我们也有理由相信，在2012年越来越多的公司 会朝着 这个方向前进。CollabNet和HP也在11月发布了使团队能够将他们所用的所有工具集成到一个独立的开发系统中的产品。
>> >>
>> >> 开发人员正在尝试各种新方法来给项目做计划和找出一个特定的sprint所需要的时间。敏捷游戏帮助开发人员更加投入，以及从不同的角度思考问题。有些游 戏，例 如计划扑克，帮助开发人员了解每个特性所需要的时间。其他的，例如Speed
>> >> Boat，帮助开发人员了解流程。
>> >>
>> >> 在2011敏捷大会上，敏捷宣言的支持者们发现，在刚开始的时候工具似乎不是很重要，但是，现在是需要软件工具来帮助团队扩展他们的敏捷流程的时候了。在 大会上 的演讲者们说："随着敏捷越来越成熟，对工具的需求也越来越强烈。"
>> >>
>> >> 在敏捷大会的参与者都认为他们并不会改变敏捷宣言的任何部分，虽然有人建议他们在所有文档的顶部加上全大写的"我们是认真的"。他们都同意现在是敏捷需要 扩张的 时候了，然后在如何才能扩张和应该怎么扩张上面却出现了分歧。有的人认为应该为传统的敏捷流程引入新的思想，如Kanban和精益；而有的人却认为敏捷不 应该只 局限于IT，而应该深入到企业的各个领域当中去。

>> >>
>> >> 但是总的来说，好消息是分析师在敏捷大会上表示"敏捷"已经不是一个个默默无闻的术语，它代表着如何简单地完成一件事的方法。
>> >>
>> >> zz fromhttp://www.scrumcn.com/news/html/?394.html
>> >
>> > --
>> > 敏捷中国 http://www.agilechina.net 邮件列表
>> > 如果想发起讨论，请发送邮件到 agile...@googlegroups.com
>> > 如欲退订请发送邮件到 agilechina-...@googlegroups.com
>> > 更多选项，请访问 http://groups.google.com/group/agilechina
>>
>> --
>> 敏捷中国 http://www.agilechina.net 邮件列表
>> 如果想发起讨论，请发送邮件到 agile...@googlegroups.com
>> 如欲退订请发送邮件到 agilechina-...@googlegroups.com

>> 更多选项，请访问 http://groups.google.com/group/agilechina

>
>
> --
> - - - - - - - - - -
> Xu Yi, Kaverjody
> Senior Agile Consultant @ HP Enterprise Services
> Blog : http://blog.sina.com.cn/kaverjody
> Sina Weibo : http://weibo.com/kaverjody
> Skype : kaverjody
> - - - - - - - - - -
> --

> 敏捷中国 http://www.agilechina.net 邮件列表
> 如果想发起讨论，请发送邮件到 agile...@googlegroups.com
> 如欲退订请发送邮件到 agilechina-...@googlegroups.com

> 更多选项，请访问 http://groups.google.com/group/agilechina
>
> --
> -----------------
>
> Best Regard，
>
> 李建业

[Jesse Cai]

Http://www.redmine.org 我们用的工具，没有要求的所有功能，基本够用，免费。

Sent from my iPhone

[李建业]

����һ���Ŷ��ж��

�� 2012��02��22�� 00:25, Ƥ�� д��:

һֱ����һ������һϵ�й��߰�����������¹�����
1.��¼ÿһ��story.
2.��¼ÿ��task����ά��task��story�Ǹ����һ��ϵ��
3.ÿ��story��task����һ��input �˺�output �ˣ�task��input��Ĭ������story��output�ˡ�
4.ÿ��story����task��������ϸ�ı���¼��������״̬��Ǩ�����޸ġ�
5.ÿ��story�����0��n��������ÿ��task�����0��n���ļ��ύ�汾��¼��
6.�ҿ���ѡ���ԵĽ��Ѿ���ɵ�m��task�е�n(n<=m)��task�ϲ���beta��֧��
7.���t1��t2����task��ͬһ���ļ�f1��������ֱ��γ�r1.r2�����汾�������Ҫ�ϲ�t2��ô�������Ҫ���ұ���ϲ�t1
8.ÿ��task���мƻ���ʱ��ʵ�ʺ�ʱ��task��input�������üƻ���ʱ��output�������ʵ�ʺ�ʱ
9.�й������յ�ͳ��
10.���ۻ����

��֪������Ķ�����û��




�� 2012��2��21�����ڶ����ҵ <li.j...@gmail.com> д����

>> ���ѡ������ http://groups.google.com/group/agilechina

>
>
> --
> - - - - - - - - - -
> Xu Yi, Kaverjody
> Senior Agile Consultant @ HP Enterprise Services
> Blog : http://blog.sina.com.cn/kaverjody
> Sina Weibo : http://weibo.com/kaverjody
> Skype : kaverjody
> - - - - - - - - - -
> --

> �����й� http://www.agilechina.net �ʼ��б�
> ����뷢�����ۣ��뷢���ʼ��� agile...@googlegroups.com
> �����˶��뷢���ʼ��� agilechina-...@googlegroups.com

> ���ѡ������ http://groups.google.com/group/agilechina
>
> --
> -----------------
>
> Best Regard��
>
> �ҵ

>
> --
> �����й� http://www.agilechina.net �ʼ��б�
> ����뷢�����ۣ��뷢���ʼ��� agile...@googlegroups.com
> �����˶��뷢���ʼ��� agilechina-...@googlegroups.com
> ���ѡ������ http://groups.google.com/group/agilechina --
�����й� http://www.agilechina.net �ʼ��б�
����뷢�����ۣ��뷢���ʼ��� agile...@googlegroups.com
�����˶��뷢���ʼ��� agilechina-...@googlegroups.com

���ѡ������ http://groups.google.com/group/agilechina

-- 
-----------------

Best Regard��

�ҵ

[皮宇]

谢谢 Jesse 抽时间我会仔细研究

在 2012年2月22日 上午10:23，李建业 <li.j...@gmail.com> 写道：
> 你们一个团队有多大？

>>> 更多选项，请访问 http://groups.google.com/group/agilechina

>>
>>
>> --
>> - - - - - - - - - -
>> Xu Yi, Kaverjody
>> Senior Agile Consultant @ HP Enterprise Services
>> Blog : http://blog.sina.com.cn/kaverjody
>> Sina Weibo : http://weibo.com/kaverjody
>> Skype : kaverjody
>> - - - - - - - - - -
>> --

>> 敏捷中国 http://www.agilechina.net 邮件列表
>> 如果想发起讨论，请发送邮件到 agile...@googlegroups.com
>> 如欲退订请发送邮件到 agilechina-...@googlegroups.com

>> 更多选项，请访问 http://groups.google.com/group/agilechina
>>
>> --
>> -----------------
>>

>> Best Regard，
>>
>> 李建业
>>
>> --
>> 敏捷中国 http://www.agilechina.net 邮件列表
>> 如果想发起讨论，请发送邮件到 agile...@googlegroups.com
>> 如欲退订请发送邮件到 agilechina-...@googlegroups.com

>> 更多选项，请访问 http://groups.google.com/group/agilechina --

> 敏捷中国 http://www.agilechina.net 邮件列表
> 如果想发起讨论，请发送邮件到 agile...@googlegroups.com
> 如欲退订请发送邮件到 agilechina-...@googlegroups.com

> 更多选项，请访问 http://groups.google.com/group/agilechina
>
>
>
> --
> -----------------
>

[皮宇]

建业：我在之前的公司用过Rational 7.0的一套工具，主要是：ClearCase
ClearQuest，能够完全满足需求，项目管理起来非常方便顺手。但是：
1.Rational一套工具自身卖价较高，小团队承受不起。
2.这套工具本身培训和配置管理支持的成本也非常之高。
3.非常强大的功能背后却是一些不符合现实逻辑的设计，包括：使用AD账户作为安全控制基础、及其复杂却从没让人整明白的冲突合并工具（而且其冲突合并只能用自己的工具来做），非常占用内存的和磁盘的版本控制工具、各种程序员出的未能修复低级bug。
4.功能过于强大和复杂，我只需要其中的30%功能就足够了！
很遗憾，它只适合IBM，却不适合我们～～～

[泥泥]

正版license、培训和知识转移、系统管理员的投入……

Rational实在不适合小团队去练兵，就算是所谓破解的，后面的成本也太昂贵

[Yin Wenyan]

完成以下工作的主要目的是？

2012/2/22 皮宇 <ds3...@gmail.com>:

[Yin Wenyan]

对不起，前面的回复排版可能不够清晰，重来：完成以下工作的主要目的是？

[皮宇]

目的：
1. 方便项目所有参与者共享项目进度信息
2.KPI考评参考依据，并能够准实时的发现谁在偷懒。
3.多任务并行开发，随时发布。

[Yin Wenyan]

> 目的：
> 1. 方便项目所有参与者共享项目进度信息
> 2.KPI考评参考依据，并能够准实时的发现谁在偷懒。
> 3.多任务并行开发，随时发布。
>

那达成以上目的的目的是？

P.S. 我保证：不管答案是什么，不再继续追问进一步的目的了 :-)

[皮宇]

目的的目的：
1.完成我自己的kpi
2.研究和探讨是否对团队进行调整并观察各方面反馈，以逐步提高团队（你可以说质量，也可以说效率 ，不管是管它叫什么就是提升团队的竞争力）。

[李建业]

1. 你的KPI是"过程改进"这个抽象的概念么？还是帮助工程师生产更好的软件？
2.
看起来你是希望度量工程师的工作，这可以理解，不过，真正的有效输出是能实际运行的代码和软件，在你的设想中，工程师是否需要为你的度量分出时间呢？有没有其它“透明”的度量方式
3. 除了“度量”外，这个系统还能为提高工程师水平提供哪些帮助呢？注意，这里似乎没有任何与实际工作（代码、软件）有关的内容

于2012年02月24日 星期五 17时44分52秒,皮宇写到:

--
-----------------

Best Regard，

李建业

[Kula]

大团队也不合适。只适合外包团队

2012/2/22 泥泥 <nijp...@gmail.com>

[漠河]

我们用Mantis+Confluence

 

---

漠河

 

发件人： Jesse Cai

发送时间： 2012-02-22 07:15

收件人： agile...@googlegroups.com

主题： Re: [agilechina] 回顾2011：敏捷的过去与将来 zz

[皮宇]

TO 建业Q1:前次说的，“我的KPI”指：
1.监督和管理开发团队完成开发任务
2.在有7-8个任务并行的时候，随时接待老板对某个任务的指导（其实他就是来问某个任务进度，你最后最这个任务是否关注的时间是否是今天）。
3.我自身也会承担一些核心部分的开发任务。

我的需要：
1.高效的信息沟通，让所有人知道我们的目标和过程中需要做的事情。
2.要让老板能够随时了解所有任务的进度情况，口头沟通显然信息量不够。
3.刨除正常的沟通成本，我每天需要有一段安静的时间，来完成我自己的任务。
4.我想让团队变强。

TO 建业Q2:每天上班花10分钟在工具中查询今天要做什么，下班前花上10分钟总结一下当日的工作并在工具中录入自己所花费的时间，以及抱怨，我想不会对他的工作造成太多的影响。如果这套系统可运行，那么也免去了工程师写周报的烦恼。

TO 建业Q3:我更加希望通过量化的管理还衡量每个工程师对项目的价值到底有多大。而不是像目前一样仅凭个人或者其他人的感官去做结论。当然量化的考评不能完全说明问题，但至少当以下情况出现时我会收到信号：
1）某个工程师工作散漫，对领导和同事却表现出积极向上的态度。
2）某工程师努力工作却苦于没有找到合适的沟通方式，于是拼命加班完成额外的工作。
当类似上述信号出现的时候我希望能够尽早发现尽早处理。我相信这是对整个团队有好处的。
当然，如何提高工程师水平则是另外的工作内容，这方面我不是天才。只是我在之前的工作经历中，处理之前的事务已经有些心余力乏，所以我也希望能够腾出更多的时间来这方面的事，初步想法是能找一个切合工作内容又需要时间的主题做内部的项目或者纯开源的项目，同时组织参与技术类或者方法类的主题讨论像敏捷、NODEJS
、flashair、html5等等。

[泥泥]

我只能感叹老黄牛和报喜鸟真的无处不在，个人觉得只要不过份，都可以接受的。

每个人价值观是不同的，没到底线的话，或不是个人使命的话，是不需要调节生态的。

[皮宇]

是啊，之前的某些人（不是我）却经常被报喜鸟迷惑，而弃老黄牛不顾，让人心寒寒啊

[Yin Wenyan]

2012/2/29 皮宇 <ds3...@gmail.com>:

> TO 建业Q1:前次说的，“我的KPI”指：
> 1.监督和管理开发团队完成开发任务

白板+单反

> 2.在有7-8个任务并行的时候，随时接待老板对某个任务的指导（其实他就是来问某个任务进度，你最后最这个任务是否关注的时间是否是今天）。

白板+单反

> 3.我自身也会承担一些核心部分的开发任务。
>
> 我的需要：
> 1.高效的信息沟通，让所有人知道我们的目标和过程中需要做的事情。

白板+单反

> 2.要让老板能够随时了解所有任务的进度情况，口头沟通显然信息量不够。

白板+单反

[皮宇]

白板+单反只是权宜之计，不是长久之策

[Jeff Xiong]

为什么？

2012/3/1 皮宇 <ds3...@gmail.com>

--
Jeff Xiong
www.Gigix.me

[Vincent Lee]

那儿还用得着单反啊，对于在白板上简单写写画画讨论设计，我一般就用手机拍下来，然后存档。

但是对于文字信息，拍照片恐怕不是办法吧，时间久了无法全文检索、无法编辑啊。

[Bryan Zheng]

找个字写得周正的，然后用evernote存档，就可以检索了。

郑 柯

Bryan Zheng

[泥泥]

呵呵，看板管理不错的，但把看板当成唯一的存在也不必要吧，必要作业工具也是需要的，看规模和资源吧。

把白板上的字手打一把的确占不了多少时间。一边手打一边也可以加深理解，我们一直干这件事情，把信息建立在不靠谱的技术上没必要。

[Yin Wenyan]

2012/3/1 Vincent Lee <liyin...@gmail.com>:

> 那儿还用得着单反啊，对于在白板上简单写写画画讨论设计，我一般就用手机拍下来，然后存档。
>
> 但是对于文字信息，拍照片恐怕不是办法吧，时间久了无法全文检索、无法编辑啊。
>
> 在 2012年3月1日 下午8:28，皮宇 <ds3...@gmail.com>写道：
>
>> 白板+单反只是权宜之计，不是长久之策
>>

找个打杂的（实习啊、兼职啊、不太忙的行政或人事MM什么的都行，实在没有就自己上），专门负责每天将照片上的信息更新到你预先设计好的表中（Excel表，数据库表都行），这样信息检索就不成问题了，还可以随意做花哨的报表（看领导好不好这一口）。

团队成员只需更新白板就行了，每天一次（或早或晚），集中进行，更新完立马拍照存档。

用单反是有好处的：保证较高的成像质量，确保人眼能准确无误地识别所有信息。如果白板附近的光线条件不咋地，可以再加个三角架。

[皮宇]

有钱的团队就是不一样啊，我之前招一个月薪2k负责打杂的小姑娘都得给老板费半天口舌。单反看来只能我自个儿出钱了。

[Vincent Lee]

如果只是随便找人把照片上的信息录入保存下来，会丢失太多上下文信息，而且也失去了一次总结归纳的机会。
白板可以用，担最终还是要当事人亲自把上面信息整理归档。
如果你的团队做的是重要项目，那么他们值得拥有一个wiki之类的工具。

在 2012年3月2日 下午2:41，Yin Wenyan <yiw...@gmail.com>写道：

[泥泥]

嗯，这才是金玉良言。

自己都不愿意整理的白板，只能算涂鸦

[Yin Wenyan]

2012/3/2 皮宇 <ds3...@gmail.com>:
> 有钱的团队就是不一样啊，我之前招一个月薪2k负责打杂的小姑娘都得给老板费半天口舌。单反看来只能我自个儿出钱了。
>

- 没钱请人就自己来录入信息；也可以大家轮岗，每人轮值一个sprint，整个说法：项目经理实训计划
- 没单反就用小数码，怕抖的话配个微型三角架，下面用纸箱和书垫高到合适的位置，或者搞两盏灯照着白板，保证光源
- 没小数码就随便拿手机照，能看清burndown图就行，其它信息一边在白板上更新一边就录入电脑

办法总比问题多嘛 :-)

P.S. 其实普通单反（或者微单）比月薪2k的小姑娘要便宜很多吧

[Yin Wenyan]

2012/3/2 Vincent Lee <liyin...@gmail.com>:
> 如果只是随便找人把照片上的信息录入保存下来，会丢失太多上下文信息，而且也失去了一次总结归纳的机会。

- 总结归纳的机会其实挺多的，这里少的可以到那里去补
- 总结归纳要是天天做，没准就做油了，用处也有限
- sprint结束时不是还要有回顾的嘛，大家坐下来一起好好总结总结归纳归纳呗

> 如果只是随便找人把照片上的信息录入保存下来，会丢失太多上下文信息，而且也失去了一次总结归纳的机会。

会丢失哪些重要的上下文信息，可以举些例子吗？

> 白板可以用，担最终还是要当事人亲自把上面信息整理归档。

感觉是否当事人亲自整理不是重点。为啥“但最终还是要……亲自……”？求解释。

P.S. "当事人"是指谁啊？队员？队长？总不会是教练吧？

> 如果你的团队做的是重要项目，那么他们值得拥有一个wiki之类的工具。
>

[泥泥]

我很闲的，Sprint回顾会好的实践和不好的实践，列表以及投票后的效果，除了拍照之外，全部会人肉转成文字，再写一点花絮，把有趣的场景和言论记录下。

而且转成文字后还要用图片处理工具再转成图片，发公司内刊。以做噱头骗稿费，不光我自己做，还动员Team的同仁们一起骗稿费。

貌似这种工作就是报喜鸟常做的嘛，呵呵，所以生态要保护，报喜鸟也要做得有职业操守嘛，天天唱赞歌表扬老黄牛。

>

[泥泥]

比如这种东东 http://www.step365.com/home.php?mod=space&uid=2814&do=blog&id=1358 

看起来和小孩子秀他的宝贝玩具样子，在某些大师眼里这个比较小儿科吧。我只是一线观察者，连实践者都谈不上了。

[Jeff Xiong]

这样的观察和总结很好啊。最起码，对你自己有用，对你的团队成员有用。只要是能让在现场干活的人感到开心还能有所进步，那就是善莫大焉了。

2012/3/2 泥泥 <nijp...@gmail.com>

--
Jeff Xiong
www.Gigix.me

[gleader]

哈哈  gigix还是很关心开心的，真不错

[Sunny Xu]

轮流来，不错，先理一个固定的格式

Sunny Xu

[Shaopeng]

My 2 cents:

正确地使用看板可以

1 帮助团队内进行有效及时沟通
2 进行现场管理，及时发现解决问题
3 增加透明度，任何人可以一眼就看到团队项目进展
4 优化开发流程，减少浪费

关于看板和现场管理有很多书籍。

绩效评定和团队能力提升是另外的话题，靠工具是不行滴。

绩效评定个人比较认可360度反馈+经理意见。千万不要以绩效为目的的量化开发人员的工作。They are smarter than us. 戴明十四条之一：取消量化绩效，用领导力取代之。

团队能力提升推荐两本书：Beautiful teams 和 For Your Improvement

绍鹏
发自我的 iPhone

[Xu Yi]

哈哈，中文版的《团队之美》我有参与翻译哦，欢迎大家阅读给建议哈！

- http://book.douban.com/subject/4803982/

《For Your Improvement》是指这本么？

- http://book.douban.com/subject/4309469/

//徐毅

[泥泥]

绩效评估、绩效评价、绩效考核，一个词汇之差反映了文化上的倾向，对于非要从成本角度切入研发绩效评估的组织，我个人往往会持“此地非久留之处”的想法。

[张克强]

绩效XX不同的说法 主要来自于不同的翻译。

在软件开发领域，采用度量数据衡量个人绩效 是很难很难把握其中平衡的。

对于敏捷开发，更不建议利用度量来评价个人绩效。

从成本角度来切入研发绩效评估 是什么样的做法？

张克强

blog: 从高效过程到卓越结果

weibo: http://weibo.com/zhangkeqiang 

[gleader]

项目投入人力资源，人力多了，领导感觉不爽，还要延期，不行。

人力成本投入已经很高了，还要更高，不行。

马国庆

TEL        13911714404

MSN       njz...@live.cn

E-MAIL   gle...@gmail.com

[Shaopeng Zhang]

呵呵。。。《团队之美》是捧你场啊！kidding, 书确实不错

《For Your Improvement》就是你说的这本。任何对软技能有疑问，觉得无法落地，不清楚具体含义，不了解如何评估，如何改进的，这本书里都有答案。

在 2012年3月12日 上午11:20，Xu Yi <kave...@gmail.com>写道：

--
- 

大鹏

+86 13911855372

[泥泥]

呵呵，管理者是不会看英文单词来翻译的，这不是翻译的问题，是一种态度和认知的折射

软件开发领域中远离绩效个别团队是可能的，但并非普遍的，彻底取消个人绩效是很大的变革，企业很难做到对这方面的淡定。

敏捷团队内部，最好放弃个人绩效评价，但未必真能做到。

我现在面临一个困扰，一方面有些工程师陷入在不可知的焦虑中，第二管理层面有些人觉得Scrum实践这么久，感觉流程不顺畅，就是意志到达不了团队中。

在 2012年3月12日 下午6:40，张克强 <zhangk...@gmail.com>写道：

[Xu Yi]

任重而道远啊

[Xiaoming Wang]

看到大家的讨论，我有两个疑问：

1，为什么使用敏捷方法的组织和团队不能用绩效考核？

2，为什么无法用度量来评价个人绩效？

不知道大家有什么好的见解？

Many thanks!

Best Regards
Xiaoming Wang

http://Aaladdin.com  -- Agile organization transition framework
http://blog.aaladdin.com  -- Professional project management
LinkedIn Profile: http://www.linkedin.com/in/wangxiaoming

Weibo(In Chinese): http://weibo.com/mmxw

2012/3/13 Xu Yi <kave...@gmail.com>

[泥泥]

不是不能，是能力不够:(

如果明明能力不够还非要假装很懂地去給技术人员打分、评价他们的能力和贡献。风险就太大了。

我指的能力未必就是考核者的能力，也包括组织能力

[泥泥]

另外，很多人不习惯自己Team内安排工作，而更习惯领导安排工作

如果没有“领导”，他们会陷入一种不靠谱的焦虑。

我发现一些工程师虽然讨厌每周写周报，但是却很习惯Leader每周給个工作安排。

[Jeff Xiong]

责任。

既不承担"决定做什么"的责任，又不承担"把什么做完"的责任，是最轻松的。

人的本性就是偷懒，如果没有额外的能量放进来。这就是热力学第二定律，没有什么是无需努力自然就会做好的。

2012/3/13 泥泥 <nijp...@gmail.com>:

--
Jeff Xiong
www.Gigix.me

[泥泥]

嗯，的确如此，所以慢慢地一些工程师觉得Scrum混乱，不如以前按流程做事，该审批的审批，该确认的确认，工作清晰可见。

我当局者迷了，思考方式没跟上，谢谢Jeff

[落Nicety]

看到这个讨论，有个问题

 

能力不够去评价风险很大。

那么不去评价风险就没有了么？或者比评价的风险反而小？

[泥泥]

再我看来是的确这样的。

我举个例子，比如一组开发工程师，每个人一定同时具备多种能力，能力和经验上高中低都有，当然薪酬也各有不同，众所周知，并非综合能力越强薪酬越高。

当一个考核周期到了后，最简单的评价就是不评价，每人一笔奖金，不透明。表扬一个贡献最卓著的，或者进步最快的。

复杂一点：设计几个纬度，Leader按照纬度打分，然后发奖金，不透明，表扬一个分数最高的，或者进步最快的。

再复杂些：设定一些KPI，然后由专职的人出具报表，分三六九等，发钱，也不透明，表扬一个指标完成最好的，或者进步最快的。

最复杂：既有主观，又有KPI，按一定比例打分。表扬一个综合分数最高的，或者进步最快的。

问题：哪种更能让人接受？哪种被质疑的概率最高？

[泥泥]

当我雇了一群蚂蚁背粮食，我们也许可以知道扛得最多的，走的最快的，但也许有的蚂蚁背得少但他的歌声能够让蚂蚁们快乐，也许有的蚂蚁背得多，也是吃得最多的，也许某蚂蚁和另外一个蚂蚁是亲密战友双宿双飞，也许某个蚂蚁是个来来回回的传令蚁。

我试图分清楚每个蚂蚁应该打多少分，某天当我怀着公平之心不小心伤害了那个爱唱歌的蚂蚁，我发现所有的蚂蚁都充满敌意的看着我。

[jayden guan]

 有这点精神，还是多去想想这个组，对外部贡献吧。

在 2012年3月13日 下午4:51，泥泥 <nijp...@gmail.com>写道：

[泥泥]

嗯，你的话锋芒毕露。不过我愚钝，没理解你这句话所指的是什么，是我的例子不对，还是我举例这件事情不对。

[皮宇]

如果每只蚂蚁都是发自内心的想背好粮食，那么我们需要做的就是帮他们把粮食口袋扎得更紧不要路上漏开，我们要吧路上的障碍清除掉，同时路上要提供写休息站和饮料。同时要观察他们的沟通方式，降低这方面的成本。
我理解的泥泥的公平之心和不小心伤害都是制度带来的恶果，其实制度真正防范的是偷懒的蚂蚁而不是背得少爱唱歌的蚂蚁。所以制度必须有，但不能凡事都靠制度。
我最痛恨的制度是末位淘汰制，因为它会让整个团队中不再有歌声！

[泥泥]

嗯，你明白我要表达的

[jayden guan]

    如果认同开发工程师是 “知识工作者”，那么就不要老是想着，有什么标准化的方法可以去衡量他们的工作成果。

    即便要测量一些指标，也要基于整体的外部贡献。不要老去琢磨，把每个人割裂开来比较什么。除非你想毁掉人们之间的协作关系。也不要指望给多给几个奖金，可以有什么激励效果。就冲着那几个钱，不起反作用就不错了。

    

    至于怎么做能起作用，可以看看《卓有成效的管理者》，里面会有不少启发。

[Vincent Lee]

能力不够、评得不合理，当然会带来更大的风险，
人类对大锅饭还是能够忍受的，但对奖惩不当是无法接受的，而且这个奖惩不当在每个人眼里还不一样，
人类总是会放大自己的有点和别人的缺点，程序员相轻、自以为是的现象很多。
所以，你有什么把握让大家对接受你所谓公平客观的考评啊？

在 2012年3月13日 下午3:20，落Nicety <hunt...@gmail.com>写道：

[Shen Siwei]

呵呵。。。。泥泥的这个帖子最有意思。

记得 《人件》里也说过，团队中有这样一种人，平时很难看看到他做了什么，但是只要有他存在的团队，项目总能成功。

尽管打分的方式多种多样，但是我觉得根据代码行数来打分是最让我无法接受的。 

另外，我觉得软件开发不同于传统工业，想为每个人打分太困难了。。。

2012/3/13 泥泥 <nijp...@gmail.com>

[落Nicety]

那你这个不是不评价，仅仅不是不公开而已。

 

难道我理解错了？ 之前说的绩效评价就一定是要公开的？

[赖祥芳]

agilechina，您好！

 

    看大家的讨论，学习了很多东西。想请教大家几个问题，就是怎么调动团队成员的积极性。前提：团队成员有能力，但是就是工作积极性不高，有啥好办法不？团队成员写程序的能力强，但是不喜欢写文档，很头痛，有没有啥好招？

 

---

 

发件人： 泥泥

发送时间： 2012-03-13 17:00

收件人： agilechina

主题： Re: [agilechina] 回顾2011：敏捷的过去与将来 zz

[He Xin]

各位，邮件组不是聊天群。一个主题似乎七七八八了太多的内容。

管理无常态，无常形，大家是不是可以更关注目标和适合自己的方法，拿出建议、分享和讨论...

批判是一种讨论，但无建设性的批判似乎并不应该过多出现在这个非传统行业的行业。

希望看到大家的深度思考和建设性的分享，谢谢。

Robin (Xin He)

2012/3/14 Shen Siwei <sg552...@gmail.com>

--
Best Regards!

Yours Robin He

[Xu Yi]

在 2012年3月13日 下午5:10，赖祥芳 <la...@ffcs.cn>写道：

agilechina，您好！

 

    看大家的讨论，学习了很多东西。想请教大家几个问题，就是怎么调动团队成员的积极性。

这玩意儿还真难调动，你必须去了解他们，发现他们的积极性之源泉，而后再激发出来。 

前提：团队成员有能力，但是就是工作积极性不高，有啥好办法不？

能力和工作积极性是两个不同的维度。如果是你说的有能力、无积极性，那么会不会是工作难度不高没有足够的挑战性？ 

团队成员写程序的能力强，但是不喜欢写文档，很头痛，有没有啥好招？

这个要看具体的情况。如果连必要的文档都不写，那应该是习惯的问题，得有一些契机和他们强调必要的文档的重要性；如果确实是要求他们写的文档太多、没必要、没人看等等原因，那么可能原因更多的要从自身上面去找，而不是找团队成员身上的毛病。 

[anders lin]

慢慢的就跑题了。。。不过也无所谓，说不定就触发一个新题目来。

话说回来，你这问题属于队伍建设了，因人而异，看书固然能有些指定。关键的还是是人，什么时间谈、什么地点谈、怎么谈都会影响效果。

2012/3/14 Xu Yi <kave...@gmail.com>

[泥泥]

深度思考来自于批判和讨论，仁者见仁智者见智。 

个人觉得即使歪楼了，没什么不妥的，google Group单个话题最多100次回复，超标了就新建话题的，问题不大。

我也说下积极性的问题。

首先，无论积极或消极，情绪都是会传播的，无非是每个人的抗体能力不同而已，所以，如果个体足够积极的话，他帮助团队其他成员积极思考、积极行动的概率会高些。

其次，即使积极，也看对怎么样的事件而言，走对方向，做对事情，积极才会正面的价值。而这个对和不对的判断并非轻易可以得到结论的，比如給工程师打分，在管理能力不够的情况下，积极得去推动，后果未必和预设的一样。

再次，积极是一种状态，而这种状态随时会因为搞不定技术、得不到支持、或者看不到结果，等等非预期外的情况出现，导致积极向消极转变，而又会随着强力增援、薪资岗位的提升、竞争对手的加入，导致消极向积极转变。

结论一：先不谈状态，多谈职业化和自我定位，职业的思考方式、职业的沟通方式、职业化的目标，自我定位和自我能力评估。知道方向才好走路

结论二：除非对所有事情都消极对待，通常人一定有积极的一面，把事务利弊分析透彻，把可能出现的困难，以及应对的事情想清楚，正如皮宇同学说的

“粮食口袋扎得更紧不要路上漏开，我们要吧路上的障碍清除掉，同时路上要提供些休息站和饮料‘（这个我超喜欢，谢谢）

解决蚂蚁们的后顾之忧，消极的一面下去了，积极的一面自然浮出来了

实际的问题，同认Xu Yi的。写好东西要花的精力很多，如果走过场的看看，或者没人看，那工作投入就白费了，这样就不能体现写作的工作价值。

必须要做的事情，总会有人做，而始终没人做的话，也许真不是必须的事情。

[变大象]

这个问题真的是说的比较大了，做软件也许不能算得上是艺术创作，但是能明确的感觉到有一些共性，

我只是想说也许目前的这种经济化的公司从根本上就束缚了软件开发团队，软件开发在拉动人类的文明

发展，它需要更好的文化生态作为土壤，呵呵

[赖祥芳]

agilechina，您好！

看大家的讨论，学习了很多东西。想请教大家几个问题，就是怎么调动团队成员的积极性。

这玩意儿还真难调动，你必须去了解他们，发现他们的积极性之源泉，而后再激发出来。

前提：团队成员有能力，但是就是工作积极性不高，有啥好办法不？

能力和工作积极性是两个不同的维度。如果是你说的有能力、无积极性，那么会不会是工作难度不高没有足够的挑战性？

 

 

==》不过我们日常工作不可能总是有难度高、具备足够挑战性的内容，经常会有一些比较琐碎的事情需要做。

     

 

---

 

 

发件人： Xu Yi

发送时间： 2012-03-14 15:16

收件人： agilechina

主题： Re: Re: [agilechina] 回顾2011：敏捷的过去与将来 zz

[赖祥芳]

agilechina，您好！

 

谢谢 Xu Yi、anders lin 的热心指点，受教了。

     

 

---

 

发件人： anders lin

发送时间： 2012-03-15 09:58

收件人： agilechina

主题： Re: Re: [agilechina] 回顾2011：敏捷的过去与将来 zz

[陈之过]

我倒是觉得正是因为这种经济化的公司,才使软件开发变得有意义,只是现在很多公司过分的急功近利,把开发过程引入了歧途.

[皮宇]

急功近利是商人的本性，在国内市场无法避免的，正是是由于市场导向（有钱的商人大多比较急功近利，而软件开发团队又是一个纯花钱没有直接收入的组织）。
所以，最可怕的就是让一个做市场出身的老板带一个软件开发团队做事情。

[胡凯]

>>> 急功近利是商人的本性，在国内市场无法避免的

在国外市场不是如此么？ 只是它的交易成本比较高，让变化的发生不如中国来的剧烈。

2012/3/20 皮宇 <ds3...@gmail.com>

--
All Infomation: http://iamhukai.info
Twitter:  http://twitter.com/iamhukai
Blog:  http://iamhukai.com

[Yin Wenyan]

On Tue, Mar 20, 2012 at 10:33 AM, 皮宇 <ds3...@gmail.com> wrote:
> 急功近利是商人的本性，在国内市场无法避免的

- 逐利是商人的本性，急功近利不是
- 急功近利就存在性而言无法避免，就个体而言可以避免

[Cherrot Luo]

�� 2012��03��22�� 13:39, Yin Wenyan �:
> On Tue, Mar 20, 2012 at 10:33 AM, Ƥ��<ds3...@gmail.com> wrote:
>> �������������˵ı��ԣ��ڹ����г��޷������
>
> - ���������˵ı��ԣ�����������
> - ��������ʹ����Զ����޷����⣬�͸�����Կ��Ա���
>
������˼��������⻰������Google Groups���͵��ż����������Լ�Ҳ�յ�һ��
�� ���Ҳ����ط��������������ء���
--
Cherrot
http://www.cherrot.com

[Richard Zhang]

你可以bcc自己吧

On Mar 23, 2012 7:47 PM, "Cherrot Luo" <ad...@cherrot.com> wrote:

不好意思，插个题外话……向Google Groups发送的信件不能设置自己也收到一份
吗？ 我找不到地方可以这样设置呢……
--
Cherrot
http://www.cherrot.com

[Cherrot Luo]

�� 2012��03��23�� 19:52, Richard Zhang �:
> �����bcc�Լ���

> ������˼��������⻰������Google Groups���͵��ż����������Լ�Ҳ�յ�һ��
> �� ���Ҳ����ط��������������ء���

����ȷʵû���⣬���ò�������Ҫ��������ʾ��Ч����Thunderbird�ϣ��������������������ʽ���ڡ��ź��� :(
--
Cherrot
http://www.cherrot.com