请教怎么为上班做准备，tax方向 - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Accounting - 会计审计

请教怎么为上班做准备，tax方向

请教怎么为上班做准备，tax方向# Accounting - 会计审计

n*s2011-12-20 08:12

1 楼

可能是个老问题了不知道有没有过来人和我情况相似
PhD最后一学期，大概4月初毕业，正在找工作。学术界和工业界的都找了，还没有
确定的消息。我导师许诺让我留在lab做临时postdoc，直到找到ideal的position就走
。导师还说如果到六月份还找不到工作的话就帮我办H1B转成带正式的postdoc，条
件是要确定留下来至少工作一年。
这样的话是不是我现在需要马上申请OPT了，把OPT开始时间定在四月份毕业那会？
另外一旦拿到H1B的话 OPT就废掉了对吧？
谢谢！

t*r2011-12-20 08:12

2 楼

偶五分钟前刚刚收到一个。这是新政策吗？还是只在多伦多美国领管有效？
H1B，目前在美，5月3日在多伦多美领馆作H1B visa renewal的签证。五分钟前
收到领馆的电话，说我的签证申请有可能有延迟 for days or
weeks. 再问是否因我的个人情况导致这个电话通知，那人说不知道，领馆只给了一
个名单让他逐个电话通知。
看看旧贴，发现网友totoro2010已经收到一个了。

c*a2011-12-20 08:12

3 楼

第一次打的，大概有15mil的距离，不知道价格是如何算的。是事先说好还是打表的呢？
另外需要给司机小费吗？给多少比较合适？
谢谢

h*s2011-12-20 08:12

4 楼

关于校园欺凌，到现在没有停息过，
到处都是校园欺凌，这个社会是怎么了？到底是哪里的错？又该怎么做？
这只是个玩笑啊
这是孩子之间的事情
他们还小不懂事。
...
……
呸，我不信，特么就是娇生惯养。
这些欺凌事件除了孩子本身性格之外，还和以下三点有关系：家庭、教育、和社会。
1.家庭
孩子的第一任老师，便是家长。
所以给孩子树立一个好的榜样，是对孩子教育的最大成功。
邻居街房间，一直有这种话，“从小瞧大”。
现在，独生子女太多，大多都是掌上明珠。
幼儿园里，中午，一个小孩子甲不小心把另一个小孩子乙碰倒了。家长第二天便去幼儿
园闹事，可能导致双方家长打起架，甚至上升到法院的地步。
孩子之间的事情，幼儿园老师完全可以调和得了的事情，可能会上升到大人的吵架，打
架，甚至打官司。
这是个真实的故事，这里便说明了一个家庭观念教育的问题。
家长为此打动肝火。闹得沸沸扬扬，双方都不愉快。孩子甲可能会认为，他这样无理是
正确的，不经意间会助长他内心的这种想法。孩子乙也会认为，有家长在可以肆无忌惮
，不经意间小孩子的心理多会萌生出欺凌的想法。
这确实是孩子之间的事情，只是爱过了火。
为什么不了解一下情况，合理的引导一下？
2.教育的问题
这也是个教育的问题。
一个关乎学生尊严，祖国未来的事件，被学校定义为玩笑！
学校能再搞笑一点嘛？书上说的人人平等哪去了？
不能一味地说是玩笑，也不能只是道歉了就可以了。每个人都是平等的。
可是到处可见，有的孩子有豪车接送，大把的零花钱用，花点钱买作业答案，以为钱权
可以摆平一切。自负不然而然地便跑了出来。
而我只能有在破烂的自行车上看，哆嗦着，每天考虑着不够用的零花钱！我该怎么面对
同学们？自卑便会悄无声息的滋生出来。
教育，不单单是关心孩子的分数，多关心关心的身心发展。不能一味地用书本文化，来
教习知识，多开展一些活动，当然这跟一个好的教师也是分不开的。
出了过分的欺凌乱象，作为教师不可能不知道，也不可能没听过一点点消息。
无非就是有两种可能，他们不想管，他们只想做一个教书人；或者他们想管又不敢管，
一个个背后的势力足以让他们丢了工作，所以选择不闻不问。
3.社会
发展迅猛的社会，得益于好的政策。
可是，我的家里房屋漏水了，妈妈还没找人来修，爸爸也忙着工作，去学校还得小心翼
翼的数着零花钱，功课也不是很优秀，也不会老师眼里的好孩子。
哎，我的卧室又换了装潢，可爱的粉红色，过几天再换什么颜色呢？妈妈忙着工作，爸
爸忙着工作，天天去学校装着大把大把的零花钱，功课花点钱就可以OK了。
有钱忙，没钱忙，每个人都忙，孩子的教育却落了一大截，他们是每天读着书，考着试。
学校里发生了什么，他们身上发生了什么，有几件是跟你们大人亲口说的？
这个我觉得可以归于社会问题，家长应该学会合理处理好社会工作和家庭之间的关系。
总结，
我想对受欺凌的人说，不是我看不起你，是你把自己放得太低，低到了尘埃里。
关于我
我很幸运，有个会打我的爸爸和批评我的妈妈。
屁股一撅起来，就会挨板子，走路没正形也会挨板子，写字不公正都会挨批斗。
妈妈是个很要强的农村人，从小，便给我灌输
“人不欺我，我不欺人”、“别人敢打你一拳，你要回敬打他一拳，他进医院妈掏钱”
的粗俗道理。
现在，我还任性的活着，写作着，愤世恶俗着……

