精华内容
下载资源
问答
  •  3敏捷开发需要把软件设计分成三个部分:特性->用例->任务 特性:对最终用户有意义的一个功能 用例:由特性分解而来的一个可以用来做功能测试的小情节 任务:用例分解而来,有开发人员需要完成的一个最小的工作单元4...
  • 在这篇文章中,将会介绍如何成功地完成了一个大型的(20人年,超过十万行代码)、分布式(开发人员位于印度和荷兰)Scrum项目,而这个 项目曾经在传统开发方式下被废弃过 。为了帮助读者顺利运作大规模项目,在这里...
  • 不知道大家是否还记得年初写的《软件工程四十年预测》一文,里边提到了“实践软件工程”的概念。也就是说未来引领软件工程的不再是少数大师,而很...敏捷开发的主体,不是理论也不是大师,而是所有不执着于定论,勇...

    不知道大家是否还记得年初写的《软件工程四十年预测》一文,里边提到了“实践软件工程”的概念。也就是说未来引领软件工程的不再是少数大师,而很可能是在实践中不断摸索,或有经验或有教训或有心得的普通一线开发者和管理者。

    本书是由京东、IBM、淘宝、SAP、暴风影音等IT名企专家——也包括博主本人微笑——所编写的敏捷经验分享,都来自于真实的开发经历。

    敏捷开发的主体,不是理论也不是大师,而是所有不执着于定论,勇于不断摸索最好方法的一线人员。书名叫做一千零一夜,就是希望实践者的故事永远讲不完,期待大家的参与和分享。

    京东,亚马逊、当当、互动出版社均有销售,以下内容节选自京东的介绍(今天图书上了京东的首页,在“新书速递-科技”栏目下)。

    内容简介

      《敏捷开发一千零一夜》以多位作者的亲身经历,再现真实的敏捷实施过程,描述各个企业在实施敏捷的过程中,遇到的种种问题、解决的思路及最终得到的经验与教训。这本案例集从不同的视角,为读者展示从大型互联网企业到初创公司、从大型国企到独资外企、从典型的甲方到第三方咨询公司的敏捷历程。这里面既有大的组织的敏捷转型,也有一个小团队或个人的敏捷历程,还涵盖某个敏捷实践或工具的应用描述。
      本书的特色在于由真实实践提炼,对正在实施敏捷的读者具有很高的参考价值。

    作者简介

    陈勇,在工作的17年间,曾任其程序员、项目经理、事业部总监、副总经理、咨询师等各种技术与管理岗位。开发中获得的一线工程经验和CMMI/FPA功能点估算/敏捷开发等跨领域知识,令其可以更广的视角来理解敏捷开发。

    当前他作为产品经理、架构师带领一个小型团队,从事“火星人敏捷开发在线平台”的研发工作。很多课程与咨询中的最佳实践,均来自于其之前及当前参与的实际项目的一线实践。本书收录的文章就是他们在实际开发过程中,同时应用敏捷开发的用户故事和功能点估算中的功能点时的实际经验总结。
    日常工作与培训之余,陈勇在其博客http://blog.csdn.net/cheny_com上总结编写了300多篇系列文章,点击量150万次,其中200篇以上是敏捷开发相关的文章,力求逐一解决敏捷开发中的一些似是而非的问题,为一线工作人员及敏捷推广者提供完整透彻的应用思路和方法。


    杜伟忠,中国人民大学管理学硕士,京东商城敏捷教练,精通Scrum、Kanban、XP等敏捷实践。10年电信软件开发经验,6年敏捷实践经验,其中有3年教练经历。作为教练指导团队超过200人,目前专注于互联网公司敏捷的推广和实施。


    冯国馨,网名“谷雨霖”。天津大学工学博士、PMP 联合永道高级副总裁兼CTO
    PMBar IT项目管理实践公益社区创始人、天津大学北京校友会秘书长
    曾任神州数码网络研发中心副总经理、质量管理部总经理,现任联合永道高级副总裁兼CTO、联合创始人。美国项目管理学会协会PMI会员、中国国家外专局资深专家、中国系统与软件过程改进协会主任专家会员、中国计算机学会软件工程师工作委员会专家组成员、国家应用软件产品质量监督检验中心特聘专家。长期从事项目管理、产品研发、持续改进与团队管理,对教育信息化建设有一定见解。创办IT项目管理实践公益社区www.pmbar.net,长期积极活跃在CSPI、CSDN CTO俱乐部、IT168等IT管理社区,与用友集团、阿里巴巴集团、盛拓传媒、搜狐集团、安博教育集团、神州数码集团等多家IT单位多次开展沙龙交流活动。


    史昀,2004年毕业于上海交通大学,同年拿到国家高级程序员证书,2009年获得PMP认证,2010年作为CMMI评估组成员参加CMMI 3级评估,典型的技术型管理人员,沉浮于软件开发行业,专注于通信、商业类软件研发,为国内外大型企业客户提供咨询、实施等解决方案,关注软件工程及相关领域的研究与培训。现就职于一家大型外资ERP软件厂商,从事财务软件、软件生命周期以及LEAN相关内容的研究。


    王立杰,敏捷爱好者、实践者,独立培训师,专注Scrum与XP。2006年开始探索敏捷,应用敏捷,于2009年与许舟平合作出版国内第一本小说体敏捷项目管理图书《敏捷无敌》;2010年进入敏捷咨询培训领域,为诺基亚、北电、爱立信、VMWare、阿尔卡特-朗讯等多家公司提供服务,曾在AgileChina、ScrumGathering、AgileTour等行业会议发表多次主题演讲。


    许舟平,就职于IBM公司。本一北国布衣,求学于西,工作于都,躬耕于代码十余载,苟全技术于IT间,不求闻达于海内。
    亲实践,远空谈,此敏捷之所以兴隆也;实践者,敏捷之本。盖闻流程者莫高于Scrum,实践者莫高于XP,皆因敏捷而成名。今天下贤者智能,岂特西洋者乎?好友立杰,邀士十余,原始察终,见盛观衰,论考之行,历经春秋,终成此集。
    敏捷者,其行虽不轨于瀑布、CMMI等,然其言必信,其行必果,已诺必诚。周易曰:天下一致而百虑,同归而殊途。窃以为,敏捷之事,内立法度,务实践,修研发之具;外连横而协客户,则事可成已。至于XP、Scrum、Lean、Crystal等,各有所用,若欲循观其大旨,可阅此书。
    布衣之人,不害于政,不妨百姓,取与以时而行敏捷,仅愿读者有采焉。


    杨立东,就职于暴风影音公司。PMP,美国加州州立大学富尔顿分校硕士,中欧国际工商学院EMBA,华中科技大学特聘教授。北京暴风科技股份有限公司董事、首席技术官。2011年第二批“中关村高端领军人才聚集工程” 科技创新人才。发表学术论文4篇。曾从事过6年一线Java开发工作,作为项目经理带领过多个大型软件项目,2006年 开始从事CMMI咨询和评估工作,服务过的软件企业超过30家,多次举办项目管理,软件度量,敏捷项目管理的公开课,培训人数超过15000人。2008年开始专注于公司级管理工作,2010年开始总结自己多年的研发管理经验,专注于互联网公司敏捷项目管理的推广和实施。


    杨瑞,个人简介:厦门英睿信息科技有限公司联合创始人,目前致力于敏捷的推广,研发管理咨询、培训及移动开发。
    10年软件工程管理经验,在基于传统和敏捷的开发管理方面具有丰富经验。曾任三五互联产品技术中心总监、福州网龙程序中心高级经理等职位,擅长软件研发管理、过程改进咨询、培训及实施,精通CMM、CMMI及Scrum。
    2011、2012年ScrumGathering分享嘉宾,2011、2012年AgileTour厦门站&福州站组织者、分享嘉宾,Agile China 2013程序委员会专家,厦门敏捷社区发起人、技术社区积极分子。


    张克强,思碧睿inspearit高级顾问,高级程序员、系统分析员、IPMP、CSM。
    本硕毕业于清华大学。曾在宝信软件担任过测试经理、EPG组长、项目总监,曾在Intel担任过QA Manager,曾在DNV担任过资深咨询师。
    在软件工程/系统工程方面拥有10年多经验,主要经历在组织过程改进、质量保证和测试方面,帮助组织参照CMM/CMMI/Agile/Scrum等进行改进,在软件开发技术方法论和流程管理两方面都积累了丰富的经验,熟悉OOAD,UML,TDD, 测试等等。

    目录

    第一篇 组 织 篇
    第1章 暴风敏捷项目管理实践
    一、暴风的项目危机
    二、组织级的敏捷初体验
    三、再次组织级探索
    四、持续优化的力量
    五、组织改进中人的因素
    第2章 淘宝的敏捷实践与过程改进
    一、背景介绍
    二、不同背景下的解决方案
    三、ScrumMaster心得
    四、敏捷与过程改进
    五、工具的支持
    第3章 从CMMI5到敏捷
    一、案例背景
    二、敏捷导入过程
    三、敏捷优化改进过程
    四、整体回顾
    第4章 从装甲兵团到特种部队
    一、引子
    二、实施过程
    三、反思

    第二篇 产 品 篇
    第5章 火星人一千零一夜
    一、第一个月:一个产品的诞生
    二、第二个月:框架优先,还是故事群优先
    三、第三个月:故事树
    四、第四个月:用户故事的颗粒度(上)
    五、第五个月:用户故事的颗粒度(下)
    六、第六个月:用户故事的分类
    七、第七个月:分类语法
    八、后记
    第6章 从敏捷到精益
    一、背景
    三、破窗理论
    四、敏捷宣言错了吗
    五、南辕北辙
    六、MVP才是王道
    七、跨越鸿沟
    八、小结

    第三篇 团 队 篇
    第7章 敏捷英雄传之火烧赤壁
    一、人物介绍
    二、故事梗概
    三、引子
    四、CEO孙权的故事:计划永远赶不上变化
    五、CTO周瑜的故事:究竟是变好,还是变得更烂
    六、产品经理太史慈的故事:一个大版本经理的困惑
    七、编码狂人凌统的故事:主刀,就是能上得天堂,下得地狱的主儿
    八、测试经理陆逊的故事:敏捷测试,就是明知不可为而为之
    九、产品集成主管甘宁的故事:持续集成的烦恼
    十、臭皮匠的话
    第8章 打造学习型自适应团队
    一、背景介绍
    二、团队实践过程
    三、回顾与反思
    第9章 从传统软件开发到敏捷的初体验
    一、背景
    二、迈出第一步
    三、对第一次迭代的改进
    四、关键的第三次迭代
    五、第四次迭代:低耦合软件设计
    六、总结
    第10章 敏捷在传统软件与互联网中的应用
    一、背景介绍
    二、敏捷实施过程
    三、回顾与反思

    第四篇 实 践 篇
    第11章 敏捷无它,唯持续改进
    一、背景介绍
    二、我与敏捷的第一次亲密接触
    三、敏捷原来是这样的
    四、第一个挑战
    五、团队的好奇心
    六、更多挑战
    七、团队的惯性
    八、镜子
    九、从一开始就要高标准
    十、TDD的争议
    十一、“道”与“术”
    十二、程序员文化
    十三、程序员与建筑工人
    十四、TDD不是目的,“拉”与“推”
    十五、Coding Dojo
    十六、让实践落地
    十七、程序员的产出
    十八、权威
    十九、认同权的建立:无私,勇于说不知道
    二十、成就感:点燃程序员的热情
    二十一、PDD:痛苦驱动开发
    二十二、排除障碍,创建舒适的技术环境
    二十三、投资回报率
    二十四、让领域模型裸奔
    二十五、架构
    二十六、你做什么就是什么(You are what you do)
    二十七、Scrum是不行的,如果只有Scrum
    二十八、做正确的事情 vs 正确地做事情
    二十九、问题和解决方案,5-whys
    三十、“为什么”
    三十一、估算(动词)很有帮助,但估算(名词)往往没有
    三十二、守破离
    三十三、测试优先
    三十四、QA vs QC
    三十五、分享:Wiki、博客、书籍、技术讨论、编程练习
    三十六、没有银弹,只有持续改进
    三十七、敏捷宣言
    第12章 网龙持续集成实践
    一、案例背景
    二、案例分享

    前言

      前些日子,有人在微博上发文说,现在IT界有三大俗:云计算、大数据、敏捷,这从一个侧面反映出了敏捷的热度!如果你最近一年内参加过各类IT过程改进大会、测试大会、研发管理大会、案例研讨大会,一定会发现有很多人在讲敏捷、谈敏捷,而且占据的场次越来越多。以前是我们这些所谓的敏捷狂热分子在讲,现在连一些CMMI/PMP死硬分子也加入进来讲。敏捷让以前的CMMI/PMP阵营不得不做出调整,PMP搞了敏捷的认证,CMMI新出了1.3版,据说里面有97处提到了敏捷……这从另外的角度说明敏捷的确已经入“俗”。
      中国人素来讲究雅俗共赏,在这个越来越“俗”的过程中,我们该怎么保持那份“雅”呢?希望大家在看热闹、参与热闹的同时,能够冷静地思考,敏捷到底能为我们带来什么?我们该如何变得敏捷?敏捷又将何去何从?
      大师们也在思考,2011年,敏捷10年回顾的时候,将“追求技术卓越”放在了第一的位置;10年之后,敏捷又将如何呢?著名敏捷大师Mike Cohn认为:“在接下来的10年,面向对象世界中发生的事情会再次出现,即我们将不再讨论敏捷。不久前我们不再讨论对象了,因为它们已经胜出,没有人再会参加针对面向对象的大型辩论。当然,还有一些应用我们不使用对象,比如有严格性能要求的应用,也有些项目是用非OO语言开发的。但即使在这些案例中,我也怀疑开发的代码仍然受到对象的影响。我希望敏捷也能达到这一点,我们不再讨论敏捷,不再说‘敏捷软件开发’,我们仅仅说‘软件开发’,当然一定是敏捷的。没有人会问我编写的Ruby代码是否面向对象,因为这毋庸置疑;我希望某一天也没有人问我项目中是否使用了敏捷,这也将会毋庸置疑。”
      在过去几年中,我们给客户做敏捷培训时,收集到的最多的反馈之一,莫过于学员想听到更多的敏捷实施案例。于是,慢慢地就有了收集各类敏捷实施案例的想法,并日渐强烈起来。毕竟,每个人都有偷窥别人隐私的好奇心,不然Twitter、微博也就不会这么火了。同理,正在实施敏捷的人,无论自己做得好的,做得不好的,其实都希望看到同行是怎么做的。
      冯国馨,作为PMBar IT项目管理公益实践社区发起人,在社区内外的各种敏捷分享和交流过程中,看到大家也非常希望了解、学习和探讨国内不同IT行业、不同特点IT企业敏捷开发的真实案例。加之,2011年8月PMBar社区推出的第一部实践案例书籍《IT项目管理那些事儿》在社会上反响热烈,至今图书热卖万余册。这些极大地增强了我们进一步开展敏捷实践案例书籍撰写的信心!
      于是,在王立杰的协调下,PMBar社区内外的十几位敏捷专家决定共同分享自己的敏捷实践案例,希望通过出书使行业内的敏捷实践者或敏捷观望者有所借鉴和体悟。
      本书采用的是叙事的风格,通过分享每个敏捷实践者自身的实践案例,为读者展现一个个鲜活的敏捷实施过程,展示敏捷团队的成长烦恼和喜悦,从而和读者达到共鸣。这是一个百花齐放、精彩纷呈的故事集,就像《一千零一夜》一样,有十几位作者,他们中有来自国际著名IT公司的敏捷专家、有来自国内著名电商的敏捷教练、有来自大型国有企业的IT总监、有民营高科技企业技术管理者,有纯粹的敏捷实践者、也有CMMI/敏捷融合实践者等,他们以不同的经历、用不同风格的言语,为我们描述一个又一个精彩的敏捷开发故事。
      感谢本书编委会全体成员(王立杰、冯国馨、许舟平、陈勇、杨立东、张克强、杨瑞、杜伟忠、郑贺宸、蔡阿彬、胡峰、范佳莹、马越、史昀)的共同努力,因为他们的努力才有了这本书的诞生。感谢电子工业出版社博文视点的张月萍,她的“博文视点除了盈利的任务外,还承担着教育用户、传播思想的重任!”一句话为《敏捷开发一千零一夜》这本书画龙点睛。我们希望这本书能启迪正在或者准备开展敏捷实践的读者,如果它帮助你加快了敏捷步伐,那就是我们最大的欣慰。
      再次,真心感谢曾经为此书劳心劳力的各位朋友,愿天下人幸福安康。
      编者

    展开全文
  • 最新在博客园看到一篇博文,介绍一个混乱小项目的敏捷应用,作者利用XP(极限编程)的最佳实践完成了近乎不可能完成的项目,由于没有博客园的账号,不能在原文留言,转过来供自己学习参考。  原文地址:...

            最新在博客园看到一篇博文,介绍一个混乱小项目的敏捷应用,作者利用XP(极限编程)的最佳实践完成了近乎不可能完成的项目,由于没有博客园的账号,不能在原文留言,转过来供自己学习参考。

            原文地址:http://www.cnblogs.com/meil/archive/2007/03/13/672530.html


           原文内容如下:       

    我们假设一个project中有以下状况:
    (1)需求不明确,没有完整、详细的需求描述。用户没有提供标准的需求文档。
    (2)技术架构明确要求为J2EE,要求使用:Struts,Tile,EJB,DAO,OJB,数据库为Oracle 8i/9i,集成开发工具要求为WSAD,系统有大量的计算,对性能有明确要求。
    (3)团队人数为6人,三人为刚大学毕业的新人,对上述技术架构和开发工具不熟悉。另外3人均不能full time参与。其中项目SA只能参与第一周(5天)。
    (4)交付时间特别急,要求3周就必须完成。但是交付物只需要:SRS(软件需求描述)、源代码/安装包、安装文档,不需要概要设计、详细设计等文档。
    (5)项目规模不大,业务需求约为12个左右,其中有5个非常简单的需求(增加、删除、修改,没有特别的计算)

    基于上述状况,不能根据大概判断就直接拒绝,首先进行了风险识别(实际的Risk Management Plan就不show了):
    (1)项目范围不明确,特别是不明确最终用户的需求。
    (2)没有确立变更机制,没有SOW(Statement of Work)
    (3)没有明确的验收条件
    (4)没有合适的标准软件过程、开发模式、生命周期适合本项目
    (5)对于上述的技术架构没有经过验证和测试,特别是OJB。
    (6)项目组对于上述技术(J2EE)要求没有足够的开发经验,有经验的SA时间不能保证。
    (7)项目组对于客户指定的WSAD不熟悉
    (8)测试服务器的性能可能不能满足测试要求
    (9)关键资源(SA和另外2位)不能确认能够参与的时间
    (10)Team为全新,之前都没有互相进行团队并行开发
    识别风险后对每一个制定了应对计划。
    做到这里,已经可以跟Manager汇报说不可能了...

    然后基于项目需求分解WBS(Work BreakDown Structure),找来SA进行历时估算,对每一个UseCase估算其开发时间,当然按照有相关开发经验的人员来估算的。得到了总共Effort以及Price。
    根据最终的交付时间回溯列出了一个Schedule,设置多个重要的Milestone。

    回来来Review自己做的Project Plan,仔细看看Schedule,可能吗?别忘了,我们还不能周六周日加班,-_-。

    不管如何,这是个混乱的项目,进度、资源、风险,各个方面都有大的问题,抱怨是解决不了问题的,还是脚踏实地做下去吧。

    回过头来,该做的事情还得继续做下去:
    第一步,控制需求(Scope)。客户不是没有需求描述吗?我们自己根据其提供的需求原始文档编写,同时做出需求的UI原型,我们不确定的地方都做为Assumption。提交给用户审核,不必要的功能通过谈判砍掉:时间这么短,架构、性能要求高,怎么可能做出那么多需求来?很快需求控制住了,我们实现的功能很明确。
    心得:这个项目能够控制住需求的原因有二:(1)采用需求原型开发,根据自己对需求的理解快速把UI整理出来。(2)仔细的编写SRS,把一些假设(Assumption)明确的写进去,避免后续的问题。

       现在该回到主题:XP(极限编程)了。
       (1)No Plan, then plan every day. 现在说自己写了一个项目计划,但是3周时间,这么短如何跟踪?所以每周制定一个Activities List,每天计划,每天跟踪!任务分配到个人并定义相关接口人员。
    心得:(a)天天分配新任务并跟踪的做法对于Team members来说工作强度太大,压力也太大,不适合长时间项目使用。一般我会事先说好采用的时间段。在长时间项目中只在关键阶段采用该方法。
    (b)天天计划要求PM对工作任务和技术方面非常熟悉,否则就是瞎指挥!危害很大,Team members背后可能都把你骂死了,你还自以为自己安排得非常好。因此首先需要征询SA或者Senior Enginneers的意见,在计划和分配时也需要得到相关members的同意。不要直接命令下去。
    (c)理性对待Delay,过程中有2天的Delay,不要试图加班等初级手段赶上去,一般来说,赶只会越赶越慢。想想看有没有其它的解决之道。

      (2)Continous integration:采用Smoke Testing的方法. 也就是冒烟测试,保证从项目初期到最后交付都有一个可运行的版本。指定一个配置管理员,负责每天将最新版本部署在测试服务器上,保证可以编译并运行。
    心得:由于配置管理skills方面的原因,初期并未能run起来,之后才能得以跑起来。

      (3)Simple Design:其实我想做详细设计也没门,因为SA只有一周的时间参与,怎么做?做一个例子,数据库上建一个table:product,然后从前台JSP,Tile ->Struts->EJB->OJB->DB能够跑通,可以在页面上add,delete,update。嗯,中间漏了DAO,可以以后加嘛。这个例子做好之后做为例子供其它Team member学习和熟悉。
    心得:迫不得已的做法,但是的确有好的效果,在SA做这个例子的期间,其它人紧张的进行环境准备和技术准备,大家得以熟悉开发工具和开发环境以及必须的技能。有一个现实的例子,普通程序员开发起来心里更有底一些,自己设计会有问题,难道照着做还不会吗?

      (4)Pair programming,当然有些变通,Pair programming的意思是两个程序员在一台机器上来开发代码。我的做法是将前台部分的功能(从Jsp,Tile,struts到EJB)根据不同特别分配给3位Entry SE(入门级软件工程师)。这部分工作量很大,大家的缺陷都非常多,但是通过互相检查和共享,效果很不错。进展快得人可以更快将功能集成进系统。
    心得:如果采用水平分配任务,可能有的人能够做得好能够提前进度,但是任何一人出了问题,那么整个系统就没有一个功能可以run,同时在接口上的沟通成本会非常大。

      (5)40-hours work, 在项目初期就先说好,前两周开发时间不要求加班,在最后一周集成测试时才要求晚上部分加班。
    心得:象这类风险大的项目,如果全靠加班才能做好,那么肯定是初期有大问题。还是那句话:进度不是赶出来的,进度是plan出来的。

    没有完全采用CMMi的一套Process,而是采用了XP的部分Best Practice,最终项目按时、按质提交,似乎完成了不可能完成的任务,但是当SQA来Audit的时候,报表很难看。所以采用这种方法有以下缺陷:
    (1)知识保存:所有的项目管理经验都在PM脑子里,设计理念在SA里,好的实现都在开发人员的脑子里和代码行间。项目结束后,不少项目组成员都到了其它项目组,后续项目(该项目有后续大的单子)得不到之前继承的知识。
    只剩下了结果。
    (2)Tracking:只有PM了解项目的真实情况,其它人都无法知道,SQA也没法检查(XP里面是没有SQA的)。

    由于一直是在CMMi下面Lead项目,因此部分工作还是采用CMMi的Process,比如配置管理(CM),需求管理(Requirement Management),PMR(Project Management Review),Risk Mangement, Issue Management,DefectTracking等等。


            从结果来看,作者的这个开发解决方案接近perfect,顺利完成了项目目标。虽然说过程资产缺失严重,但是这么短的周期,还能要什么自行车?如果按照正常项目开发流程,我想连立项恐怕都难以完成,更别提要交付给用户了。从整篇文章来看,作者对项目管理已经有了很高层次的理解,不仅是CMMi,还有敏捷开发,对不同类型,不同条件的项目也可以将从容应对,非常厉害。

    在作者的实施方法中,有几点非常认同:

    作者刚开始就针对需求做控制,把不确定的需求明确下来,确定项目范围,这点至关重要,在项目失败的原因中,需求的不确定是第一要因,更何况还是这么短的周期,需求稍微变一点,失败肯定是必然的。

    每周制定一个Activities List,每天计划,每天跟踪!这招比较狠,每天每个人都有一个deadline,鸭梨山大,在这种情况下,每个人每天都很明确自己的任务以及完成时间,虽然有压力,但是我想效率应该会很高,而且在项目完成之后team member的成就感会很大,对士气的提升很有帮助。

    简单设计,作者根据XP的实践准则结合自身项目特点,制定了适合自身项目的设计准则,比如由SA做DEMO,其他新人并行熟悉环境,随后再由新人参考DEMO来做开发。


    也有不太认同的:

    结伴编程,作者描述的太简单,木有看出来哪里有结伴。

    40-hours work,项目时间紧急,又有很多不确定因素(比如需求、WSAD),虽然我很不赞同加班,但是这种情况下,开发周期不长,要求team member保持高效率、高产出比硬性遵守每周40hours更合适,如果下班之后,某个兄弟感觉自己依旧精力旺盛,又十分愿意主动加班,这个时候我想应该对项目,对团队来说都不是什么坏事,但前提是加班不是完全无偿的,至少要提供调休或者其他福利之类的,这样大家才会有动力,毕竟雷锋同志不是每个人都愿意当的。

    统一编码风格这篇文章中没有说明,不知道在这个项目中有没有用到,这个项目中有几个新人,如果没有统一编码风格,很可能最后代码风格非常混乱,或者根本就没什么风格(有的童鞋编码从来不讲究风格),如果是这样,以后维护的童鞋有罪受了。


    展开全文
  • http://www.itpub.net/868217.html
    http://www.itpub.net/868217.html
    展开全文
  • 我把原文去粗取精了一下,保留了一些核心思想,去掉了小日本的广告.1 任务板任务是分解到手头的... 2 需求特性板需求特性是软件大的功能需求,通常按照月份来进行归类.3 敏捷开发需要把软件设计分成三个部分: 特性->用

    我把原文去粗取精了一下,保留了一些核心思想,去掉了小日本的广告.

    1 任务板

    任务是分解到手头的实际的工作

    把要做的任务,正在做的任务和已经完成的任务,用简单的贴士贴在白板上.不同的颜色表示不同的重要程度.

    可以画一些横的泳道来表明任务应该是谁来完成.

     

    2 需求特性板

    需求特性是软件大的功能需求,通常按照月份来进行归类.

    3 敏捷开发需要把软件设计分成三个部分: 特性->用例->任务

    特性: 对最终用户有意义的一个功能
    用例:由特性分解而来的一个可以用来做功能测试的小情节
    任务:用例分解而来,有开发人员需要完成的一个最小的工作单元

    4 敏捷过程中,时间分为: 发布->迭代->每日

    发布:通常一到六个月
    迭代:通常一到四周
    每天:

    5 我们把工作和时间对应起来,就是这样

    在每一个发布过程中,我们完成需求.
    在每一个迭代周期中,我们实现案例
    每一天,我们都要完成多个任务

    6 更形象一点,我们把他们都结合起来:

    你要准备三块黑板:

    需求特性黑板:每一列标识一个发布需要完成的特性
    案例黑板:每一列标识每一个迭代周期需要完成测试的案例
    任务黑板:每一天要做的任务

     
    展开全文

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 654
精华内容 261
关键字:

敏捷开发案例