只显示主题贴

在北京的慈济体检的,没有排队管理系统,只有几个小护士在每个门口安排调整,整体效果非常好,都检完大约需要40分钟。 个人觉得这个还不能算企业软件吧。 lsm说到工序优化这个永恒的话题了。
风景好,人少,其他就不值一提了。
个人认为是在扯淡。 你们公司是做应用的还是做产品的? 做应用有多少个项目? 做产品的有多少个产品? 有搞通用日志组件的必要么? 什么叫日志组件?日志组件都有哪些方面的功能性、非功能性要求?现有的日志解决方案都有哪些,哪些方面不能满足你们的要求? 做这个事情的初衷有没有想清楚,就讨论怎么做了。 为了日志的性能做成分布式还说可以减少应用服务器负担,我觉得lz就是在搞笑。
  • 进入论坛 Java
yecllsl 写道xellos 写道yecllsl 写道不知道使你们浮躁还是我太胆小、落伍,工作8年了,才税后10k多一点。不过,自己英语不好,绝对的短板,技术、沟通、管理自认为还是可以的。上海,民企,100人左右,手下几个项目经理。 看这话,好象有这个意思: 如果不是我们浮躁,那就是你胆小,落伍。 我觉得这个不成立。 我们浮躁与不浮躁,你落伍不落伍,这二者没什么联系。 我们显然不是浮躁的。你是否落伍,我也不好妄加评论。 可为什么我面试了很多毕业两年号称如何如何的,结果真的不怎么样。 有一点我可以确认了,我过低要求了自己,胆子要大点,步子要大点。英语要学好。 不是浮躁,不如何如何的 ...
项目估算没有这方面经验的人参与,估算对问题没有预见性,造成估算乐观。 项目需求阶段中后期或概要设计阶段,没有做关键技术可行性判定,可视化界面平台移植性,硬件操作性是java的硬伤,没有定义风险,更没有采取有效措施规避风险。 貌似coding阶段没有做持续集成测试,如果开发不够规范,单元测试做的不够完善,造成质量不可控,大量问题拖延到下一阶段。 对内部测试没有做质量评审,评估问题严重性,对计划、资源作出调整,告知相关项目干系人。 强行交付,陷入焦油坑。
测试驱动开发,如果你认为开发是在功能点明确的情况下来做具体实现,那就没有问题。 对于一定规模的系统,一定是在基本技术架构基础上,划分出明确功能点,功能模块才开始开发的,这个时候TDD,顺利成章。如果是功能点本身不明确,模块划分有问题,那是需求确认问题、整体设计问题,和TDD关系不大。当然整体架构也可以TDD,这个就说来话长,仁者见仁了。 对于如何TDD,不必那么学究,只要在明确的功能规格下开发,可以自成一派。
第一个场景: 项目立项要定义项目范围。 范围的定义大体要说明主要功能需求,非功能需求,目标用户,软硬件环境, 而不是讨论设计问题。 第二个场景: 在问题还不明确的情况下,讨论解决问题方案,南辕北辙。 第三个场景: 同上。 总体上看: 这不是细节不细节的问题,是范围的问题、跑题的问题。上述这些内容也有是很多细节,是属于讨论范围内的细节。 开会之前没有明确好会议的内容、范围、目标。
DraculaW 写道-@- 引用 我反对你同意 所以 我比你层次高 自从哪部电影呢? 英雄还是什么 国内的舆论导向就是这样子的 骂声一片 呵呵 英雄还好,个人感觉应该是从无极开始的。 赤壁这么搞于情于理是说不过去的,商业和艺术的分歧越来越大。
多看几本武侠小说就知道怎么回事了。
这个故事有点意思,lz有做顾问的潜质,主要还是刚毕业没经历过什么事情,继续努力。
Godlikeme
搜索本博客
其他分类
存档
最新评论