敏捷软件开发---闲话敏捷

第一篇状态模式,其实比本文更先发表。但是我终觉得要写点什么,来开始我的敏捷的旅程。知道看了bob大叔这本书

以后,我才知道敏捷到底是怎么回事,纯属个人东拉西扯,所以就叫闲话敏捷。

《敏捷软件开发》问世与2003年,距今已有13个年头了,能够历久长盛不衰,必然有其光辉的一面。

以下都是个人的经验结合《敏捷》讲解和分享一些东西。

敏捷软件开发 乍一看有点摸不着头脑,不知道是什么东西。

软件开发从计算机问世直接快60个年头了。软件也从非常简单的机器语言,到现在的面向对象。

在这个过程中,无数的开发者,遇到了各式各样的问题,而中间绝大多数问题现在的开发者还在重复。

软件开发是一件非常复杂的脑力活动,尤其是大型复杂系统,方方面面的问题将非常之多。而对于软件设计而言,

更是建筑在软件开发上一层的框架。

无数的先贤,在众多软件开发“思想”中提炼了23种设计模式,这就是闻名于世的“设计模式”。

敏捷这个东西也是在2001年的时候,软件开发团队自发组织了"agilealliance"

敏捷软件开发是对设计模式的另一种表述。

Bob大叔是业界有名的大师。他的著作在软件业界是公认的经典。

《代码整洁之道》

《程序员的职业素养》

《敏捷软件开发》

《UML for Java For Promgram》

《Extreme Programming in Practice》

这里有一些关于程序员个人修养的书籍,可以选取部分作为阅读过程。

http://agiledon.github.io/blog/2013/04/17/thoughtworks-developer-reading-radar/

当然程序开发是一门艺术,而非仅仅是民工。

9年以前当我有幸成为一名软件开发者的时候,我不停的追随的技术的脚步,涉猎颇广,但是杂而不精。

一开始做VC++,后来做纯C的rom开发,大概2年后开始C++的开发,一直从事手机rom方法。

大概从2012年开发,转向android开发,期间应该是C++和java一起使用,差不多2年以后,渐渐发现流于语言表面的技术,属于 

浅层次的开发。

从15年开发,转入互联网行业,开始研究各种设计模式。毕竟从android & ios兴起以后,java取代 C++的趋势更加明显,或者说语言的

屏障已经变得不重要了。C/C++ 对于软件性能的提升其实已经被硬件的快速升级所取代。

代码本生的性能(内存消耗,内存泄漏等)已经远远大于语言带来的问题。

当然也有安全方面的东西,或者反编译这种东西的存在,但是对于一个大型的软件项目,软件的设计和维护已经远远超越所谓的细枝末节的技术点。

软件的原则,模式,实践都很重要,但是更重要的是人。

所以,对于软件开发趋势而言,最重要的不是积累一些设计模式,一些现成的代码框架和解决方案。而是培养可以使用和创造这些方法的人。

可以在一起协作,开发大型项目的软件开发团队。如果只是把每个软件工程师看成是一堆码农堆砌的结果,那么这个团队的产品也只是一个个

堆砌的代码而已。

把团队人员按各自的特长和经验做有效划分,有构架师,teamleader等角色,还有充分有效的沟通,一个开发团队的负责人才能启动这个团队的活力。

而每个人也可以看到自己的成长方向。这是一条艰辛的路。形成这个团队可能只要一位老大+若干核心成员。但是这需要长期的合作,才能产生这样的领袖核心。

兵不在多而在于精,这个道理以前很难理解,最近开始有了深刻体会。一个几十人的团队如果是一群乌合之众的话,远远没有10来个人的精干团队的效率来的高。

人数的增加会扩大内部沟通的成本。如果老大还没有很强的个人魅力和领导能力,根本没有能力指挥一群只想分配既得利益的人。

李云龙去独立团形成战斗力的过程,可以说是一个团队建立的完美过程。

1.去的时候要了张大彪 ,搞了几百套棉服。要张大彪很简单,“用的顺手”是李云龙的原话。有了张大彪+李云龙+孔杰 就形成了一个新的领导团队。

棉服是靠着当厂长的机会搞得,有好处他李云龙当然要捞。一个老大就得给小弟们,谋福利。一句话,“跟着你,有肉吃”。老大为小弟谋福利,小弟们就会

给老大“冲锋陷阵”。相辅相成,这个团队的战斗力就上去了。

2.赵刚去的时候,李云龙套路很明确。这一亩三分地,我说了算,听我的,一起干,不听我的,直接搞走。

