软件开发和项目管理论坛最新讨论 - JavaEye 软件开发过程、XP、TDD、软件配置管理、软件测试、项目管理、UML - Java编程，Ruby编程，微软.net，AJAX，敏捷软件开发，综合软件技术 http://www.javaeye.com UTF-8 Copyright 2003-2008, JavaEye.com http://blogs.law.harvard.edu/tech/rss JavaEye - 做最棒的软件开发交流社区 小项目怎么做需求分析? JavaEye网站 网站: JavaEye  作者: mfcai  链接：http://www.javaeye.com/topic/192073  发表时间: 2008年05月12日
声明：本文系JavaEye网站发布的原创文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！
在做项目时，经常会碰到这样的事情.
客户向我们反映在和你们的工程师谈论需求时，他们总是满口答应没问题。可是，当他们做好以后，拿过来一看，根本就不是这么回事。而开发人员也在诉苦：用户什么都不懂，而且他们的需求老是变动，时间又这么紧,你让我们怎么办？
我觉得如果开发人员在做需求分析时,如果注意以下几点,也许可以避免被动的局面.

1、掌握相关的行业知识
在和客户沟通之前，最好了解一下相关的行业知识。
有一个项目管理人员说：行业知识可有可无，作为需求人员，最重要的是和客户沟通。最好把客户讲的东西都记下来。然后，由项目组决定后，再把意见反馈给用户。这种沟通方式，既不能有效的发现问题，也容易延误项目时间。
案例：
小A某名牌大学毕业，公司为了锻炼他，特意安排他和一个比较重要的客户进行一次沟通。小A和客户电话联系，商定了见面的时间和地点。西装革履的小A提前十分钟来到了见面的地点。一番客套之后，小A和客户就开始进入话题。客户开始谈他的需求，从项目背景到项目目的，从业务流程到相关部门和人员。客户兴致勃勃地说着，小A手忙脚乱的记着。客户停下来，问小A你觉得我的观点有什么需要补充吗？小A老实地回答说，我对业务还不是很熟悉。客户一下兴致全无，对小A说，等你对业务熟悉了，再来找我把。

2、重在沟通
沟通的方式可以是访谈和调研、会议、电话、电子邮件、小组讨论、模拟演示等不同形式。我的意见是最好是与客户面对面的沟通。金庸武侠小说中的高手过招，都是面带微笑，不露声色，比拼的是内力。面对面的沟通，就是比拼内力。所以，一定要把准备工作都做好了。
沟通其实也是在相互妥协。对用户合理的要求，要尽量满足。用户的一些不合理的要求，要想办法避免。要委婉地提醒用户，如果这样做，可能要增加项目时间，或者对运行环境有更高的要求。
沟通一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。

3、深究细节
不要等到项目做好后，才让客户发现问题。
客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的.这时，在客户看来当然需要更改.但这种更改却被我们看成了需求的更改。既然是需求的更改,那么就需要增加项目成本(资源)或延长项目时间。我看过一篇文章,说要要想项目成功,就得和用户建立亲密的伙伴关系.可是,这种以需求的更改为理由让用户从口袋里掏钱,亲兄弟也不干阿.
所以,需求分析不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Mon, 12 May 2008 01:43:07 +0800 http://www.javaeye.com/topic/192073 http://www.javaeye.com/topic/192073 比丰田生产方式和精益的消除浪费，更重要的东西 JavaEye网站 网站: JavaEye  作者: partech  链接：http://www.javaeye.com/topic/191749  发表时间: 2008年05月10日
声明：本文系JavaEye网站发布的原创文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！
丰田生产方式和精益开发，如果用一句话来说就是“消除浪费”，但我认为在这之下还有更重要的东西，那就是
“人和”，这很重要，精益之所以能起源于日本，正和这个“大和民族”占绝大多数不无关系。相比于中国人崇尚“一”（一个世界，一个梦想），日本人崇尚“和”，丰田公司将员工看作自己宝贵的财富，努力使员工视公司为家。
没有这些丰田生产方式是不可能诞生的。
如果作为领导不能激发起员工积极参与的主动性，是不可能实践好精益开发。
如果只停留在雇主/员工层面，简单的只是把上班看作拿到报酬，而不是把工作作为自己理想的一部分，也不可能实践好精益开发的。
如果团队间没有相互关心，相互帮助的温情，也不可能实践好精益开发。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sat, 10 May 2008 16:53:20 +0800 http://www.javaeye.com/topic/191749 http://www.javaeye.com/topic/191749 项目组中管理者与被管理者的关系与说话态度、语气等的问题 JavaEye网站 网站: JavaEye  作者: banner  链接：http://www.javaeye.com/topic/191695  发表时间: 2008年05月10日
声明：本文系JavaEye网站发布的原创文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！
这段时间有个想法：公司领导更喜欢在工作中对下属严厉的 Teamleader（执行力强？）。
工作中常听到此类语言：“***，你的***做完了吗？”、“为什么还没有做完！”、“你必须今天做完！”、“你是怎么回事！”、“这个问题有那么难吗？”。语气冷漠严厉。
不知道大家所在的公司、项目组在工作中是不是这个样子？
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sat, 10 May 2008 11:03:01 +0800 http://www.javaeye.com/topic/191695 http://www.javaeye.com/topic/191695 询问下各位所在公司开发人员是如何交流的 JavaEye网站 网站: JavaEye  作者: lsk  链接：http://www.javaeye.com/topic/191325  发表时间: 2008年05月09日
声明：本文系JavaEye网站发布的原创文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！
不知道各位所在的公司开发人员平常是如何进行交流和沟通的?
比如在碰见一个问题大家都有分歧的话? 是如何来处理.
难道技术人员在讨论一个问题的分歧都是争的脸红脖子粗还瞪着眼睛大声的说话才证明自己的技术路线或者思想是对的?

