有知道Agile methodology的吗？

key

原帖由 乱码 于 2010-10-8 10:56 发表


project进度量化，有很多可以衡量的指标，可以有效地控制成本，这是进步。

我觉得现在的问题是：

如果公司很急功近利，所有的时间都记入成本，developer没有适当的时间知识更新（在公司，不是在家），不利于developer的职业发展。
因 ...

project进度的量化似乎是CMM这套东西做得更好吧？
Agile则是以有形来避免无形，以具体避免空谈，在假设大家都是坏蛋的前提下，
以坏蛋控制坏蛋的方式来避免项目出现不可控的情况。

key

原帖由 乱码 于 2010-10-8 22:01 发表


很同意你的观点。

别人教的不经过消化永远别不成自己的，sql 这块更是这样，很多case要仔细揣摩+实践的,很多情况下，如果需要大数据量多场景的测试，一天也写不了几个statement.这样每天的技术总结不可缺。

pair program ...

pair programming要解决的是两个问题，一是senior programmer的偷懒窝工问题，
另一个是牛人跑掉对公司的响影问题，至于pair coding提高代码质量，提高交流有效性，
互相传送知识，这些基本上是bullsh*t。多参与技术论坛、News Group的讨论，
多参加技术会议，多培训才能提搞员工的技术水平，这些在agile里连影子都没有。

ericbado

原帖由 key 于 2010-10-9 11:10 发表


谢谢指点。
我想请教一下这个问题的操作办法：
一是如何做到每天都交换pair？或者如何频繁交换pair？是否有什么样的pair的换人规则？
轮岗制？按我的理解，换pair毕竟不是programmer喜欢自发做的事，需要有一定的规则或执行者
驱 ...

我现在的team，每个release会有个iteration manager，他会安排谁跟谁pair，但理论上这不需要谁来安排
同样的，我们team里2天交换一次pair是比较理想的，不过这要基于card的point，一天一换恐怕效率不能最大化吧

ericbado

原帖由 key 于 2010-10-9 11:25 发表


说得很对，agile就是要淡化整体规划，因为整体规划往往引入太强的前期风险。
不知道我理解你说的“沿用之前的设计”对不对，你在这里是不是指沿用之前设计的思想？
以及重用之前设计的框架？还有重用之前实现的一些程序库？这 ...

我的确是指沿用设计或框架，不管agile提倡什么，保证一定的连贯性总是需要的，我想agile总不提倡一切都推翻重来吧
我前两天就碰到搬石头砸自己脚的事。前后两张card，从业务角度上来看是连贯的，只是后者的业务功能是前者的加强
第一张卡片要生成invoice，因为一次只生成一条记录，所以developer就新建了一张表来保存
第二张卡片同样也是生产invoice，但一条invoice有多条item，我们必须把原先的一张表拆成2张表，前一张card的代码也都要改过了
我不知道这是不是agile带来的典型问题，还是我们自己没做好，但我实在不喜欢这种缺乏规划的工作
如果把需求都合起来看，至少不会出现这样的设计问题吧
所以，agile似乎真的只适用于小型项目

至于重构，说的很对，别人用不用就不知道了，不过这不是agile特有的东西
我以前在国内的项目，比较重要的重构之后，都是整个项目组开会沟通的，如何使用新的方法，或者必须使用新的方法等

总之还是不习惯agile，并不是因为waterfall根深蒂固，而是没看到agile有多大好处
其实以前虽然用的是瀑布，但很多方法也是agile所提倡的，比如晨会，比如和业务人员一起工作
反过来，agile的每个迭代，不也是一个个小瀑布吗
所以还是我中有你你中有我更适合实际应用
至于pair，可以肯定的是并不适合中国国情

key

原帖由 ericbado 于 2010-10-10 11:23 发表
我现在的team，每个release会有个iteration manager，他会安排谁跟谁pair，但理论上这不需要谁来安排
同样的，我们team里2天交换一次pair是比较理想的，不过这要基于card的point，一天一换恐怕效率不能最大化吧

请教一下关于integration manager的角色。这个角色是确定的还是动态的？也就是说，
在整一个project里，是否指定一个或少数确定的若干个 IM ？他们和 PM 的关系如何？
这些人是否参与开发工作？

刚才在youtube上看了一个视频是关于Agile中的IM的，印度人说话太难听了，所以我尝试把自己听到的，连蒙
带猜的写下来，如果哪位有时间也听一下，请帮我纠错一下。不过我听完后，基本上还是不清楚这个角色。

http://www.youtube.com/v/cbNmVUbdKRo

My role so as speek is Business Analyst, Support IM. That is what I am now.
Right now though, I am now doing is giving support and trying to understand
what an enhancement and a bug means, and what the priority is, and the
the capacity is and how they match (each other). So how quick they could
implement what they want, and setting those expectation.

You can leave when they wake up, when, after half pass five. The good thing is,
because, you know, they can work eight hours, at the end of the day sending
an email saying tomorrow when you come in please look into these things.
So most of us include in a stand up clause look into these things,
try to understand what these problems are. If we have a false card,
... look into what the problems are, we can discuss these problems
at the end of this part, .. whatever. Mostly, the .. card, questions,
development,

So, mostly, the investigatiom the cards is the first part of the day.
The second part of the day, would be the support to establish a development
environment, or we like user stories ...

.. 25 people, and that was a problem, because you would have difficulties
to assign the ownership of which people what to do. Every single day,
people ... on.. What is the session to do is getting everything as everything.
With a small application, maybe this is possible. When we realize that,
we decided to break up the them into smaller pieces. That will be possibly
add less dependency on to each other as possible.Apart the whole team,
and I tracked the whole team as one.