1)喝酒。跟我一条心,就喝酒,就是咱一伙的。

2)分权。军事我管,生活你说了算。就是确地主导地位,大权必须在手上。

3)要人。和尚是个人才,李云龙没跟赵刚客气,直接要了。

当然这3件事,赵刚都很到位,所以很快确立了“二把手”的位置。要知道张大彪跟着李云龙多少年了,还没有赵刚地位高,

1)赵刚是组织确认的政委

2)赵刚能和李云龙他们混到一起

3)赵刚文武双全。(抗大毕业+神枪手)楚云飞,这么心高气傲的人,第一次见赵刚,也很佩服。

所以解放以后,赵刚明显混的比李云龙要好。

其实李云龙一直谋划的无非就是:

对团队的绝对领导,这是一个精小团队必须保证的指挥权。

兄弟们跟着我干,有肉吃。但是,该出力的时候,你们必须出力。

这就是只要给我枪,给我炮,我能拿下任何一个山头。

一个优秀的软件开发经理,就应该具备这些素质。

软件开发,精细化的趋势越来越明显。精小,稳定,快速,是现在软件APP的特点。

没有强大执行力的团队,很难做到。

一个合格的软件开发从业人员,应该把软件开发当成一门艺术。

这是工业社会和20世纪以前从来都没有的工作:它需要非凡的智力 和高超的情商,才能创建出优秀的软件产品。

