小刀的话显然让作者感到不舒服，于是出来做了解释
[quote]我是本文作者，之所以写这篇文章的目的是，敏捷开发中很重要的一个环节是发现问题，从根源上解决这个问题。很多读者对事实的实际发生根本不了解，所以会误解为我给这个开发者穿小鞋。事实上，这个开发者"A"从一开始就说“我会帮助你完成该完成的。”暗地里，他在三个星期中什么都没有做。我和他沟通无数次说，你要专心把一件工作做完再转到另一工作上，而不是这里忙一点，那里忙一点，最后什么都没有做完。我把自己的想法很清楚地传达给他 -- 我想看到实质性的工作进展。敏捷需要清晰的交流，我觉得我做得很好了。和我一起工作的"B"同样做了口头，文字上的交流。我和"B"在三个星期内做出的努力得到的结果是0。
最近我和文中的"B"，还发现"A"从被雇用以后的八个月里，总共提交了15次代码，其他QA提交了百次以上。我和"B"都发现"A"根本就不愿意在我们组里工作。与其让他不工作，不如将其调离我们组，这就是我和B最后所做的。
还有，最后"D"分配给我一个新的人手“W”，我和“W”在两天内就完成了"A"本来三个星期内该做甚至能做得更多的事情。所以请不要提醒我说沟通很重要，或者这不是敏捷。你要是站在我的立场上，你也会作出我的选择，因为“B”都这么做了。[/quote]
而近跟着其他三个人对这个解释做了评论。
Arui Zen首先问了几个问题
[quote] "最近我和文中的"B"，还发现"A"从被雇用以后的八个月里，总共提交了15次代码，其他QA提交了百次以上。我和"B"都发现"A"根本就不愿意在我们组里工作。与其让他不工作，不如将其调离我们组，这就是我和B最后所做的。"
为什么这个人如此不愿意在你们组里工作? 既然他是所谓的高级工程师,难道此人就如此一无是处? 你了解你的这个手下到底在想什么吗?如果你能指到此人的真实想法然后在做决定是否会更好一些?[/quote]
这些问题很重要，但是我看不到答案。
不过确实知道别人的真实想法有些时候很困难，而且也来不及做到这一点。因为作者已经说了，他不能容忍进度停滞。但是最终还是要搞清楚为何别人不喜欢在你的环境下工作，至少下次遇到同样的人，你就会提前知道他会不喜欢不快乐。而工作失去了快乐，就别谈什么敏捷了。当然这需要沟通和设身处地的从A的角度考虑问题，也就是需要换位思考。当然在当时的情况下，时间可能不允许。不过事后是不是就没有机会这么做了呢？
不过我并不觉得知道了真实的想法，再做决定就必定会好些，毕竟很多时候你会理解他人，但是并不代表你就会认同他人。
小刀面对作者的解释继续坚持原有的看法
[quote] 我的意思是，这个故事没必要往敏捷身上套，你说，“敏捷开发中很重要的一个环节是发现问题，从根源上解决这个问题”，但是，难道不使用敏捷开发的软件开发流程，“发现问题解决问题”就不是它们的重要环节了么？
“敏捷需要清晰的交流”，这句话没错，但是，我的看法是，软件开发需要清晰的交流。不要硬生生的把敏捷从软件开发中隔离出来。[/quote]
确实发现问题是解决问题的前提，并且采取任何方法都需要。但是毕竟发现问题的手段在敏捷和其它方法下是有所不同的。传统的方法是加强控制，并且提前做出种种应当措施。而敏捷则是加强交流，时刻观察到最细微的变化，并实时的采取调整。敏捷确实需要清晰的交流，但是什么方法不需要呢？
问题在于作者很显然沟通出来问题。比如他说，他认为他和B做的沟通工作够好了。但是我看他仅仅是在说，他和B很清晰的表达了自己的意思给A，但是A得反馈呢？反馈清晰吗？难道沟通就只是单向的吗？难道现在才发现A八个月才提交了那么点东西，是正常的吗？难道这还不够说明问题吗？
沟通出了这么大的问题，难道这么看重沟通的敏捷会没有问题？我们当然可以说作者不够敏捷，但是为什么会实施错了呢？是对敏捷认识的偏差，还是实施的偏差，还是环境因素造成的偏差？难道这些问题都不是关于敏捷的吗？
接着gigix出场了，眼光确实比较尖锐。[quote] > 敏捷开发中很重要的一个环节是发现问题，从根源上解决这个问题。
但我在文中看不出你有什么机制或者方法来发现“开发者A”所存在的问题。你提到他的问题，在我看来，都是你“认为”他“应该”怎么怎么。好吧，他没有照你 “认为应该”的那样去做。so what？他造成了什么损害？哦，你“心里急啊”。仅此而已吗？难怪你老板一直把他扔在你组里呢。
你号称自己在做敏捷，号称自己很看重发现问题解决问题，可是对于“开发者A”的问题在我看来你就没有认真的去发现。如果你做了，你的数字在哪里？你的证据在哪里？如果你有他给项目造成损害的数字和证据在，老板还会坚持让他在你项目里呆着吗？
即便不说发现问题，你也同样没有体现出解决问题的决心和行动力，当然这就扯远了，打住。
[/quote]真所谓点到即止。
不过我有个问题，显然发现问题，和得到问题发生的原因不是一个概念，而发现根源更加不是一个概念，再加上从根源上解决问题更加不是一个概念。
而显然作者在很多时候都不知道A究竟是在干啥，难道他说在看文档就没有办法检验一下吗？看了那么久的文档，难道就不该去交流一下他看得过程中的问题吗？我不说应该每一个小时都经常性的去交流一下，至少每天去看看，关心一下是不是遇到了问题，并且把自己在对方领域看到的疑点提出了给对方参考，都不去做一下吗？沟通是这样搞得吗？
事后说和B三个星期的努力结果是0，但是真的就努力了吗？难道交待下去的工作就不跟踪，不评审了吗？
而现在来个新人W，你说效率比A高多了。但是这又能说明了什么，是说明你沟通没有问题？我看这仅仅说明你和W沟通没有问题罢了。同时B也这么做了，难道别人也如此做就说明是对的吗?
小刀可能看得兴起，又发言了[quote] >让我认识到如何使用敏捷教条对管理方面的问题进行分析
再来看一下文章第一段的这句话，敏捷都已经成教条了呢～～[/quote]
于是上 里巴人出来打圆场[quote] 我想这儿作者用“教条”的意思是说“敏捷原则”或者“敏捷的指导思想”，小刀同学大可不必如此追究作者用词的问题，而且我不认为这儿用“教条”就有什么不妥。
从文章中来看，作者所表达的观点还是非常中肯的。在团队中作者的角色应该是敏捷教练，文章中所发生的这件事情是作者身为教练的经历，为何就不能作为敏捷的案例来讲呢？敏捷是软件开发中的一个方法，但是它有自己的特性，那就是强调沟通，如果是传统的方法，一切用制度和文档来约束，可能就不会产生类似的故事。[/quote]
什么是敏捷教练，作者能被称作敏捷教练吗？
而问题在于如果采取传统模式，一切都由知道和文档来约束，就真的能很快发现怠工了吗？而你在作者的叙述里面，很明显的可以看到A是十分希望搞过程改进的，其实说来说去就是A喜欢搞文档而不喜欢提交代码。这在作者看来是不能容忍的，没有见到实效的。难道这样一个人在传统方式下就真的会高效率起来，我看只能说是能够更好的隐藏起来罢了。
[quote]我是本文作者，之所以写这篇文章的目的是，敏捷开发中很重要的一个环节是发现问题，从根源上解决这个问题。很多读者对事实的实际发生根本不了解，所以会误解为我给这个开发者穿小鞋。事实上，这个开发者"A"从一开始就说“我会帮助你完成该完成的。”暗地里，他在三个星期中什么都没有做。我和他沟通无数次说，你要专心把一件工作做完再转到另一工作上，而不是这里忙一点，那里忙一点，最后什么都没有做完。我把自己的想法很清楚地传达给他 -- 我想看到实质性的工作进展。敏捷需要清晰的交流，我觉得我做得很好了。和我一起工作的"B"同样做了口头，文字上的交流。我和"B"在三个星期内做出的努力得到的结果是0。
最近我和文中的"B"，还发现"A"从被雇用以后的八个月里，总共提交了15次代码，其他QA提交了百次以上。我和"B"都发现"A"根本就不愿意在我们组里工作。与其让他不工作，不如将其调离我们组，这就是我和B最后所做的。
还有，最后"D"分配给我一个新的人手“W”，我和“W”在两天内就完成了"A"本来三个星期内该做甚至能做得更多的事情。所以请不要提醒我说沟通很重要，或者这不是敏捷。你要是站在我的立场上，你也会作出我的选择，因为“B”都这么做了。[/quote]
而近跟着其他三个人对这个解释做了评论。
Arui Zen首先问了几个问题
[quote] "最近我和文中的"B"，还发现"A"从被雇用以后的八个月里，总共提交了15次代码，其他QA提交了百次以上。我和"B"都发现"A"根本就不愿意在我们组里工作。与其让他不工作，不如将其调离我们组，这就是我和B最后所做的。"
为什么这个人如此不愿意在你们组里工作? 既然他是所谓的高级工程师,难道此人就如此一无是处? 你了解你的这个手下到底在想什么吗?如果你能指到此人的真实想法然后在做决定是否会更好一些?[/quote]
这些问题很重要，但是我看不到答案。
不过确实知道别人的真实想法有些时候很困难，而且也来不及做到这一点。因为作者已经说了，他不能容忍进度停滞。但是最终还是要搞清楚为何别人不喜欢在你的环境下工作，至少下次遇到同样的人，你就会提前知道他会不喜欢不快乐。而工作失去了快乐，就别谈什么敏捷了。当然这需要沟通和设身处地的从A的角度考虑问题，也就是需要换位思考。当然在当时的情况下，时间可能不允许。不过事后是不是就没有机会这么做了呢？
不过我并不觉得知道了真实的想法，再做决定就必定会好些，毕竟很多时候你会理解他人，但是并不代表你就会认同他人。
小刀面对作者的解释继续坚持原有的看法
[quote] 我的意思是，这个故事没必要往敏捷身上套，你说，“敏捷开发中很重要的一个环节是发现问题，从根源上解决这个问题”，但是，难道不使用敏捷开发的软件开发流程，“发现问题解决问题”就不是它们的重要环节了么？
“敏捷需要清晰的交流”，这句话没错，但是，我的看法是，软件开发需要清晰的交流。不要硬生生的把敏捷从软件开发中隔离出来。[/quote]
确实发现问题是解决问题的前提，并且采取任何方法都需要。但是毕竟发现问题的手段在敏捷和其它方法下是有所不同的。传统的方法是加强控制，并且提前做出种种应当措施。而敏捷则是加强交流，时刻观察到最细微的变化，并实时的采取调整。敏捷确实需要清晰的交流，但是什么方法不需要呢？
问题在于作者很显然沟通出来问题。比如他说，他认为他和B做的沟通工作够好了。但是我看他仅仅是在说，他和B很清晰的表达了自己的意思给A，但是A得反馈呢？反馈清晰吗？难道沟通就只是单向的吗？难道现在才发现A八个月才提交了那么点东西，是正常的吗？难道这还不够说明问题吗？
沟通出了这么大的问题，难道这么看重沟通的敏捷会没有问题？我们当然可以说作者不够敏捷，但是为什么会实施错了呢？是对敏捷认识的偏差，还是实施的偏差，还是环境因素造成的偏差？难道这些问题都不是关于敏捷的吗？
接着gigix出场了，眼光确实比较尖锐。[quote] > 敏捷开发中很重要的一个环节是发现问题，从根源上解决这个问题。
但我在文中看不出你有什么机制或者方法来发现“开发者A”所存在的问题。你提到他的问题，在我看来，都是你“认为”他“应该”怎么怎么。好吧，他没有照你 “认为应该”的那样去做。so what？他造成了什么损害？哦，你“心里急啊”。仅此而已吗？难怪你老板一直把他扔在你组里呢。
你号称自己在做敏捷，号称自己很看重发现问题解决问题，可是对于“开发者A”的问题在我看来你就没有认真的去发现。如果你做了，你的数字在哪里？你的证据在哪里？如果你有他给项目造成损害的数字和证据在，老板还会坚持让他在你项目里呆着吗？
即便不说发现问题，你也同样没有体现出解决问题的决心和行动力，当然这就扯远了，打住。
[/quote]真所谓点到即止。
不过我有个问题，显然发现问题，和得到问题发生的原因不是一个概念，而发现根源更加不是一个概念，再加上从根源上解决问题更加不是一个概念。
而显然作者在很多时候都不知道A究竟是在干啥，难道他说在看文档就没有办法检验一下吗？看了那么久的文档，难道就不该去交流一下他看得过程中的问题吗？我不说应该每一个小时都经常性的去交流一下，至少每天去看看，关心一下是不是遇到了问题，并且把自己在对方领域看到的疑点提出了给对方参考，都不去做一下吗？沟通是这样搞得吗？
事后说和B三个星期的努力结果是0，但是真的就努力了吗？难道交待下去的工作就不跟踪，不评审了吗？
而现在来个新人W，你说效率比A高多了。但是这又能说明了什么，是说明你沟通没有问题？我看这仅仅说明你和W沟通没有问题罢了。同时B也这么做了，难道别人也如此做就说明是对的吗?
小刀可能看得兴起，又发言了[quote] >让我认识到如何使用敏捷教条对管理方面的问题进行分析
再来看一下文章第一段的这句话，敏捷都已经成教条了呢～～[/quote]
于是上 里巴人出来打圆场[quote] 我想这儿作者用“教条”的意思是说“敏捷原则”或者“敏捷的指导思想”，小刀同学大可不必如此追究作者用词的问题，而且我不认为这儿用“教条”就有什么不妥。
从文章中来看，作者所表达的观点还是非常中肯的。在团队中作者的角色应该是敏捷教练，文章中所发生的这件事情是作者身为教练的经历，为何就不能作为敏捷的案例来讲呢？敏捷是软件开发中的一个方法，但是它有自己的特性，那就是强调沟通，如果是传统的方法，一切用制度和文档来约束，可能就不会产生类似的故事。[/quote]
什么是敏捷教练，作者能被称作敏捷教练吗？
而问题在于如果采取传统模式，一切都由知道和文档来约束，就真的能很快发现怠工了吗？而你在作者的叙述里面，很明显的可以看到A是十分希望搞过程改进的，其实说来说去就是A喜欢搞文档而不喜欢提交代码。这在作者看来是不能容忍的，没有见到实效的。难道这样一个人在传统方式下就真的会高效率起来，我看只能说是能够更好的隐藏起来罢了。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
