《大家是否有这样的想法？》的相关内容

客户总是提出一大堆需求，然后又不detail,又希望立马看到一些结果， 该如何处理？

在进行需求分析时，总会遇到这样几种情况： （1）客户说不清楚需求； （2）由于政策，业务原因，需要对需求进行变动； （3）分析人员或客户理解有误。 这些情况往往是在完成编码时暴露出来的。直接的后果就是要求程序人员返工，重新编码。为了赶进度，要求程序员加班加点的干，造成手下人员怨声载道。如果反复如此，就会直接打击大家对这个项目的信心，使这个项目趋于失败。 怎样才能避免这样的情况发生呢？ ...

http://www.blogcn.com/user27/zbw25/blog/6965056.html

在做软件设计之前，画好系统的界面图是一种非常有效的建模和交流方式。 总是有人抱怨在需求和软件设计之间仍然有很大的鸿沟需要填补，这是至今仍然未能有效解决的软件工程难题。多年以来，有很多人一直在寻找从需求到设计的直接的形式化映射方法，但是收获很少。实际上软件工程对于软件生命周期前面的那些阶段并没有多大的帮助。为了响应 o6z 说的努力在在现有技术基础上杀死人狼的号召，我来推荐一种有效的设计方法。 这 ...

UML 中包括有很多种图形。我最初学习 UML 是通过三友的《UML 用户指南》，这本书是一本很详尽的著作（另外一本更详尽的著作是三友的《UML 参考手册》），是 UML 领域最重要的著作之一，然而却不利于初学者掌握重点。因为时间有限，我没有能够读完用户指南的全书。对于一个形式主义者，很容易陷入大量 UML 的细节之中，使用昂贵的建模工具（ROSE、Together、PowerDesigner、V ...

在进行需求分析时，总会遇到这样几种情况： （1）客户说不清楚需求； （2）由于政策，业务原因，需要对需求进行变动； （3）分析人员或客户理解有误。 这些情况往往是在完成编码时暴露出来的。直接的后果就是要求程序人员返工，重新编码。为了赶进度，要求程序员加班加点的干，造成手下人员怨声载道。如果反复如此，就会直接打击大家对这个项目的信心，使这个项目趋于失败。 怎样才能避免这样的情况发生呢？ ...

（本文发表于程序员杂志2006年第4期） 在很多人的印象中，敏捷软件开发是种类似黑客行为的过程，是程序员最爱的勾当。不写文档，不作需求分析，没有项目经理，做什么东西完全是程序员自己的行为。所以他们认为这样的过程无法满足真正大型项目和复杂项目的需要，因此在经过考虑后，放弃了敏捷方法。 真的是这样吗？敏捷过程到底是如何做需求分析？用户故事和用例有什么区别？敏捷过程如何去管理需求的？这些是一些想要实 ...

OOP/AD basic 本文是为了配合庄子的论文，做一些OO的基础知识普及工作。 当然，即使是OO基础知识，我也不一定有足够的资格来普及，主要目的还是为了相互学习，共同进步。因此，为了便于读者找出漏洞，进行批评和抨击，帮助我进步，我尽量使用朴实无华，简单易懂的语言。用咱老百姓自己的话，讲述老百姓自己的故事。 为了突出重点，加强效果，文中不免矫枉过正，提出一些片面极端的看法。 为了方便起见，我也把 ...

一些心得，写下来时刻提醒自己。 1.实现优先 这个问题很明显：无论如何，你都要先做出来。技术，性能，优化甚至代码对齐等等技术人员才会想到的东西是不应该按这个标题序号去考虑的。 记住：即使一天拼出的只是一个杂碎，也比闷头做一个月的“优雅”产品要好得多。 2.以人为本 充分的衡量一下整个团队的能力，按照全队的综合能力去选型。项目负责人的任务就是把项目拆散了平摊到每个适合的人的头上。 记住：你必须详 ...

  首次采用敏捷方式进行开发，我想把我们的做法与大家分享下，同时希望大家指出我们的不足和需要改进的地方，让我们的项目进行的更顺利，目前项目已过三分之一，客户比较满意，还算顺利。   项目简介：一个DMS小项目，预计时间14人月.客户需求不是很明确，想一边做一边提，适合引入敏捷开发（实际上用户的需求也一直在变，当他们看到每次的small release时都会有新的想法）。 ...

JavaEye网站成立快三周年了，但是一直到现在，还只是一个论坛而已，将JavaEye网站扩展成为一个综合性的软件技术交流社区，一直是我的梦想，也是很多JavaEye会员的愿望。 在我和我的团队决定采用ruby on rails之后，我就意识到这是一个极好的敏捷web2.0项目实战探索的机会。JavaEye的每个会员都是我们的敏捷客户，JavaEye网站最终做成什么样子，不是由我决定的，而是由你 ...