随笔分类 - 项目管理
摘要：敏捷开发不是信仰，团队成员并不关心什么是敏捷，他们只关注把工作搞定，。同样他们不关心什么是敏捷，他们仅仅关心那些能帮助他们解决当前问题的事情。AD：敏捷开发已经成为广受开发人员关注的软件工程方法，如何实施有效的敏捷开发，如何有效的在团队中推行敏捷开发是每个项目管理人员都要关注的问题。可以说敏捷开发已经成为优秀程序员新挑战。引荐——当敏捷教练走马上任，初到一个团队的时候（不管是已经存在的，还是新的团队），都可能有一段阵痛期。团队不是很确定谁是教 练，为什么需要教练，甚至怀疑他能不能胜任这份工作。这时，来自高层（经理、团队主管或者在团队中很受尊敬的人）的引荐会有助于减少担心。除此之外，敏捷 教练应
阅读全文
摘要：【51CTO专稿】今天是敏捷中国大会2009的第一天，各地的敏捷专家与关注敏捷的企业代表、项目管理者以及开发者们汇聚北京，相互之间了解各自敏捷开发的理解与进展，并从敏捷大师那里直接学习有关敏捷开发的精髓与最新理念。此次大会邀请到了敏捷宣言创始人中Kent Beck与Dave Thomas，敏捷领域大师级专家Fred George，已经成功运用敏捷的上海贝尔、赛门铁克、诺基亚-西门子、eBay、腾讯等公司的项目负责人来大会上进行主旨演讲，分享他们的敏捷经验与心得。敏捷开发现在在欧美已经有了相当的普及，在国内也已经流传实践了几年，现在正逐渐进入到越来越多的项目中。虽然敏捷开发既有成功的案例也有失败
阅读全文
摘要：其中有几条我挺有感触的。特别是第6条、第11条、第19条、第21条、第22条.......==================================================我经常收集各种各样的至理名言，最近我重温敏捷开发；真正的问题是什么？下面是一份26条关键原则的清单，以指引敏捷软件开发团队。1、完整地干完一件事后在开始另一件事：用厨房比喻来说就是：“先上这道菜，再开始做下一道”。软件开发的最大问题就是同时开始几件事情，这将不可避免的造成某些工作被废弃，从而造成浪费。专注于一件事；完整地实现其功能；运行测试；编写文档；签入所有，把这当做一项工作完成，然后再开始下一件事。2、
阅读全文
摘要：丰田公司精益管理的14项原则 - [Lean and Agile]版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明http://duweizhong.blogbus.com/logs/112137019.html14项原则：1）管理层决策必须以长期哲学为基础，即使为此牺牲短期财务目标也在所不惜。2）做到流动，批量规模越来越小，周期越来越短，从而快速交付价值并暴露弱点。3）使用拉力系统，越晚做决定越好4）均衡工作--减少变化和减轻负担以消除不平衡5）建立停止并修复的文化，教导每个员工都要有条不紊地研究问题。6）掌握规范（实践）以实现改善和授权于员工。7）使用简单可视化管理揭露问题
阅读全文
摘要：用户故事Invest原则 - [Estimating and Planning - Back] 版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明http://duweizhong.blogbus.com/logs/112151436.html Invest描述:I dependent
阅读全文
摘要：《关键链》是一本关于项目管理的书，首先必须得承认这是一本很不错的书。只有在上下班的地铁中偶尔读《关键链》,且读的断断续续，现把读书的一点心得记录下来。1、关键路径不同于关键链，关键链考虑到了资源瓶颈的问题。 如在非关键路径中需要资源X，由于在多个分支上都需要X，那么关键链应该比关键路径要长，其中包含多个X。2、安全时间。 现在把项目分成阶段，每个阶段都有了安全时间，但往往人们在最后时才开始做相应的工作，且往往还要超时，即使提前完成一般也会在最后的时间提交给下一阶段的人。这样安全时间白白的浪费掉了，所以应该把安全时间放在最后。 对于供应商等，我们平衡是时间重要还时金钱重要，如时间重要则应该尽..
阅读全文
摘要：考察用户界面的部署约束用户界面的部署约束可概括为以下几种:1、经常要离线工作的移动电脑。2、手持设备（例如：PDA,Java手机）3、支持Internet上的任何一种浏览器（包括低速的拨号上网方式和老版本浏览器）4、支持Internet上的较新版本的浏览器。5、支持内部网上的较新版本浏览器。6、支持内部网上的特定浏览器。7、内部网上的专用工作站（传统C/S架构的客户端软件）
阅读全文
摘要：项目实践精解读后感（需求分析注意点）一、考察用户的数量和类型考察用户的数量和类型可概括为以下几种1、少数的专业用户：关注功能强大，期望量身定制，东于学习新特性，例如图形制作系统的用户。2、组织内的日常使用者：主流用户，关注便利和易用，例如考勤系统用户。3、大量的爱好者：对系统的功能有执着的兴趣，有意愿克服使用时遇到的各种困难，包括软件本身的缺陷，例如游戏软件的用户。4、数量巨大的消费型用户:关注速度和服务感受，例如商业网站用户。
阅读全文
摘要：按会议的内容及与另一项目经理上一项目的经验我准备了如下内容 一、服务器 2台内存4G、硬盘80G的虚拟机 2003 server 操作系统 一台布SVN 及装SQL2008 另一台用于发布测试（含应用及数据库SQL）及源码备份。framework 3.5 二、例会 9:10 9:20 工作日任务例会
阅读全文
摘要：项目的原型确认已一周多了。总结一下我们开发前的准备工作吧。与领导沟通确认后续工作内容，借鉴其它项目经验。内容如下1、 第1、2周做文档，含流程、逻辑、功能拆分，做到原型的补充。文档模板待确定。2、 第1、2周做数据库设计。3、 第3周做框架修改及数据库评审4、 第1-3周招6人，计划留4人，1个质量检查员，3个程序员，办公地点确认，服务器确认。 质量检查员工作：测试，配置管理， 测试检查代码，源代码管理，版本管理。5、 第3周确定代码代码规范，管理规范，例会规范; 开发计划; 服务器正式、测试环境配置。6、 第4周第一天框架规范培训，第二天试用.7、 第4周上线计划（含数据、服务器、培训、文档
阅读全文
摘要：经过三个多月的需求沟通，特殊是近一个月与需求方在同一个会议室一会商讨一边制用原型。终于在上周末原型确认下来了。下面总结一下：1、做原型不难，难在对业务全面（重点是全面啊）理解，特别是业务流的打通；难在将需求合理的转化为系统。2、考虑问题是要站在不同工作岗位去看问题。还要看数据。3、界面问题，易用性问题大家很注意。4、在做需求时一定要有一个负责人的业务方面的主管。另个还要有在非常懂业务的人。5、做需求确认时要找不同的人一起评审。做需求时特别是打能业务流时真的要反复的思考，想的一定要全面。
阅读全文
摘要：原型制作已有一阶段了，到春节前，自己觉得已制作OK,业务流程OK。但是。。。。。项目经理（业务部门）在最开始时有参加过需求沟通的会议，后期主要关心基础数据了。工程部分他也有看过，只是到快春节时觉得工程部分不对了，通过他对业务的介绍自己也觉得系统这么做不妥了，所以一上班的前两周就开始了工程的大变化。接下来对CASE进行确认，其实我觉得CASE部分业务流程、状态变化等都觉得挺OK的了，但是项目经理改了一部分，主要是呈现方式，但对业务流没有太大的变化。。另外提到了“回访”部分（一期没做）。只是“回访”的业务有所调整，觉得他比我站的高。我看到了，做需求分析时一定要站得高，业务要通，精通。我要进步！
阅读全文
摘要：今天将服务系统的工程部分又一次的和需求方对了一次。1、发现少了一个节点。2、由于我的疑问又改了一部分内容（不知道这个算不算是潜在需求）3、增加了下放任务，让参与人填写任务。发现需求分析越来越有意思了。不过对原型确认又有了疑惑，原型要做到什么程序。1、确认每个字段是否必填？在哪个节点是必填的？。。。。。。2、每个字段在不同人处理时，不同节点时内容不同，且字段之间还有关联。怎么办？
阅读全文
摘要：项目开通已有一段时间了，但是进度很慢。本来计划是12月31日验收原型，但是项目经理需要给基础数据部分迟迟没有给，同时其它模块的需求给的也不是很及时，加之做出来的部分也没有完全确认。项目经理主动推迟了两周。昨天项目经理又已通知2月15日高层要验收原型。(说明：1月31日至2月13日放假。)。 今天，我要出一个详细的原型确认计划了。要不怕时间来不急了。
阅读全文
摘要：售后的系统开工了。1、前期做了需求，基本上流程梳理完毕。2、开了形式上的kick off会议。3、由于精力有限（实限上也是自己技术不怎么样），在别的组借了个实习生来帮助自己做原型。 本次考虑到有现成的框架（有已成型的样式等），所以直接在框架上画原型。和实习生用SVN代码管理，每天通过“项目管理工具”给实习生分任务。 由于前期自己做的需求，界面基本上是自己设计。但要给实习生分任务太粗了吧，他看不明白，太细了刚写完发给他任务他就做完了。也就是说前期只是在自己的心目中有设计，落实到"word"上不是那么细" 上。分任务要说的特别细，在界面查询项上有哪些，查询出来的记录有哪些，打开有哪些，新建有哪
阅读全文
摘要：刚刚接手项目，如下步骤是否正确？1、需求方提供业务流程、表单、报表2、项目需求人员调研，确认流程。其中含业务流程优化。3、原型制作。4、原型确认。（在与3之前与需求方不断的沟通，确认字段，实现方式等。确认后原则上需求方不得更改需求）5、需求功能点拆分与数据库设计。6、开发。7、测试。6、交付。
阅读全文
浙公网安备 33010602011771号