1 / 49

项目经理的工具箱

项目经理的工具箱. Scrum、XP以及更多工 具 2011-11-24. Section I. 引言. 程序员是什么？. 我觉得程序员是 匠 人 http :// www.lixinyang.com /2008/07/ jiangren /. 匠 人不是贬义词. 石 匠 做好 了 ， 是 雕塑 家. 画 匠 做好了，是画家. 教书 匠 做好了，是万世师表. 即使一个保鲜袋 ，也可以别具 匠 心. 项目是什么？. 是 把“东西”做出来. 阿波罗登月是为了把人送上月球. 曼哈顿计划是为了把原子弹扔到日本. 我们的开发项目是为了什么？. 为了工资？

dawn-price
Télécharger la présentation

项目经理的工具箱

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 项目经理的工具箱 Scrum、XP以及更多工具 2011-11-24

  2. SectionI 引言

  3. 程序员是什么？ • 我觉得程序员是匠人 http://www.lixinyang.com/2008/07/jiangren/

  4. 匠人不是贬义词

  5. 石匠做好了，是雕塑家

  6. 画匠做好了，是画家

  7. 教书匠做好了，是万世师表

  8. 即使一个保鲜袋，也可以别具匠心

  9. 项目是什么？ • 是把“东西”做出来

  10. 阿波罗登月是为了把人送上月球

  11. 曼哈顿计划是为了把原子弹扔到日本

  12. 我们的开发项目是为了什么？ • 为了工资？ • 为了创造人们喜爱的产品

  13. 总结一下 • 程序员是匠人 • 项目是把“东西”做出来 • 所以“工具”很重要

  14. SectionII 工具箱一瞥

  15. Scrum系列工具 • Product Backlog / 需求文档 • 产品人员加入团队 • 冲刺计划会 • 估算任务点数的纸牌 • 项目公告 • 燃尽图 • 每日站立会 • 冲刺演示 • 冲刺回顾

  16. XP系列工具和其他工具 • XP • 结对编程 • 重构 • 持续集成/Hudson • 测试驱动的开发 • 其他 • 版本管理/SVN • Bug管理系统/Jira • 软件包发布管理/Maven • Design Pattern • Code Review • 代码分析工具

  17. Section III 工具使用手册

  18. 《硝烟》是如何Scrum的 • 太多细节了，见《硝烟中的Scrum和XP》

  19. 我们是如何Scrum的 • 冲刺之前 • 非正式需求交流 • 正式需求讨论 • 交互设计、GUI设计 • 冲刺计划会 • 上半场：需求讲解（逐行、逐像素的） • 下半场：任务拆解、纸牌游戏 • 会后：冲刺计划进Wiki，开发任务进入Jira，发邮件给所有干系人公告项目开始 • 每日站立会 • 开发、设计资源协调、测试、部署 • 测试用例评审 • 上线和产品发布公告 • 冲刺总结会

  20. 把谁加到项目团队里？ • 产品经理是项目团队成员吗？ • GUI设计师是项目团队成员吗？ • 测试工程师是项目团队成员吗？ （成为项目成员意味着：共同做决策、每日站立会、共同做项目变更） • 一般，越多的角色成为团队成员越有利

  21. 产品需求确认方式 • 开个会，然后分头做 • 按照Email会议记录做开发 • 按照Word的FeatureList（ProductBacklog）做开发 • 按照Axure原型图做开发 • 按照GUI设计图做开发 • 越“真实”的产品需求越好，至少需要Axure原型

  22. 产品发布时间如何决定？ • 产品人员主导，设定一个大致的产品发布时间 • 冲刺计划会上，产品技术一起，结合发布时间期望、开发资源、任务优先级，确定发布计划（Feature Set） • 冲刺计划会上，开发团队通过任务拆解和纸牌游戏，给出准确的开发计划

  23. “需求斩” • 是“斩需求”吗？不是 • 是在深挖用户价值，排列组合对用户最有价值的Feature Set • 是在按照3～5周一期的发布节奏，进行项目排期（或者说做发布计划） • 如果没有Focus在用户需求和产品价值上，仅在讨价还价，那么项目经理完全不合格。 • 如何“斩” • 设定一个时间框架，圈定项目人力资源，以计算当期的开发能力 • 调节Feature的细节，以改变任务点数 • 排列组合，做算术 • “诚实”、“勇气”：做不完就说做不完

  24. 如何定义项目“完成”？ • 产品发布 • 我们希望以此为项目完成标志 • 正式环境部署 • 仅在产品推广计划未定，或者需等待Apple Store审批等情况下采用 • Release环境测试通过 • 仅在产品不能单独发布，需要等待其他产品一起发布的情况下采用 • 代码和自测完成 • 仅在产品不能单独测试，需要等待其他产品一起测试的情况下采用

  25. 冲刺计划会 • 准备好再开 • 需求要足够明确，否则开了也不能开始冲刺，开始冲刺了结果也会痛苦 • 分为上下两部分 • 上半部分明确需求（逐行，逐像素） • 下半部分任务拆解、纸牌游戏（包含了《详细设计》） • 下部分也需要有产品人员在场（三陪？） • 因为经常讨论任务开发方案的过程中设计需求明确和微调 • 不一定非连续开 • 当需要技术调研才能准确评估时间的时候，把下半场延到1、2天后再开 • 对应到传统软件过程：这里插入的就是《详细设计》阶段

  26. 任务拆解 • 记得加入非产品需求 • 项目初始化复杂时（SVN、Maven、Hudson、Linux、Mysql、Redis、Mongo的准备），记得列入任务列表 • 部署复杂时（部署文档、脚本、联系系统部），记得列入任务列表 • 测试数据准备复杂时，记得列入任务列表 • 重视数据统计需求 • 底层技术改进也记得加入 • 拆解 • 冲刺计划会前提前准备一下，拆解会顺利些 • 每个任务2～5个点 • 任务分配完，Review每个人工作的前置条件，看看是否有人几天内都没法儿开工

  27. 纸牌游戏 • WhyItWorks？ • 出纸牌的过程消除了需求歧义，确定了程序详细设计 • 多人出纸牌和“PK”消除了个体预估偏差 • 谁能出纸牌？ • 写代码的人出纸牌，其他人都不能出。（除非项目开发人员小于三人） • 出纸牌的过程 • 详细设计：出牌前要先讲解清任务的实现细节。别直接出牌，那是“拍脑袋” • “PK”：两个人点数差两倍要分别解释各自的时间是如何估算的。 • 任务不知道如何实现就不要出纸牌，做好技术调研后，第二天再来出纸牌。 • 随手记录下讨论出的每个任务的实现方式，放到SVN或Wiki

  28. 任务点数到项目时间表的换算 • 任务点数 • 1个任务点是一个人100%投入开发一天的工作量 • 投入程度 • 一般按照80%投入程度估算 • 最多可以90% • 线上产品维护工作多的同事按照60～70% • 组长按照60～70% • 项目组里避免有人投入度50%一下 • 开发时间 = 任务点数 / 投入程度 • 测试时间由测试人员估算

  29. 每日站立会 • 要按照项目而不是小组来开站立会 • 这样可以增加项目成员对项目的专注度。（当然，组长要累一点儿） • 在早上开还是晚上开？ • 早上，因为今天要做什么比昨天做了什么重要 • 产品人员要参加 • 要回顾项目进展和计划的偏离程度（燃尽图？） • 不要大家低头讲完工作就低头散了 • 要发现“坑”，更新ToDo List / Block List • 控制住时间，最长15分钟 • 细节的沟通应该白天随时、面对面的就做了。我们要更多的面对面沟通

  30. 时间、质量和项目计划调整 • 质量是第一位的 • 质量是产品的生命 • 质量是个人的品牌 • 每个环节都应该有自己的质量标准 • 开发人员提交Release代码应该是BugFree的 • 产品上线发布给用户的状态应该是让人惊艳的 • 提交Release的时间点到了，程序员的自测还没做，怎么办？ • 马上到发布的时间点了，测试中bug还层出不穷，怎么办？ “勇敢”的调整项目计划，延期或者延Feature

  31. Scrum里哪些环节我们常疏忽？ • 冲刺前的需求沟通，特别是非正式沟通那部分 • 在需求不清晰的情况下开始项目 • 不是“斩需求”，是共同指定“发布计划” • 纸牌游戏：“拍脑袋”而不是“详细设计” • 冲刺会后的那一系列“公文”工作 • 冲刺计划进Wiki，开发任务进入Jira，发邮件给所有干系人公告项目开始 • 每日站立会上最项目总体进度偏离程度的Review • 每日站立会要主动发现“坑”（TodoList/ Block List） • 项目计划不是不可变更的 • 冲刺总结会 • 这是Scrum过程里第二重要的环节，是过程改进的基础 • 冲刺结束后的掌声

  32. 引入新技术框架 • 第一步：个人，精研和全面考量 • 第二步：团队，分享和获得认同 • 第三步：在冲刺计划中加以落实 • 希望每个冲刺技术都有所进 • 新技术的引入应该是加速开发的

  33. 持续集成 • Hudson/Jenkins的确更好 • 我们曾经这样部署：ant/scp/ssh/cd/kill/java -jar • 我们也曾经这样部署：ssh/cd/./deploy.sh • Hudson这样部署：打开网页/点击按钮 • Hundson好处：1）无需linux权限，任何人可操作；2）部署有记录；3）省的敲入ssh/cd等命令 • 配置Hudson绝对是为你省时间的事情 • 尽可能早的持续集成，从空接口就开始持续集成 • 开发阶段开发人员控制部署，测试阶段测试人员控制部署

  34. 软件包发布 • Email • 本机编译、Email发布，Email获取 • Maven • http://192.168.0.28:8080/nexus/index.html#view-repositories • Maven发布和获取 • Website • http://192.168.0.28/life/ • Svn和hudson发布，http获取 • 还不完美，继续改进

  35. 结对编程 • 毋庸置疑，结对编程产生的代码质量更高（亲身体验） • 据说，结对变成开发效率也更高（体会不深） • 对复杂逻辑，两个人一起结对编程，很合适 • 其他场景，大家自由发挥和使用

  36. 测试驱动的开发（TDD） • 对不起，这个我真没有经验，但我真想试试 • 原来的项目都是Web/Wap，现在有很多ThriftService项目，这些太适合自动化测试了，我们一定要实施，而且是对Service接口的测试，不仅是DAO层的。 • 期待着一个完美的TDD项目

  37. 联调 • 有什么针对联调环节的工具？

  38. SectionIV 回顾

  39. 程序员是匠人 • 项目是把“东西”做出来 • 所以“工具”很重要

  40. 持续集成/Hudson 必要时，冲刺计划会上下半场拆开开 把干系人纳入项目团队 软件包管理/Maven/Alabama 准备好后，再开冲刺计划会 冲刺计划时，加入非功能需求和技术改进 “出纸牌”就是详细设计，不能含糊 “诚实”和“勇气” “需求斩” VS “发布计划” 站立会：发现“坑”、跟踪计划偏离度 项目计划调整 结对编程 测试驱动开发 提高联调效率

  41. 治大国如烹小鲜 • “丝路印象”餐厅的后厨门口写着：“烹小鲜如治大国” 掌握这些“工具”，你也可以“治大国”，也可以“烹小鲜”

  42. SectionV next

  43. 项目过程的三个事儿 • 要做的“东西”是第一位的 • 发现Bad Smell • 使用“工具” • 这次，我们讲“工具”，因为“工具”是基本功，也更简单 • 以后有机会给大家讲“BadSmell和提高嗅觉”，“发现问题”是最重要的能力

  44. 延展阅读 • 最好的Scrum介绍：《硝烟中的Scrum和XP》 • 很好的Scrum理论介绍：http://www.cnblogs.com/zhoujg/archive/2009/08/08/1541991.html

  45. 延展阅读：敏捷软件开发宣言 • 个体和互动 高于 流程和工具 • 工作的软件 高于 详尽的文档 • 客户合作 高于 合同谈判 • 响应变化 高于 遵循计划 也就是说，尽管右项有其价值， 我们更重视左项的价值。 （http://agilemanifesto.org/iso/zhchs/）

More Related