2009年11月23日 星期一 23:29
2009/10/15 Zoom.Quiet <zoom.quiet在gmail.com>: > 2009/9/28 Zoom.Quiet <zoom.quiet在gmail.com>: >> 2009/9/28 傅志红 <zhihong.fu在gmail.com>: >>> 最近一批新书上市,大家可以登录图灵教育网站,找找自己喜欢的图书。 >>> >>> 链接:http://www.turingbook.com/Books/ListBook.aspx >>> >>> 另外也可以推荐合适的朋友接受样书。每人有五个名额。 >>> >>> 也有个小要求,收到书以后要写点读后感(书评),发表在各自博客,并在此登记链接哦。 >>> >>> 请大家提供邮寄图书的地址、电话。 >>> >> 软件开发沉思录:ThoughtWorks文集 >> 最近这书争论很厉害哪,申请样书解读哈... >> 俺的Blog >> http://blog.zoomquiet.org/pyblosxom/ >> ... > > 今天俺收到书了!非常感谢! 在本周哲思峰会结束后,认真阅读给出感想 ;-) 不好意思,一直拖到现在才交作业,不过,的确是认真看了两遍才起笔的, 总想写很多,但是,又都是不成体系的,就吐点槽好了>...同时发布在: ZqreadThoughtWorksAnthology - openbookproject - 图灵:样书申请~软件开发沉思录 - Project Hosting on Google Code http://code.google.com/p/openbookproject/wiki/ZqreadThoughtWorksAnthology 应图灵俱乐部列表的倡议,申请了样书 "软件开发沉思录" 想就此进一步整理 敏捷中国2009 中的见闻; = Thought Works 文集 = 整体上是本包罗万象的薄书; 167页的容量包含了14篇,由 Thought Works 成员在日常工作中总结出来的真实体验, 非常不寻常;也非常真诚; 由于本人涉及软件开发时间不长,经验也比较狹窄,并没有对所有章节有所共鸣,特此评论其中非常有触动的: == "最后一英里" == 这是Thought Works创始人的,果然只说问题域,不给答案的;-) 这是所有高层在输出文字时的通病, 不过,这也正是现实世界的真实一面, "没有银弹" 回想俺在过往所有公司项目中的糟糕体验,对比所有自由软件社区项目中的自在体验; 也逐渐明白,掺合了利益的项目,都无法轻灵起来的,这是不可能的; 但是,我们可以选择自个儿的"态度"; 正如,这篇短文中最后给出的对策: * 深刻理解了问题本质后 * 勇敢的给出自个儿的应对,并坚持下去,坚信可以成功 就好,就好 ... == 对象健身操 == Jeff Bay 的这篇短文,则是标准的技术成员风格: * 给出解决方案 * 给出案例操作/自我训练流程 * 给出现实应用案例统计 完全的分享即学即用技巧的格局; 非常习惯,也非常受用,而且非常认同; 这些在使用 OOP 语言时,精练出来的原则,其实在各个公司,各种技术框架上都多少有些; 但是,可以总结到这种程度,以及可以内部推广坚持到的地步,实在叹为观止; 准备内部也精简结合相关静态代码检测工具,进行推广!-) * PS: 这篇和"重构Ant脚本" 那篇都是非常非常地道的技巧分享,只是俺没有什么机会用 Ant 就没有共鸣了>.. == 迭代经理 == 这是 Thought Works 自创的一种角色吧,非常有启发性, 这其实是给所有项目中的热心大妈正了名,给了一个"*经理"的名头; * 不过,的确这样将以前多个人自觉配合完成事儿,定一专人统一进行效率要高很多; * 但是,这真的有非常苛刻的先决条件的哪! 1. 团队是 敏捷的! 1. 项目是 敏捷的! 1. 文化是 敏捷的! 否则,迭代经理在开发/技术/项目/产品经理之间,纯粹是个概念>.. == 项目生命体征 == 咳!这篇就是一位成功的迭代经理的经验分享! 当然也同样适用其它各种经理 ;-) 给出了5种核心实用体征,以及图表的建立和使用方法; 嗯嗯嗯,对俺感触最大的就是"团队感觉", 在我的团队中也在部分使用,只是: * 这东西真的要坚持才可用! * 真的要习惯才管用! * 真的要诚实才能用! * 真的要认同才要用! 真的是是真的用才可以的.... 看过太多各种 KIP/PPC 等等对程序员的绩效考核,都考不到点儿上, 但是"团队感觉" 非常容易作到是真实的, 但是,非常难以和真实的绩效结合起来... 这也只能是在有足够空闲的情况下的一种参考... == 一键发布 == 果然是位技术主管的文章,这种全流程的自动化,没有高层的支持是绝对作不下来的; 每次看各种自动化全流程的方案时,都在流口水,其实我的团队主要是 Python 为主进行开发的,和 Thought Works 的核心开发语言 Ruby 是同类的动态脚本语言,照理,这种没有编译过程的动态脚本系统,应该非常好进行"一键发布"的; 但是,真正的作了才发现很难要很大的决心和毅力: 1. 先建立配置管理规范 1. 再建立测试主机环境 1. 再确立版本发布策略 1. 然后明确一切都是理解并执行的 1. 最后才是"一键发布"的配置而已... 前提条件的各种团队建设的事儿,只要超过3人,就非常容易进入中国的江湖状态,难以理清楚了... * 羡慕从一开始就竖立规范的团队, * 或是有大神力,大法力的技术主管,可以整合所有人的思想和行为,快速打造出这一流程>.. = 小结 = 书名翻译的好: * Thought Works 文集 * 被翻译为 "软件开发沉思录" * 的确,所有文章没有真实的项目经验支撑的话,是写不出来的 * 而且 Wought Works 作为专业的敏捷文化推广者和受益者,可以说一直处在对自我和项目的不断反省中 只是,这么小的书这么贵有点难以下决心买... > 2009年哲思自由软件峰会-行动-哲思自由软件社区 > http://www.zeuux.org/campaign/zeuux-summit-2009.cn.html > > > > -- > http://zoomquiet.org 人生苦短? Pythonic! > Time is unimportant, only life important! > -- http://zoomquiet.org 人生苦短? Pythonic! 工作的层次(依靠谱程度从低到高)=有做->做完->做对->做好->帮助他人做好
Zeuux © 2024
京ICP备05028076号