Wordpress themes are available for download at wordpress-related website.

Uncategorized mmpower on 18 Sep 2006 12:09 pm

新项目管理流程要点

word格式文档见本帖子附件.

由本周开始,我们试行以下流程。

目标是提高开发效率,尤其是开发质量保证在既定时间内开发出用户接受的产品。以下流程部分采用一些Agile Development的方法,例如XP(extreme programming)中一些适用于目前我们环境的做法。另一方面以文字的形式把我们以前强调的的流程进一步规范化和细化。

1. 开发团队组成及职责:

包括软件工程师,美工, 项目领导等;每个人同时兼具测试人员职责。

· 客户: 项目团队包括至少一位来自business领域的代表,在此简称“客户”。根据每个项目的不同,客户可以是老狼、野猫等,也可以是技术部某位人员,其职责是提供需求,设立优先级以及对整个项目状况的评估和确定是否接受产品。
· 开发者:
· 测试者:
· 项目管理者:

一些日常职责:

· 广州公司日常管理和项目管理: 协调日常开发工作及与美国方面技术/管理人员的交流和汇报,督促和管理项目进展,组织广州办公室开发讨论 。唐昌成
· 网络及系统管理:负责广州公司服务器,PC,网络和海归网服务器一般软硬件安装、维护,管理。唐昌成。
· 集成及软件配置管理:包括版本控制软件(CVS,SVN等)的管理和维护;监督开发者对版本控制软件的使用确保符合规范(见后面相关章节)及code repository的一致性;负责release cycle的tagging 和branching, 以及开发的产品在开发服务器,测试服务器和production的安装. 袁泉
· 数据库管理:开发、测试,正式运行环境数据库的管理维护;负责制定和执行数据备份计划,以及日常数据建表,performance tuning,以及处理数据更改要求,查询要求, 维护数据库DDL等等. 吴云林
· ISSUE tracking 工具的维护: 吴云林。
· 文档维护:各类文档的维护,更新。吴云林
· 总体开发部管理,总体技术架构,与其他部门和其他海外人员沟通等:李杰
· 自动acceptance测试工具的运行和维护,以及开发和测试环境自动安装script的维护:邓计明
· 会议记录:记录每次开发部会议讨论决定,并在会后将会议纪要发给大家。邓计明。
· 页面及美工:页面和图形设计;静态html和php模板开发。

2. 项目开发流程

此规范覆盖海归网软件开发项目批准后从需求分析到测试维护的各阶段。

2.1 总体项目计划及需求分析阶段

· 由business analyst (目前来说老狼,野猫等等)提出初始需求文档。
· 项目组仔细阅读文档,进行分析, 对问题进行讨论, 弄清需求,形成核心功能use cases文档。
· 项目组每个成员给出实现各部分需求的时间估计。
· 项目管理人员和客户一起根据反馈调整需求范围和完成时间,并给出总体项目计划。可以给项目起一个代号,例如“箭鱼行动”之类。
· 之后在页面设计人员的帮助下做出静态html的快速原型, 要求符合需求的外观,链接和主要页面。
· 之后由business analyst和客户对原型和use cases进行“测试“,确定是否接受;若接受则继续下一步,否则提出反馈由分析员修改并提交给客户,如此直至通过。

2.2 开发阶段

· 在SCM中创建下项目的code repository;