一个优秀的软件开发经理,当然打造这样的一个团队,我相信,在当今信息科技时代,必有他的一席之地。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
目录   译者序   第2版前言   第1版前言   第0章不可知和不可说   0.1和解析体验相关的问题   0.1.1解析模式的冲突   0.1.2检测解析模式   0.1.3思考不准确的思想   0.2沟通的不可能性   0.2.1内部重新组织   0.2.2触及共享体验   0.2.3管理不完美的沟通   0.3聆听的三个层次   0.3.1三个层次和方法集   0.3.2三个层次与本书   0.3.3守-破-离   0.4那么,明天我做什么   第0A章不可知和不可说:演进   0A.1沟通和共享的体验   0A.2守-破-离   第1章创造和沟通的合作博弈   1.1软件和诗歌   1.2软件与博弈   1.2.1博弈的类型   1.2.2软件与攀岩   1.2.3创造和沟通的博弈   1.2.4软件与工程化   1.2.5软件与模型构建   1.3再论合作博弈   1.3.1程序员成为沟通专家   1.3.2更快地博弈   1.3.3标识物和道具   1.3.4减少回报   1.3.5对于首要目标的充分度   1.3.6对于积淀的充分度   1.3.7博弈中的博弈   1.3.8开放源码开发   1.4这对我意味着什么   第1A章创造和沟通的合作博弈:演进   1A.1沼泽游戏   1A.2合作中的竞争   1A.3其他领域的合作博弈   1A.4软件工程的重建   1A.4.1这一词汇从哪里来   1A.4.2我们从哪里走错了   1A.4.3重建软件工程   1A.4.4技艺   1A.4.5合作博弈   1A.4.6精益制造   1A.4.7重建后的软件工程   1A.4.8其他工程化中的协作   第2章个人   2.1人是古怪的   2.1.1寻找特征函数   2.1.2古怪性格的元素   2.1.3不可避免的多样性   2.1.4技术的作用   2.1.5相互冲突的共同点   2.2克服失败模式   2.2.1犯错误   2.2.2宁可失败也要选择保守   2.2.3创新而不研究   2.2.4不能始终如一的习惯动物   2.2.5使用纪律和容忍来应对   2.3以一些更好的方式工作   2.3.1具体化   2.3.2实物   2.3.3在某些东西的基础上进行修改   2.3.4观察和聆听   2.3.5支持专注和沟通   2.3.6工作分配要与个性相匹配   2.3.7天赋   2.3.8奖励要能保留乐趣   2.3.9组合奖励   2.3.10反馈   2.4利用成功模式   2.4.1善于四处寻找   2.4.2人们学习   2.4.3可塑性   2.4.4贡献和采取主动   2.4.5组合成功模式   2.4.6英雄也是普通人   2.5明天我该做什么   第2A章个人:演进   2A.1策略平衡   第3章团队的沟通与合作   3.1信息的对流   3.1.1延迟和机会损失成本   3.1.2尔格-秒   3.1.3渗透式沟通   3.1.4穿堂风   3.1.5信息辐射源   3.1.6热空气理论的应用   3.2跨越沟通的鸿沟   3.2.1沟通的形态   3.2.2去掉某些形态所产生的影响   3.2.3利用各种形态   3.2.4黏度与跨越空间的鸿沟   3.3团队就是集体   3.3.1友善和冲突   3.3.2工作时间的公民意识   3.3.3敌意的XP与友善的XP   3.3.4使用胜利来建立“团队”   3.3.5团队文化与亚文化   3.4团队就是生态系统   3.5我明天该做什么   第3A章团队:演进   3A.1一个修订后的办公室布局样本   第4章方法集   4.1一个交付软件的生态系统   4.2方法集中的概念   4.2.1结构术语   4.2.2范围   4.2.3概念术语   4.2.4发布一个方法集   4.3方法集的设计原则   4.3.1常见设计错误   4.3.2在方法集上成功的项目   4.3.3与作者的相关性   4.3.4七条原则   4.4细看XP   4.4.1XP简介   4.4.2剖析XP   4.4.3调整XP   4.5到底为什么使用方法集   4.5.1方法集解决什么问题   4.5.2如何评估一个方法集   4.6明天我应该做什么   第4A章方法集:演进   4A.1方法集与策略   4A.2组织级的方法集   4A.3过程就是循环   4A.4更简单地描述方法集   第5章敏捷与自适应   5.1轻但足够   5.1.1刚好足够   5.1.2对于编制文档的建议   5.2敏捷   5.2.1最佳击球点   5.2.2虚拟团队的麻烦   5.3变得自适应   5.3.1不厌其烦地进行反思   5.3.2方法集成长技术   5.3.3反思研讨会技术   5.4明天我该做什么   第5A章敏捷与自适应:演进   5A.1对于寓意的误解   5A.1.1迭代必须简短   5A.1.2敏捷团队必须驻扎在一起   5A.1.3敏捷团队不需要计划   5A.1.4架构已死;重构是你全部所需要的   5A.1.5我们不需要什么经理   5A.1.6敏捷开发在纪律上要求很低   5A.1.7敏捷只适合最优秀的开发人员   5A.1.8敏捷是既老又新的、失败的、没有尝试过的   5A.2敏捷方法集的演进   5A.2.1XP第2版   5A.2.2Scrum   5A.2.3实用主义和无名的   5A.2.4可预测、计划驱动和其他中心调整   5A.2.5约束理论   5A.2.6精益开发   5A.3新的方法集话题   5A.3.1敏捷项目管理   5A.3.2测试   5A.3.3用户体验设计   5A.3.4规划管控、Burn图和系统工程   5A.3.5用例和用户故事   5A.4经久不绝的问题   5A.4.1最佳击球点和下降   5A.4.2固定价格、固定范围的合同   5A.4.3敏捷、CMMI和ISO9001   5A.4.4何时停止建模   5A.4.5高科技/高接触的工具箱   5A.4.6敏捷的中心   5A.4.7你有多敏捷   5A.4.8引入敏捷   5A.5软件开发之外的敏捷   5A.5.1项目组合管理   5A.5.2客户关系   5A.5.3合同   5A.5.4将变更引入组织   5A.5.5程序员读哈佛商业周刊   5A.5.6建造房屋   5A.5.7机场建设   5A.5.8图书出版   5A.5.9会议组织和敏捷模型的限制   第6章Crystal方法集   6.1对Crystal家族塑形   6.1.1核心Crystal元素   6.2CrystalClear   6.2.1CrystalClear的简要描述   6.2.2CrystalClear的反思   6.3CrystalOrange   6.3.1CrystalOrange的简要描述   6.3.2CrystalOrange的反思   6.4CrystalOrangeWeb   6.4.1CrystalOrangeWeb的简要描述   6.4.2CrystalOrangeWeb的反思   6.5明天我该做什么   第6A章Crystal方法集:演进   6A.1Crystal基因代码   6A.1.1合作博弈的理念   6A.1.2方法集的重点   6A.1.3方法集设计原则   6A.1.4高度成功的项目的7个特性   6A.1.5技术与选择   6A.1.6样本方法集设计   6A.2CrystalClear   6A.3把CrystalClear扩展到Yellow   附录A敏捷软件开发宣言   附录Aa敏捷软件开发宣言和相互依赖声明   附录BNaur、Ehn、宫本武藏   附录BaNaur、Ehn、宫本武藏:演进   附录C后记   参考文献

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值