今天team来新人了...

Fernando

前阵子研究Agile，有一个缺点就是对开发人员要求高，最好都是snr

乱码

原帖由 Fernando 于 2011-6-21 15:29 发表
前阵子研究Agile，有一个缺点就是对开发人员要求高，最好都是snr

都是snr到也不至于，只要大家都基本上在一个水平上就好，作estimation的时候，找中间的level，不高不低.

考虑到scrum master可能会随时jump out to help out others/或者很多meeting，他的focus factor要调低.

大家做起来的时候，都按delivery order从pool里拿东西，自己轮到什么就是什么。这种可能要求技术要全面，不能只是根据某方面的喜好干活。

有的team在planning的时候就把task根据skill set assign给某一个人了，个人觉得这样不是很好，会导致某些team过渡依赖某些member作某些事情，不够健康。

greed

原帖由 Fernando 于 2011-6-21 15:29 发表
前阵子研究Agile，有一个缺点就是对开发人员要求高，最好都是snr

全snr也不成。到时候想法忒多，开个会没完没了。如果standup meeting的话，腿都要折了。

乱码

今天又教他如何用attach to w3wp来debug，没想到帮人也会这么容易哈 :)

I'm glad he made it today

[ 本帖最后由 乱码 于 2011-6-21 18:18 编辑 ]

dalaohu

靠。。。这种水平都招进来啦，这个堕落得。。。
谁招得。。。

乱码

原帖由 dalaohu 于 2011-6-21 18:20 发表
靠。。。这种水平都招进来啦，这个堕落得。。。
谁招得。。。

不知道．．．．好像谁都不知道，

There's no stupid questions.--我这种非常professional的态度就源于这种神秘感　

dalaohu

那你给他开个足迹博客，记录一下snr 是怎样练成得

乱码

原帖由 dalaohu 于 2011-6-21 18:38 发表
那你给他开个足迹博客，记录一下snr 是怎样练成得

it's what i'm doing now

porcorosso

看得我都脸青了。。。不懂啥是w3wp!!

乱码

原帖由 porcorosso 于 2011-6-21 21:22 发表
看得我都脸青了。。。不懂啥是w3wp!!

兄弟，其实也没啥，隔行如隔山，你跟我说php的东西，我也不懂。

从iis6开始，w3wp.exe在app pool中run来处理request，如果solution deploy在local iis上，你就可以用vs的debugger attach到这个w3wp来debug程序.

如果设好了starting project/page，用f5开始debug也没问题，好像大系统很少有人这么干了，小系统还行，可能改来改去比较麻烦，基本上都是用attach的方式来做.

linkspeed

Agile的特点是否决定了项目必须是非常熟悉的。如果遇到技术难题
也许要等拍脑袋拍出来的那天。我自己写的程序有时候搞不定，
拖几个月都有。

dalaohu

这是VS， asp.net专有得，做php当然不用知道。
是debug attach to process 到web server用得。

Dan.and.Andy

问一句，Agile 不能总是干活啊，有闲的时候学习学习，无事可做，搞搞培训什么的吗？

dalaohu

原帖由 Dan.and.Andy 于 2011-6-21 21:44 发表
问一句，Agile 不能总是干活啊，有闲的时候学习学习，无事可做，搞搞培训什么的吗？

那就学完了再agile吧，agile就是资本家用残酷得制度来剥削劳动力得。

学习属于福利一类得。

Dan.and.Andy

原帖由 dalaohu 于 2011-6-21 21:49 发表

那就学完了再agile吧，agile就是资本家用残酷得制度来剥削劳动力得。

学习属于福利一类得。

那不是整个团队的素质随着时间的增长呈现下降趋势了吗？这有什么好处吗？

flyspirit

原帖由 linkspeed 于 2011-6-21 21:37 发表
Agile的特点是否决定了项目必须是非常熟悉的。如果遇到技术难题
也许要等拍脑袋拍出来的那天。我自己写的程序有时候搞不定，
拖几个月都有。

恰恰相反， Agile比waterfall更适合用于需要用新技术的项目， 或者需求不清的项目。

乱码

原帖由 linkspeed 于 2011-6-21 21:37 发表
Agile的特点是否决定了项目必须是非常熟悉的。如果遇到技术难题
也许要等拍脑袋拍出来的那天。我自己写的程序有时候搞不定，
拖几个月都有。

没什么特别难得东西，大家现在讨论的都是business层面的东西，和如何实现，纯技术的也有，但很少。

有时候纯技术的东西卡一下，google就解决了，也犯不着问别人，应该是每个人都这么来trouble shooting的。

乱码

原帖由 Dan.and.Andy 于 2011-6-21 21:44 发表
问一句，Agile 不能总是干活啊，有闲的时候学习学习，无事可做，搞搞培训什么的吗？

好像没闲的时候，这点scrum/agile我的确很不喜欢.

training要根据management对个人的判断来决定，但需要training的人当初基本上拿不到职位。

除非整个team的开发环境有实质性的变化，比如用到mvc3,可能会有相应的training.

