fangang
- 浏览: 877863 次
- 性别:
- 来自: 北京
-
最新评论
-
Junjing：
非常感谢楼主的分享，受益匪浅！我是一位从业务规划和运营转需求分 ...
我们应当怎样做需求确认：评审与签字确认会 -
kersky：
感谢楼主的辛苦输出，半天看完了整个系列。对于一个转从开发转需求 ...
我们应当怎样做需求确认：评审与签字确认会 -
DEMONU：
必须要顶
谈谈软件开发的那些事儿 之 软件开发的轮回 -
dripstone：
非常感谢楼主，用了大半天的时间，一口气读完了需求分析阶段。好多 ...
我们应当怎样做需求确认：评审与签字确认会 -
Codepoe：
做了一些开发，看了楼主的文章，我深有感触，为自己的做法找到了理 ...
我们应当改变我们的设计习惯
文章列表
前面我一直在反复强调这样一个观点，需求分析不是一蹴而就的，是一个反复迭代的过程。它将从第一次需求分析开始，一直持续到整个项目生命周期。为什么这样说呢？让我们一起来分析分析。
在第一次的需求分析阶段，我 ...
前面我们探讨了业务研讨会应当怎样组织，下面我们再具体讨论一下我们应当怎样与客户讨论业务需求。如果说组织业务研讨会是项目经理的功底，那么讨论业务需求就是需求分析人员的功底。
以往我们常常认为，需求分析是 ...
经过一番努力，我们终于在客户中找到了一批人，可以解答困扰我们多时的业务问题了，真是不容易呀。但是，如何以合适的时间、合适的地点、通过合适的形式与客户研讨业务需求，是摆在项目经理面前的一道难题。在我所经历的项目中，业务研讨会没有一个是相同的。
我曾经做过一个政府机关的项目，在这个项目中，从总局到省、地市、区县，形成了一个多组织机构的管理系统。虽然全国管理流程大体相同，但各地因各地实际情况的不同、领导管理思路和政策理解的不同，管理模式在许多细节上存在着差异，也就是说，这个项目存在着需求个性化的问题。在项目进行之初，客户方领导提前意识到这方面的问题，因此在组织需求研讨时，分别从各个省市抽调业务人员， ...
项目组经过一番努力，获得了一些初步的成果。首先是给客户留下了一个良好的印象，这是一个开端，但要在他们心目中树立自己的职业威信还要看你今后的表现。同时，我们与客户一起为项目制订了短期与长期目标。不要小看 ...
很多需求分析的工作是从需求调研开始的，我们就从这里说起吧。需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，更是一份技术活儿。它既要求我们具有一种理解能力、设计能力， ...
又到新年了，日历又要从2011年翻到2012年了，这使我有太多的感慨，进而勾起了对太多往事的回忆。过去的10年，毫无疑问是中国软件业发展最快的10年。当我们刚刚毕业的时候，还在使用VB、PB开发一些简单的数据库应用，而现在 ...
前言：你写过用例模型吗？也许有；你写过领域模型吗？也许还没有。在这里，我们可以尝试写写领域模型，看看它的作用、带给我们的好处。
随着RUP在中国的传播，人们开始尝试用RUP统一过程来指导软件的设计和开发，但这 ...
不论哪种持续集成工具，使用过程都是相似的，我们来听听敏捷大师Martin Fowler对持续集成的定义就可见一斑：持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
每天，程序开发人员将各自开发的代码上传到配置管理工具（如SVN、VSS）中，而配置管理工具会记录下谁在什么时间上传了什么代码文件。随后，持续集成工具会定期（可以是几个小时、半天，或者一天，由使用 ...
2001年2月，在软件开发各领域有所建树的17位大师联合发表了《敏捷软件开发宣言》，提出了敏捷开发这一概念，至此敏捷软件开发风靡世界，为无数软件开发项目所采用。而在所有这些运用敏捷开发获得成功的软件项目中，运用持续集成工具无疑成为一项最重要的最佳实践，因为它集中体现了敏捷开发的各项思想。
持续集成工具的意义
首先，它促进了项目团队的沟通与反馈。想想看，持续集成工具使每个人每天的劳动成功及时发布到应用服务器上。你只要登陆服务器，就可以运行和查看整个项目的每项功能。开发人员可以相互学习各自的设计，需求人员可以确认开发成功是否符合需求，测试人员可以及时测试各项功能。再这样一个平台下，沟通变得简便， ...
随着软件业的不断发展，软件项目的规模越来越大，软件结构越来越复杂，技术要求越来越高，参与人员越来越多，管理也变得越来越难。在这样一个大背景下，如何提高软件研发质量，相信是所有软件公司都在关注的话题。但 ...
其实做一个项目经理真不是一个好的职业，它需要太多的千锤百炼才能修炼出来。这不仅需要反复经历“失败-总结-再失败”的轮回，而且需要有一颗无比坚强的心，能够在无数次经历无比艰难并且令人沮丧的时刻而能坚持不懈 ...
前面我们提到了需求变更。当客户提出了需求变更，经过与我们的需求人员的详细讨论与分析，最后确定下来了变更内容和修改方案。但这时草率地开始进行设计和开发是不正确的，它将成为项目后期的一个巨大的风险，一颗定时zhadan，为什么呢？我们来详细分析分析。
每当发生需求变更的时候，不管是大是小，项目的许多因素都会相应地发生变化。首先发生变化的是工作量。每次的变更必然造成工作量的增加，到底增加了多少呢？我们需要对其进行评估。同时，我们还要对增加的工作进行优先级评估。一般来说，新增加的工作往往优先级都是最高的，是客户急切想看到结果的部分，那么其它的工作的优先级就会收到影响，优先级就会有所下降。当工作量的增加 ...
前面我们已经详细描述了一次迭代式开发的完整过程，首先是项目计划的前期分析——工作量评估和优先级评估，然后是制订迭代式的项目计划，最后是按照项目计划执行项目。每天，运用Burn-Down Table监控项目进程，随时掌握项目进度的偏差（是滞后还是超前），然后制订相应的应对方案予以调整，直到最后的项目结束，一切似乎进行得比较顺利。但真实的情况往往不是这样，这里忽略了一个最重要的因素，那就是需求变更。
如果没有需求变更，我们就不需要采用迭代式开发了，瀑布模型足矣。正如我在第一章谈到的，我们的软件开发存在着风险，这个风险就是需求变更。需求变更无处不在，就如同我们人类面对的浩瀚无垠的宇宙，必须得有防护措 ...
我们经过以上一系列的分析，工作量评估与优先级评估，制订出一个迭代式的项目计划，再经过一系统用户确认与公司评审以后，终于可以开始我们真正的开发工作。
其实，迭代式开发的执行过程，也就是制作和不断去关注与 ...
前面我们提到，当我们为软件分解工作项目，评估了工作量，确定了优先级。同时，整个项目的人员安排，也就是哪些人负责需求分析，哪些人负责设计，哪些人负责开发，哪些人负责测试，被确定下来，我们就可以制订我们的迭代式开发的项目计划了。
迭代式开发的最重要的特点就是迭代，即将整个开发过程划分为数个迭代期，每个迭代期的时间长短并非完全一致，但却差别不大，这就是迭代周期。迭代周期的长短视项目情况而定，过短可能会使项目的变更过于频繁（每次迭代都需要提交交付物与客户沟通，从而产生变更）。迭代周期过短的另一个毛病是使迭代中的每个步骤的时间过短，而使项目组成员有一种匆匆忙忙赶进度而跟不上趟的感觉，使整个项目的组织混乱 ...