l*92011-12-20 08:12

5 楼

geek 直接和用户联系，
用户提出模糊要求
{loop
geek provides quick solution
用户即时test并提出改进要求
}
核心精神：reduce development overhead
1。不花大量精力于coding前做documentation
2。减少文山会海
3。 short delivery cycle
实际运作上，agile都成了外行PM的更多米饭，programmer 陷于文山会海，估点数，报
进度，增加了development overhead
中国古话说：经再好，也怕歪嘴和尚。Agile就是被歪嘴和尚（外行PM）给念歪的。根
子是公司高层都是狗屁不懂的MBA，他们相信，有了matrix,傻瓜也会coding

x*02011-12-20 08:12

6 楼

期末考完后，其实已经休息得差不多了。觉得还是做点准备心理比较踏实。
我想到的是，练习口语，还有就是穿着打扮方面，得买些适合办公室的衣服。
特来请教前辈们，还可以做哪些准备？应该注意些什么？谢谢！

a*n2011-12-20 08:12

7 楼

可以开始申请了，定在你毕业后一天
不知道，反正你要申请OPT也要去问ISSO,直接问他们就知道了

【在 n******s 的大作中提到】

: 可能是个老问题了不知道有没有过来人和我情况相似
: PhD最后一学期，大概4月初毕业，正在找工作。学术界和工业界的都找了，还没有
: 确定的消息。我导师许诺让我留在lab做临时postdoc，直到找到ideal的position就走
: 。导师还说如果到六月份还找不到工作的话就帮我办H1B转成带正式的postdoc，条
: 件是要确定留下来至少工作一年。
: 这样的话是不是我现在需要马上申请OPT了，把OPT开始时间定在四月份毕业那会？
: 另外一旦拿到H1B的话 OPT就废掉了对吧？
: 谢谢！

t*02011-12-20 08:12

8 楼

我也想知道。。
好奇问问termengineer：你现在是什么类型的visa,专业是什么？我是人文领域的，不
是什么敏感专业。收到那电话很纳闷。。。

N*r2011-12-20 08:12

9 楼

一般打电话预约的是事先说好，招手的话是打表。
小费看着给。一般10% - 15%，也有多给的。

g*e2011-12-20 08:12

10 楼

哈哈，有那么点意思。最近一段时间我每周20+ hr的meeting，活一点不少，觉得真tmd累

【在 l*****9 的大作中提到】

: geek 直接和用户联系，
: 用户提出模糊要求
: {loop
: geek provides quick solution
: 用户即时test并提出改进要求
: }
: 核心精神：reduce development overhead
: 1。不花大量精力于coding前做documentation
: 2。减少文山会海
: 3。 short delivery cycle

s*12011-12-20 08:12

11 楼

同问

【在 x*******0 的大作中提到】

: 期末考完后，其实已经休息得差不多了。觉得还是做点准备心理比较踏实。
: 我想到的是，练习口语，还有就是穿着打扮方面，得买些适合办公室的衣服。
: 特来请教前辈们，还可以做哪些准备？应该注意些什么？谢谢！

n*s2011-12-20 08:12

12 楼

哦明天就去哈
3x

【在 a*****n 的大作中提到】

:
: 可以开始申请了，定在你毕业后一天
: 不知道，反正你要申请OPT也要去问ISSO,直接问他们就知道了

t*r2011-12-20 08:12

13 楼

check your mailbox, pls. thanks.

n*t2011-12-20 08:12

14 楼

"geek 直接和用户联系，" then what is the use of manager?

【在 l*****9 的大作中提到】

t*f2011-12-20 08:12

15 楼

Firm的着装如果是business casual的要求，很多ann Taylor or banana republic的衣
服都合适。上身sweater or 衬衫, 下身西裤或及膝短裙, 皮鞋要不露脚趾的。款式简
单大方。
其他准备也没什么，一边做一边学很就好了。如过excel掌握熟练的话，是很有帮助的.
很多work paper 都是用excel做的。

a*n2011-12-20 08:12

16 楼

明天不上班吧，公众假期

【在 n******s 的大作中提到】

: 哦明天就去哈
: 3x

b*s2011-12-20 08:12

17 楼

agile的本质是，假定大家都会犯错
所以不信任任何大包大揽的设计和工程方式
削弱pm是肯定的，但是不意味着就取消相关职能
不过开很多会，肯定是哪里出问题了

【在 l*****9 的大作中提到】

r*y2011-12-20 08:12

18 楼

话说我就以实习为借口买了好几身衬衣.....

n*s2011-12-20 08:12

19 楼

哦是哈

【在 a*****n 的大作中提到】

: 明天不上班吧，公众假期

z*e2011-12-20 08:12

20 楼

控制在15分钟以内结束，我没有任何意见

【在 b*******s 的大作中提到】

: agile的本质是，假定大家都会犯错
: 所以不信任任何大包大揽的设计和工程方式
: 削弱pm是肯定的，但是不意味着就取消相关职能
: 不过开很多会，肯定是哪里出问题了

r*y2011-12-20 08:12

21 楼

话说我就以实习为借口买了好几身衬衣.....

o*e2011-12-20 08:12

22 楼