不知各位如何处理这种情况.
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 09 May 2008 10:18:53 +0800 http://www.javaeye.com/topic/191325 http://www.javaeye.com/topic/191325 将听吾计用之必胜留之，将不听吾计，用之必败，去之 JavaEye网站 网站: JavaEye  作者: lengyue  链接：http://www.javaeye.com/topic/191604  发表时间: 2008年05月09日
声明：本文系JavaEye网站发布的原创文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

    我一直认为让技术人员转向管理岗位是一种资源的浪费，回想做程序员的日子也许是我职业生涯中最快乐的日子，很忙，但是总觉得有很多进步。然而，我必竞是太浮躁了，（我一直认为中国的程序员比较浮躁，虽然我没有留过学，但是看到外国那些胡子都白了的人还在写代码，就觉得自已的在技术方面太肤浅了），我也不知道自已为什么会走向浮躁的行列中来，刚刚写了5年的代码就要逼着自已去想一些管理上的事情，技术在渐渐荒废，本来想做10年的程序，然后再转向项目的管理，看来很多事情不能象自已想的那样前进了，但，提前了也许是好事。

      做项目要是没有管理，单拼技术，项目一定会乱得一塌糊涂，自从单独负责项目后就很少有睡得踏实的时候，项目中最活跃的因素就是人，而人不象计算机那样好把握了，以前写程序时，执行出错了，就不要怀疑是别人的错，一定是自已弄错了，然后计算机才执行出错。而现在做项目管理上的情情，可能这样也是对的，那样也是对的，每次做一件决定的时候非常的难下决心。但是为了能够将事情做下去，就得撑着。这周将一位同事开除出公司了，项目正是用人之际，只要我有退让的余地，我都不会做出将人开掉的决定，何况这个人还是老板朋友的孩子呢。但是，没有办法，我要想将这个团队建设好，首先我就要做一个正直公正的人。否则，我将很难开展工作。开除的直接原因就是因为这个兄弟在开发现场玩游戏，且第一次提醒后（本来是和另一个人一起玩，我提醒的是其中的一位，并没有直接叫他不要玩），当我出去一趟回来后，发现他不完sony那个东西了，又上网上玩游戏了，难以忍受。再想想这位兄弟平时的表现，我再不下决心拿掉团队中这块短板，这个团队必将一盘散沙。于是，找他谈了一下，让他回公司办离职手续，开会，宣布将其开除，别外一个以观后效（虽然也参与玩了，但听到提醒后就没有再继续）。宣布完心情异常沉重，不知道这样办是不是最好的方式？

     我觉得做项目如同带兵打仗，将听吾计用之必胜，留之，将不听吾计，用之必败，去之。做为项目的负责人，首先我要做一个正直的人，做正确的事。我应该努力提高团队的整体水平，即团队的上限，而不能因为迁就某一个人而降低团队的下限。就象看电视剧《亮剑》当时独立团与山本一木在杨村相遇时200：0的情况是存在的，一个团队如果训练好了，以一当十，或以一当百是完全可能的。

   