开发阶段由多个小的开发周期组成,每个周期的时间阶段都较短,约在一周左右。每个周期的过程是:
· 由客户和项目管理人员一起以列表形式提出这个周期所需要完成的功能目标。
· 开发人员根据本周期目标, 以及issue tracker上的bug分成小的任务,每个人主动分担其中一部分任务。 由项目管理人员协调。
· 任务(和bug request)都统一由issue tracker跟踪。
· 编写Canoo WebTest格式的自动acceptance test的test cases.
· 开始设计和开发:
a. 设计: 设计要求尽量简单,只需要考虑如何满足当前周期的功能目标。
b. 在开发过程中不断地通过refactoring完善和优化系统设计。
c. 新开发代码必须符合海归网代码规范;(见以前相关文件);代码按照版本管理工具使用规范(见附录)每天check in.
d. 开发人员在自己的PC上安装开发环境并在那里进行开发。(相见开发环境文档,即将更新)
e. 不断的集成和test-driven development.
· 页面设计和美工不能等到最后,而是与程序开发同步进行。系统的设计要遵循MVC模式,页面与business logic, controller尽量区分开,根据设计约定页面设计者直接开发创建template和静态页面。
· 不断的集成: 每天每个开发者将最新完成并经过自己unit test没有错误的代码check in. 至少check in一次,注意只能check in经过测试无误的代码。一般情况下可以每天下午5点钟后大家check in.
· 每天晚上由script自动从code repository (CVS/SubVersion)将最新代码安装到开发服务器上。
· 每天晚上Canoo WebTest自动运行由这些test cases生成的test scripts测试开发服务器上的当前版本,并自动生成测试报告。
· 每天早上一来开发人员阅读测试报告,改正错误并继续完成未完成的部分。
· 在每个周期的开始所有test cases都会失败,之后随着开发的进行每天通过的test cases越来越多。至周期结束前所有test cases都应该通过。
· 周期结束时(所有test cases通过后)由CM管理员将code repository中最新的代码(应该与开发服务器上的版本一致)加“ITT” tag.
· 测试服务器上有script每晚从CVS/SVN中将最新标有”ITT” TAG的代码拉出来并自动安装。End user/customer一般在测试服务器上进行acceptance测试. 发现的错误和改进的要求在issue tracker上报告. (关于issue tracking 使用和流程详见其他文件)

· 所有周期完成后由CM管理员将code repository中最新的代码(应该与开发服务器上的版本一致)加“TEST” tag.

其他:
· 每周二上午的开发部例会和status report照常进行。除此外碰到问题请及时讨论解决,必要时由小唐召集主持在办公室开会讨论。
· 每天工作时间内必须保持在MSN上登陆,以方便与大家沟通交流。

· 团队的每个人都是项目的拥有者,每个人都对项目的成败负责。若周期计划提前或按时完成建议大家应予庆贺,公司可考虑报销一定费用,如小纪念品或中午一起出去吃午饭。 若周期计划未完成除了根据奖惩规定对未完成的个人惩罚外,相关人员需要加班将进度赶回来。

· 有时间尽量将自己的开发感想或心得整理帖到海归网内部技术论坛上,与大家分享一起进步。
· 沟通!沟通!沟通!包括与项目管理人员, 与需求制定者, 以及开发者之间的沟通.不清楚的需求需要及时提问, 不合理的要主动提出而不是等着别人指出来分配任务; 碰到设计和开发的问题要主动和大家讨论解决, 而不是光靠自己闷头解决. 一句话:加强主动性。

a.

2.3 系统测试阶段

这个时期是在所有计划中的开发完成后。由于是test-driven开发,应该大部分的代码都已经被自动覆盖了。但是还有一些自动测试无法覆盖的部分需要手工测试。测试由customer和end user(如果可能的话)共同进行,发现问题和改进建议放在issue tracker里,由项目管理人员分配给开发人员,确定优先级和完成时间及版本。关于issue tracking的流程详见相关文档。

此周期与开发阶段一样每晚自动安装。

2.4 正式release使用

· deployment一般在系统traffic最少时,以使受影响用户最少。一般来说是北京时间半夜12点。
· go live当晚开发者需要在线,或者通过电话支持。由项目管理人员决定谁需要在线。
· 如果是对现有用户有影响(例如须停止服务),则需要先在10分钟前通知用户;
· 如果是对现有版本升级,需要先停止服务器。
· 安装最新代码。(如果是如果是对现有版本升级,这一布不需要)
· CM管理员将code repository中最新的代码(应该与开发服务器上的版本一致)加“PROD” tag.
· 设置;如果是如果是对现有版本升级,需要把测试site设置值(ip, 数据库name, username/password etc)改为production values, 把原 production settings改为测试site的values.也就是说production site 和testing site互换。对于新应用则需要建立production 和testing两个环境。

