敏捷开发是20世纪90年代提出，极限开发早于敏捷概念。敏捷是一个概念，有四大宣言： Individual and interaction over process and tools; working product over documentation; customer collaboration over customer contract; embrace change over follow a plan.
概念的好处在于给你巨大的空间发挥，坏处在于你做得好是概念的成功，做得不好是你实施的失误。我们总是跟着别人在走，国外说瀑布，于是我们哗啦啦的看着珍珠滩，国外说敏捷，于是我们又敏捷地转换方向，四处宣扬敏捷带来的好处。我想自己创造一个概念引领潮流，但很清楚还没那个能力，每日疲于奔命般的生活注定我们只能被别人带领。但是我也小小地思考过还有没有更好的方式，我只能说现在的我，认为敏捷已经是一种非常理想的概念了。瀑布太慢，敏捷却不快，因为它空间很大，快与慢由你自己决定，概念最讲求的是中庸之道。
我有过瀑布开发的经验，需求分析师的职责很重要也很无聊，在产品开发之前四处搜集需求，确认需求，写出厚厚的文档，担心需求变化莫测，却又不敢强硬的告诉客户，你别改哦，改是有代价的哦！所谓的签字画押根本就是扯淡，不管是开发还是需求人员，在下面闹腾的再厉害，客户他要改？！不给他改！领导一来，改吧，还不是屁颠颠的就去改了。看自己以前的东西我会很高兴地发现自己还是有些成长的，表现就在于认识到过去很傻很天真，我真以为contract是一种非常好非常有效的约束，我以为我们没做到不是因为理论有错，而是我们没有努力让理论达到最好的状态。（现在的我会觉得这个傻帽思想同样适用于敏捷，甚至以后更多更好的概念，如果我当时有所怀疑，我就不会这样信奉让自己显得很傻。）当我的思想开始成长，开始质疑，即使什么都不相信，那也是我思想的生长。文档写完了，就等着开发做，像我这样自学心理很强烈却很懒的人就开始无聊加矛盾。在项目开发过程中，项目经理需要时不时跑到客户处向客户汇报心得体会，等到项目做得差不多了，客户看了又提出这样那样的要求，于是我就改需求然后陪着他们加班加点的无聊。
瀑布结束，我开始敏捷。在敏捷中，我恐慌着，需求分析师总有一天会被取代吧。这是事实，不得不承认。我总叫嚷着，软件过程告诉我们60%的软件后期成本都是因为需求不明造成的，这就是我存在的价值。分析能力，综合能力，沟通能力，理解能力……这一堆抽象的能力不像你会写JAVA，C#，你会用selenium, QTP，能够评价，而且人人也都具备，你凭什么说你就比别人好？越做久了，就越不知道自己在干什么，或许所有问题都要上升到哲学的高度才能缓解。
抛开我是BA，单纯从软件来说，我也希望客户能够完全的参与到项目中来，但这永远是充满矛盾的，如果客户完全参与到项目中就不叫客户了，一个客户的需求更多的是他的需求，上面怎么想，下面怎么做，他也不是百分百确定，所以我们只能力求无限接近，却不能完全达到，一边挣扎一边进步是所有人正在做的事情。所以BA或者PM依然存在，让我缓口气。
敏捷就像一只麻雀，个子虽小却五脏俱全。需求、开发、测试、发布一样不少，不过它不是迭代的瀑布，但是我可以认为其实是高速迭代的瀑布吗？只是更多的上升到了人的高度。更灵活，更积极，更宽阔，更自由。
战略需要战术来支撑，敏捷需要各种开发模式来支撑。我粗略读完了Agile patterns，知道了有TDD，simple design，continuous integration, pair programming, etc. 如果开发能够为每一个class写unit test，如果所有的test case能够被自动化，如果每次integration都是成功的，如果每次增量开发都是有价值的，世界多美好。我相信，在敏捷中，自动化测试占着重要的位置。解决重复性工作才能释放人类的双手以及大脑。于是我们又需要提高自动化的功效，从各个方面。没有最好，只有更好。
我总是觉得我这一个月的快速填鸭式的学习好像学到了些，又好像什么都没学到。我本来想写写我最近学到了什么，我告诉自己你就随意的想到什么写什么吧，就成了这样。
在敏捷团队里面工作了一年半，因为疲于奔命也因为惰性，我并没有多想，只知道scrum, standup, 3 weeks/release, retrospective。现在开始看这些书，想起上个团队中有个老外讨厌别人动他的代码，估计他对敏捷的理解与我之前一样。之前？那现在或者之后我是怎样？
在现在这个团队里，我当前的任务是设定一个automation capability index for whole company. 我一边兴奋地猛吸新鲜的知识，偶尔又觉得这是在"整"我。我一个没做过automation的人怎么去制定标准。But anyway, 我只能边做边等待被开除，或者边做边等待认可.这些可都是激发我生命活力的大鲶鱼啊！
概念的好处在于给你巨大的空间发挥，坏处在于你做得好是概念的成功，做得不好是你实施的失误。我们总是跟着别人在走，国外说瀑布，于是我们哗啦啦的看着珍珠滩，国外说敏捷，于是我们又敏捷地转换方向，四处宣扬敏捷带来的好处。我想自己创造一个概念引领潮流，但很清楚还没那个能力，每日疲于奔命般的生活注定我们只能被别人带领。但是我也小小地思考过还有没有更好的方式，我只能说现在的我，认为敏捷已经是一种非常理想的概念了。瀑布太慢，敏捷却不快，因为它空间很大，快与慢由你自己决定，概念最讲求的是中庸之道。
我有过瀑布开发的经验，需求分析师的职责很重要也很无聊，在产品开发之前四处搜集需求，确认需求，写出厚厚的文档，担心需求变化莫测，却又不敢强硬的告诉客户，你别改哦，改是有代价的哦！所谓的签字画押根本就是扯淡，不管是开发还是需求人员，在下面闹腾的再厉害，客户他要改？！不给他改！领导一来，改吧，还不是屁颠颠的就去改了。看自己以前的东西我会很高兴地发现自己还是有些成长的，表现就在于认识到过去很傻很天真，我真以为contract是一种非常好非常有效的约束，我以为我们没做到不是因为理论有错，而是我们没有努力让理论达到最好的状态。（现在的我会觉得这个傻帽思想同样适用于敏捷，甚至以后更多更好的概念，如果我当时有所怀疑，我就不会这样信奉让自己显得很傻。）当我的思想开始成长，开始质疑，即使什么都不相信，那也是我思想的生长。文档写完了，就等着开发做，像我这样自学心理很强烈却很懒的人就开始无聊加矛盾。在项目开发过程中，项目经理需要时不时跑到客户处向客户汇报心得体会，等到项目做得差不多了，客户看了又提出这样那样的要求，于是我就改需求然后陪着他们加班加点的无聊。
瀑布结束，我开始敏捷。在敏捷中，我恐慌着，需求分析师总有一天会被取代吧。这是事实，不得不承认。我总叫嚷着，软件过程告诉我们60%的软件后期成本都是因为需求不明造成的，这就是我存在的价值。分析能力，综合能力，沟通能力，理解能力……这一堆抽象的能力不像你会写JAVA，C#，你会用selenium, QTP，能够评价，而且人人也都具备，你凭什么说你就比别人好？越做久了，就越不知道自己在干什么，或许所有问题都要上升到哲学的高度才能缓解。
抛开我是BA，单纯从软件来说，我也希望客户能够完全的参与到项目中来，但这永远是充满矛盾的，如果客户完全参与到项目中就不叫客户了，一个客户的需求更多的是他的需求，上面怎么想，下面怎么做，他也不是百分百确定，所以我们只能力求无限接近，却不能完全达到，一边挣扎一边进步是所有人正在做的事情。所以BA或者PM依然存在，让我缓口气。
敏捷就像一只麻雀，个子虽小却五脏俱全。需求、开发、测试、发布一样不少，不过它不是迭代的瀑布，但是我可以认为其实是高速迭代的瀑布吗？只是更多的上升到了人的高度。更灵活，更积极，更宽阔，更自由。
战略需要战术来支撑，敏捷需要各种开发模式来支撑。我粗略读完了Agile patterns，知道了有TDD，simple design，continuous integration, pair programming, etc. 如果开发能够为每一个class写unit test，如果所有的test case能够被自动化，如果每次integration都是成功的，如果每次增量开发都是有价值的，世界多美好。我相信，在敏捷中，自动化测试占着重要的位置。解决重复性工作才能释放人类的双手以及大脑。于是我们又需要提高自动化的功效，从各个方面。没有最好，只有更好。
我总是觉得我这一个月的快速填鸭式的学习好像学到了些，又好像什么都没学到。我本来想写写我最近学到了什么，我告诉自己你就随意的想到什么写什么吧，就成了这样。
在敏捷团队里面工作了一年半，因为疲于奔命也因为惰性，我并没有多想，只知道scrum, standup, 3 weeks/release, retrospective。现在开始看这些书，想起上个团队中有个老外讨厌别人动他的代码，估计他对敏捷的理解与我之前一样。之前？那现在或者之后我是怎样？
在现在这个团队里，我当前的任务是设定一个automation capability index for whole company. 我一边兴奋地猛吸新鲜的知识，偶尔又觉得这是在"整"我。我一个没做过automation的人怎么去制定标准。But anyway, 我只能边做边等待被开除，或者边做边等待认可.这些可都是激发我生命活力的大鲶鱼啊！
扫一扫
288
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