办OPT；
用OPT（F1）的身份让你老板雇你为postdoc（让老板pay你钱）。
你老板不准备pay你钱（不准备在你OPT时hire你）的话，不必做什么“临时postdoc”。
这时候即便办了OPT，你也一样是“失业”状态，90天内你若找不工作就进入“grace
period”而可能要不得不离开美国。这种情况下，不妨让OPT开始得稍晚一点儿。
你老板若肯在你OPT一生效时就hire你为postdoc（并且也愿随时放你走的话），那就
不妨让OPT紧接你被授予学位（5月？）后开始。

【在 n******s 的大作中提到】

s*o2011-12-20 08:12

23 楼

说得不错。不过更理想的情况是由"geek manager"和用户联系。如果直接让geek
programmer跟用户打交道，危害有可能比外行PM还要严重

【在 l*****9 的大作中提到】

l*y2011-12-20 08:12

24 楼

All I have and wear is sweater and suit pants no matter whether it is summer
or winter. I have a lot of sweaters. It is comfortable and pretty.
haha

【在 x*******0 的大作中提到】

c*d2011-12-20 08:12

25 楼

grace period 是在opt前还是之后啊？

w*z2011-12-20 08:12

26 楼

我觉得 Agile 的精髓就是 small task, short cycle, 随时根据客户反馈，修改。

【在 l*****9 的大作中提到】

x*02011-12-20 08:12

27 楼

谢谢！看样子sweater和西裤是必备了。
能讲讲Excel除了基本的function，哪些比如什么Vlookup，PriovtTable，用得比较多
呢？

的.

【在 t******f 的大作中提到】

: Firm的着装如果是business casual的要求，很多ann Taylor or banana republic的衣
: 服都合适。上身sweater or 衬衫, 下身西裤或及膝短裙, 皮鞋要不露脚趾的。款式简
: 单大方。
: 其他准备也没什么，一边做一边学很就好了。如过excel掌握熟练的话，是很有帮助的.
: 很多work paper 都是用excel做的。

i*t2011-12-20 08:12

28 楼

小心老板人品,当初说毕业后给postdoc直到找到出路,当时小米都在场,结果后来老板压
根不提了,白费早申请opt了

b*n2011-12-20 08:12

29 楼

short cycle碰到傻逼coder就是埋炸弹。用户测不全，以后就是在生产环境中核弹。
比如一个coder手挺快，出活利索，manager挺喜欢。终于由此染指他的code了，原来全
tmd的都是即时贴。
比如
foo1（string s){
foo2 (s, true);
}
foo2(sting s, boolean t){ //核心实现部分
...
}
由于某bug，需要对s做处理后，在做实际工作，结果补丁直接打到foo1处，完全不管
foo2是否被别的调用，和以后是否被别的code调用。
这种情况到处都是，基本少就是bug出来顺着看，第一处能fix的就改那里就完了。
cycle真是短，可是天天bug真不少。可manager看起来觉得就是又能出活，又能改bug。
咱这种，提交版本后基本没啥事的，看起来就是出货慢，还不会修bug。
需求看的不够远，天天折腾。

【在 w**z 的大作中提到】

: 我觉得 Agile 的精髓就是 small task, short cycle, 随时根据客户反馈，修改。

t*f2011-12-20 08:12

30 楼

这两样会一点儿就成，用的不多。主要还是些基本的function，比如sumif还有format
的功能要比较熟悉。

【在 x*******0 的大作中提到】

: 谢谢！看样子sweater和西裤是必备了。
: 能讲讲Excel除了基本的function，哪些比如什么Vlookup，PriovtTable，用得比较多
: 呢？
:
: 的.

w*z2011-12-20 08:12

31 楼

short cycle 不是说把测试环节省了，该测的还要测。是把 feature 分小，短时间
完成，有问题马上该。

【在 b*******n 的大作中提到】