本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 09 May 2008 23:03:58 +0800 http://www.javaeye.com/topic/191604 http://www.javaeye.com/topic/191604 美工和开发人员同步开发的问题 JavaEye网站 网站: JavaEye  作者: lsk  链接：http://www.javaeye.com/topic/191141  发表时间: 2008年05月08日
声明：本文系JavaEye网站发布的原创文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！
最近开发人员和美工人员.经常在修改页面文件上冲突. 美工人员的电脑上没有SVN.因为电脑配置的问题.装了SVN还要装web服务器.性能吃不消. 所以现在采取的办法是:
将美工改好的界面文件拉到我自己机器上.然后再更新SVN.这样如果版本库里有新版本会冲突或者合并.

但是发现这样存在一个很大的问题. 如果我改了某个页面文件.提交了后在 把美工的界面文件拉到我本地会覆盖.不管我提交或者不提交.更新或者不更新.我改过的文件都会被覆盖. 非常的头疼.

不知道有没有人有这方面的经验.来处理美工和开发人员同步开发之间的冲突...
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Thu, 08 May 2008 16:55:36 +0800 http://www.javaeye.com/topic/191141 http://www.javaeye.com/topic/191141 项目管理的软件 JavaEye网站 网站: JavaEye  作者: ygxdha  链接：http://www.javaeye.com/topic/190598  发表时间: 2008年05月07日
声明：本文系JavaEye网站发布的原创文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！
情景描述：
1：组织结构：
整个项目组的开发人员有20来个，其中有一个pm，3个tl，每个tl下面有6-7个开发人员，在每个tl下的小组中，能力比较强的有1-2个，中等的有2-3个，还有1-2个是比较弱的。
2：开发现状：
每个tl下面的小组都有自己独立的任务，整个项目组还有一些共享的任务（这些任务每个人都可以去做）。但是因为能力的差别，能力强的人非常忙，能力中等的人的工作强度比较适中，能力弱的人却比较空闲。作为PM，无法清楚并且实时的了解到整个项目组下每个成员的当前工作状况，无法进一步安排工作，了解每个人的工作效率。
3：已有的管理工具：
项目组有wiki进行知识积累。有mantis进行bug管理。svn进行版本管理


需求：
1：站在pm，tl的角度上。
需要一个软件能了解当前所有成员当前的工作情况。包括手上已有的任务，当前正在做的任务，每个任务预定需要的时间，已经花费的时间，整个项目还未分配的任务。能统计每个成员任务的完成情况。（比如一周完成了预算为多少人天的任务，延期的有多少等等）
2：站在pg的角度上。
知道自己当前已经分配的任务。在软件中登录自己正在解决的问题。如果遇到难点，可以通过类似短信广播的方式，向所有组员提出自己的问题，寻求帮助。



不知道现在有这样的管理软件吗？
如果没有，我倒是打算自己开发一款出来给自己项目组用。不过希望能得到其它大大的建议，毕竟当前我对这个项目管理软件的概念和需求还不是非常清晰。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 07 May 2008 14:41:10 +0800 http://www.javaeye.com/topic/190598 http://www.javaeye.com/topic/190598 互联网公司组织结构畅想曲 JavaEye网站 网站: JavaEye  作者: googleboy  链接：http://www.javaeye.com/topic/190661  发表时间: 2008年05月07日
声明：本文系JavaEye网站发布的原创文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！
互联网公司，按我的理解应该是非常有朝气，有活力的company.他的公司性质决定了这一切。
互联网公司不同于一般的软件公司。他应该没有那种老掉牙的东西。没有历史的负担。它更像一
个单身青年,百分百投入，做事毫无顾及.
研发中心的配备：
技术总监，依照公司商业方向，制定相应技术路线。并且调节各个部门项目的进展。
并参与公司项目的抽象业务分析。

技术经理： 所分配项目进度的掌控，团队氛围的和谐化。并且对开发人员调动方面于PM的协调。参与
制定各自部门的活动

架构师： 技术选型，项目整体架构的搭建,相应技术难题的公关。