例如,ttest.haiguinet.com是海归网的test site, 而www.haiguinet.com是production.

· 正式release后还需要将最新代码安装到另一个测试环境(fast track testing site). 改环境总是保持与production相同的版本,作为debug和维护releases (见下节)测试用。

2.5 维护阶段

发现问题和改进建议放在issue tracker里,由项目管理人员分配给开发人员,确定优先级和完成时间及版本。关于issue tracking的流程详见相关文档. 项目管理人员可根据优先级将request放到新版本计划中,或者是维护release中。

如果该issue经项目管理人员批准放在在维护release中,需要在code repository以”PROD” tag为 root建立一个新的branch,所有修改在该branch上进行。需要有一个不同正常开发test environment的 fast track test environment.

新版本的开发则在main trunk上进行。

注意: 一般情况下不能直接在production上直接修改代码,而是需要通过正常的CM process在发fast track testing server上经过测试再deploy到production上。维护release不需要切换环境,而是直接将最新代码安装到production.

Production安装后需要在CVS/SVN中把改动的代码与开发中的代码进行合并. (merging)

附录0 项目开发周期及各阶段交付成果

遵照传统软件工程周期,以下为项目各阶段及其可交付产品

–项目计划

交付:计划及预算,包括时间,金钱,开发人员及其他所需资源。

–系统定义及需求分析

交付:需求说明;系统总体架构设; use cases; .test cases.

–高层设计:

交付(注:新方法中此步略去): 对于面向采用对象开发的应用:UML class diagram /sequence diagram。 对于结构化开发方法的应用需要模块结构设计说明书。

prototype screens;

数据库模型:E-R model.

– 详细设计,编码,单元测试:

交付: 遵照海龟网编码规范的PHP及其他代码文件;包括phpDocumentor产生的API文档。SQL文件。应用配置文件, 用户手册等。

– 测试

分为系统测试及集成测试。前者测试子系统,后者测试各子系统之间的集成。
交付: 测试计划 (test plan)及测试结果。

– 维护
主要是三种: (1) 解决production system 因系统或网络引起的问题,这一般是系统管理员的责任。(2)改bug (3) 系统新功能开发。

附录1。 版本管理工具的使用规范。
CVS或Subversion. 二者各有优缺点。从用户概念简单话来说subversion稍好一些,并且网络访问速度较快,并且与open source的trac集成。今后趋向是新项目采用subversion, 并逐渐将CVS中的老项目转移到SVN中。

· code repository 的建立,位置,命名, authentication protocol.
· 哪些文件需要存在CVS/SVN中
· 哪些不能存在CVS/SVN中
· 推荐统一使用的windows客户端 (turtoiseCVS 或turtoiseCVS.)
· 正确的使用方法和顺序,如何Check out; update , 改code, add files/remove files , commit
· 什么时候做,如何做tagging和branching. 版本序列号从1。0开始,由CV/SVN自动增长。每到一个新的production release, 我们将
label所有文件。第一次正式版本tag为PROD_1,第二次为PROD_2,等等以此类推。

平时新版本的开发总是在main branch上。对于每个production branch, 我们将建立一个分支。对于production bug fix,我们将在该production release的分branch上修改,这样bug fixing不会影响到新版本的开发。
· 如何从code repository export某个tag或branch的代码用于deploy。

todo: add more details.

附录2。 Issue tracking工具与流程。

目前使用BugFree.

TODO: add details.

以后根据情况可能该用其他功能更全面的产品,例如TRAC.

附录3: 海归网开发环境,测试环境和production环境指南,以及使用规范。

附录4。 海归网production server管理指南:

