2010年01月29日 星期五 15:25
2010/1/27 qiaojie <qiaojie在gmail.com>: > 这种抱怨毫无意义。 > 嗯嗯嗯,不过,有怨才能吼, 如果已经从了现在的 项目环境将永远沉沦了... 又从 InfoQ 架构师 看到一段深以为然的抱怨... 很多时候非常奇怪,为什么在社区中使用良好的各种沟通/开发/管理工具都用的不错, 但是一到企业项目中就面目全非? 年度总结中,俺自以为了一句:"没有时间,一切改进都是奇迹!" 不论是 SVN/WIKI/Blog/IRC/统一命名/Scrum .... 一切软件工程相关的规范化行为,在时间紧急情况下,都会自动抛弃... 正如敏捷宣言中修正的, 一切源自尊重! * 公司尊重团队,从而有勇气不乱加任务,容忍初期自组织成型时的"混乱" * 团队尊重自己,从而有勇气承担责任,在时间盒内尽力交出活儿 * 客户尊重开发,从而有勇气承认自个儿的需求不一定靠谱,参与到开发中 * 财务尊重变化,从而有勇气将绩效核算方式进行升级,切合用户的真实需求 一切源自对软件的尊重!然而这正是最最最难的变化! 和过程改进一样,最大的敌人不是工具/平台/方法论/组织改革...而是积习难改! > > 2010/1/27 Zoom.Quiet <zoom.quiet在gmail.com> >> >> 有关项目管理/敏捷开发/代码质量... >> 一切软件工程相关的研究,都是P话! >> 截屏的怒吼,才是真实的! >> >> 自个儿的活儿,真想作好,就有无穷的办法! >> 不想作好,就想得钱,就有无尽的借口! >> >> 当然,现实 99.999999% 的项目都是 狗屎,完全不知道想作什么, 俺们也只能徦装一起玩软件工程游戏了... -- http://zoomquiet.org 人生苦短? Pythonic! 向靠谱,反脑残! Kaopulity,小白退散! [Kaopulity~= Keep all processes usablity!] -------------- 下一部分 -------------- A non-text attachment was scrubbed... Name: 2010-01-29-151812_1019x293_scrot.png Type: image/png Size: 85492 bytes Desc: 不可用 URL: <http://www.zeuux.org/pipermail/zeuux-universe/attachments/20100129/6fb73822/attachment-0002.png> -------------- 下一部分 -------------- A non-text attachment was scrubbed... Name: graphviz-G-b8c34ecdbe491e6193534b875d26dfdee67a3109.png Type: image/png Size: 27748 bytes Desc: 不可用 URL: <http://www.zeuux.org/pipermail/zeuux-universe/attachments/20100129/6fb73822/attachment-0003.png>
2010年01月29日 星期五 16:07
> 很多时候非常奇怪,为什么在社区中使用良好的各种沟通/开发/管理工具都用的不错, > 但是一到企业项目中就面目全非? > > 年度总结中,俺自以为了一句:"没有时间,一切改进都是奇迹!" > > 不论是 SVN/WIKI/Blog/IRC/统一命名/Scrum .... > > 一切软件工程相关的规范化行为,在时间紧急情况下,都会自动抛弃... CMMI 要解决的只是不确定性,而不是速度。也就是说要使你软件的产出时间变成可以预期的。 而对于企业而言,一切改进恐怕都是希望能够更快的出产品。 所以,问题不在于这些工具和方法本身,而再于你部署这个工具的方法和策略。 当我在一个支离破碎的项目中开始部署起 svn 的时候,整个团队的生产力和士气都提高了很多,这是否能够证明企业也并非不能使用软件工程? 不是为了软件工程而软件工程,而是找到项目中的关键弱点,并寻求有价值的方式去改进之。――如果你能够跳出项目之外去看这个问题就会看到,其实时间问题是表象,而不是实质。
2010年01月29日 星期五 17:01
2010/1/29 pan shizhu <pan.shizhu在gmail.com>: >> 很多时候非常奇怪,为什么在社区中使用良好的各种沟通/开发/管理工具都用的不错, >> 但是一到企业项目中就面目全非? >> >> 年度总结中,俺自以为了一句:"没有时间,一切改进都是奇迹!" >> >> 不论是 SVN/WIKI/Blog/IRC/统一命名/Scrum .... >> >> 一切软件工程相关的规范化行为,在时间紧急情况下,都会自动抛弃... > > CMMI 要解决的只是不确定性,而不是速度。也就是说要使你软件的产出时间变成可以预期的。 > > 而对于企业而言,一切改进恐怕都是希望能够更快的出产品。 > > 所以,问题不在于这些工具和方法本身,而再于你部署这个工具的方法和策略。 > > 当我在一个支离破碎的项目中开始部署起 svn 的时候,整个团队的生产力和士气都提高了很多,这是否能够证明企业也并非不能使用软件工程? 俺进行这类基建好几次了,在不同公司, 都是开始开发都很高兴,总算有人关心他们的生活了,,, 然后,继续在混乱的需求/时间计划/交付指标/配置管理中挣扎, 在发觉靠谱的工具和流程,并不能理性化来自管理层的混乱后, 一切,就回到原点... 不过是多了一些主流管理系统在用最混乱的方法来使用而已... > > 不是为了软件工程而软件工程,而是找到项目中的关键弱点,并寻求有价值的方式去改进之。——如果你能够跳出项目之外去看这个问题就会看到,其实时间问题是表象,而不是实质。 > 所有的问题都指向高层问题: - 公司战略方向迷失 - 产品市场定位模糊 - 开发技术方向漂移 - 用户群变动频繁... 到最后,开发依然回到使用最in 技术来开发最烂产品的 阿Q 式生活中>.. 工程的作用在这种环境中,也就是 捞取 CMMI 几级证书来宣传而已... -- http://zoomquiet.org 人生苦短? Pythonic! 向靠谱,反脑残! Kaopulity,小白退散! [Kaopulity~= Keep all processes usablity!]
Zeuux © 2024
京ICP备05028076号