fangang
- 浏览: 861419 次
- 性别:
- 来自: 北京
-
最新评论
-
Junjing：
非常感谢楼主的分享，受益匪浅！我是一位从业务规划和运营转需求分 ...
我们应当怎样做需求确认：评审与签字确认会 -
kersky：
感谢楼主的辛苦输出，半天看完了整个系列。对于一个转从开发转需求 ...
我们应当怎样做需求确认：评审与签字确认会 -
DEMONU：
必须要顶
谈谈软件开发的那些事儿 之 软件开发的轮回 -
dripstone：
非常感谢楼主，用了大半天的时间，一口气读完了需求分析阶段。好多 ...
我们应当怎样做需求确认：评审与签字确认会 -
Codepoe：
做了一些开发，看了楼主的文章，我深有感触，为自己的做法找到了理 ...
我们应当改变我们的设计习惯
文章列表
前面我们提到，迭代式开发最重要的两项前期分析就是工作量评估和优先级评估。工作量评估不仅能够确定整个项目的开发周期、成本预算，而且能够确定每项工作的开发周期，为工作的时间分配提供了依据。
但是，如此多的工作，谁先做谁后做，如何安排它们的先后顺序，则是由工作优先级来决定的。
迭代式开发的特点就是持续集成，也就是首先开发最重要、最基本的功能，而暂时忽略掉分支的、次要的功能。正因为如此，迭代式开发需求将优先级最高的功能放到前面最先完成，然后安排次优先级的，依此类推。总之，优先级评估决定了迭代式开发的工作安排。
那么，如何决定每个功能，每项工作的优先级呢？其决定因此很多，但通常来说，有两个因素是最基 ...
当我问起无数人，什么是迭代式开发时，人们总是抛来一副不屑的神情：“迭代开发！这还不清楚？就是按迭代的方式进行开发嘛，开发过程采用持续集成的方式。”但我再详细询问怎么进行开发，甚至谈到如何制订计划，以及 ...
古人云：“运筹帷幄之中，决胜千里之外。”一次成功的软件开发，制订完善的项目计划是决定性的第一步，迭代式开发更是如此。前面我们提到，迭代式开发与传统开发方式差异不小，迭代式开发其过程更加复杂，协调各方协 ...
前面我们提到了迭代式开发的巨大优势，它可以降低我们软件开发的巨大风险，它可以使我们把握用户的真正需求，它可以使我们从错误与偏差中及时纠正过来，那么我们应该如何进行迭代式开发呢？要回答这个问题，我们首先要弄清迭代式开发与传统的瀑布式开发的差别在哪里。
1.需求分析的差别
与传统的软件开发一样，迭代式开发同样需要与客户进行一个充分的需求分析。但与传统的软件开发不一样，迭代式开发不要求初期的需求分析是一个完全的需求分析。它承认需求分析需要一个过程，它承认需求的变化（或者说需求是一个进化的过程）。所以，在迭代式开发中，起初的需求分析只要进行到当时的阶段能够理解到的程度就可以了，而不是瀑布式开发那样需要 ...
我们的软件开发存在着巨大的风险，当我们经历了数月的辛苦工作后才发现，我们的软件并不是客户满意的软件。这时候往往出现几种情况：
1.客户开始频繁挑刺，大量的需求变更在很短的时间发生，加班再所难免，团队士气降 ...
我们的软件开发存在巨大的风险，但问题到底出在哪里呢？这对于问题的解决至关重要。
1. 我们在没有深刻理解业务需求的情况下就必须完成需求分析；
2. 客户在没有弄明白自己的真正需求的情况下就被要求确定软件的业务需求；
3. 我们在没有与客户再次沟通的情况下埋头苦干，直到完成开发并交付客户。
既然问题出在这里，我们就可以制订我们的解决办法：
1. 业务需求的分析不再是一蹴而就，而是贯穿软件开发的始终。一方面，我们在与客户的持续沟通中加深业务领域的理解，进而加深对业务需求的理解，另一方面，客户也在加深对软件的理解，进而完善自己的需求。
2. 软件开发的过程不再是单反面的埋头苦干，而是双方的良性 ...
如题，谁是我国历史上最牛的老师呢？当然不是袁鹏飞，注意不是最牛的历史老师，是历史上最牛的老师。是孔子吗？虽说有弟子三千，但试问你数得出几个，基本都是碌碌之辈吧。什么样的老师算牛呢？当然就是他培养出来的弟子能名垂青史，如雷贯耳。然而中国悠悠数千年的历史，最后能名垂青史流传至今的伟人可以说是凤毛麟角，能培养出一个就已经不错了，谁还能培养出几位呢？然而就是有这么一位老师竟然一口气培养出了四位，先看看他培养出的四位弟子吧：庞涓、孙膑、苏秦、张仪。
孙膑是谁应当不用我说了吧，写《孙膑兵法》的那位。他一生只打过两场仗，桂陵之战和马陵之战。桂陵之战就是著名的“围魏救赵”的出处，而马陵之战则是一举干掉自己的同 ...
也许你是一位项目经理，也许你是一位项目骨干成员，或者开发小组长。在我发表“如何提高代码质量”的这一系统文章后，有许多网友都向我抱怨，说他无法把握整个项目组成员的代码质量。我想，这也是所有项目组普遍存在的问题吧，它通常表现为以下几个问题：
软件项目普遍存在的问题
1）新手。任何项目组成员都不可避免地出现新手，他们往往是刚刚从大学毕业的学生。这些新手由于软件开发时间太短，往往技术不成熟，没有形成良好的开发习惯，所以编写代码质量较差，问题很多。他们常常成为项目组的“鸡肋”，用多了项目质量无法得到保证，不用则又人手不够。
2）人员变动。一个维护时间稍长一点儿的软件项目，人员变动是在所难免的。老 ...
终于到了该说说领域驱动设计的时候了。我们在这场关于代码质量的讨论中，从代码可读性开始，讨论了代码复用性、设计模式，然后探讨了职责驱动设计。代码可读性是对代码质量最基本的要求，可惜我们仍有做得不够的（即使那些开发程序很多年的老程序员）。代码复用是提高代码质量的最初级阶段，但是在一个多人开发的项目团队中，围绕代码复用值得讨论的问题依然非常多，它依然是一个非常复杂的问题，甚至有时它不再仅仅是一个技术问题，而是一个管理问题。唉，提高代码质量的道理漫漫兮同志们要上下而求索。一个比较成功的保证代码质量的管理模式就是代码复查。让一些有经验的程序员定期去复查那些初级程序员的代码，指导他们的开发，被认为是成功的， ...
3）职责驱动设计和领域驱动设计
前面我提到，当我们尝试写一些复杂功能的时候，我们把功能分解成一个个相对独立的函数。但是，应当将这些函数分配到哪个类中呢？也就是系统中的所有类都应当拥有哪些函数呢？或者说应 ...
3.可变更性
前面我提到了，软件的变更性是所有软件理论的核心，那么什么是软件的可变更性呢？按照现在的软件理论，客户对软件的需求时时刻刻在发生着变化。当软件设计好以后，为应对客户需求的变更而进行的代码修改，其所需要付出的代价，就是软件设计的可变更性。由于软件合理地设计，修改所付出的代价越小，则软件的可变更性越好，即代码设计的质量越高。一种非常理想的状态是，无论客户需求怎样变化，软件只需进行适当地修改就能够适应。但这之所以称之为理想状态，因为客户需求变化是有大有小的。如果客户需求变化非常大，即使再好的设计也无法应付，甚至重新开发。然而，客户需求的适当变化，一个合理地设计可以使得变更代价最小化， ...
今天这堂培训课讲什么呢？我既不讲Spring，也不讲Hibernate，更不讲Ext，我不讲任何一个具体的技术。我们抛开任何具体的技术，来谈谈如何提高代码质量。如何提高代码质量，相信不仅是在座所有人苦恼的事情，也是所有软件项 ...
前面讲了为什么我们要使用分析模型，现在我们看设计分析模型的基本原则。
分配职责和职责驱动设计
我们在开始分析模型的时候，首先要弄清楚一个非常重要的原则，就是以职责为中心。OO分析设计的核心原则之一，就是 ...
——对分析模型的一点儿见解
当需求分析结束、需求确认完成、需求讨论告一段落的时候，我们的需求分析员拿出了厚厚的一打用例分析模型、领域设计模型，需求分析阶段结束，开始进入开发阶段。但是，这时候虽然需 ...
前面我们讲了如何从业务领域获取知识，创建领域模型，那么建立领域模型应当注意什么呢？
建立领域模型应当注意的问题
1．领域模型不是数据模型，也不是软件对象模型
一个创建领域模型的过程中非常容易犯的错误就是， ...