敏捷开发：千金难买早失败

   <p>我们不应该忘记任何经验，即使是最痛苦的经历。-- Dag Hammarldskjö</p>    <h2><strong>1、 前车之鉴</strong></h2>    <p>我们从项目管理的一个经典案例谈起。</p>    <p>这个项目是美国的A-12 Avenger II隐形攻击机。此款机型是冷战时期由美国海军主导开发的攻击机，它可以躲避雷达的侦测，一旦研发成功，不但海军会用，空军也会采用。</p>    <p><img src="https://simg.open-open.com/show/f3b21cef5f0f41cd856127063c512437.jpg"></p>    <p>但是随着项目的开展和时间的推移，A-12的研发遇到了很多的问题，其中一个最大的障碍是隐形技术的问题。</p>    <p><strong>对军事有所研究的同学知道，飞机要对雷达波隐形，有两种方式：</strong></p>    <p>第一种，利用飞机外形设计，在不同的方向散射电磁波，使得接收到的电磁波信号大幅度减弱，无法侦测飞机的位置；</p>    <p>第二种，利用特殊的涂料，透波材料和镀膜来减弱机体结构对雷达的散射。各国的隐形飞机，例如歼-20， F-25， F30都是利用这两种技术手段来达到隐形的目的。</p>    <p>事实上，给A-12的开发带来致命一击的是冷战的结束。1991 年 1 月 7 日，该项目在成本严重超支，时间严重拖后的情况下，国防部长Cheney下决心全面终止项目，并否决了美国海军提出的修改战技要求继续研制的方案。</p>    <p>A-12研发项目终止时，美国已经投入了2亿美金的成本，而此项目唯一的产出物是一个用木头做的模型。</p>    <p><img src="https://simg.open-open.com/show/a4eb4c197c37254a662a400775db4b55.jpg"></p>    <h2><strong>2、 软件开发是一场充满挑战的丛林探险</strong></h2>    <p>很多人曾问安娜： <strong>我们为什么要做敏捷开发？</strong></p>    <p>安娜想说的是，采用敏捷开发法不仅仅是为了快，如果A-12采用敏捷开发方法不断的验证克服技术上的困境和方案的话，DOD就不会遭遇2亿美金换来复仇者之死的局面；如果在项目监控过程中进行渗透式沟通和周期性回顾总结，项目的重大问题和风险就不会在历时2年之后才暴露出来。以更快的速度，更少的成本消耗应对现实世界需求的快速变化是敏捷管理法的优势，为了保障产品的成功（注意，不是项目的成功），敏捷式方法又离不开个体之间的互动和高效沟通。</p>    <p>信任和沟通使产品经理和团队成员都朝着同一个方向前进，这是许多敏捷基础实践诸如集中办公，需求交底，立会，迭代计划，共同估算，和反思的基础，同时也意味着更少的错误，更少的浪费，风险和成本。迭代过程是一个逐步求精的过程，而用户故事是互动和沟通的另一种体现形式，它鼓励团队推迟事无巨细得考虑细节，它又提示我们以随机应变的方式开发软件，使团队能够在高层需求及底层设计思考间来回切换，并以讨论为主不断精炼和挖掘客户的需求来回应市场的反馈。</p>    <p><img src="https://simg.open-open.com/show/63246dea00bead009c19e2f21debfd9b.jpg"></p>    <p>做敏捷要从改变固有的思维习惯开始，走出自我思维的舒适区。</p>    <p><strong>何谓Agile mindset？我认为它由如下几个方面构成：</strong></p>    <p>积极的态度，对产品的成功有很高的期待</p>    <p>以实用为出发点</p>    <p>个人的成功不是成功，团队的成功才是真正的成功</p>    <p>对未知世界和领域知识的渴求</p>    <p>勇敢尝试新的方法，坦然接受失败</p>    <p>我个人的理解：敏捷就是把一切作为经验教训总结，基于反馈及时的调整我们的下一步行动，并向着我们期待得到的结果出发，这才是促使团队持续改进的源动力。</p>    <p>我曾有幸和许多有才之士一起工作，他们经常从“这样做我们的产品/企业能获得什么”的角度考虑需求和问题，他们经常提出自己已经试验过的创新解决方案来克服项目中遇到的障碍，同时他们又是一群非常现实的实战主义者，从不吝啬帮助别人使团队获得成功。这些人，正是我在组建敏捷团队的时候想要找寻的最强助力。</p>    <h2><strong>3、 天下难事，必作于易；天下大事，必做于细</strong></h2>    <p>白蚁巢穴是世界上最奇妙的建筑，地面上有十几米，地下还深达二十几米，产卵室，育婴室，通风道等无一不缺，井然有序。科学家还发现白蚁开始建造一座蚁巢时像没头的苍蝇，没有秩序，一会儿把一粒小小的土块搬到这，一会儿又可能挪走。这么折腾一阵子之后，白蚁们就会建设起初级的形状，然后开始按着这个形状相对有秩序地添砖加瓦，变无序为有序，修修补补，日积月累就形成了形状各异，功能相似的蚁巢。蚁巢的建造过程颠覆了我们头脑的认知。</p>    <p><strong>《我们不要假装有远见，微小前进胜过完美规划》</strong></p>    <p>白蚁不是依靠详尽的规划，而是像我们中国人所说的“摸着石头过河”来做建筑。敏捷式项目管理何尝不是这样？我曾好多次以我党的长征为例，来向大家阐述“摸着石头过河”的敏捷项目是怎样一步一步实现了最终的目标，屡试不爽。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/1ca29d82859f7af759402840a8ec2633.jpg"></p>    <p><strong>敏捷式是一整套生态系统的搭建和维护</strong> 。</p>    <p>敏捷的成功实施既要依靠各级管理层对敏捷的完善和较为一致的认识，又要保证基层员工在日常的敏捷实践中踏实认真地执行每一个工作要素。</p>    <p>敏捷的实践，远远不只是每天站在白板前面“汇报”昨天今天做了什么，和time-boxing的迭代那么简单。团队要反思，拿什么反思？在建造“可用的软件”过程中，有历史数据没有？定性的反思容易流于形式，并且反思的内容都是大同小异，久而久之我们就会忽略‘反思’这项敏捷式方法中激励团队持续改进的精华实践。在用户故事，迭代计划会议等类似非技术实践中，团队还要结合TDD（测试驱动的开发），continuous integration(持续集成)，refactor(代码重构)等技术实践，否则想要生产出高质量的软件产品就是纸上谈兵。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/16ffb6ef9ba2ead6662362ceef7f89c9.jpg"></p>    <p>戊戌变法和明治维新是中国和日本在差不多同一时期进行的富国强兵的改革，但是一个失败了，另一个却成功了，为什么？因为日本不仅引进西方技术，更引进了西方的生产关系和政治制度，人家要学就学一整套的；中国人聪明，仅仅是引进了技术，我们习惯挑着学习我们容易接受的东西。</p>    <p>回头看团队实践敏捷的方法做项目，在起步过程中有很多同事问安娜，我为什么一定要每天更新一次JIRA的Scrumban?能不能两天更新一次，我都记得住？</p>    <p>安娜在这里冒昧的引用一句备受崇拜的改变了互联网时代的偶像的一句话来回答你： <em> <strong>Stay Hungry Stay Foolish.</strong> </em></p>    <h2><strong>4、 大成若缺</strong></h2>    <p>缺陷是任何事物的组成部分，只要我们是从不同的角度去观察他的。产品如此，人亦如此。</p>    <p><strong>互联网产品软件开发的路径，是一条充满了荆棘，陷阱和无奈的开发者之路。</strong> 在营造团队敏捷价值观的同时，我们更应该关注团队自身的发展，让团队成长为一个“自我组织”的team，他们才会具备一颗真正强大的内心来抵御和坦然接受任何风险，哪怕是失败。</p>    <p>在伦敦旅游的时候我曾发现好多纪念品上都印有“ <strong> <em>Keep Calm and Carry On</em> </strong> ”的字样，我饶有兴致的Google一番，原来这句话是有历史故事的：二战时期纳粹轰炸英国的时候，英国皇家印了几万张“Keep Calm and Carry On”的海报准备发放给老百姓，体现了他们冷静而绅士的英国文化。</p>    <p>在互联网软件开发崎岖之路上，我们则可以将这句话改造为“ <em> <strong>Keep Calm and Refactor</strong> </em> ”.</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/385ce940f17e949c6496ccd60865c89a.png"></p>    <p> </p>    <p> </p>    <p>来自：http://www.jianshu.com/p/60361cb678f7</p>    <p> </p>