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>

> 很多时候非常奇怪,为什么在社区中使用良好的各种沟通/开发/管理工具都用的不错,
> 但是一到企业项目中就面目全非?
>
> 年度总结中,俺自以为了一句:"没有时间,一切改进都是奇迹!"
>
> 不论是 SVN/WIKI/Blog/IRC/统一命名/Scrum ....
>
> 一切软件工程相关的规范化行为,在时间紧急情况下,都会自动抛弃...

CMMI 要解决的只是不确定性，而不是速度。也就是说要使你软件的产出时间变成可以预期的。

而对于企业而言，一切改进恐怕都是希望能够更快的出产品。

所以，问题不在于这些工具和方法本身，而再于你部署这个工具的方法和策略。

当我在一个支离破碎的项目中开始部署起 svn 的时候，整个团队的生产力和士气都提高了很多，这是否能够证明企业也并非不能使用软件工程？

不是为了软件工程而软件工程，而是找到项目中的关键弱点，并寻求有价值的方式去改进之。――如果你能够跳出项目之外去看这个问题就会看到，其实时间问题是表象，而不是实质。

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!]