我们在用外面的4个senior consultant,有些自己不熟的东西也是请consultant onsite工作，可能对自己的员工就暂时没有training的需要。

我个人理解从管理层的角度来看，get job done是priority，员工traing在短期不能deliver business value，所以不值得。

[ 本帖最后由 乱码 于 2011-6-21 22:12 编辑 ]

dalaohu

原帖由 Dan.and.Andy 于 2011-6-21 21:52 发表


那不是整个团队的素质随着时间的增长呈现下降趋势了吗？这有什么好处吗？

其实就像你请人来帮你盖房子，你期望你请得人都是有经验得，你不会想看到工人门为了如何搭个围墙，先要花5天得时间来研究学习吧，钱还要照收不误。

乱码

我个人对agile/scrum的理解是,它很适合中小型team，比如几个人到几十个人的大team，分割成若干小team之后，然后协同作战，但他们的tasks应该尽量减少不必要的dependency，否则很难agile.

几百人的大团队，agile起来协同相当困难，project不可避免有阶段性的dependency，或者等待，这种overhead就很高，不过大公司应该都可以承担的起.

而且他们dev的分组也是根据skillset来的，不分前后混战的可能性不大。

我知道悉尼几个大的团队都是还在用waterfall，管理上不去是一方面，团队的规模和project的性质是另一方面。

greed

我的理解也是大项目很难整体用agile，拆成小块用用还成。敏捷的本意是把过程细化，变一个里程碑为一个个小台阶。从项目管理的角度而言，更容易控制。好比run一个很长的处理，如果有进度条一点点往前走，大家就比较耐心；如果过程中啥都不提示，大家心里就没底。即使过程中出现意外，导致进度出现问题，也能让管理者可以及时做出调整。太大的项目各种冲突就比较多，想以1，2周为单位解决所有冲突难度较大；如果周期太长，又达不到敏捷的初衷。另外敏捷强调及时交流，这对团队力量的充分利用有好处。当然一切都事在人为，革命歌曲唱走样的人也多得是，流于形式在世界每个角落都不稀奇。

[ 本帖最后由 greed 于 2011-6-22 08:57 编辑 ]

乱码

parallel programming 也是scrum重要的一方面，能有效地降低dependency，从而降低overhead。

从技术上讲coding On abstraction.

scrum划分tasks boundary的时候要用vertically slicing的策略（frontend to backend）,不要用horizental的方式。

grouping策略也应该分成若干功能相对完整的team，才能支持高并发的开发环境。

flyspirit

乱码兄， 你们用一周的sprint， 结束后deliver什么？整个项目周期是多长？

kr2000

太牛了

怎么样做vertically的划分任务，能具体点吗？

原帖由 乱码 于 2011-6-22 09:59 发表
parallel programming 也是scrum重要的一方面，能有效地降低dependency，从而降低overhead。

从技术上讲coding On abstraction.

scrum划分tasks boundary的时候要用vertically slicing的策略（frontend to backend）,不要 ...

乱码

原帖由 flyspirit 于 2011-6-22 10:34 发表
乱码兄， 你们用一周的sprint， 结束后deliver什么？整个项目周期是多长？

@flysprit, 我们sprint倒数第二天上午pm/BA作acceptance test,反馈回来做bug fixing.

其实我们几乎每个block的logic都有unit test, page level有functional test, 这个acceptance test只是把functional test整合一下而已。

真正的bug并不多.

最后一天上午给management作demo，下午作下个sprint的scrum meeting,还是比较紧张的。

现在这个project dealline还没定下来，pm那边说marketing那边也不是很清楚，应该还有4/5的工作要做。

针对scrum的周期，developer不用管太多，只要做好当前这个sprint的东西就好，有人会不断feed backlog queue的。

乱码

原帖由 kr2000 于 2011-6-22 10:38 发表
太牛了

怎么样做vertically的划分任务，能具体点吗？

vertically slicing的目的是deliver一个功能相对独立的unit，理想状态下，它没有任何的dependency，整个team能fully engage,从front end到back end.

这种划分使得从开发角度不用pend任何东西，fully control自己的进度，从而可以若干个team同时并发开发，从而降低overhead.

team的划分也要根据这种原则来做，它要求team member技术全面，而不是某一个领域的专家但对另一个领域一窍不通，这样就可以从pool里面按delivery order来做sprint.

据我所知，很多大公司dev team都是按功能划分（水平划分），比如backend/frontend team,team member skillset相同，很难完成vertically slicing task划分的要求，所以他们做project必须用waterfall，不可能作agile,pending不可避免。

完全脱离dependency有时候也是不可避免的，比如很多framework/infrustrature的东西,这就要看management的水平了。

linkspeed

这种项目管理方式蛮好，啥时候招人请说一声。

乱码

原帖由 linkspeed 于 2011-6-22 12:50 发表
这种项目管理方式蛮好，啥时候招人请说一声。

no prob!!

linkspeed

多谢多谢。

ilchocolate

我是外行,请问bug fixing 是谁编程的bug就谁负责修改吗?