`
一蓑烟雨任平生
  • 浏览: 51008 次
  • 性别: Icon_minigender_1
社区版块
存档分类
最新评论
文章列表
信息系统经过持续不断的补丁和升级,进化到最后往往如同得了癌症,刚开始时只是对系统进行局部的处理,做一些代码修改,然后开始补丁,加一些代码,癌细胞开始产生。 随着维护人员的加入,原系统的开发人员逐步退出,后续的代码则针对现有的问题解决,至于相关模块的隐患则由于经验能力不足而没有考虑,癌细胞开始扩散。系统升级中,因为有的新的模块或者对老的周边模块做修改,癌细胞开始转移。 最后系统完蛋,推翻重来。
1、韩国棋手认为古力局部计算不如小李、官子不行,拼到官子古力就有问题 2、小李的策略是从布局阶段就开始导入混乱未知的局面,哪怕自己被动,也要打乱古力的节奏,也是看准古力的优势心理下专注度降低的弱点 3、2人都会瞬间短路,头2盘2人各自都手起刀落,很干脆的解决战斗,后面3盘错进错出,也是体力到了极限,这个期间防守比攻击容易,也节省体力,看起来攻势凶猛,最后未必能笑到最后 小李的序盘看起来不如古力,但是整体的策略非常连贯,这种下法,如果是3番棋,古力体力有保障,我赌古力赢,如果是5番棋,我赌小李赢。
前段时间把家里的图书清理了一次,留了一些质量较好的开发类图书送人,剩下的都打包卖了废纸。现在书架上软件研发和项目管理的书不多了,看了看也就10几本,年底是总结的时候,这次拿出来晒晒,想想还是有值得推荐的。 1、对抗比尔盖茨的阴谋 华夏出版社 我把这本书放在头前,是想告诉大家,技术选型上要冷静理智,不要被忽悠。 开篇引用约翰.斯坦贝克的的一段话: 在我们所赞美的人类品质中,仁慈、慷慨、坦率、诚实、理解和情感无不与我们社会体系中的失败连在一起;而那些我们所深恶痛绝的不择手段、贪婪无度、卑鄙无耻、自私自利才是成功的品性,尽管人们极力赞美前一种人品,但真正喜欢的却是后者的结果。 这本书买的早,感谢 ...
被恶心了,妊娠反应较重,身心健康重要,停上论坛一个月,不发言不潜水不看帖。
时光倒流二十年 童年你与谁渡过 圣诗班中唱的歌 再哼一哼可以么 当时谁与你排着坐 白色恤衫灰裤子 再穿一穿可以么 遗憾我当时年纪不可亲手拥抱你欣赏 童年便相识 余下日子多闪几倍光 谁让我倒流时光一起亲身跟你去分享 能留下印象 阅览你家中每道墙 拿着你歌书 与你合唱 从前你与谁路过 逛的公园有几多 再走一走可以么 当时谁对你凝望过 是否真的比我多 再演一演可以么 遗憾我当时年纪不可亲手拥抱你欣赏 童年便相识 余下日子多闪几倍光 谁让我倒流时光一起亲身跟你去分享 遗憾印象 没有你家中那面墙 拿着你相簿 从前拍过的相 多么妒忌你昨日同过的窗 ...
再说敏捷,兼对“对敏捷开发等时髦概念泼点冷水”的回复 敏捷在国内的宣传中,给人的感觉是降低成本,实际上能做这些的咨询公司,人力的单价都很高,也会有一些商务的政策保护,如果把这钱给一些有经验的公司,我相 ...
这么多年碰到很多项目,体会是没有一个项目是能把人配齐,当手上项目多的时候,资源就会不断的稀释,各种非正常的手段无所不用,人最后跟赌徒没有什么差别,知道会有风险,就赌会不会出现。 倒不是说教科书有什么问题,只是在资源配备不到位时,一个没有经验的项目经理会发憷,觉得越是这样就越要做好管理,越要学习,形成恶性循环。 其实标准的说法是,资源不足就不应该做,可是话可以这么说,现实是哪有这么简单的事情。
看到很多帖子上讲怎么样才能做好项目,这次就讲讲我的经验吧。 项目经理的能力,我觉得有两个,一个是基本的技能(技术、业务、项目管理),一个是形势分析和判断能力。前者还可以通过自学做到,后者自学的可能性微 ...
开发能否成功,在于各个角色是否明白各自应该担当的工作内容,目标要一致,我把项目的角色分为主担、辅担两类,业务开发是项目的主担,对项目负责,管理是辅担,由公司管理部门对项目的过程指标进行检查和提供帮助。两类角色都是非常必要的,只是要有侧重,尽管相互制衡,但是管理角色做的是辅助流程,不是关键路径,就是不要过早的让这些角色由“一票否决”的权力。 开发主担主要是业务分析、设计、开发和测试,实际上抓好两个关键要素就可以,一个是业务设计,一个是任务管理。任务管理的基础也是业务设计充分,不清楚不做,粒度要细,要让开发人员真正明白要做什么。之所以项目做不好,业务理解设计不充分占绝大多数,造成任务的分解做不下 ...
敏捷与Spring、Hibernate这些东西都一样,草民革命,目的也就是为了被招安,等到目的达到,行事方法跟那些大佬也没有什么区别的时候,当初忽悠的东西只有自己强撑着,等着下一轮的革命。 预计一下技术咨询的热点: 1、Lean,具备迷人的故事潜力,拉动、看板、节拍,理论经典,可塑性强。 2、GTD,可以做为Scrum的改进版,更加有效的进行任务管理。
上次是敏捷,这次说说TDD。 TDD现在的路子不对,讲的再怎么天花乱坠也还是单元测试的路子,实际上在业务系统的开发中作用未必如所说的那么明显,否则这么好的东西也不可能推广的这么困难。 业务系统的核心是数据,开发过程是数据驱动的,在一开始做开发设计的时候,用例和场景应建立在数据的基础之上,粒度在服务这一层就够了,然后逐步细化。单元测试这个层级粒度太小,做得再多,也不能保证一个完整业务跑的是不是正确。 那么什么才是正确的TDD呢?站的角度要高一点点,层次也要高一点点。 TDD不应该用现在这样的套路,而是应该基于功能,将测试数据和业务代码、测试代码分开,在项目的一开始就由业务顾问负责,组织设计、开 ...
总体而言,“敏捷”就是一个bizword,几个定制开发项目的公司和技术咨询公司所创造的“蓝海”。 这其中有意无意的忽略了一些关键环节,有些地方很恶劣。比如业务,将因为自己业务经验的匮乏,所带来的项目需求变更和交付期延长等风险,全部转嫁给客户。我们假设自家装修,施工队说你怎么说我怎么做,之所以没有做是因为你当初没有说,如果要改,需要另外付钱,会是什么心情。 同时,除了FDD这样的方法论,有一个完整的过程来支撑外,其它的都是一些成功实践,也就是一些经验之谈,容易让学习的人混乱,角色要哪些,日常怎么来管理?在具体的术上,确实有很多优秀之处,但是所处的层次不是在整个项目上,毕竟开发只是项目实施的一个 ...

知拍任君斗

--刚在他力前,柔在他力后,彼忙我静待,知拍任君斗 项目的准时化、均衡化生产的关键是生产节拍。定义好开发工序、制定好任务粒度划分的规则,则是生产节拍的核心,这点做好,看板就很好实现。
按照个人理解整理了一个丰田生产方式的大纲,以便在开发过程中进行比对学习。 1、总则:杜绝浪费 丰田的7种浪费 消除浪费的步骤 零库存 2、准时化 均衡化生产 生产流程化 生产节拍与看板 5S 3、自动化 标准作业书 省人化 缩短更换作业时间 维修保养 4、改善 目视管理 现场改善 IE手法 5、IE手法 工序分析 动作分析 时间分析
什么人做功能测试比较好?这是我写这篇《功能测试谁来做》的想法。 经常有人会跟我说他们公司开发过程很好,配备了独立的功能测试组,有的成立了独立的测试部门。也有顾问告诉我,要有独立的测试人员。也有相当的人 ...
Global site tag (gtag.js) - Google Analytics