|
多数情况下，需求内容需要更加充实和详细，这一步要放到后面做，开始不要这样。用户故事的方法有时会因过于简短、不断重复而受到批评。这里我们必须明白：需求文档不是散文或诗歌，应该清晰、简明地描述用户需求;需求文档的重点也在于此，不要管形式多变或内容是否重复这样的问题。项目管理者联盟
4. 多沟通，尽量减少文档项目管理者联盟
任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。在圈子里面混得越久，越会强调良好高效的沟通的重要性。pmp.mypm.net
团队要确保日常的交流，面对面沟通比邮件强得多。项目管理者联盟
敏捷开发鼓励日常的协调会议和碰头会，5~7人参与的会议尽量控制在10分钟内。碰头时，要过一遍昨天完成了什么，今天要做什么，哪些问题仍待讨论。可以用Burndown Chart(燃尽图)来形象展示工作进度。每次迭代的时候也都要开一个计划会议和评审会议，一般需要的时间可能会长些，比如半天。这些会议的目的就是对工作查缺补漏。项目管理者联盟
评审会议很重要，传统开发模式往往略过该环节，导致一些错误做法不断重复，好的做法无法推广。PgMp.mypm.net
开会时，可以将原先的分组打散，让整个团队都参与到项目的需求讨论和测试中来，这样可以突出成员个人，让大家更乐意参与。项目管理者联盟
5. 做好产品原型项目管理者联盟
建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。talent.mypm.net
一个常见的问题是软件新的功能与用户想要的不一致。为了避免这一问题，可以模拟真实操作，改进模拟操作过程中难以理解和不清楚的操作行为。talent.mypm.net
6. 及早考虑测试training.mypm.net
及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。
敏捷开发中一个常见问题就是开发者没有对已有的代码库进行充分的回归测试。迭代周期很短，从开始到交付就是4周的时间，这样可以对迭代的设计、实现和底层测试一块进行回归测试。talent.mypm.net
一系列迭代之后，可以只针对测试活动再补充一个迭代。这个迭代可以将重点放在系统测试、与其他系统的集成度、性能等方面。敏捷开发过程中，可能会导致过少的测试文档。如果迭代周期为1个月左右，可以不必对测试文档过于要求，但要制定好测试策略。项目管理者联盟
最后项目经理圈子
可能大多数公司或团队还没有开始尝试敏捷开发，不过可以开始从点滴做起，比如开碰头会、为项目管理采用一个更加高效的管理工具等等。最后，希望上面的建议能够为大家的软件开发管理带来帮助。club.mypm.net blog.mypm.net
|
