: ※ 引述《yellowpeach (端)》之铭言： .... : : 中坜市中央大学工程五馆 A207室 : : 台湾软体业积弱不振，是大家心中的痛。其中固然有市场行销面的困难， 然而 : : 工程品质普遍低落，却也是不争的事实。 : : 如何提升品质？ 近年的敏捷方法(Agile Method)强调： 开发团队(含客户)沟通 : : 要快而准。又，国内业界有工厂观念，只重视产量增加、成本降低，却不追求思考品 : : 质的提升；其实要重视：开发者个人思考要深且密。这整个观念会形成：测试带动的 : : 开发(Test-driven development)。 =========================================================================== =有去听的请发表一下心得. =讲得很不错, 虽然慢了一个钟头才进去, 但到结束都没睡着. = =首先, 觉得陈教授的演讲跟底下拿来比对讨论的这篇文章所讲的方法流派很接近 ! = =http://www.ithome.com.tw/itadm/article.php?c=39401&s=1 = ========================================================================== XP诉求以最佳智慧做出客户最想要的东西 敏捷软体开发联盟宣言 ● 个人及互动胜於流程和工具 ● 可用的软体胜於详尽的文件 ● 与客户合作胜於合约谈判 ● 回应变更胜於墨守计画 导入XP（eXtreme Programming，极限制程）的第一步就是拿起扳手与螺丝起子，动手 拆隔板，因为XP强调的沟通、简单、回馈与决心这4个价值观，以及12项实务，主要精 神说穿了就是贯彻「沟通」两字。 XP是以少数人力在短时间开发系统的方式，适合2～12人的开发团队，特别适合应用在 需求经常改变的领域，因为需求的不确定性，所以相当重视客户在开发过程所扮演的 角色。管理者、客户及开发人员对XP而言，都是专案的成员，必须透过充分的沟通与 回馈，让每个成员了解目前的版本能否满足需求。 12项实务贯穿XP的核心精神－沟通 仔细研究XP，会发现以下12项实务多数只是为了达到充分沟通的手段： 1. 客户驻厂：为方便随时随地的沟通，因此客户必须驻厂，即时地回馈意见，并确认 目前的版本能否符合需求。 2. 系统隐喻：XP并没有系统分析师（SA）、系统设计师（SD）与程式开发人员等区别 ，每个人都扮演SA、SD和程式开发者的角色，直接跳过需求分析的阶段，藉由客户驻 点面对面沟通的方式，取得第一手的需求，并直接做给客户看，目的是为了做出符合 客户真正想要的东西。 而隐喻是为了让客户与开发者以共通的语言，确保彼此的沟通没有误解。以实际的比 喻或故事，取代冗长而难以理解的文件，比喻可以与IT无关。例如说明授权机制可以 举实际生活的例子说明：一栋房子有很多层楼，每一层又很多房间，而某人的钥匙只 能开启9楼A室的房间。总之尽量以易於了解的方式，表达需要的功能。 ========================================================================== =听了陈教授的演讲, 提到了 on site user expert , 这位专家是 acceptance test =与 object interface 的关键人物. = =讨论时, 有人问道: 少了 SA SD 甚至没有 Architect , PM 对目前的台湾业界怎麽 =能接受导入 ? = =不晓得 customer(买方)可不可以另外独立雇用某家(甚至是同一家)公司不写程式的 =Architect/PM/SA/SD 之一当 on site customer expert 专门沟通买方使用人员替买 =方决定 GUI 界面. = =至於使用隐喻还是明示的需求目标, 纯脆就是买方是否要透过 on site customer =expert 透露其使用机密(例如军事用途)而已. 而需求不讲是不可能透过沟通让开发 =者做出期望中的功能. =========================================================================== 3. 通盘规画：透过使用案例（User Story）发掘与评估需求，并在卡片（Story Card） 写上对需求的描述，让开发者得以根据客户的描述切割工作量，并确保在稳定的周期 内，发布新的版本。 4. 小阶段发行：依据Story Card切割工作，分阶段发行新版本，而且必须是可执行的 版本。 5. 简单设计：今天的需求可能明天就改变，预留弹性反而是包袱，而且环境与技术都 会改变，因此不去预想未来可能的功能，尽可能保持符合需求的最简单版本。 ============================================================================ =基本上, 初期应该是只有全案的大体样子与概略目标, 排程是且战且走在依负荷与时间 =的紧迫性与代价上适当调整的. = =提前完工或让买方逐期导入试用, 似乎是可以进一步发挥的地方. 让 Architect 或 =PM 站在买方甚至当监工是一种合乎实务的创举. = =开发者此时比较像工程的承包者, 开发者的卖方也可以形成有一个会写程式的包工头, =依某段工期的工作量动态加减人手, 新增人手的沟通与任务指派一定是由工头负责. =========================================================================== 6. 测试先行：XP的创始者Kent Beck提出的测试哲学，包括单元测试与整合测试。单 元测试由开发者在撰写系统程式前先写测试程式，所以专案应有25~50%的时间是开发 测试程式；而整合测试才是由测试人员负责。 7. 编程标准化：包括命名原则、编码风格、函数、类别设计、继承、运算符号等，设 定一致的表现方式，提高程式的可读性，将有助於改善软体品质、提高开发效率并简 化维护工作。 8. 重构：在每个小阶段发行、每个往覆式（Iteration）的周期後，甚至是每天下班 前都可以执行一次重构，以保持程式码的乾净、简单且具表达性。 9. 搭档编程：两个人共同开发一只程式，一个人写程式，另一个人看程式，检视是否 有错误或可改进的地方。两人经常互换角色，这麽做的目的，是藉由充分的沟通与交 流提升团队整体的能力。 10. 共同维护：搭档编程的搭档关系，也需要经常替换（Switch Pair），让每个人都 可以维护系统的每个部分。 11. 持续整合：在开发期间，每一组搭档可以随时在测试过後，将程式签入整合至系 统，并谘询其他搭档执行所有测试，所以XP一天可能建构系统好几次。 12. 每周40工时：为避免精疲力尽，XP希望以持久稳定的步调，维持高品质的工作效 率，不借用明天的精力，强求在今天多完成一些工作，因此XP不允许团队超时工作。 唯一可以超时工作的例外，是发行前的最後一周，做最後的冲刺。 测试先行应该就是在逼迫开发者进行 SA SD 与 文件记叙的工作, 甚至是透过 data test 样例来展现可读性的文件. 除了是为了应付各种变动的弹性外, 她可以让开发 方的 source program 的行数大量增加, 可以在程式的价值感上增加品质价值. 测试驱动的开发流程 XP之类的敏捷开发方法论，其轻巧特质，颇受开发者认同，然而大家着眼於其简单设 计与灵活因应需求改变的主张，却往往忽略XP是测试驱动（Test Driven）的开发方 法论，「测试」是必要的条件，若未撰写测试程式，便不算是XP。 需求恒变是许多专案团队抱怨的问题，然而XP的建议是拥抱改变，测试案例的目的， 就是为了因应改变。以XP的经验来看，透过录制使用者介面的操作剧情，所执行的测 试太过脆弱，系统底层很多功能与使用者介面无关，可能导致测试的漏洞，而建置健 全的测试案例将使专案无惧改变。 未着手写程式前，如何写测试「程式」的程式？事实上，写测试程式本身就是在进行 系统的细部设计，写测试程式前，必须决定Class（类别）的命名、参数为何、功能 为何等。从测试的角度分析，叫用者（Caller）的观点将多於开发者观点，有助於设 计更弹性、易用及简洁的系统。 而先写程式再写测试的问题，在於开发完成後，团队往往会缺乏动力，而且可能因为 遗漏，使得有些程式没有测试到，或者也可能将测试写得太复杂。 强调不拘型式的文件 XP的「文件无用论」广受IT界争议：一个没有文件的专案，後续的维护性令人质疑。 其实XP有文件，而且是不拘型式的文件，以「Story Card」说故事打比方、画UML图 、拍下白板上画好架构的图，甚至手绘的各种图或文，都可以是文件的一种。 更重要的是，软体会变，文件会过时，所以最好的文件是程式码。为了让程式拥有像 文件一样的可读性，所以必须落实编程标准化，以同样的风格撰写程式，才能降低对 文件的依赖性。 ======================================================================== = =听完讲习再对照看此篇文章, 感觉上这个流派的做法是: =1.像 人月神话 提到的外科手术式团队 =2.On site customer/GUI expert 是买方执行委外的 关键人物. =3.测试先行是强迫先分析, 查看各种 case , 进行资料化的文件说明. =4.动态排程可以随时考量是否可以加派 "无关人手(指不必太多沟通就能进行的 = 工作)" 缩短工期. =5.这是一种各自委外, 专业分工的做法 ! ======================================================================== BUT...12项实务必须面临现实环境的考验 盲目套用XP可能导致专案的成本难以估算，反而增加团队的痛苦指数。 条件1：成员个个是高手 人的素质是影响XP最关键的因素，团队要有经验，否则有很多实务将流於形式，例如 搭档编程实际执行起来，负责看程式码的人很容易会发呆或做别的事情，就算认真看 ，既然已经编程标准化，理论上能发挥的创新作法将大幅减少，因此未必能够提出更 好的建议。唯有双方都是高手，才有可能激荡出令人赞叹的火花。 此外，Stand Up会议的用意是希望简短而有效率地达到沟通的目的，最好在10~15分 钟以内结束会议。若人员的素质参差不齐，对意念的表达没有默契，只要有人提出不 同的意见，将展开冗长的讨论，致使会议无法於短时间内落幕。 重构对程式做分析变动以提升程式的品质，但对於阅历不深的工程师，可能轻忽事前 设计的重要性。任何技术上的说法，都必须有基本假设，虽然重构的精神是「不妨先 动手」，但若草率行事，代价很高。 条件2：切割适当的版本 XP要求2～3周演化一个新的版本，若系统的复杂度高，或版本切割不当，加入新的需 求後，影响的范围可能很大，将使重构与演化的进度遥遥无期，始终看不到结果的情 况，对成员的信心打击很大。就企业的立场来看，开发周期拖长，成本将越垫越高， 产品可能错失市场先机，造成更大的损失。 条件3：适合需求不明确，却希望提早看到东西的创新产品 小版本发行的概念，适合需求尚在发散的方案，专案的时程压力较大，若需求不明确 ，便难以估算成本。因此无论企业或资讯厂商，都宁愿在清楚分析与定义需求的情况 下承接专案，因此XP较少应用於专案的开发。 若是仍在演化中的创新产品，希望提前看到东西，并进一步评估未来的走向，以利尽 早投入市场试水温，便很适合采用XP。开放源码就是以这种「永远的Beta版」开发出 使用者真正想要的产品。 =========================================================================== =这是强调专业精英的思惟, 对於人口大国, 先天上她有一定的比率的精英, 她可以很 =快形成包工/代工的聚落效应, 不过, 这会是技术个人主义与 System Architect 间 =的争斗矛盾. = =软工一直就是未能达到 建筑设计, 监工, 工程施工 三者分离的程度 . =========================================================================== --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.115.5.81 ※ 编辑: ggg12345 来自: 140.115.5.81 (06/16 08:01)