看导师痛打凉粉与作者再次辩解

本文讨论了一个敏捷项目管理案例,分析了项目经理对团队成员的信任及管理方式,并探讨了敏捷原则的应用。通过对项目过程中出现问题的原因分析,提出了改进措施。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

这个时候另外有一个cao yufei出来发言
[quote] 文章的题目改为:一个敏捷初哥放任越轨列车的故事。这样更符合文章的内容。同学们以批判断的眼光来看作者对项目中问题的反应,作为教训,不要再犯类似作者的错误。[/quote]
导师马上追问:why?
可惜为何不与gigix继续进行下去呢?那个议论显然比这个深入,而且有实际的意义。
于是得到一个回答:[quote]那个时候我就已经预见了今天我不得不作出的处理。”
实际上从一开始作者就知道A的情况,A的弱点。
“我知道,这样的人不能重用,我对他没有信任感。”
在这样的认识前提下,作者应该作出的反应是什么呢?我觉得应该是细粒度的监控,充分的沟通,每天早上和A来个2分钟的meeting,每周起码两次小组 scrum meeting。但是作者没有做这些,“我在周一分配了任务让他阅读文档,我给了他一个星期。” 对于一个你不信任的人,你知道弱点的人,为什么会放任他自己干一个星期而不管不问?整个火车越轨的过程长达3个月,太长了!作者的反应太不敏捷了。
抛开敏捷不谈,任何管理者,对于同事在3个月的时间里“不出活”的现象也无法容忍,绝对不能坐视事态发展3个月。实际上最多一个月,作者就应该解决问题,3个月才解决已经失职了。

[/quote]这里其实是cao yufei看错了,于是作者马上出来指出[quote] 作者再次答疑,--是三个星期!!不是三个月!!!
我容忍了"A"三个星期,另外一个组容忍了八个月。不要搞错![/quote]
你看作者其实还是很敏捷的,至少比另外一个组敏捷,三个星期就搞定了。
你看导师在此时也及时的发言了[quote] 他所做的一切好像就是为了用证据来证明 A 的无能,证明自己一开始就下的结论。为了证明,就需要时间来等待,却忘了敏捷项目应该做的事和达到的效果。

Richard 在前面也亮出了他对“敏捷”的定义和理解,他认定这就是敏捷,显然是非常片面的。

我觉得在这起事件中,A 的越轨毫无悬念,本在大家意料之中,而作者对于敏捷的误解才是真正“出轨的列车”,这可能是一个有趣的新发现。[/quote]确实作者的对敏捷又误解,但是其他人的认识就不存在误解了么?其实前面导师的发言,已经给这个问题的提出埋下了伏笔。导师后来的发言,无疑将给这个问题一个明确的答案。

而导师在明白原来cao yufei搞错了之后,马上就说[quote]如果是三周,我觉得在合理范围之内。兼一点建议
只花 3 周是合理的,我原来设想是否能在 2 周(一个迭代)内解决问题。不管如何,这点时间还是需要的。从时间上来看,确实要比其他组“敏捷”得多。
应该是 yunfei 看错了。事实上,这篇故事我也至少认真读了 30 分钟,才确认自己大体看明白了。本案的叙述过长,而且涉及到很多细节,容易出错。
Richard,我看到你的故事中差不多有一大半的篇幅是在讲 A 如何如何不对,然后你如何如何应对。给人的感觉是,你要充分证明 A 是多么的无能和令人讨厌。但你明白,在本案中 A 绝对不可能有任何的申辩机会(主动权掌握在你手里),我们读者可以完全而且只能相信你的陈述。所以,要我们得出 A 错误,你正确,从而支持你的结论其实是相当容易的,也就是说这方面的篇幅可以大大缩短,更加的精练和概括。
另外,由于比重设置不当,你对你们团队是如何实际运用 Scrum 或者敏捷方法,谈到的较少。这方面能否再介绍一下,作一些补充?
这样我想这个案例才更完整,对大家更有帮助。
[/quote]
导师认为是合理的当然就合理了,谁敢和导师作对,自然导师一个这点时间还是需要的,就可以挡住所有的疑问。而且从时间上看,确实别其他组“敏捷”的多。你看导师似乎也认为,敏捷就是时间更少。
不过我却糊涂了,因为本人是个村夫,年轻时性格暴躁,喜欢打架。如果我是作者,我可能看A不爽,直接上去就是一顿爆打,5分钟就解决了问题。即便我不出手,我为人也比较卑鄙,早就在私下联系领导将这个人排挤出公司了。这些都比三周的时间短很多啊,看来我要回去好好反省一下我现在是不是已经不敏捷了。
资源下载链接为: https://pan.quark.cn/s/f989b9092fc5 HttpServletRequestWrapper 是 Java Servlet API 中的一个工具类,位于 javax.servlet.http 包中,用于对 HttpServletRequest 对象进行封装,从而在 Web 应用中实现对 HTTP 请求的拦截、修改或增强等功能。通过继承该类并覆盖相关方法,开发者可以轻松地自定义请求处理逻辑,例如修改请求参数、添加请求头、记录日志等。 参数过滤:在请求到达处理器之前,可以对请求参数进行检查或修改,例如去除 URL 编码、过滤敏感信息或进行安全检查。 请求头操作:可以修改或添加请求头,比如设置自定义的 Content-Type 或添加认证信息。 请求属性扩展:在原始请求的基础上添加自定义属性,供后续处理使用。 日志记录:在处理请求前记录请求信息,如 URL、参数、请求头等,便于调试和监控。 跨域支持:通过添加 CORS 相关的响应头,允许来自不同源的请求。 HttpServletRequestWrapper 通过继承 HttpServletRequest 接口并重写其方法来实现功能。开发者可以在重写的方法中添加自定义逻辑,例如在获取参数时进行过滤,或在读取请求体时进行解密。当调用这些方法时,实际上是调用了包装器中的方法,从而实现了对原始请求的修改或增强。 以下是一个简单的示例,展示如何创建一个用于过滤请求参数的包装器: 在 doFilter 方法中,可以使用 CustomRequestWrapper 包装原始请求: 这样,每当调用 getParameterValues 方法时,都会先经过自定义的过滤逻辑。 HttpServletRequestWrapper 是 Java Web 开发中一个强大的工具,它提供了灵活的扩展性,允许开发者
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值