我完全同意。诚实是关键，它还可以带来信任，并塑造高效的团队。也许有人认为这是陈词滥调，但是彼此信任的团队确实表现得更为出色。这也是Scrum master的必备素质，也会对团队产生重要的影响。在实施敏捷流程时，很多人都认识不到，这其实与组织文化更加相关。 无论任何人、任何项目，都应该尽量诚实。下面是我的一些想法： 随着对Scrum和敏捷开发的深入理解，我理解到：在这些貌似疯狂的项目管理方法背后，还有更深入的东西。我同意Jim的说法，Declan说的也对。敏捷的目标之一，就是要帮助人们摆脱政治干扰，尽量好地完成手上的工作。它要求我们心态开放、诚实待人、尊重团队其他成员。有了敏捷，不诚实的人和行为会更快显露出来。一个好的团队是不会容忍这样的情况发生的。
|
A:你对软件流程方法论有多少了解？
B:你指的是哪些？
A:Agile/RUP/Scrum/XP/CMMI？
B:有那么一点点研究,我在项目中正在实施scrum
A:你是什么角色？
B:pm啊
A:靠，应该是ScrumMaster或者Product Owner
B:哦 你是说在scrum中的角色啊
------------------------------------------------------------------------------------------------------------------------------
这位老兄可能对Scrum没多少了解（他也承认）就在实施，他似乎更关心行政上的PM title.
------------------------------------------------------------------------------------------
B:我们没有完全的按照scrum checklist中的方法去组织项目,毕竟，这些方法论在实践中要灵活的使用，不能一味的完全照搬。xp，scrum的一个很大问题，就在于它们和传统的QA制度简直是格格不入。
A:传统QA都具体做些什么？
B:传统qa主要是通过在开发和集成阶段的一系列测试来保证qa质量
A:那么QA的工作应该转移到ScrumMaster这里，test成员应该是开发Team的一部分，对吧
B:不能这么简单的来转移,qa并不属于开发team，在任何一个公司都不属于
A:我的意思是，没必要专门成立QA部门,质量的保证是一个Scrum团队的责任和义务
B:你不可能在全局范围上 让公司的建制跟着你的项目变动，那样的话，你根本推不动scrum
A:思维的转变，管理层的支持是推进敏捷的必不可少的东西
B:如果这是必不可少的，那就不要实施敏捷好了 ：）,你不可能让老板们放弃传统的qa制度，仅仅因为你说敏捷可以解决一切问题
A:敏捷和传统的方式都能解决问题，只是敏捷可以更好的交付真正有价值的产品。如果老板不能放弃，那么真的很难
B:站在老板的视角，你凭什么说敏捷能交付更好的产品呢
A:实践是检验真理的唯一标准
B:公司不是实验室，产品也不是实验室里的小白兔。况且敏捷的方法并不是万能药，特别在大型项目上，要掌控好敏捷项目，对pm是一个很大的挑战
A:就是为了掌控好项目，所以才采用敏捷的方法论。当然不是万能药，敏捷是一个框架，你可以根据自己的需要扩展。有那么多的成功软件企业都在实践敏捷（最多的是Scrum），他们不是在闹着玩吧
B:有实践的结果吗？微软的哪一个大型产品是敏捷开发的？adobe呢？sap，oracle，IBM呢
A:Nokia是Scrum实践最好的，还有google http://www.infoq.com/presentations/Agile-Management-Google-Jeff-Sutherland
B:什么产品？
A:我认识的诺西的一个Manager，他们的网管产品NetArt,他们自己部门在实践Scrum
B:google只是在试验scrum罢了 成果还没看到呢。说实话 像NetArt这种大型产品，根本没有做scrum的必要，我不看好这种胡乱上马的架势。
A:Scrum是一种软件开发的方法论。任何东西，千万不要上来就排斥，兼容并包......
B:我怎么排斥了 我正在自己的项目中实践scrum
---------------------------------------------------------------------------------------------------------------------
一个正在实践Scrum得管理者对Scrum抱着种种猜疑，我很怀疑其实践Scrum的动机。
对于Agile和QA/Test的讨论，发现有很好的一篇讨论文章,援引几段文字表达我的看法。
The problem with QA is that programmers lose the responsibility for quality, because they start to think "it's QA's job." No, quality is not QA's job. It is the programmer's job, and the designer's job, and the architect's job.
You want quality in software? Make your programmers do peer reviews of all code before it gets checked in.
You want quality in software? Don't let your programmers start writing code until they can explain it clearly in English (or whatever spoken language your team has standardized on) to someone else on the team. Make sure the design makes sense before they get half-way done building the new pile of spaghetti code.
Our industry -- the software industry and those who write application -- as a whole produces mostly crap.
忘了粘贴讨论中的一句话：scrum的整体架构大话都知道，它起源自制造业的精益生产的变革，它是为了解决传统瀑布的问题，没有限定使用在什么软件开发环境。当然工程性的软件开发用起来最有效果。说到解决什么问题：根据市场变化就是快速生产，减少浪费（制造业的视角）。
当然对于偏产品研发的项目，适当保留QA的角色是合理的，但要求在项目中更多的参与并成为团队的一员。
还是很感谢B先生，思路和想法真的在讨论/辩论中才会越来越清晰。
历史总是不断地重复，只是你视而不见而已
《改变世界的机器》，这本只粗读了一半的陪我度过“至今最苦闷”的那段职业生涯的日子的一本书，不仅让我了解了汽车史和福特、通用和后来的丰田的发展史，更让我豁然开朗，作为制造业代表的汽车行业上演的关于如何更好地进行生产管理的理论的与时俱进的不断演进，也让我更好地理解了当前的商业竞争的趋势。对于一个当时身处于“软件制造业”笼罩的软件工人的我，发现来自软件开发的领域的敏捷开发的方法论就是从“制造业”前辈的变革和哲思中，引入和借鉴而来的。
日本人提出了精益生产模式，主要是通过降低成本的方法来提高利润。在长期的生产管理实践
中，日本人发现决定产品成本和利润的主要因素是制造过程中的各种消耗，特别是人的工资消耗。于是日本汽车业就提出了精益生产，旨在优化生产组织结构，去掉一切不增值的生产过程和环节，通过降低成本的方法来提高利润。
在Scrum为代表的敏捷软件开发方法论中，无论是通过快速开发的Iteration，还是每天的Daily Scrum对过程的Visiblity不断Inspector，和Retrospect meeting试图对过程的改进的最终目的都是减少那些和“增加客户价值”无关的活动。以前那段苦闷的经常开会的日子里，没有人关心这些meeting有没有增加产品的价值。
作为技术人员，我也曾经痴迷于技术实现，也的确认为技术有意思。
但当我们将软件行业作为社会各行业的一分子去看待的时候，站在更高的视角来看待其中的很多的背景的时候，你会发现IT是服务性的行业，还很年轻，其变革是随着整个商业变革演进而演进。
1950年，日本的丰田英二抱着学习美国先进经验的想法，考察了美国底特律福特公司的轿车
厂。当时这个厂每天能生产7000辆轿车，比日本丰田公司一年的产量还要多。
丰田英二在思考：怎样建立日本的汽车工业？照搬美国的大批量生产方式，显然是不可能的。
一是战后的日本经济萧条，缺少资金和外汇，没有能力全面引进美国成套设备来生产汽车。二是战后日本的经济和技术基础也与美国相距甚远，日本当时的生产量仅为美国的几十分之一。三是日本的社会文化背景与美国大不相同，完全照搬美国模式肯定行不通。显然应该按照日本的国情，发挥日本人的家族观念和团队精神，探索一条不同于福特公司的流水线生产模式的道路。
丰田英二和他的伙伴大野耐一进行了一系列的实验，经过30多年的努力，终于形成了完整的丰
田生产方式（TPS，即Toyota Production System）。在丰田生产方式TPS中，很重要的一种生产管理方法即是准时生产方式JIT。
准时生产方式的基本思想可用现在已广为流传的一句话来概括，即“只在需要的时候，按需要
的量生产所需的产品”，这也就是Just in Time（JIT）一词所要表达的本来含义。这种生产方式的
核心是追求一种无库存的生产系统，或使库存达到最小的生产系统，为此开发了包括“看板”在内
的一系列具体方法，并逐渐形成了一套独具特色的生产经营体系。准时生产方式在最初引起人们的注意时曾被称为“丰田生产方式”，后来随着这种生产方式被人们越来越广泛地认识、研究和应
用，特别是引起西方国家的广泛注意以后，人们开始把它称为JIT生产方式。
-------------------------------------------------------------------------------------------------
日本人还真有一套，实事求是，厚积薄发。
第一次从宏观地看待软件开发，还是在研究生毕业论文中对“软件危机/OO/CBD”的研究。当时主要是从代码重用，代码可维护性等软件实现技术的角度来探讨，在现在看来是“盲人摸象”。
软件开发是“脑力制造业”,属于服务业，服务的对象是其他不同行业，帮助他们降低成本改善运营和扩展business。
既然是服务性质的辅助行业，那么来自不同行业和领域的软件需求，固然会随着整个经济形态的不断变化，客户需要的是软件系统能支持和适应市场的瞬息万变，所以需求复杂度的提高、需求可变化成为必然。
软件开发是一个群体合作的过程，人怎么组织和规范他们的行为从而使得软件开发更有效率，关于软件开发流程和管理的方法论也不断演进。人的参与带来了软件开发的不确定性，这其中还包括组织架构，多团队合作对软件开发的影响。
能够让软件开发在技术实现、团队组织、客户需求等方面有好的表现，才能减低复杂度。
我突然想到，在Scrum中的ScrumMaster就要从这三方面均衡掌控。
最近接受了两个面试，一个HR一个Manager,他们在面试前都做了功课——看了我的Blog，试图了解我这个人的过去和性格。
面试是一个让公司和应聘者的信息更加对称的过程，公司希望了解应聘者的技能和综合能力，所以通过设置不同类型的面试轮次来从不同的侧面探测信息，应聘者也不是被动地被“吸血”，他们也会观察公司，了解公司的文化，前景，当然重要的是薪资水平（呵呵）。
面对面的测试和交流推动信息的对称在很多时候是苍白的，尤其对应聘者一方，所以很多时候是通过内部人打听，或者到网上查询一些评论；公司希望通过内部推荐的方式，也是为了降低“看走眼”的风险。
设想一下，如果所有的人都写Blog，人与人之间通过社会关系网络相连，公司和应聘者的信息将畅快地流动，极大地降低了招工和找工作的社会成本（甚至免去了交通成本，笔试的纸的成本）。但同时也是相当可怕的，一个公司中，内部到底怎么样，哪些人适合做什么，哪些人更优秀，都将是透明的。对于一个诚实的公司，愿意看到这样的情景，因为他展示了自己，展示了自己的人才，也相信有才华的人不会被挖走（因为公司有吸引他的东西），当然这也导致了好的公司和稍差公司（但都是诚实公司）的人才分化。一个可怕的假设后的可怕推论，就此终止吧。
言归正传，谢谢两位光顾我的Blog(in the name of interview), 如果你们能留言或者和我进行文字的沟通那就更好了。
All can benefit from your openess，I believe.
博文
所有评论