1.安全规定
(1) please avoid using root acount on the server whenever possible. I have set up sudo privileges for all of you. please log on using your own accounts, and while doing previlege operations please use the sudo command instead of login as root. for example, to view /etc/shadow, you need to type:

sudo vi /etc/shadow

system will prompt you for your password and you need to enter your own password in order to continue.

you can update your user’s profiles (your .bashrc file under your home directory) so the default paths include the mysql/bin and /usr/local/apache2/bin, and alias to view/edit httpd/mysq/php config files and start/stop servers; here are the alias so you don’t need to type the entire command, for example:

alias starthttp="sudo service httpd start"
alias cdhttpd="cd /usr/local/apache2".

etc.

(2) please pick a complex password for your account id. rule is that:
– at least 8 characters long,
– contains at least alphanumeric chars (a-z A-z), at least one digit, at least one special character
– no common english words in password

when choosing your password you can try the following: 窍门1: 记住键盘位置 窍门2: 用数字代替字母, 比如 3=e @=a S=$ 窍门3: 单词中间插特殊字符

(3) right now haiguinet application is using root user to connect to mysql– this should be changed. please create a "haiguinet_cs" user, limit the access of this user only to select/insert/update/delete and "create//delete tmp table" on haiguinet_cs schema only and uses that user for haiguinet application.

2. 维护管理指南

– 文件系统和目录结构
――各种logs,firewall settings
——各种scripts,例如database backup, cron jobs, 自动deploy等。

TODO: add more details
附录5。文档管理

目前继续使用phproject的文档管理。以后考虑使用wiki,例如trac中的wiki.

附录6. 每周例会和status report

· 每周进行一次online meeting, 时间是每周二上午十点;

· 每周五下班前发一封status邮件给我和老狼, 列一下:

— 本周所作的工作; 当前开发进展状况
— 下周的工作计划
— 遇到的问题

下面是一个简单例子:

日期: 5/29 - 6/4
— 本周所作的工作: 后台管理设计完成; 开始编码,
完成了与供货商管理界面的分离;
— 下周: 继续后台管理开发; 开始设计自动抓取数据部分;
— 问题:
页面的设计需要专业美工;我现在需要做页面模板吗?如果做了,以后还得返工?如果不做,怎么测试?

附录7 开发规范

7。1 数据库

命名:
– 所有新建table前面需加 "HG_ " 作为前缀,以利于区分新建table和原来framework中的table。

--table name 和column name 需为英文字母和下划线的组合。

– index 名应为 i_xxx

– primary key 名应为 pk_xxx

– foreign key 名应为 fk_XXX

7.2 PHP 编程规范

基本上采用phpBB和evolt规范。这里变量的命名用全小写字母加数字,而不是大小写间隔的命名法--注意这与许多人的习惯(包括我)不同。在我们用 的开源系统中,phpBB和osCommerce是用的这种命名法,但mambo则是大小写间隔的。为统一风格,我们还是统一到全小写的命名。

与数据库命名类似,新建立的php文件名,类名及函数名应以"hg_"作为前缀。

以下为英文版的编程风格规范:

1. Editor Settings
Tabs vs Spaces: In order to make this as simple as possible, we will be using tabs, not spaces. Feel free to set how many spaces your editor uses when it displays tabs, but make sure that when you save the file, it’s saving tabs and not spaces. This way, we can each have the code be displayed the way we like it, without breaking the layout of the actual files.Linefeeds: Ensure that your editor is saving files in the UNIX format. This means lines are terminated with a newline, not with a CR/LF combo as they are on Win32, or whatever the Mac uses. Any decent Win32 editor should be able to do this, but it might not always be the default. Know your editor. If you want advice on Windows text editors, just ask one of the developers. Some of them do their editing on Win32. Top
2. Naming Conventions
We will not be using any form of hungarian notation in our naming conventions. Many of us believe that hungarian naming is one of the primary code obfuscation techniques currently in use. Variable Names: Variable names should be in all lowercase, with words separated by an underscore, example:$current_user is right, but $currentuser and $currentUser are not.Names should be descriptive, but concise. We don’t want huge sentences as our variable names, but typing an extra couple of characters is always better than wondering what exactly a certain variable is for. Loop Indices: The only situation where a one-character variable name is allowed is when it’s the index for some looping construct. In this case, the index of the outer loop should always be $i. If there’s a loop inside that loop, its index should be $j, followed by $k, and so on. If the loop is being indexed by some already-existing variable with a meaningful name, this guideline does not apply, example:for ($i = 0; $i < $outer_size; $i++){ for ($j = 0; $j < $inner_size; $j++) { foo($i, $j); }}Function Names: Functions should also be named descriptively. We’re not programming in C here, we don’t want to write functions called things like "stristr()". Again, all lower-case names with words separated by a single underscore character. Function names should preferably have a verb in them somewhere. Good function names are print_login_status(), get_user_data(), etc. Function Arguments: Arguments are subject to the same guidelines as variable names. We don’t want a bunch of functions like: do_stuff($a, $b, $c). In most cases, we’d like to be able to tell how to use a function by just looking at its declaration. Summary: The basic philosophy here is to not hurt code clarity for the sake of laziness. This has to be balanced by a little bit of common sense, though; print_login_status_for_a_given_user() goes too far, for example — that function would be better named print_user_login_status() , or just print_login_status(). top
3. Code Layout
Standard header for new files: Here a template of the header that must be included at the start of all phpBB files: /*************************************************************************** filename.php ——————- begin : Sat June 17 2000 copyright : (C) 2000 The phpBB Group email : [email protected] $Id: $ ***************************************************************************//*************************************************************************** * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * ***************************************************************************/ Always include the braces: This is another case of being too lazy to type 2 extra characters causing problems with code clarity. Even if the body of some construct is only one line long, do not drop the braces. Just don’t, examples:/* These are all wrong. */if (condition) do_stuff();if (condition) do_stuff();while (condition) do_stuff();for ($i = 0; $i < size; $i++) do_stuff($i);/* These are all right. */if (condition){ do_stuff();}while (condition) { do_stuff();}for ($i = 0; $i < size; $i++) { do_stuff();}Where to put the braces: This one is a bit of a holy war, but we’re going to use a style that can be summed up in one sentence: Braces always go on their own line. The closing brace should also always be at the same column as the corresponding opening brace, examples:if (condition) { while (condition2) { … }}else { …}for ($i = 0; $i < $size; $i++) { …} while (condition) { …} function do_stuff() { …}Use spaces between tokens: This is another simple, easy step that helps keep code readable without much effort. Whenever you write an assignment, expression, etc.. Always leave one space between the tokens. Basically, write code as if it was English. Put spaces between variable names and operators. Don’t put spaces just after an opening bracket or before a closing bracket. Don’t put spaces just before a comma or a semicolon. This is best shown with a few examples, examples:/* Each pair shows the wrong way followed by the right way. */$i=0;$i = 0; if($i<7) …if ($i < 7) … if ( ($i <7> ) …if (($i <7> ) … do_stuff( $i, "foo", $b );do_stuff($i, "foo", $b); for($i=0; $i<$size; $i++) …for($i = 0; $i < $size; $i++) … $i=($j < $size)?0:1;$i = ($j < $size) ? 0 : 1;Operator precedence: Do you know the exact precedence of all the operators in PHP? Neither do I. Don’t guess. Always make it obvious by using brackets to force the precedence of an equation so you know what it does, examples:/* what’s the result? who knows. */$bool = ($i <7> 8 || $k == 4);/* now you can be certain what I’m doing here. */$bool = (($i < 7) && (($j < || ($k == 4)))SQL code layout: Since we’ll all be using different editor settings, don’t try to do anything complex like aligning columns in SQL code. Do, however, break statements onto their own lines. Here’s a sample of how SQL code should look. Note where the lines break, the capitalization, and the use of brackets, examples:SELECT field1 AS something, field2, field3 FROM table a, table b WHERE (this = that) AND (this2 = that2)Top
4. General Guidelines
Quoting strings: There are two different ways to quote strings in PHP - either with single quotes or with double quotes. The main difference is that the parser does variable interpolation in double-quoted strings, but not in single quoted strings. Because of this, you should always use single quotes unless you specifically need variable interpolation to be done on that string. This way, we can save the parser the trouble of parsing a bunch of strings where no interpolation needs to be done.
Also, if you are using a string variable as part of a function call, you do not need to enclose that variable in quotes. Again, this will just make unnecessary work for the parser. Note, however, that nearly all of the escape sequences that exist for double-quoted strings will not work with single-quoted strings. Be careful, and feel free to break this guideline if it’s making your code harder to read, examples:
/* wrong */
$str = "This is a really long string with no variables
for the parser to find.";

do_stuff("$str");
/* right */
$str = ‘This is a really long string with no variables
for the parser to find.’;

do_stuff($str);
Associative array keys: In PHP, it’s legal to use a literal string as a key to an associative array without quoting that string. We don’t want to do this — the string should always be quoted to avoid confusion. Note that this is only when we’re using a literal, not when we’re using a variable, examples:
/* wrong */
$foo = $assoc_array[blah];
/* right */
$foo = $assoc_array[’blah’];
Comments: Each function should be preceded by a comment that tells a programmer everything they need to know to use that function. The meaning of every parameter, the expected input, and the output are required as a minimal comment. The function’s behaviour in error conditions (and what those error conditions are) should also be present. Nobody should have to look at the actual source of a function in order to be able to call it with confidence in their own code.

In addition, commenting any tricky, obscure, or otherwise not-immediately-obvious code is clearly something we should be doing. Especially important to document are any assumptions your code makes, or preconditions for its proper operation. Any one of the developers should be able to look at any part of the application and figure out what’s going on in a reasonable amount of time.
Magic numbers: Don’t use them. Use named constants for any literal value other than obvious special cases. Basically, it’s OK to check if an array has 0 elements by using the literal 0. It’s not OK to assign some special meaning to a number and then use it everywhere as a literal. This hurts readability AND maintainability. Included in this guideline is that we should be using the constants TRUE and FALSE in place of the literals 1 and 0 — even though they have the same values, it’s more obvious what the actual logic is when you use the named constants.
Shortcut operators: The only shortcut operators that cause readability problems are the shortcut increment ($i++) and decrement ($j–) operators. These operators should not be used as part of an expression. They can, however, be used on their own line. Using them in expressions is just not worth the headaches when debugging, examples:
/* wrong */
$array[++$i] = $j;
$array[$i++] = $k;
/* right */
$i++;
$array[$i] = $j;

$array[$i] = $k;
$i++;
Inline conditionals: Inline conditionals should only be used to do very simple things. Preferably, they will only be used to do assignments, and not for function calls or anything complex at all. They can be harmful to readability if used incorrectly, so don’t fall in love with saving typing by using them, examples:
/* Bad place to use them */
(($i <size> $size)) ? do_stuff($foo) : do_stuff($bar);
/* OK place to use them */
$min = ($i < $j) ? $i : $j;
Don’t use uninitialized variables. for phpBB 2, we intend to use a higher level of run-time error reporting. This will mean that the use of an uninitialized variable will be reported as an error. This will come up most often when checking which HTML form variables were passed. These errors can be avoided by using the built-in isset() function to check whether a variable has been set, examples:
/* Old way */
if ($forum) …
/* New way */
if (isset($forum)) …


.doc
 描述:

下载
 文件名:  .doc
 文件大小:  94 KB

Trackback This Post | Subscribe to the comments through RSS Feed

Leave a Reply

校验码:  

Buy movie . Why buy movies at the store while you can download complete movies at our home? You can pay with your credit card. Lowest prices over the Internet.

22 queries in 0.168 seconds.© 2004-2008.   海归博客. RSS Comments RSS