: short cycle碰到傻逼coder就是埋炸弹。用户测不全，以后就是在生产环境中核弹。
: 比如一个coder手挺快，出活利索，manager挺喜欢。终于由此染指他的code了，原来全
: tmd的都是即时贴。
: 比如
: foo1（string s){
: : foo2 (s, true);
: }
: foo2(sting s, boolean t){ //核心实现部分
: ...

x*02011-12-20 08:12

32 楼

谢谢回复！
今天开始去旅游了，回来还有几天做准备工作。

format

【在 t******f 的大作中提到】

: 这两样会一点儿就成，用的不多。主要还是些基本的function，比如sumif还有format
: 的功能要比较熟悉。

b*s2011-12-20 08:12

33 楼

所以agile要需求非常清晰才行
不过好处是错了，改起来也很快
你这个同事在传统方法里，可能更危险

【在 b*******n 的大作中提到】

N*K2011-12-20 08:12

34 楼

geek这个词很不明确
按照中国人的观点要能文能武谦虚谨慎面对客户不是装13 也不是自贱而是合作
另外这个agile 是否可以用来设计iphone？你面对的是无穷多客户

【在 l*****9 的大作中提到】

N*K2011-12-20 08:12

35 楼

奖金= 100-a*(时间-标准时间)-b*(bug数量-标准bug数量)*用于修复bug的平均时间
调节 a和b 这个傻逼coder就没有立足之地了
这个标准时间和标准数量根据公司最好的几个能手来定这样高手￥100 傻逼为￥0

【在 b*******n 的大作中提到】

r*y2011-12-20 08:12

36 楼

见过几次核弹的, 同意你这个

【在 b*******n 的大作中提到】

l*s2011-12-20 08:12

37 楼

you don't have code review?

【在 b*******n 的大作中提到】

r*y2011-12-20 08:12

38 楼

code reviewing targets code logic, instead of business logic
some nuke is in business logic

【在 l*********s 的大作中提到】

: you don't have code review?

r*y2011-12-20 08:12

39 楼

-- "无穷多客户"
这个倒不是问题, jetbrains 的产品现在都是 agile 出来的. 但自从它们 agile 了以
后, bugs 也越来越多, 非常 annoying .
以前老汉还时不时用用它们的 EAP 给它们提交个bug, 现在出了 EAP 直接 ignore .

【在 N******K 的大作中提到】

: geek这个词很不明确
: 按照中国人的观点要能文能武谦虚谨慎面对客户不是装13 也不是自贱而是合作
: 另外这个agile 是否可以用来设计iphone？你面对的是无穷多客户

l*92011-12-20 08:12

40 楼

Mordulization
small function, code sharing
readability/maintainability/scalability
没有 business logic 一定要 nuke implementation

【在 r***y 的大作中提到】

: code reviewing targets code logic, instead of business logic
: some nuke is in business logic

l*92011-12-20 08:12

41 楼

exactly
Agile is to empower 能力强的 IT developer
Business users 和 IT developers 之外，都是 IT developers' 服务员

【在 w**z 的大作中提到】

: 我觉得 Agile 的精髓就是 small task, short cycle, 随时根据客户反馈，修改。

M*z2011-12-20 08:12

42 楼

agile也有它的适用范围和环境。反正不管什么方法论，都不能教条地使用。最怕那种
拜神教，任何适合都拿出一本金科玉律，朗朗上口，其实根本没搞明白里面精髓是什么
意思，如何在实践中应用。

S*s2011-12-20 08:12

43 楼

你说这人聪明，还是弄个非常stable/generic/flexible的系统出来，最后让所有程序
员包括自己都失业的程序员聪明？
蓝玉牛还是李成梁牛？

【在 b*******n 的大作中提到】

l*92011-12-20 08:12

44 楼

are you a programmer?

【在 S*******s 的大作中提到】

: 你说这人聪明，还是弄个非常stable/generic/flexible的系统出来，最后让所有程序
: 员包括自己都失业的程序员聪明？
: 蓝玉牛还是李成梁牛？

S*s2011-12-20 08:12

45 楼

does it matter?

【在 l*****9 的大作中提到】

: are you a programmer?

l*92011-12-20 08:12

46 楼

of course

【在 S*******s 的大作中提到】

: does it matter?

S*s2011-12-20 08:12

47 楼

unwarranted

【在 l*****9 的大作中提到】

: of course

N*n2011-12-20 08:12

48 楼

Code review is somewhat overrated. If you cannot review your own
code to make sure it's bug-free then it's less likely you can review
someone else' code to spot the bugs.

【在 l*********s 的大作中提到】

: you don't have code review?

l*92011-12-20 08:12

49 楼

Code review is necessary to weed out nuke programmers

【在 N********n 的大作中提到】

:
: Code review is somewhat overrated. If you cannot review your own
: code to make sure it's bug-free then it's less likely you can review
: someone else' code to spot the bugs.

t*h2011-12-20 08:12

50 楼

这话说到点子上了。很多公司项目失败的原因是一些SB高层问具体情况硬上Agile，听
人家说好就当成Silver Bullet，执行起来完全不是那么回事。很多老外就一根筋，没
有中国人具体问题具体分析的精神。

【在 M****z 的大作中提到】

: agile也有它的适用范围和环境。反正不管什么方法论，都不能教条地使用。最怕那种
: 拜神教，任何适合都拿出一本金科玉律，朗朗上口，其实根本没搞明白里面精髓是什么
: 意思，如何在实践中应用。

M*z2011-12-20 08:12

51 楼

其实各方面都会存在这样的人，不过非技术人员概率更大，因为他们不是工具的直接使
用者。
这篇文章我觉得靠谱，希望有帮助：
Why Agile Is So Hard
http://www.uxmatters.com/mt/archives/2013/08/why-agile-is-so-ha
Is agile a dirty word in your company or among the members of your UX team?
Do you hear the term lean UX and groan? It’s okay—and not really
surprising—if your answer is yes. Agile is hard, and we all know it. But
since agile is likely to stick around for a while, I’m sure you’ve thought
about how to make it easier.
However, the question shouldn’t be how to make it easy; rather, it should
be about understanding why agile is so hard in the first place. That way, we
can get at the root problems and maybe have some hope of turning what can
be a frustrating experience into an amazing one.
By nature, designers are well-organized and linear people. Logical flow is
something we can grasp easily. We work well within structure. We are
perfectionists and want all the I’s dotted and theT’s crossed. We thrive
on recognition and success. But being agile or lean goes against these
tendencies and forces us to step into an uncomfortable zone.
There are three aspects to this discomfort that I think majorly impact our
experience of the agile philosophy and methodology that I think are worth
considering:
We deceive ourselves that being agile means you don’t need a vision.
We don’t understand the pace that an iterative process requires.
We don’t allow enough space for experimentation and failing within a safe
environment.
Stop Deceiving Yourself
The biggest problem that I see again and again with agile teams is their
thinking that you can dive into sprints and figure out what you’re doing as
you go along. Vision is a major premise of the agile methodology. But we
often forget that there is more to the work than the day-to-day grind.
It doesn’t matter how big or small your project is, you need to set a
vision for it beforehand and make sure that someone is responsible for
keeping an eye on that target throughout the process. Understand the end
goal and define small, incremental blocks of work that will enable you to
achieve it. Measure success by increments.
And the most important part—given that agile is an iterative process—is
that you continually need to do ongoing work to maintain the current state
of the vision. These statements may seem contradictory, but if you set the
vision and forget it, there wasn’t really a point to your defining a vision
in the first place. Things morph during the process, and ultimately, being
agile is about being responsive. It’s okay for your vision to evolve, but
it’s not okay to start without a clear vision to begin with.
Don’t let yourself get caught up in the chaos of iterating yourself into an
incoherent whole. Find the balance between your ultimate vision and the
natural progression of iterative processes.
The Truth About Iteration
We call the iterations of work that we do when following the agile
methodology sprints, but many times I think that we forget the true meaning
of the word—and that causes a breakdown in the process. For iterative
processes to work well, there is a certain pace and rhythm that you have to
maintain as a constant. When iterations constitute a broken, choppy cycle,
we fall down, lose momentum, and get stuck in the weeds. To be successful,
iterative processes need to remember these key factors:
Iteration must happen quickly—without too much time to think in between
sprints. If it doesn’t, you risk losing focus, forgetting the valuable
insights that you need to address, and missing out on experimenting with
ideas that occur in the moment. In essence, you’ll spin and lose time.
Iterative loops must be small enough to be digestible. If they are too large
, you risk slowing the pace—or in some cases, overwhelming people with too
much at once and allowing things to slip through the cracks.
Feedback needs to be constant. It is almost impossible to execute an
iteration that actually moves you forward without getting feedback. Lapses
in your feedback loop hurt your ability to make meaningful moves in a
positive direction.
If you are feeling a little scared after reading these key factors, I don’t
blame you. Rapid iteration is a rigorous exercise. I won’t lie about that.
It takes effort to maintain the pace that will make you most successful.
It’s not surprising then that many teams find iterative processes so hard
in comparison to the more traditional waterfall process. But you don’t have
to kill yourself to make this work. Remember to give yourself breathing
room. Plan time to check in on the big picture. Plan empty or catch-up
sprints into the process if you need to. What is key is to work in the
breathing roomaround the iterations, not in their midst when it might upset
the pace.
Why Failing Doesn’t Always Mean You’ve Failed
One of the biggest advantages of an agile process is the one thing that
usually gets left by the wayside: the fact that quick, iterative changes
should allow us room for experimentation, which means failing with some
ideas. The whole idea behind iteration is that you should test ideas as
quickly as possible, find out which work, keep and refine those that do, and
drop the rest.
Unfortunately, human nature often doesn’t want to test imperfect ideas—
never mind admit that we had unsuccessful ideas to begin with. And at times,
it’s difficult to accept the reality that we must let some ideas go
because they don’t fit the vision, especially when we think they’re the
most brilliant ideas in the world.
We also put a lot of negative energy around failing that doesn’t need to be
there. We don’t need to hold on to ideas that don’t work. And just
because every idea doesn’t work, doesn’t mean you’ve failed in any way
shape or form. If you find the one idea that is right through a process of
testing and respond by making iterative improvements, you’ve succeeded.
And remember that ideas don’t need to be perfected before you can get
feedback on them. That’s why we, as UX professionals, sketch and paper-
prototype our initial concepts. It’s not worth making the investment in
pixel perfection until you know something is the right idea.
If you need to feel good about your failed ideas—or maybe are feeling
pressure to explain why you tried them—figure out the story of how those
ideas led to the right idea. What did you learn from those failures that led
you to success? Because, if you are doing feedback and iteration right, I’
ll bet you can’t tell that success story without telling about the failures.
The Original Agile Methodology: Improv
There’s a fantastic TV show that just came back on the air called “Whose
Line Is It Anyway?” In one of the new episodes, there was a prime example
of why improv is the original agile methodology. Let me explain.
In the episode, the performers were playing a game that was something like
“things you can say about your favorite pair of shoes, but not your
girlfriend.” One of the performers starts to do a bit and quickly goes down
a very dirty and unintended path. He stops, they all laugh, and move on.
The next bit the performer did played on the gaff, but by the third round,
he had moved on.
This seems simple, but clearly articulates why improv is akin to agile. He
tried something, it didn’t work, he acknowledged it, then tried again. The
whole point of the exercise was iterative attempts at coming up with ideas.
The ideas didn’t have to succeed, but they still led to some good outcomes.
They didn’t agonize over thinking through the ideas that they should try.
They maintained a quick pace. Essentially, they got it all right, even when
they got it wrong.
Chris Spagnuolo wrote an excellent article in which he talks about key
principles of improv that drive innovation. They fit very well into the
conversation on agile and can also help us to learn how to be successfully
agile.
Keep questioning what works. Agile methods do ultimately allow us to attain
our perfectionist desires. But they require us to learn that we’ll get
there in increments, not in one shot. It’s constantly a question of how you
can make things better in the next iteration.
Be a risk taker and take chances. There is no reward without any risk. Rapid
iteration lets us take bigger chances because we can play with ideas before
committing to them. We can be more innovative if we allow ourselves this
play.
Always be open to making changes in response to what people say and to what
happens.Being improvisational means learning how to be a good listener and
adjust to the current circumstances. Always being open to new information
consistently enables us to understand how to proceed and adapt to the
iteration process.
Create shared plans and agendas. Having a clear vision and goals is critical
. But if they aren’t shared and understood by all involved, they have no
meaning. Agile requires a lot more conversation and a lot less documentation.
Be fully present and engaged. You can’t be truly agile, move with the
process, and keep your momentum if you aren’t always there and engaged. You
let your team down the moment you step out.
Keep moving forward. Maintain the pace, maintain the pace, and maintain the
pace. Looking backward will not get you any further forward. Agile is not a
case in which objects in your rear-view mirror are larger than they appear.
Focus on the good of the whole. It is important to understand that the
strength of the ensemble, or team, makes or breaks an improv or agile
experience. Always make sure that you support what is good for the whole
team and know what is in everyone’s best interest. That way, you all
succeed.
Let yourself lose control. Learn how to let go and work with your team.
Collaboration keeps the process sane. One person trying to run the show
breaks down the cycle.
Self-organize. Understanding your role in the group and how to manage
yourself makes you a better team player. Being a successful collaborator
requires that you hone your interpersonal and intrapersonal skills.
The Real Truth
So, why is agile so hard? I think it’s because agile requires us to learn
how to become a better version of ourselves than we perhaps have been in the
past. It requires a strong ensemble that can work together. It also
requires a rigorous pace and our constant attention.
This shouldn’t scare us off, though. We’re all capable of honing our
improvisational skills. The basic fundamentals of improv are those that
actually play on human nature—such as the initial characteristics that I
mentioned earlier. And maybe, by understanding the challenges that agile
presents and working through them, we can make agile a little less difficult.
Reference
Spagnuolo, Chris. “Is Improv the Key to Innovative Teams?” DZone, January
3, 2013. Retrieved August 01, 2013.

【在 t*******h 的大作中提到】

: 这话说到点子上了。很多公司项目失败的原因是一些SB高层问具体情况硬上Agile，听
: 人家说好就当成Silver Bullet，执行起来完全不是那么回事。很多老外就一根筋，没
: 有中国人具体问题具体分析的精神。

k*g2011-12-20 08:12

52 楼

This is what I would have done in the first year of GUI development. (I no
longer with with GUI.)
An agile coach told me that QA would have the responsibility to catch this
kind of bugs.

【在 b*******n 的大作中提到】

l*92011-12-20 08:12

53 楼

这个作者不是techie
Agile is not hard with good IT developers running the show and all crap out
of way.

team?
thought

【在 M****z 的大作中提到】

: 其实各方面都会存在这样的人，不过非技术人员概率更大，因为他们不是工具的直接使
: 用者。
: 这篇文章我觉得靠谱，希望有帮助：
: Why Agile Is So Hard
: http://www.uxmatters.com/mt/archives/2013/08/why-agile-is-so-ha
: Is agile a dirty word in your company or among the members of your UX team?
: Do you hear the term lean UX and groan? It’s okay—and not really
: surprising—if your answer is yes. Agile is hard, and we all know it. But
: since agile is likely to stick around for a while, I’m sure you’ve thought
: about how to make it easier.

M*z2011-12-20 08:12

54 楼

如果是以某个产品为目标团队合作的话，这就陷入另一个陷阱了。现在确实是个多数
hacker内心膨胀的年代。呵呵。大多数人都逃不过这些。
不过我觉得product + development双料的明星确实可以有这样的水准，但首先，绝大
多数人只能满足其中一个条件或是同时满足两个条件中的一部分。这样，绝大多数人最
后还是需要作为团队一份子完成目标。其次，真正的双料明星还需要care别人说怎么做
吗？理论最多给他们一些参考，他们一定是按自己的方式实践的。as long as he/she
delivers
当然大多数人在一个本行业膨胀的年代会误以为自己已经是双料明星了。
我只关心什么能解决问题，更好地解决问题。其他的无所谓了。

out

【在 l*****9 的大作中提到】

: 这个作者不是techie
: Agile is not hard with good IT developers running the show and all crap out
: of way.
:
: team?
: thought

g*g2011-12-20 08:12

55 楼

I wouldn't count on QA for this. But the unit tests should catch it.

【在 k**********g 的大作中提到】

:
: This is what I would have done in the first year of GUI development. (I no
: longer with with GUI.)
: An agile coach told me that QA would have the responsibility to catch this
: kind of bugs.

b*n2011-12-20 08:12

56 楼

不是说同事不对，不过manager天天早上开会scrum。
你要不说你改了点啥，code committed了，还在说在研究代码，testing，立马就不理
你了。逼的大家都在不停地check in。
mb的，一天能check in 10次的绝逼都是问题大把的。除了改bug，我这种一天check in
次数平均都不上1，虽然一次check in都是10个以上文件。
永远是喜欢出活的manager比喜欢不出bug的manager多。

【在 b*******s 的大作中提到】

: 所以agile要需求非常清晰才行
: 不过好处是错了，改起来也很快
: 你这个同事在传统方法里，可能更危险

b*n2011-12-20 08:12

57 楼

code review是渣，人会疲劳，到时什么都看不出来，
跟别说，你把a=0，然后b=a, c=b,。。。z=y 最后，foo/z这种绝逼没人看出毛病来。
code review 这种最多查查代码规范罢了，边界/临界值几乎查不到。

【在 l*********s 的大作中提到】

: you don't have code review?

b*s2011-12-20 08:12

58 楼

你们这scrum怎么问题能扩展？不是一般就三问题吗？三问题的不容易出这种妖蛾子吧

in

【在 b*******n 的大作中提到】

: 不是说同事不对，不过manager天天早上开会scrum。
: 你要不说你改了点啥，code committed了，还在说在研究代码，testing，立马就不理
: 你了。逼的大家都在不停地check in。
: mb的，一天能check in 10次的绝逼都是问题大把的。除了改bug，我这种一天check in
: 次数平均都不上1，虽然一次check in都是10个以上文件。
: 永远是喜欢出活的manager比喜欢不出bug的manager多。

b*n2011-12-20 08:12

59 楼

foo2以后再其他代码被调用怎么测。
agile这玩意就是假设别人都跟他一样nb，一样通晓几乎所有的代码，一样的代码质量
，一样的风格。
事实上几乎是不存在的，除了自己一个轮轮子的。

【在 w**z 的大作中提到】

: short cycle 不是说把测试环节省了，该测的还要测。是把 feature 分小，短时间
: 完成，有问题马上该。

b*s2011-12-20 08:12

60 楼

我觉得你对agile理解是不对的

【在 b*******n 的大作中提到】

: foo2以后再其他代码被调用怎么测。
: agile这玩意就是假设别人都跟他一样nb，一样通晓几乎所有的代码，一样的代码质量
: ，一样的风格。
: 事实上几乎是不存在的，除了自己一个轮轮子的。

N*K2011-12-20 08:12

61 楼

NaN 和 Inf 你们不用？

【在 b*******n 的大作中提到】

: code review是渣，人会疲劳，到时什么都看不出来，
: 跟别说，你把a=0，然后b=a, c=b,。。。z=y 最后，foo/z这种绝逼没人看出毛病来。
: code review 这种最多查查代码规范罢了，边界/临界值几乎查不到。

b*n2011-12-20 08:12

62 楼

卡，举个例子罢了。
这里的0不过是某个可能中间结果，可能来自db的null，可能是文本中的“”，也可能
是某个中间计算结果。
没经验或有经验没agile逼的没时间考虑的这种错误很容易犯，这种问题靠用户测，靠
QA？都不靠谱，
用户可能给的文件永远都不会有“”，不过他离开的时候他儿子上去胡搞说不定就搞个
“”出来。
然后上k个文件在一个batch里过来处理，不考虑这种东西，突然爆掉，万一后面还有几
百个文件，最后结果直接就飞了。

【在 N******K 的大作中提到】

: NaN 和 Inf 你们不用？

t*h2011-12-20 08:12

63 楼

Architect在Agile里的作用有什么变化吗？

r*y2011-12-20 08:12

64 楼

code review 只是个 practice, 是个经而已, 还是歪嘴和尚念坏了
我以前做 CMMI 的项目的时候 code review , 都是至少 3+ reviewers 花半天以上的
时间review 某个功能的代码...
后来的 scrum team , 就是他妈的走过场, mgr 要求快速 review , 就是不能耽误你这
一天出活, 这样的歪嘴和尚, 码工要不糊弄怎么活?
记得有个mgr 曾经超级二B的隔段时间统计每个码工的 commits , 虽然是半认真的, 也
让人不爽. 造成team里有sb青年每个文件一个commit, 改几行就commit...

【在 b*******n 的大作中提到】

m*l2011-12-20 08:12

65 楼

哈哈,用脚本自动commit会不会被人打死? 随便加几个空行啥的

【在 r***y 的大作中提到】

: code review 只是个 practice, 是个经而已, 还是歪嘴和尚念坏了
: 我以前做 CMMI 的项目的时候 code review , 都是至少 3+ reviewers 花半天以上的
: 时间review 某个功能的代码...
: 后来的 scrum team , 就是他妈的走过场, mgr 要求快速 review , 就是不能耽误你这
: 一天出活, 这样的歪嘴和尚, 码工要不糊弄怎么活?
: 记得有个mgr 曾经超级二B的隔段时间统计每个码工的 commits , 虽然是半认真的, 也
: 让人不爽. 造成team里有sb青年每个文件一个commit, 改几行就commit...

g*g2011-12-20 08:12

66 楼

我们不做code review，一人负责一个service，谁出问题很清楚。你爱写测试
不写测试都没人管。反正老出问题就准备滚蛋吧。

【在 r***y 的大作中提到】

m*l2011-12-20 08:12

67 楼

我们一个项目两个人同时写, 对比结果,性能,差3打的滚蛋
哈哈

【在 g*****g 的大作中提到】

: 我们不做code review，一人负责一个service，谁出问题很清楚。你爱写测试
: 不写测试都没人管。反正老出问题就准备滚蛋吧。

r*y2011-12-20 08:12

68 楼

大多数项目没法分那么清楚, agile 的 cards 都在 backlog 里, 自己去 pull/assign
, 所以每个码工之间交叉很多. 出了问题就跟小时候玩的"看谁尿炕" 的游戏一样, 倒
霉的往往是最后一个抓沙子把棍弄倒的, 其实坏事都是你一把我一把才出来的...
所以 code review 防止这样的 code debt 还是有用的. agile 压力这么大, 光靠道德
约束是没用的.
code review另外的好处是相互之间熟悉你做的那一块. 避免不定哪天哪个小爷不爽了,
走人, 别人半天捡不起来的情况.

【在 g*****g 的大作中提到】

: 我们不做code review，一人负责一个service，谁出问题很清楚。你爱写测试
: 不写测试都没人管。反正老出问题就准备滚蛋吧。

g*g2011-12-20 08:12

69 楼

虽然没那么清楚，坏在谁手里一般还是能看出来的。谁都会出bug，但有多少区别明显
，干个几个月
谁是烂人很清楚。

assign
了,

【在 r***y 的大作中提到】

: 大多数项目没法分那么清楚, agile 的 cards 都在 backlog 里, 自己去 pull/assign
: , 所以每个码工之间交叉很多. 出了问题就跟小时候玩的"看谁尿炕" 的游戏一样, 倒
: 霉的往往是最后一个抓沙子把棍弄倒的, 其实坏事都是你一把我一把才出来的...
: 所以 code review 防止这样的 code debt 还是有用的. agile 压力这么大, 光靠道德
: 约束是没用的.
: code review另外的好处是相互之间熟悉你做的那一块. 避免不定哪天哪个小爷不爽了,
: 走人, 别人半天捡不起来的情况.

z*e2011-12-20 08:12

70 楼

code review最常遇到的新人的错误代码就是
for(int i=0;i...
list.remove(i);
}
这种其实用强循环直接就抛异常了

r*y2011-12-20 08:12

71 楼

是这么说. 但 code review 不是甄别烂人, 是防止好人犯错.
我们组曾有个很好的码工, 但后来老婆怀孕, 同时又闹离婚, 那哥们儿那几个月搞了很
多烂码... 然后自己走了, 去了 flag 之一. 都一年了, 现在他的名字还常被我们提起
, 当然被提起的方式大家都懂的...

【在 g*****g 的大作中提到】

: 虽然没那么清楚，坏在谁手里一般还是能看出来的。谁都会出bug，但有多少区别明显
: ，干个几个月
: 谁是烂人很清楚。
:
: assign
: 了,

g*g2011-12-20 08:12

72 楼

这个你们QA应该把关的吧。俺们QA写了一堆integration test，每个commit都会自动编
译，部署，整合测试，有showstopper一小时内就知道了。

【在 r***y 的大作中提到】

: 是这么说. 但 code review 不是甄别烂人, 是防止好人犯错.
: 我们组曾有个很好的码工, 但后来老婆怀孕, 同时又闹离婚, 那哥们儿那几个月搞了很
: 多烂码... 然后自己走了, 去了 flag 之一. 都一年了, 现在他的名字还常被我们提起
: , 当然被提起的方式大家都懂的...

r*y2011-12-20 08:12

73 楼

悲摧的就在这里
UT, IT 代码也是码工写. QA 只是在 build 后检查 jenkins 里面的 reports .
不是所有的项目都配的起 netflix 那么好的 QA team
但 agile 还是不耽误的
所以, 我觉得 agile 想跑的好, 对team 的整体要求不低, 而且要均衡.
我们这组上 agile 的时候, 人都是外面新招的, 虽然so far so good, 也不过到这个
程度... 如果是其它process转过来的, 最后
都照猫画虎就不奇怪了.
我只是抛砖引玉, 筒子们自己的team都咋agile的, 都来聊聊

【在 g*****g 的大作中提到】

: 这个你们QA应该把关的吧。俺们QA写了一堆integration test，每个commit都会自动编
: 译，部署，整合测试，有showstopper一小时内就知道了。

N*K2011-12-20 08:12

74 楼

微软还是华为？

【在 m*******l 的大作中提到】

: 我们一个项目两个人同时写, 对比结果,性能,差3打的滚蛋
: 哈哈

b*s2011-12-20 08:12

75 楼

这种人怎么招进来的

【在 z****e 的大作中提到】

: code review最常遇到的新人的错误代码就是
: for(int i=0;i: ...
: list.remove(i);
: }
: 这种其实用强循环直接就抛异常了

z*e2011-12-20 08:12

76 楼

阿三写的

【在 b*******s 的大作中提到】

: 这种人怎么招进来的

N*K2011-12-20 08:12

77 楼

这能运行下去？ java强大

【在 z****e 的大作中提到】

: code review最常遇到的新人的错误代码就是
: for(int i=0;i: ...
: list.remove(i);
: }
: 这种其实用强循环直接就抛异常了

z*e2011-12-20 08:12

78 楼

list不是thread safe的
如果你用vector就出问题了
但是vector会有性能问题
多线程并发本来就是难点
要性能自然要牺牲一点东西

【在 N******K 的大作中提到】

: 这能运行下去？ java强大

g*g2011-12-20 08:12

79 楼

这个应该会出ConcurrentModificationException，我觉得只要跑过就会出问题，
不会等到review。

【在 N******K 的大作中提到】

: 这能运行下去？ java强大