开发经理： 技术精英。对技术熟练，项目业务清晰。分配Task给组内Developer,并督促按时完成。

开发人员： 实际代码的编写

额 好像这样就是一般公司研发部分的人员体系吧
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 07 May 2008 17:08:43 +0800 http://www.javaeye.com/topic/190661 http://www.javaeye.com/topic/190661 [讨论]有关wiki的选择和如何将原有系统迁移到wiki。 JavaEye网站 网站: JavaEye  作者: sdiablo  链接：http://www.javaeye.com/topic/190914  发表时间: 2008年05月08日
声明：本文系JavaEye网站发布的原创文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！
想使用wiki来管理文档和建立公司内部的知识库。比较了一些wiki产品。confluence无疑是做得比较好的，但是要银子。trac和moinmoin没有所见即所得的编辑功能。mediawiki权限管理功能比较弱。

我期望wiki能具备的功能：
1 权限管理。企业内部知识库的权限无疑是很重要的一部分。
2 所见即所得的编辑器。要让使用者拿到工具就能上手工作。wiki语法虽然不难，但是也是需要学习，有可能造成项目无法正常启动。

综上所述我选择了xwiki。基本能满足我的需求。而且，它开发的主要目标就是为企业管理而考虑的。同时，xwiki还获得了google的赞助。近来的版本更新也非常频繁。

另外一个问题也出来了。公司内部已经有了许多文档，多是word，excel，powerpoint。大约3-4G，近万个文件。正是因为管理不变所以想使用wiki。
如何顺利迁移到wiki系统呢？

这么大的数据量，迁移肯定是个长期的过程，有可能迁移的过程中产生两个版本的知识库。如何避免迁移期的不便？
word，excel，powerpoint的格式比网页丰富很多,如何保持原有文件的排版?
原有文件的录入有没有什么好的办法?能否直接导入?

上述的问题希望能和大家讨论一下.同时也非常希望有过类似经验的同学能够指点迷津.
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Thu, 08 May 2008 09:57:48 +0800 http://www.javaeye.com/topic/190914 http://www.javaeye.com/topic/190914 现在大家都在用什么测试工具 JavaEye网站 网站: JavaEye  作者: zhaoaifang  链接：http://www.javaeye.com/topic/190687  发表时间: 2008年05月07日
声明：本文系JavaEye网站发布的原创文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！
现在大家都在用什么测试工具啊！
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 07 May 2008 18:00:02 +0800 http://www.javaeye.com/topic/190687 http://www.javaeye.com/topic/190687 从金融学的角度看“重构” JavaEye网站 网站: JavaEye  作者: tuti  链接：http://www.javaeye.com/topic/190154  发表时间: 2008年05月06日
声明：本文系JavaEye网站发布的原创文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！
前些日子在InfoQ看到篇文章 "抛砖引玉——重构是必要的浪费" http://www.infoq.com/cn/news/2007/12/refactoring-is-waste.
文中认为 “重构并不能为客户创造可衡量的价值。所以将重构归为必要的浪费。
个人觉得这样的解读很牵强，也有悖于精益的基本精神。

我觉得问题核心在于重构对于客户创造了什么价值。
近日从金融学的角度来进行分析，略有所悟。

重构其实提供了“需求变化”的“看多期权”（call）--事实上还提供了其他多种变化的看多期权。需求变化的可能性越大，这份期权就价值越高。而在金融市场上充满了明码标价的期权交易。

以TDD的三步骤(不可运行，可运行，重构)为例，可以看做实现一个功能的“现货价值”并附加该功能需求变化的“看多期权”。 而只完成功能要求程序，不进行重构，只能看单纯含有一个功能的“现货价值”。
对于客户而言，附加有“需求变化看多期权”的程序价值要高于只含“现货价值”的程序。
对于“需求变化看多期权”最坏的情况也就是“需求不变化”，这份期权就没必要行使。
这就是“需求稳定项目（如：学校大作业）”和“需求总是与时俱进的项目”在开发行为上存在差异的原因之一。

事实上，我觉得软件项目开发，充满了时间序列上的发生的不确定性，项目的过程中需要不断的吸收这种不确定性，并追求项目达到更高的价值。这种情况很适合以金融学的视角进行分析。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 06 May 2008 13:07:22 +0800 http://www.javaeye.com/topic/190154 http://www.javaeye.com/topic/190154