...

you can focus on a team for a while. What is the main thing that you will
realize is when you are talking to someone, that is your audience. You have to
understand what your audience says. When you are talking to a project manager,
he may concern on different level of details, and different type of information.
When you are talking to developers in the team, they may have different kinds of
.... That is important to realize. In my role, it is supposed to realized
who knows what, because my support and skills are critical to get back to the
customers as possible...

ericbado

应该叫iteration manager吧，顾名思义就是负责一个iteration的mgr，所以是动态的
我们team是自愿的，谁想当IM就说出来，如果几个人都相当的话就协商一下确定一个。。。应该是轮流的
我们的dev mgr相当于pm，他同时管2个项目，主要负责进度控制
IM参与所有开发环节，只是这个release他多负责点而已，有点lead的意思
我们用thoughtworks的产品控制release周期，比如mingle，以及selenium自动测试，感觉还是很强大的

fenghuo

我们只用scrum，没觉得特别有效，可能是刚刚引进的缘故把

key

原帖由 ericbado 于 2010-10-10 11:51 发表
我的确是指沿用设计或框架，不管agile提倡什么，保证一定的连贯性总是需要的，我想agile总不提倡一切都推翻重来吧

如果我没有搞错，prototype是明言推翻重写的，而incremental则是逐层添加。
Agile则既不说推翻，也不说迭加，iteration之间并没有明确的关系。在Craig Larman的
Applying UML and Patterns中，他提出的是抽取关键use cases的方法来做，
这个有点incremental的味道。如果是这种做法，一般都不需要推翻重来吧。
Agile很强调refactor，从这个角度看，Agile强调的是每次迭代的目标是功能的实现，
讨好客户，代码质量放在次要位置。但由于refactor本身的量化有难度，所以就要看管理人员和
tech lead的意识了。不过，现在越来越多工具用于测试“量化”代码的质量，就不知道工规范的
Agile公司有没有用这种工具来驱动生产了。

我前两天就碰到搬石头砸自己脚的事。前后两张card，从业务角度上来看是连贯的，只是后者的业务功能是前者的加强
第一张卡片要生成invoice，因为一次只生成一条记录，所以developer就新建了一张表来保存
第二张卡片同样也是生产invoice，但一条invoice有多条item，我们必须把原先的一张表拆成2张表，前一张card的代码也都要改过了
我不知道这是不是agile带来的典型问题，还是我们自己没做好，但我实在不喜欢这种缺乏规划的工作
如果把需求都合起来看，至少不会出现这样的设计问题吧

我觉得这是第七只饼和前六只饼的区别。从我理解的Agile的角度看来，如果没有前一只card中的“不好”的实现，
你在第二张card的时候可能根本无从做起，或者做得很糟；而有了第一张卡，需要你需要重构数据表结构，
但只会做得比原来更好，而不会比原来更差，这样工作是向前推进了。

而再换一个角度，如果你第二张卡实现失败了，你的客户至少要获得前一张卡的实现，这可能是工作的40%，或者30%，
但比之竹篮打水一张空好得多。“缺泛规划工作”可以大大减轻你在实现第一张卡时的难度和负担，以确保第一卡的顺利实现。

上一周，我带我的开发人员实现一个系统功能。我制定了一个三步迭代的系统。在我眼中，第一个迭代是最简单的，
因为第一个迭代系统完全参考了我们之前的一个prototype（其他人开发的），所以我觉得第一个迭代没有难度。
但由于我们参考的prototype系统采用了一些tricky的方法来实现，并不是一个straightforward的东西，
在没有办法重用的前提下，我们在短时间内实现第一个方案的难度很大，而且完全没有必要。
最后我建议放弃了第一个迭代方案，直接进入第二个迭代方案。

简而言之，第一个迭代其实是失败了。但由于在第一次
迭代过程中，我们构建了系统的大部分框架、元素，所以在简单的调研后，我们很快建立了第二个迭代实现。
由于第二个迭代实现已经满足老板的要求，我并没有要求我的开发人员实现第三个迭代方案。但今天开会的时候，
老板提出所谓“新的需求”，这个新需求其实就被我第三个迭代方案所覆盖，只需他拍板，给时间，我们马上就做。
简单来说，在兄弟们看来，每个方案都可能会推翻部分东西重做，但在我看来，这些都是饼，吃了一个就饱一个，
并没有浪费。反而是，如果我一开始就把第三个迭代方案拿出来做，估计大家只好傻掉了。

我以前在国内的项目，比较重要的重构之后，都是整个项目组开会沟通的，如何使用新的方法，或者必须使用新的方法等

我觉得很多公司，尤其是以客户为中心的公司，很难有专门的时间让项目组做重构工作。
所以我一直觉得重构是海市蜃楼。

ericbado

呵呵，怎么说呢
我理解是，一个release相对于前一个release，肯定是功能上的叠加，如果后一个release失败了，前一个的确还能用
但如果同一个release里，我觉得应该有一定的整体规划，因为在同一个release中，需求基本是确定了的，每一张card（或称story），应该是功能的延续，而不是增强。换句话说，card分must have，should have，better to have等，must have基本占总数的3/4，只有这些must card都实现了，这个release才可用。所以针对这些card，应该有一个整体的设计，而不应该在这些card中再推翻前一张卡片的设计，这个等于倒退了
所以从这个角度讲，我觉得agile如何解决card之间的依赖关系是比较重要的，当然也有可能是我们自己没做好
但始终觉得agile比较随意，不严谨