只显示主题贴
可能大家的开发环境不太一样，有的人是给自己公司开发（我就是这种），有的人是给别人开发。虽然也做了好几个系统了，但文档写的并不多。说出来大家可能不太相信，需求管理我们基本上靠嘴说。靠几个业务分析人员的大脑。当然这也是我们的开发组人员相对稳定，做的行业相对专一。03、04年还写一些需求文档，现在基本不写。但差不多半年我们都要对需求进行一次梳理，产生的文档基本上也是四不像，但我们觉的管用。我自己倒觉得，用例文档中的诸多要素点对于分析需求是很关键的，但也没有必要非得写在纸上。用例故事，当然更适合面对面的沟通。05年公司来了一个据说是很牛的项目经理，搞了很正规的这种开发流程，也要求我们提交文档遭到了大家 ...
- 进入论坛 软件开发和项目管理 版
呵呵，看来让用户在需求文档上签字是好多乙方确定需求的不二法门。但该变的还是要变，只要你的需要抽象和实际业务有出入就得变。当然了，签了字的需求文档会对项目管理有帮助，可是对我们实际工作的帮助又有多少了？况且，在开发过程中，随着我们对系统的理解，我们也会对前期的一些需求有另外的看法或处理，难道我们要熟视无睹吗。在我这些年和别人的合作中，这种现象还是很多，有些人写代码好像只是完成需求文档的任务。想想这里要说的还挺多，以后有空再细说吧。《软件工艺》中有一个称谓“软件工匠”，凡“匠”者都对其作品非常的喜欢。其实，我们做东西的时候有了这种“匠”者的心态，再加上一些经验和技巧，离一件成功的作品就不远了。
- 进入论坛 软件开发和项目管理 版
说说我以前的一个领导，基本上算不了什么牛。真可以说一点都不牛，技术马马虎虎，业务基本不懂。因为在美国待了十多年，回来后成了CTO。但人家学到了老美的坦诚，把开发组紧密的团结在了他的周围。大家都觉的工作比较舒坦了，还有什么解决不了的问题了。后来离开了公司，我才觉的他还是比较牛的。
- 进入论坛 软件开发和项目管理 版
如果迷茫了就选择自己喜欢的事情，但切忌不要朝三暮四。不论你怎么描述自己的现状，我总觉得你可以生活的。这个社会太浮躁了，即使你赚钱了就一定会更快乐吗？我的第一份工作400/月数控机床维修干了半年，第二份工作3600/月（机房数据维护）2000年在西安已经算比较高了，我也没有觉的自己很快乐。03年来北京开始了软件开发，才感觉好多了，当然也是年龄在增大，心态更平和。现在的工作又离开发越来越远了，但自己喜欢的东西却一直不肯放下，别人可以用练字来休闲，我为什么就不能写代码来消遣了。一杯新茶，一段代码，一个下午，挺好。当然，男人还需要养家，年终总得给父母点心意吧。
- 进入论坛 招聘求职 版
出现这种现象只能说是自己的公司和客户都不成熟。如果你们专注的做一个行业5年以上或许你就不会认为客户的需求有多大的变化了。我到认为真正的需求变化并不是很多，很多变动是因为我们遗漏或理解错误的需求。以前看到过一句话“变化的大多不是需求，而是你对需求的理解”，感觉挺对的。敏捷开发中的现场业务专家可以很好的理顺需求的变更。我以前在项目组中做了三年的需求分析，再加上自己以前做运维的三年，
感觉是用了六年的时间才对整个系统有了比较深刻的理解。很可惜，后来项目不做了，基本都外包了。想想以前的日子，做做需求，写写代码还真是舒服。我后来也在一个外企写了两年的代码，需求都是在国外完成的，就感觉做项目没有了很多的乐 ...
- 进入论坛 软件开发和项目管理 版
不就是需求条目吗？什么story啊.
--->条目干巴巴的，story就丰富多了。难道你认为需求文档中的那些条目就可以再现需求了吗？story 是可以渲染出一个更具体且真实的需求场景。当然story最好是从人口中讲出来的，而不是什么文档。感觉再好的文档也就像葡萄干。如果你没有见过葡萄，只给你一个葡萄干让你画葡萄，也许你画的葡萄就是方的。
- 进入论坛 软件开发和项目管理 版
我是从05年开始写测试代码的，当时是一个比较小的项目，公司想试一下。等到项目结束时，只有我一个人在坚持。客观的说TDD对程序员OO的水平要求比较高，很多人达不到这个水平，也没有想去努力达到，所以就找些理由放弃了。不过我是先写实现代码的，虽然没有严格按照TDD在做，但也收获不小。不过近期也在考虑，转换一下思路去做，看看有没有别的效果。的确，测试的重要性和必要性就别讨论了，大家还是分享一下自己在测试方面的经验更好。
- 进入论坛 Java 版
小步快跑，不见的就要严格按照什么标准来执行。粒度还需要自己来把握。但一定要记住OO是根本。如果数据库设计的还可以的话，工作量也不会太大。每天早上花1个小时去review自己昨天的代码，应该是一种习惯。随便说一下，我写了7年的代码，依然喜欢。写代码不丢人，因为那是劳动。
- 进入论坛 软件开发和项目管理 版
国内银行的跨行转帐一般都是通过人民银行的系统做的。都是异步操作。如果从A行A帐户转到B行B帐户。A行先从你的帐户上扣款，然后给人行发报文，然后人行再把报文发给B行，B行再给你入帐。每天下午会进行行间的一个扎差。人行有两套系统：大额支付系统； 基本上是实时的，就是说人行接到报文后马上发给B行。小额支付系统 批量处理，隔一段时间处理一次。而人行是按照报文向银行收费的，所以我们转帐时，快的要比慢的贵。
- 进入论坛 Java 版
看到这篇文章，突然想到了前几天的一个概念。
感觉‘用户故事’或‘场景’就像一个水灵灵的葡萄，而成文的usecase就像是葡萄干虽然保留了葡萄
最重要的内容，但毕竟不是葡萄。
如果一个没有见过葡萄的人只吃吃葡萄干就去做一个葡萄，估计做出的的葡萄会千奇百怪。葡萄干的存在也是有理由的，他比葡萄好保存，易运输。这是不是和usecase的作用差不多了：）。usecase是对需的一个分析和记录。但我们为了可操作性往往只记录最关键的东西，打开usecase我们常常看到的是一些死巴巴的业务流程。而如果是用户故事了就会好很多，因为既然是故事就会用渲染，
会用人物各个方面细致的描述，会用历史背景的描述总之详尽一 ...
- 进入论坛 软件开发和项目管理 版
评论排行榜