l*****9
发帖数: 9501 | 1 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 |
g**e
发帖数: 6127 | 2 哈哈，有那么点意思。最近一段时间我每周20+ hr的meeting，活一点不少，觉得真tmd累
【在 l*****9 的大作中提到】
: geek 直接和用户联系，
: 用户提出模糊要求
: {loop
: geek provides quick solution
: 用户即时test并提出改进要求
: }
: 核心精神：reduce development overhead
: 1。 不花大量精力于coding前做documentation
: 2。 减少文山会海
: 3。 short delivery cycle
|
n******t
发帖数: 4406 | 3 "geek 直接和用户联系，" then what is the use of manager?
【在 l*****9 的大作中提到】
: geek 直接和用户联系，
: 用户提出模糊要求
: {loop
: geek provides quick solution
: 用户即时test并提出改进要求
: }
: 核心精神：reduce development overhead
: 1。 不花大量精力于coding前做documentation
: 2。 减少文山会海
: 3。 short delivery cycle
|
b*******s
发帖数: 5216 | 4 agile的本质是，假定大家都会犯错
所以不信任任何大包大揽的设计和工程方式
削弱pm是肯定的，但是不意味着就取消相关职能
不过开很多会，肯定是哪里出问题了
【在 l*****9 的大作中提到】
: geek 直接和用户联系，
: 用户提出模糊要求
: {loop
: geek provides quick solution
: 用户即时test并提出改进要求
: }
: 核心精神：reduce development overhead
: 1。 不花大量精力于coding前做documentation
: 2。 减少文山会海
: 3。 short delivery cycle
|
z****e
发帖数: 54598 | 5 控制在15分钟以内结束，我没有任何意见
【在 b*******s 的大作中提到】
: agile的本质是，假定大家都会犯错
: 所以不信任任何大包大揽的设计和工程方式
: 削弱pm是肯定的，但是不意味着就取消相关职能
: 不过开很多会，肯定是哪里出问题了
|
s***o
发帖数: 2191 | 6 说得不错。不过更理想的情况是由"geek manager"和用户联系。如果直接让geek
programmer跟用户打交道，危害有可能比外行PM还要严重
【在 l*****9 的大作中提到】
: geek 直接和用户联系，
: 用户提出模糊要求
: {loop
: geek provides quick solution
: 用户即时test并提出改进要求
: }
: 核心精神：reduce development overhead
: 1。 不花大量精力于coding前做documentation
: 2。 减少文山会海
: 3。 short delivery cycle
|
w**z
发帖数: 8232 | 7 我觉得 Agile 的精髓就是 small task, short cycle, 随时根据客户反馈，修改。
【在 l*****9 的大作中提到】
: geek 直接和用户联系，
: 用户提出模糊要求
: {loop
: geek provides quick solution
: 用户即时test并提出改进要求
: }
: 核心精神：reduce development overhead
: 1。 不花大量精力于coding前做documentation
: 2。 减少文山会海
: 3。 short delivery cycle
|
b*******n
发帖数: 449 | 8 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, 随时根据客户反馈，修改。
|
w**z
发帖数: 8232 | 9 short cycle 不是说把测试环节省了， 该测的还要测。 是把 feature 分小， 短时间
完成，有问题马上该。
【在 b*******n 的大作中提到】
: short cycle碰到傻逼coder就是埋炸弹。用户测不全，以后就是在生产环境中核弹。
: 比如一个coder手挺快，出活利索，manager挺喜欢。终于由此染指他的code了，原来全
: tmd的都是即时贴。
: 比如
: foo1（string s){
: <---- 补丁放到这
: foo2 (s, true);
: }
: foo2(sting s, boolean t){ //核心实现部分
: ...
|
b*******s
发帖数: 5216 | 10 所以agile要需求非常清晰才行
不过好处是错了，改起来也很快
你这个同事在传统方法里，可能更危险
【在 b*******n 的大作中提到】
: short cycle碰到傻逼coder就是埋炸弹。用户测不全，以后就是在生产环境中核弹。
: 比如一个coder手挺快，出活利索，manager挺喜欢。终于由此染指他的code了，原来全
: tmd的都是即时贴。
: 比如
: foo1（string s){
: <---- 补丁放到这
: foo2 (s, true);
: }
: foo2(sting s, boolean t){ //核心实现部分
: ...
|
|
|
N******K
发帖数: 10202 | 11 geek这个词很不明确
按照中国人的观点 要能文能武 谦虚谨慎 面对客户 不是装13 也不是自贱 而是合作
另外 这个agile 是否可以用来设计iphone？ 你面对的是无穷多客户
【在 l*****9 的大作中提到】
: geek 直接和用户联系，
: 用户提出模糊要求
: {loop
: geek provides quick solution
: 用户即时test并提出改进要求
: }
: 核心精神：reduce development overhead
: 1。 不花大量精力于coding前做documentation
: 2。 减少文山会海
: 3。 short delivery cycle
|
N******K
发帖数: 10202 | 12 奖金= 100-a*(时间-标准时间)-b*(bug数量-标准bug数量)*用于修复bug的平均时间
调节 a和b 这个傻逼coder就没有立足之地了
这个标准时间和标准数量 根据公司最好的几个能手来定 这样高手￥100 傻逼为￥0
【在 b*******n 的大作中提到】
: short cycle碰到傻逼coder就是埋炸弹。用户测不全，以后就是在生产环境中核弹。
: 比如一个coder手挺快，出活利索，manager挺喜欢。终于由此染指他的code了，原来全
: tmd的都是即时贴。
: 比如
: foo1（string s){
: <---- 补丁放到这
: foo2 (s, true);
: }
: foo2(sting s, boolean t){ //核心实现部分
: ...
|
r***y
发帖数: 4379 | 13 见过几次核弹的, 同意你这个
【在 b*******n 的大作中提到】
: short cycle碰到傻逼coder就是埋炸弹。用户测不全，以后就是在生产环境中核弹。
: 比如一个coder手挺快，出活利索，manager挺喜欢。终于由此染指他的code了，原来全
: tmd的都是即时贴。
: 比如
: foo1（string s){
: <---- 补丁放到这
: foo2 (s, true);
: }
: foo2(sting s, boolean t){ //核心实现部分
: ...
|
l*********s
发帖数: 5409 | 14 you don't have code review?
【在 b*******n 的大作中提到】
: short cycle碰到傻逼coder就是埋炸弹。用户测不全，以后就是在生产环境中核弹。
: 比如一个coder手挺快，出活利索，manager挺喜欢。终于由此染指他的code了，原来全
: tmd的都是即时贴。
: 比如
: foo1（string s){
: <---- 补丁放到这
: foo2 (s, true);
: }
: foo2(sting s, boolean t){ //核心实现部分
: ...
|
r***y
发帖数: 4379 | 15 code reviewing targets code logic, instead of business logic
some nuke is in business logic
【在 l*********s 的大作中提到】
: you don't have code review?
|
r***y
发帖数: 4379 | 16 -- "无穷多客户"
这个倒不是问题, jetbrains 的产品现在都是 agile 出来的. 但自从它们 agile 了以
后, bugs 也越来越多, 非常 annoying .
以前老汉还时不时用用它们的 EAP 给它们提交个bug, 现在出了 EAP 直接 ignore .
【在 N******K 的大作中提到】
: geek这个词很不明确
: 按照中国人的观点 要能文能武 谦虚谨慎 面对客户 不是装13 也不是自贱 而是合作
: 另外 这个agile 是否可以用来设计iphone？ 你面对的是无穷多客户
|
l*****9
发帖数: 9501 | 17 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*****9
发帖数: 9501 | 18 exactly
Agile is to empower 能力强的 IT developer
Business users 和 IT developers 之外，都是 IT developers' 服务员
【在 w**z 的大作中提到】
: 我觉得 Agile 的精髓就是 small task, short cycle, 随时根据客户反馈，修改。
|
M****z
发帖数: 1058 | 19 agile也有它的适用范围和环境。反正不管什么方法论，都不能教条地使用。最怕那种
拜神教，任何适合都拿出一本金科玉律，朗朗上口，其实根本没搞明白里面精髓是什么
意思，如何在实践中应用。 |
S*******s
发帖数: 13043 | 20 你说这人聪明，还是弄个非常stable/generic/flexible的系统出来，最后让所有程序
员包括自己都失业的程序员聪明？
蓝玉牛还是李成梁牛？
【在 b*******n 的大作中提到】
: short cycle碰到傻逼coder就是埋炸弹。用户测不全，以后就是在生产环境中核弹。
: 比如一个coder手挺快，出活利索，manager挺喜欢。终于由此染指他的code了，原来全
: tmd的都是即时贴。
: 比如
: foo1（string s){
: <---- 补丁放到这
: foo2 (s, true);
: }
: foo2(sting s, boolean t){ //核心实现部分
: ...
|
|
|
l*****9
发帖数: 9501 | 21 are you a programmer?
【在 S*******s 的大作中提到】
: 你说这人聪明，还是弄个非常stable/generic/flexible的系统出来，最后让所有程序
: 员包括自己都失业的程序员聪明？
: 蓝玉牛还是李成梁牛？
|
S*******s
发帖数: 13043 | 22 does it matter?
【在 l*****9 的大作中提到】
: are you a programmer?
|
l*****9
发帖数: 9501 | 23 of course
【在 S*******s 的大作中提到】
: does it matter?
|
S*******s
发帖数: 13043 | 24 unwarranted
【在 l*****9 的大作中提到】
: of course
|
N********n
发帖数: 8363 | 25
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*****9
发帖数: 9501 | 26 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*******h
发帖数: 2882 | 27 这话说到点子上了。很多公司项目失败的原因是一些SB高层问具体情况硬上Agile，听
人家说好就当成Silver Bullet，执行起来完全不是那么回事。很多老外就一根筋，没
有中国人具体问题具体分析的精神。
【在 M****z 的大作中提到】
: agile也有它的适用范围和环境。反正不管什么方法论，都不能教条地使用。最怕那种
: 拜神教，任何适合都拿出一本金科玉律，朗朗上口，其实根本没搞明白里面精髓是什么
: 意思，如何在实践中应用。
|
M****z
发帖数: 1058 | 28 其实各方面都会存在这样的人，不过非技术人员概率更大，因为他们不是工具的直接使
用者。
这篇文章我觉得靠谱，希望有帮助：
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**********g
发帖数: 989 | 29
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 的大作中提到】
: short cycle碰到傻逼coder就是埋炸弹。用户测不全，以后就是在生产环境中核弹。
: 比如一个coder手挺快，出活利索，manager挺喜欢。终于由此染指他的code了，原来全
: tmd的都是即时贴。
: 比如
: foo1（string s){
: <---- 补丁放到这
: foo2 (s, true);
: }
: foo2(sting s, boolean t){ //核心实现部分
: ...
|
l*****9
发帖数: 9501 | 30 这个作者不是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****z
发帖数: 1058 | 31 如果是以某个产品为目标团队合作的话，这就陷入另一个陷阱了。现在确实是个多数
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*****g
发帖数: 34805 | 32 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*******n
发帖数: 449 | 33 不是说同事不对，不过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*******n
发帖数: 449 | 34 code review是渣，人会疲劳，到时什么都看不出来，
跟别说，你把a=0，然后b=a, c=b,。。。z=y 最后，foo/z这种绝逼没人看出毛病来。
code review 这种最多查查代码规范罢了，边界/临界值几乎查不到。
【在 l*********s 的大作中提到】
: you don't have code review?
|
b*******s
发帖数: 5216 | 35 你们这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*******n
发帖数: 449 | 36 foo2以后再其他代码被调用怎么测。
agile这玩意就是假设别人都跟他一样nb，一样通晓几乎所有的代码，一样的代码质量
，一样的风格。
事实上几乎是不存在的，除了自己一个轮轮子的。
【在 w**z 的大作中提到】
: short cycle 不是说把测试环节省了， 该测的还要测。 是把 feature 分小， 短时间
: 完成，有问题马上该。
|
b*******s
发帖数: 5216 | 37 我觉得你对agile理解是不对的
【在 b*******n 的大作中提到】
: foo2以后再其他代码被调用怎么测。
: agile这玩意就是假设别人都跟他一样nb，一样通晓几乎所有的代码，一样的代码质量
: ，一样的风格。
: 事实上几乎是不存在的，除了自己一个轮轮子的。
|
N******K
发帖数: 10202 | 38 NaN 和 Inf 你们不用？
【在 b*******n 的大作中提到】
: code review是渣，人会疲劳，到时什么都看不出来，
: 跟别说，你把a=0，然后b=a, c=b,。。。z=y 最后，foo/z这种绝逼没人看出毛病来。
: code review 这种最多查查代码规范罢了，边界/临界值几乎查不到。
|
b*******n
发帖数: 449 | 39 卡，举个例子罢了。
这里的0不过是某个可能中间结果，可能来自db的null，可能是文本中的“”，也可能
是某个中间计算结果。
没经验或有经验没agile逼的没时间考虑的这种错误很容易犯，这种问题靠用户测，靠
QA？都不靠谱，
用户可能给的文件永远都不会有“”，不过他离开的时候他儿子上去胡搞说不定就搞个
“”出来。
然后上k个文件在一个batch里过来处理，不考虑这种东西，突然爆掉，万一后面还有几
百个文件，最后结果直接就飞了。
【在 N******K 的大作中提到】
: NaN 和 Inf 你们不用？
|
t*******h
发帖数: 2882 | 40 Architect在Agile里的作用有什么变化吗？ |
|
|
r***y
发帖数: 4379 | 41 code review 只是个 practice, 是个经而已, 还是歪嘴和尚念坏了
我以前做 CMMI 的 项目的时候 code review , 都是至少 3+ reviewers 花半天以上的
时间review 某个功能的代码...
后来的 scrum team , 就是他妈的走过场, mgr 要求快速 review , 就是不能耽误你这
一天出活, 这样的歪嘴和尚, 码工要不糊弄怎么活?
记得有个mgr 曾经超级二B的隔段时间统计每个码工的 commits , 虽然是半认真的, 也
让人不爽. 造成team里有sb青年每个文件一个commit, 改几行就commit...
【在 b*******n 的大作中提到】
: code review是渣，人会疲劳，到时什么都看不出来，
: 跟别说，你把a=0，然后b=a, c=b,。。。z=y 最后，foo/z这种绝逼没人看出毛病来。
: code review 这种最多查查代码规范罢了，边界/临界值几乎查不到。
|
m*******l
发帖数: 12782 | 42 哈哈,用脚本自动commit会不会被人打死? 随便加几个空行啥的
【在 r***y 的大作中提到】
: code review 只是个 practice, 是个经而已, 还是歪嘴和尚念坏了
: 我以前做 CMMI 的 项目的时候 code review , 都是至少 3+ reviewers 花半天以上的
: 时间review 某个功能的代码...
: 后来的 scrum team , 就是他妈的走过场, mgr 要求快速 review , 就是不能耽误你这
: 一天出活, 这样的歪嘴和尚, 码工要不糊弄怎么活?
: 记得有个mgr 曾经超级二B的隔段时间统计每个码工的 commits , 虽然是半认真的, 也
: 让人不爽. 造成team里有sb青年每个文件一个commit, 改几行就commit...
|
g*****g
发帖数: 34805 | 43 我们不做code review，一人负责一个service，谁出问题很清楚。你爱写测试
不写测试都没人管。反正老出问题就准备滚蛋吧。
【在 r***y 的大作中提到】
: code review 只是个 practice, 是个经而已, 还是歪嘴和尚念坏了
: 我以前做 CMMI 的 项目的时候 code review , 都是至少 3+ reviewers 花半天以上的
: 时间review 某个功能的代码...
: 后来的 scrum team , 就是他妈的走过场, mgr 要求快速 review , 就是不能耽误你这
: 一天出活, 这样的歪嘴和尚, 码工要不糊弄怎么活?
: 记得有个mgr 曾经超级二B的隔段时间统计每个码工的 commits , 虽然是半认真的, 也
: 让人不爽. 造成team里有sb青年每个文件一个commit, 改几行就commit...
|
m*******l
发帖数: 12782 | 44 我们一个项目两个人同时写, 对比结果,性能,差3打的滚蛋
哈哈
【在 g*****g 的大作中提到】
: 我们不做code review，一人负责一个service，谁出问题很清楚。你爱写测试
: 不写测试都没人管。反正老出问题就准备滚蛋吧。
|
r***y
发帖数: 4379 | 45 大多数项目没法分那么清楚, agile 的 cards 都在 backlog 里, 自己去 pull/assign
, 所以每个码工之间交叉很多. 出了问题就跟小时候玩的"看谁尿炕" 的游戏一样, 倒
霉的往往是最后一个抓沙子把棍弄倒的, 其实坏事都是你一把我一把才出来的...
所以 code review 防止这样的 code debt 还是有用的. agile 压力这么大, 光靠道德
约束是没用的.
code review另外的好处是相互之间熟悉你做的那一块. 避免不定哪天哪个小爷不爽了,
走人, 别人半天捡不起来的情况.
【在 g*****g 的大作中提到】
: 我们不做code review，一人负责一个service，谁出问题很清楚。你爱写测试
: 不写测试都没人管。反正老出问题就准备滚蛋吧。
|
g*****g
发帖数: 34805 | 46 虽然没那么清楚，坏在谁手里一般还是能看出来的。谁都会出bug，但有多少区别明显
，干个几个月
谁是烂人很清楚。
assign
了,
【在 r***y 的大作中提到】
: 大多数项目没法分那么清楚, agile 的 cards 都在 backlog 里, 自己去 pull/assign
: , 所以每个码工之间交叉很多. 出了问题就跟小时候玩的"看谁尿炕" 的游戏一样, 倒
: 霉的往往是最后一个抓沙子把棍弄倒的, 其实坏事都是你一把我一把才出来的...
: 所以 code review 防止这样的 code debt 还是有用的. agile 压力这么大, 光靠道德
: 约束是没用的.
: code review另外的好处是相互之间熟悉你做的那一块. 避免不定哪天哪个小爷不爽了,
: 走人, 别人半天捡不起来的情况.
|
z****e
发帖数: 54598 | 47 code review最常遇到的新人的错误代码就是
for(int i=0;i
...
list.remove(i);
}
这种其实用强循环直接就抛异常了 |
r***y
发帖数: 4379 | 48 是这么说. 但 code review 不是甄别烂人, 是防止好人犯错.
我们组曾有个很好的码工, 但后来老婆怀孕, 同时又闹离婚, 那哥们儿那几个月搞了很
多烂码... 然后自己走了, 去了 flag 之一. 都一年了, 现在他的名字还常被我们提起
, 当然被提起的方式大家都懂的...
【在 g*****g 的大作中提到】
: 虽然没那么清楚，坏在谁手里一般还是能看出来的。谁都会出bug，但有多少区别明显
: ，干个几个月
: 谁是烂人很清楚。
:
: assign
: 了,
|
g*****g
发帖数: 34805 | 49 这个你们QA应该把关的吧。俺们QA写了一堆integration test，每个commit都会自动编
译，部署，整合测试，有showstopper一小时内就知道了。
【在 r***y 的大作中提到】
: 是这么说. 但 code review 不是甄别烂人, 是防止好人犯错.
: 我们组曾有个很好的码工, 但后来老婆怀孕, 同时又闹离婚, 那哥们儿那几个月搞了很
: 多烂码... 然后自己走了, 去了 flag 之一. 都一年了, 现在他的名字还常被我们提起
: , 当然被提起的方式大家都懂的...
|
r***y
发帖数: 4379 | 50 悲摧的就在这里
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******K
发帖数: 10202 | 51 微软 还是 华为？
【在 m*******l 的大作中提到】
: 我们一个项目两个人同时写, 对比结果,性能,差3打的滚蛋
: 哈哈
|
b*******s
发帖数: 5216 | 52 这种人怎么招进来的
【在 z****e 的大作中提到】
: code review最常遇到的新人的错误代码就是
: for(int i=0;i: ...
: list.remove(i);
: }
: 这种其实用强循环直接就抛异常了
|
z****e
发帖数: 54598 | 53 阿三写的
【在 b*******s 的大作中提到】
: 这种人怎么招进来的
|
N******K
发帖数: 10202 | 54 这能运行下去？ java强大
【在 z****e 的大作中提到】
: code review最常遇到的新人的错误代码就是
: for(int i=0;i: ...
: list.remove(i);
: }
: 这种其实用强循环直接就抛异常了
|
z****e
发帖数: 54598 | 55 list不是thread safe的
如果你用vector就出问题了
但是vector会有性能问题
多线程并发本来就是难点
要性能自然要牺牲一点东西
【在 N******K 的大作中提到】
: 这能运行下去？ java强大
|
g*****g
发帖数: 34805 | 56 这个应该会出ConcurrentModificationException，我觉得只要跑过就会出问题，
不会等到review。
【在 N******K 的大作中提到】
: 这能运行下去？ java强大
|
