肉肉's Blog

SVN代码统计工具-statsvn傻瓜版，从此告别命令行统计时代

Thu, 09 Jan 2020 14:24:06 +0800

SVN代码统计工具

话不多说，我相信每个带团队的人都非常烦躁统计代码

特别是多项目维护的时候，通过CMD来统计代码实在烦，每次都要翻下命令行参数的使用

这里做了小工具，可以通过UI操作，简单的进行代码的统计，可以根据时间区间、提交人、排除文件类型等统计报表

下载链接

喜欢的可以支付宝给个打赏，鼓励下原创

敏捷的“变与不变”

Tue, 08 Oct 2019 10:12:51 +0800

瀑布模式

每一步都是建立在上一步的基础：因此对上一步的输出，就会要求尽可能准确，完整，而当后期发生任何的变化，无论是需求还是设计，都会对整个项目的风险和成本，造成很大的影响

设置严格的审批流程，评估风险和成本，以决定是否接受变化：需求大多数是通过详细的需求说明文档来管理的，无论是Use Case，还是遵循IEEE 830的标准，或者ISO标准，都是对需求有非常具体详细的记录，而且很多的需求是从系统运行的角度来描述，很多时候，很难进行优先级的排序

例如：

电视机需要一个显示屏幕

电视机需要AV接口

电视机需要遥控器

电视机需要HDMI接口

电视机需要智能操作系统

然后需求告诉你“这些都很重要！我都要！”

敏捷模式

决定需求优先级：需求是用过story和product backlog进行管理的，是从用户角度切入的对于产品的认知，他们之间相互独立，没有耦合关系，因此比较容易进行排序，我们把刚那个例子改了一下：

作为用户，我希望能看电视频道

作为用户，我希望躺在床上遥控

作为用户，我希望把PS4接入电视玩

作为用户，我希望可以在电视上聊微信

这样的方式，用户是比较容易决定哪一个功能更加重要，也就可以快速的确定优先级。

这样，用户就可以根据现实情况，灵活的调整实现的顺序。因此，当任何需求的变更出现的时候，用户只需要通过设置合适的优先级，就可以将新的变更应用于系统中。

迭代式开发：可以帮助团队更加专注于实现最重要的功能，在技术方案上，不必急于完成所有的技术细节的设计，从而帮助他们“延迟决定”，采用演进式的设计，逐步达到最优的技术方案。这种方式，会促使团队根据当前确定的需求，通过持续的重构，获得最好的技术方案，不会因为在信息不完整的情况下，匆匆作出重大的但错误的技术决定，而导致在后期进行大规模重构带来的巨大风险和成本。因此，这样可以从技术实现方面，帮助团队更容易的接受变化。

变还是不变？

拥抱变化并不是允许毫无章法的变化，软件开发是一个类似于马拉松是的长跑，需要整个团队保持一个健康的节奏，这样才能顺利的跑到终点，如果节奏总是被不断的破坏，项目是很难最终成功的。而Sprint就是Scrum的节奏，如果在一个Sprint的过程中，团队不断的被新的要求干扰，就很难培养出对整个团队能力的感觉，也就会对项目的规划和估算带来很大的影响。另外，Sprint的长度往往是2～4周，也就是说，响应用户变化的周期是2～4周，任何新的重要变更，最长就是在2～4周后，就可以被响应和实现，这种频度，对于大多数的项目来说，是可以满足用户的变更要求的。所以在一个Sprint内保持需求的相对稳定是必要的，也是可以接受的，如果用户的需求变更频率更高，可以缩短Sprint的长度，以提高响应速度。

任何无序的变化，都是需要通过一定的方式，转化为有序的变化，才能够有利于项目的成功。Scrum中，通过设置合理的需求的优先级，以及合适的Sprint的长度来将需求的变化更加有序，通过迭代的开发和演进式的设计，来帮助团队更加容易的接受和适应变化，因此，相对于传统的瀑布式的开发模式，它更贴近用户，更加灵活，变更的成本和风险更低。

其实变与不变没有一定的结论！希望人人都能做好产品经理！

react 学习

Mon, 14 Jan 2019 10:04:38 +0800

https://react.docschina.org/docs/rendering-elements.html

项目实战

在真实项目开发中，你可能会需要 Redux 或者 MobX 这样的数据流方案，Ant Design React 作为一个 UI 库，可以和任何 React 生态圈内的数据流方案以及应用框架搭配使用。我们基于 Redux 推出了自己的最佳实践 dva，以及可插拔的企业级应用框架 umi，推荐你在项目中使用。

dva 是一个基于 Redux 的轻量级数据流方案，概念来自 elm，支持 side effects、热替换、动态加载、react-native、SSR 等，已在生产环境广泛应用。

umi 则是一个可插拔的企业级 react 应用框架。umi 以路由为基础的，支持类 next.js 的约定式路由，以及各种进阶的路由功能，并以此进行功能扩展，比如支持路由级的按需加载。然后配以完善的插件体系，覆盖从源码到构建产物的每个生命周期，支持各种功能扩展和业务需求。

你可能也会对 Ant Design Pro 感兴趣，这是一个基于 umi、dva 和 ant design 的开箱即用的中台前端/设计解决方案。

本文会引导你使用 umi、dva 和 antd 从 0 开始创建一个简单应用。

创建新应用#

先创建一个空目录，

$ mkdir myapp
$ cd myapp

推荐使用 yarn 创建应用，执行以下命令，

如果你坚持用 npm，可执行 npm install -g create-umi && create-umi，效果一致。

$ yarn create umi

yarn create v1.12.0[1/4]

centos 环境配置

Thu, 13 Sep 2018 10:09:15 +0800

YUM更行

CentOS 7.x
rpm -Uvh https://mirror.webtatic.com/yum/el7/epel-release.rpm
rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm

安装：

yum -y install xxx

MYSQL:

一、检查系统是否安装其他版本的MYSQL数据

#yum list installed | grep mysql
#yum -y remove mysql-libs.x86_64

二、安装及配置

# wget http://repo.mysql.com/mysql-community-release-el6-5.noarch.rpm
# rpm -ivh mysql-community-release-el6-5.noarch.rpm
# yum repolist all | grep mysql

安装MYSQL数据库

# yum install mysql-community-server -y

设置为开机启动(2、3、4都是on代表开机自动启动)

# chkconfig --list | grep mysqld
# chkconfig mysqld on

三、设置远程root
启动mysql

# service mysqld start

设置root密码

# mysql_secure_installation

登陆root账号

# mysql -uroot -p

建立远程root用户

mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '你设置的密码' WITH GRANT OPTION;
mysql> flush privileges;

四、设置utf-8编码

查看mysql原本编码：

mysql> show variables like 'character%';

设置编码

# vi /etc/my.cnf

如下(少补)：

[mysqld]
character-set-server=utf8 
collation-server=utf8_general_ci 
sql_mode='NO_ENGINE_SUBSTITUTION'
[mysql]
default-character-set = utf8

[mysql.server]
default-character-set = utf8


[mysqld_safe]
default-character-set = utf8


[client]
default-character-set = utf8

重启mysql

# service mysqld restart

再次查看编码：

     # mysql -uroot -p
mysql> show variables like 'character%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

TOMCAT：

安装：

yum install tomcat

启动：

systemctl start tomcat.service

安装管理包：

yum install tomcat-webapps tomcat-admin-webapp

安装在线文档：

yum install tomcat-docs-webapp tomcat-javadoc

PHP：

yum install php70w

pear

Wget http://pear.php.net/go-pear.phar

php go-pear.phar

pecl

yum install php70w-devel


在php7之前是mongo扩展, 在php7之后是mogodb扩展。两者的用法完全不一样。
1.      安装轻型目录访问协议
yum install openldap-devel

MongoDb

1:创建仓库

vi /etc/yum.repos.d/mongodb-org-3.4.repo

2：把下面的内容复制到文件中保存退出

[mongodb-org-3.4]
name=MongoDB Repository
baseurl= 
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-4.0.asc

3：yum安装如图安装完成

yum install -y mongodb-org

4：修改配置文件

vi /etc/mongod.conf

把bindIP改成 0.0.0.0所有的机器都可以访问

5：启动mogodb

systemctl start mongod.service
systemctl stop mongod.service //停止
systemctl restart mongod.service //重启

6:设置开机自启动

systemctl enable mongod

7：链接mongodb

mongo 127.0.0.1:27017

MongoDB默认将数据文件存储在/var/lib/mongo目录，默认日志文件在/var/log/mongodb中。如果要修改,可以在 /etc/mongod.conf 配置中指定备用日志和数据文件目录

MongoDB默认将数据文件存放在/var/lib/momgo目录 ,

默认日志文件存在/var/log/mongodb/mongod.log目录,

如需修改可以在/etc/mongod.conf配置文件中指定目录

扩展安装

pecl install mongodb

编辑php.ini

extension=mongodb.so;

重启一下

Apache:

yum -y install httpd

yum -y install httpd-manual mod_ssl mod_perl mod_auth_mysql

yum -y install php-gd php-xml php-mbstring php-ldap php-pear php-xmlrpc

yum -y install mysql-connector-odbc mysql-devel libdbi-dbd-mysql

操作命令总结：

1. apache命令

systemctl start httpd.service #启动apache(后面的.service省略也行) 或者是：service httpd start

systemctl stop httpd.service #停止apache 或者是：service httpd stop

systemctl restart httpd.service #重启apache 或者是：service httpd restart

systemctl enable httpd.service #设置apache开机启动 或者是：service httpd enable

restart一下，然后：
输入localhost
出现之后代表已经安装上去了。

2. mysql命令

systemctl enable mysqld     #开机启动  或者： service mysql enable

systemctl start mysqld       #启动服务   或者： service mysql start

systemctl restart mysqld     #重启服务  或者： service mysql restart

systemctl stop  mysqld            #停止服务   或者：service mysqld stop

初次安装mysql是root账户是没有密码的
设置密码的方法

<code class=" hljs vala"># mysql -u root
mysql> set password for root@localhost = password('123456');  //这里注意自己替换密码
mysql> exit</code>

创建一个可以从任何地方连接服务器的一个完全的超级用户，但是必须使用一个口令

<code class=" hljs applescript">mysql> grant all privileges on *.* to user@localhost identified by ‘123456’</code>

Go:

下载并解压

下载

[root@localhost soft]# wget -c https://storage.googleapis.com/golang/go1.8.3.linux-amd64.tar.gz1

解压

将源码包解压后直接放到 /usr/local 目录下, 不用再次 make && make install 来安装了, 开箱即用

[root@localhost soft]# tar -C /usr/local/ -zxvf go1.8.3.linux-amd64.tar.gz 1

添加系统环境变量

创建新文件并打开

[root@localhost soft]# vim /etc/profile.d/go.sh1

输入以下内容

> 输入内容

export PATH=$PATH:/usr/local/go/bin> 保存退出:wq!1234567

立即生效环境变量

[root@localhost soft]# source /etc/profile.d/go.sh1

你可能会说这么添加环境变量, 多不快捷啊！当然你也可以直接在shell中输入以下内容:

export PATH=$PATH:/usr/local/go/bin1

但就个人认为我这个方法来是比较不错的, 编译一个软件需要添加一个文件,
然后 source 一下导入到当前软件需要添加的环境变量到系统$PATH中, 每一个人都有一个强迫症的习惯吧!
那好, 请尊重自己好了~~~
再在好了, 你可能在shell的任何位置输入 go 命令了!

添加GOPATH目录

添加GOPATH和添加环境变量没有本质的区别就是作用不一样罢了

创建工作路径

创建一个工作目录, 这个目录就是你以后开发学习go语言的主要战场了, 如在用户家目录创建这样一个目录 dev/go

[root@localhost ~]# mkdir -p ~/dev/go1

添加这个目录路径作为GOPATH

创建一个环境变量文件 gopath.sh 并打开

[root@localhost ~]# vim /etc/profile.d/gopath.sh1

输入GOPATH具体指向位置

export GOPATH=/root/dev/go1

保存退出

:wq!1

立即生效这个GOPATH环境变量

[root@localhost ~]# source /etc/profile.d/gopath.sh 1

验证GOPATH环境变量是否添加成功

[root@localhost ~]# echo $GOPATH/root/dev/go12

OK, 那么这个GOPATH环境变量也就添加完成了

运算GO环境测试

创建测试文件 hello_world.go

[root@localhost ~]# vim ~/dev/go/hello_world.go1

编辑文件

package mainimport (    "fmt")func main() {    fmt.Println( "Hello world!" )}123456789

运算测试文件 hello_world.go

[root@localhost ~]# go run ~/dev/go/hello_world.go Hello world!

学习型管理-培养领导团队的A3管理方法（珍藏版）读书笔记

Sat, 25 Aug 2018 14:19:46 +0800

A3是什么？人家搞了几十年，难道我读一本书就能搞定了？

8月中旬，忽然收到一封邮件，领导指示，月底前读完这本书，写个读书笔记……当时我的内心……千万头@#￥￥%奔腾而过。

内心虽然拒绝，但是表面上肯定是要欣然接受，然后屁颠屁颠的去淘宝卖书（木有电子版啊），居然都没提给我报销书费的事情，再次奔腾一次！

8月16号收到书，今天8月25日，粗略看了一遍目录，通读一次全文，划了一些重点。

说实话书的质量我就不吐槽了，能叫珍藏版的质量如此寒酸，我也是醉了。

书基本上是分了3个主要内容：介绍下概念->举了个栗子->总结一下。

用思维导图来整理我看的内容看似不太合理，我就大概简述下这本书的大概内容吧。

概念

A3:狭义上来说就是一张A3尺寸大小的纸，但是对于丰田或者书上说的那些精益的公司来说

却意味着一份基于PDCA,遵循自然逻辑，连接清晰易懂，解决问题，培育员工的流程。

怎么做

到现场去

现场描述的是员工为客户创造价值的地方，真正的改善也只能建立在对一线工作环境的观察上。

到一线才能找到真正的问题，而问题则真是组织公司达成目标的障碍。

当我们把问题定义清楚了，那么问题的一半也就解决了。

寻找根本原因

“5个为什么”但是注意不要把问题越问越大，最后超过了我们所能控制的范围，这样就失去了问为什么的作用。

目标并不是一定要问5此，而是不断地促使你思考问题的根本原因。

基于多重方案的决策

准备许多备选方案，能改善对话的质量，并激发更深层次的学习。

探寻问题的对策，并非永久解决方案。

对策只是“在找到更好的方法或状况发生变化前，为解决问题而采用的快速反应”。

只有通过模拟更宽范围的可能情况而将风险最小化；过早做出不成熟的决策，会冒错失关键事实的风险。

计划跟进

只要指定好了目标期限，那么工作才能准时完成。

隐藏错误->庆祝找到错误。

需要关注问题解决的流程是否从快速改正，转成针对根本原因的对策。

用PDCA循环来执行计划，通过试验获得知识。

培养A3的思想者

重点是需要建立A3的思想，建立有效的对策，主键灌输思考方式。

形成一套明确的、一直的规则，形成平等的相互依赖的组织。

形成清晰的、可继续培养的解决问题流程，从而创建一个问题解决这组成的组织。

总结

A3的关键不是纸张或者格式，而是其中的过程。

其实两周的时间，只能说我把这本书读完了，也基本了解了其中的一些基本的概念。

但是要运用到实践中，可能还需要不知道多少个两周，可能还需要不知道阅读这本书几遍。

A3是一种工具，是一种方法，更是一种思想，一种需要我们不断去改进的思考方式！

民工浅谈软件开发的“质”与“量”

Wed, 27 Sep 2017 21:58:05 +0800

某日与友人聊天，从他的创业中说到，农业、工业，想要质高，往往量少，往往起步就更加显得艰辛与困难。

PS：所谓的量少，并不是指的总量少，而是指的单位产出量少

突然我就低下了头，想了想我自己的处境。做IT的谁又不是经常把质量挂在嘴边呢？

虽然我既不是QA也不是QC，更不是曾经的PM，但是自从天天被别人使唤来使唤去开始，

我就深深的了解到，质高往往是需要牺牲单产量大的。如何找到平衡点才是你们做QA\QC\PM需要考虑的！

跑题了，回归下！

让我们抛弃所谓的开发模式，去他妈的SCRUM（虽然我也读过SM课程），我们要追求的是什么？

是满足干系人！是满足干系人！是满足干系人！

所有一切不从干系人利益出发的需求，都是耍流氓。

但是！ 我们要开始一个纯属虚构的故事了，如有雷同，纯属抄袭！

干系人说需要你开发某些功能，正常估时大约是40人天，然后要你在不加资源的前提下缩减到10人天。

what a fucking day!

你看着手下说，兄弟们这两天辛苦下，我们加加班，因为我们的上帝需要我们2天造出全世界，但是我们没有支援，只能靠我们自己。

10人天做完了。我了个去，单产好高，提高了4倍！

恩，干系人看着这个试用早产儿会心一笑！

然后QC牛逼哄哄的来了，劈头盖脸的开了一堆BUG。

你看着手下继续说，兄弟们这两天辛苦下，我们要在干系人没发现之前，干掉这些BUG，但是我们没有支援，只能靠我们自己。

又花了10天，在上帝还没完整使用前，偷偷把版本给替换了。单产不小心降至正常的2倍。

接着公司的验收部门骑着大黑马就来了，劈头盖脸的开了一堆反馈问题。

你看着手下无奈的说，兄弟们这两天辛苦下，我们要是内部验证版本都不过，就不能按时发布正式版了，但是我们没有支援，只能靠我们自己。

10天后，总算把反馈BUG一扫而空，喜极而泣之余，正式版总算是发出来了。不过单产又降低了点，变成了正常的1.3倍左右。

上帝用了一个月后，脚踏七彩祥云来了，手拿九尺丁耙，一棍子把你给抡的找不着北。原来一堆数据问题被上帝发现了。

你看着手下无奈的说，兄弟这两天辛苦下，我们不把上帝伺候好，估计是没有休假了，但是我们没有支援，只能靠我们自己。

在相继发了十几二十个补丁后，版本数据问题总算解决了，版本也稳定了，总算可以功成身退了。

做总结的时候突然发现，单产已经降到了原来0.5倍甚至更低！

呵呵~~~

我相信如果一开始用40个工日做计划，给上帝解释下40个工日的原因，至少能保证正常的单产数量。

而现在呢？质差量低！一塌糊涂！

外部满意度低，内部幸福度低！

质与量本身就是一对矛盾的个体，往往达到其平衡才是最高境界，而要是想追求高质量，有时候是必须要有所牺牲的。

一味的追求某一些极致，必定会鸡飞蛋打！

基于关联规则算法处理工程计价清单的自动组价数据挖掘

Fri, 09 Jun 2017 08:58:15 +0800

一、关联规则的定义和属性

考察一些涉及许多物品的事务：事务1 中出现了物品甲，事务2 中出现了物品乙，事务3 中则同时出现了物品甲和乙。那么，物品甲和乙在事务中的出现相互之间是否有规律可循呢？在数据库的知识发现中，关联规则就是描述这种在一个事务中物品之间同时出现的规律的知识模式。更确切的说，关联规则通过量化的数字描述物品甲的出现对物品乙的出现有多大的影响。

现实中，这样的例子很多。例如超级市场利用前端收款机收集存储了大量的售货数据，这些数据是一条条的购买事务记录，每条记录存储了事务处理时间，顾客购买的物品、物品的数量及金额等。这些数据中常常隐含形式如下的关联规则：在购买铁锤的顾客当中，有70 ％的人同时购买了铁钉。这些关联规则很有价值，商场管理人员可以根据这些关联规则更好地规划商场，如把铁锤和铁钉这样的商品摆放在一起，能够促进销售。

二、关联规则的应用背景

而在工程造价领域，根据不同的清单进行组价，而组价的规则千变万化，对于一个有经验的预算员来说可能驾轻就熟，但是每条清单进行处理也需要一定的时间；而对于一名新近的预算员来说，组价就会变得异常的困难。因此自动（一键）组价功能的功能价值就更加的凸显。

在实现这个算法前有几点假设：

1、清单、子目数据已经正常收集在某一个DB中；

2、已经做好初步去重工作；

3、特定项目特征，工作内容组合的清单已经映射成唯一一条清单（代码中简单的现已清单编码来进行演示）；

三、关联规则的应用实现

主要函数实现代码：

// 数据初始化，计算每个元素的权重，并去除小于一定权重的元素
function InitData(data){  
    var buffer=[];  
    var isShow=false;  
    for (var i = data.length - 1; i >= 0; i--) {  
        for (var j = data[i].length - 1; j >= 0; j--) {  
            isShow=false;  
            for (var k = buffer.length - 1; k >= 0; k--) {  
                if (buffer[k].name==data[i][j]) {  
                    buffer[k].count++;  
                    isShow=true;  
                    break;  
                }  
            }  
            if (isShow==false) {  
                buffer.push({  
                name:data[i][j],  
                count:1  
                })  
            }  
        }  
    }  
    var ret=[];  
    for (var i = buffer.length - 1; i >= 0; i--) {  
        if (buffer[i].count>=min_sup) {  
            ret.push([buffer[i].name]); 
        }  
    }  
    return ret;  
}

// 计算数组中的子集的权重，进行剪枝
function GenArr(data){  
    var candi=[];  
    for(var i=0;i<data.length;i++){  
	for(var j=i+1;j<data.length;j++){  
	    candi.push(data[i].concat(data[j]).unique());  
	}  
    }  
    candi=unique(candi);  

    var buffer=[];  
    for (var i = candi.length - 1; i >= 0; i--) {  
        buffer.push({arr:candi[i],count:0});  
    }  
    //计算权重  
    for (var i = buffer.length - 1; i >= 0; i--) {  
        for (var j = dataArr.length - 1; j >= 0; j--) {  
            if(isContain(dataArr[j],buffer[i].arr)){  
                buffer[i].count++;  
            }  
        }  
    }  
    //剪枝  
    var ret=[];  
    var lock = false;
    for (var i = buffer.length - 1; i >= 0; i--) {  
        if(buffer[i].count>=min_sup){  
            if (!lock){
                result = [];
                lock = true;
	    }
	    ret.push(buffer[i].arr);  
	    result.push({arr:buffer[i].arr, count:buffer[i].count});
        }  
    }  
    return ret;  
}

四、结果检视：

Input:

Output:

领导你除了会忽悠还会干啥？

Tue, 14 Feb 2017 12:28:48 +0800

领导你除了会忽悠还会干啥？

2011年底开始接触PMP学习，也是那时开始，让我对项目管理有了一个全新的认识。

经过几个月的学习，终于在2012年3月获得了期盼已久的PMP证书，拿到证书的那一刻，感觉，并不是一个终点，对于我来说，应该算是职业道路上一个崭新的起点。

个人2008年从学校毕业接触软件开发工作，2011年初开始将部分的工作重心转移到项目管理上，职位也从开发工程师提升为项目助理。但是所谓的助理，其实只是一些项目的分解之类的工作，而那时的自己，对于项目管理的认识应该也仅限于WBS吧。头脑里的想法就是项目管理=WBS。

2011年底开始的学习让我彻底颠覆了这个概念，原来对于一个合格的项目管理者来说，WBS真的只是冰山一角。范围、时间、成本、质量、人力资源，沟通、风险、采购，不管哪一个都可以分析的非常的复杂。

直到今日，拿到PMP证书已经是第5个年头了，可以说，这五年在我职业生涯里起到了至关重要的地位，为我的项目管理的职业盛业奠定了一定的基础。

其实说到与实际项目的结合，其实这五年应该是一个循序渐进的过程。从一开始的信心满满，无知无畏，到后来的不断碰壁，再到现在的游刃有余，其实整个里程说来简单，实际过程中的种种只有自己内心最清楚，正好趁着这次征文的机会，把我这些年来认为比较重要的几个点给大家来详细的说说。

项目成功的第一步：是否成功解耦。

其实本来是想说明下WBS的关键，但是我相信，对于中国的项目管理人来说，大部分的PM应该是从CODING转过来的，所以我个人觉得用解耦这个词语，能够更加形象的反映出整个项目管理的开始。中国有句俗话说：好的开始是成功的一半。那么好的项目解耦必定就成为了成功项目的第一步了。那么问题来了，如何做好项目的解耦呢？其实，这个问题说复杂了，我觉得这篇文章就这一个主题也是不够写的，所以我只会把关键的几点跟大家讨论一下。

1、在做项目解耦前必需做好业务的解耦，而这点其实是对PM来说最为困难的一点，因为业务往往是掌握在产品经理或者需求团队的手里，但是试问一句，不了解业务如何做好后面的功能分解呢？不过好功能分解又如何做好WBS呢？

2、用敏捷的思路来做好解耦工作。这点其实是需要结合SCRUM的思想来的，什么意思呢？只有锁定需求细节，架构设计方案等，才能把WBS做的比较合理，但是如今的软件系统的复杂程度，基本是无法确保一开始的考虑和想法是准确的，必然就会涉及到不停的修改和完善，那样就会涉及到更新一开始的WBS内容，而这个是一个耗费极高的事情。所以关键在于，我们只要先明确需求，不做详细任务拆解，只有等到某个Sprint开始前，做迭代计划的时候把这个Spring对应的需求做相应的拆解，这个拆解应该是整个scrum团队做的，而不是PM一人独立完成，除非你非常牛。

3、计划≠执行，其实做WBS从上面两点来说已经够复杂的了，但是对于是否能够按照WBS上面的时间来执行，其实才是更为困难的，其实这个主要也是牵扯到过程中管理的一些内容了，这里简要叙述的话，也就一句话，要在过程中不断地更新项目执行计划，不断调整，从而能够把WBS执行的更为合理。

项目成功的第二步：不停的更新。

不停的更新，其实应该是贯穿整个项目生命周期的一件事情，更新业务，更新需求，更新计划，更新变更，更新项目执行过程，更新项目成果，更新交付成果等等。所有的一切都需要不停地更新，才能达到最终的成功。我这里来说说项目执行和过程中的更新，这些更新能够能好的保证我们的项目按照我们预期的进度顺利的进行。

1、 WBS的跟踪+更新，前面也说了一个好的WBS意味着我们已经给项目开了一个好头，但是有个好的IDEA，没有去执行，一切都是白搭，所以我们要更好的去执行WBS，并且把实际执行的结果不停的将WBS进行调整，从而更好的执行和控制整个项目。

2、积极的应对变更，变更我想是所有项目都会遇到的一个“不好”的东西，但是要是能把这些“不好”变成“好”，那不就等于是为我们的项目添砖加瓦么？虽然说镀金不是好的项目管理，但是处理好变更却给我们的关系人带来更好的体验，给我们的项目带来更好的结果。

3、项目干系人的更新，从项目的开始、启动、执行、调整、完成，不同的阶段其实有着不同的项目干系人。而我们要做好不同阶段的干系人管理，就要不停的更新我们的干系人列表，以及干系人的优先级。比如客户只关心成果物，那么可能开始和完成就是他的优先级最高的，测试部门关心软件的质量，那么执行、调整阶段可能是他们较为关心的等等。

项目成功的最第三步：资源的优化。

其实我这里说的资源，主要指的还是团队的人。虽然说PM手里不掌握资源，但是说到底，是否有好的团队，好的人才，对于项目的成功起到了极为重要的作用。所谓的优化，就是当你拥有了这些人才之后，如何更好地整合团队，提升团队整体能力以及凝聚力，这些将会让你的项目事倍功半！

1、自愿的公开共享，团队成员要多做技术公开，藏着掖着对大家都没好处，一个人的智慧是有限的，而团队的智慧却是无穷无尽的，有的时候，团队的全面性会帮助个人的片面性更好的成长。

2、摆脱工具的束缚，其实C++，JAVA看似高大，但是如果能同样达到结果，并且过程更加的简单快速，我或许会选择VFP，也就是说我们的人才最重要的才能不是他精通一些一辈子都用不上来的技术，而是他能够在最短的时间内掌握一门陌生工具的能力。

3、让人才们有回家的感觉，一个TEAM应该像一个家一样，而不是真正的在公司，这样，当你项目结束开始下一个项目的时候，这帮兄弟才会继续陪在你的身边，帮你拿下一个又一个项目，曾经碰到一位领导是这么评论下属的：这个世界上没有谁没有了谁是不行的，你不干就滚蛋，有的是人干。当然我不能说这样的领导不是好领导，但是这样的领导一定带不出好的团队！

其实这三部曲说来简单，或许你们也正是这么做的，但是同样，他们和计划与执行的关系是一样的，希望各位管理人能在平时的工作中同样是这么做到的，虽然他们不怎么高深，但是我觉得如果你这么做到的，至少你离成功应该又近了一步吧，不积跬步无以至千里，认真的走好每一步必定在最后会到达成功的顶峰。

通过htaccess绑定二级域名到子目录的方法

Tue, 07 Feb 2017 17:14:47 +0800

国内虚拟主机商一般一个主机只提供1个域名绑定，而不支持多个子域名。这时候我们可以自己通过.htaccess文件设置重定向，把二级域名绑定到指定的子目录。
先把要绑定的域名A记录或CNAME也指向和主域名所在的主机IP，然后可以.htaccess通过如下代码绑定相应文件夹：

RewriteEngine on

RewriteCond %{HTTP_HOST} ^SLD.domain.com$
 
RewriteCond %{REQUEST_URI} !^/Catalog/
 
RewriteCond %{REQUEST_FILENAME} !-f
 
RewriteCond %{REQUEST_FILENAME} !-d
 
RewriteRule ^(.*)$ /Catalog/$1
 
RewriteCond %{HTTP_HOST} ^SLD.domain.com$
 
RewriteRule ^(/)?$ Catalog/index.php [L]

二级域名
SLD （ second-level domain ）;

如果很多个二级域名都指定的话，每个都这么写.htaccess文件就会非常庞大臃肿，可以使用以下正则匹配写法：

RewriteCond %{HTTP_HOST} ^(SLD1|SLD2|SLD3).domain.com$
RewriteRule ^(.*)$ /%1/$1 [L, NC]

这样，会自动把SLD1对应到Catalog1目录，SLD2对应到Catalog2目录，SLD3对应到Catalog3，要加新的域名时，只需要在上面按格式添加即可。

Scrum 大白话总结

Mon, 12 Dec 2016 15:41:02 +0800

Scrum是敏捷过程中比较著名的一个过程框架，被很多团队采用。

Scrum使用迭代的开发方式，每一次迭代中，都会经历一个“计划->实施->验证->反思”的过程。这是一个开发过程，同时也是一个对项目的认识过程，这样的设计其实也是遵循了哲学的认知论.

名词解释：

Sprint：每一次迭代称为一个Sprint。

Backlog：其实就是需求列表。

SM：Scrum Master，Scrum过程的管理者。

PO：Product Owner，需求他说了算。

TEAM：架构师、开发人员、测试人员等。

Chicken：其他相关的人，如老总、客户。 ^_^

故事点：一个相对独立的功能点。

度量：在过程中的一些度量值。如当前系统的BUG数。

事件：过程中出现的一切事件。如小王今天早上在大家在全身心投入站会时时，放了一个屁……

角色

Scrum中只有三类角色：SM、PO、Team。

计划会议

一个迭代的时长一般定在2-4周。而计划会议是 Scrum 中最重要的会议。目的是定出本次Sprint的任务目标和计划，让所有成员能在接下来的日子里更流畅地进行各自的工作。同时，这也会让PO更有信心。

主要活动：PO做出产品Backlog，然后在会议上给大家讲解。会议上Team在对故事点理解的基础上，对其进行估时。最后再将其拆分为任务点。故事点和任务都放在小黑板上。

产物(按优先级排序)：

业务目标、Demo会议日期、

Sprint Backlog（故事点列表、估优先级和估时、HowToDemo）、

速度和资源的计算、成员列表、

每日站会的时间地点、

故事点拆分为任务。

注意事项：

PO必须参加这个会议！这是因为需要和Team进行面对面的交流来进行计划，以确定估算时间、范围、重要程度等可变因素。

PO和团队之间要保证对故事的理解没有问题。可以保证backlog所有的列都全部写好。最重要的就是How to demo列。

技术性的故事点，不要让PO来定优先级，这样会得到很低的优先级，而往往它们是很重要的。

Sprint Backlog

每期Sprint都需要一个Backlog。Backlog也就是对当前需求的描述文档。

同时，使用黑板进行平时的调整：

每日站会

每天，Scrum团队成员都会参加这个会议。会议时间在15分钟以下，大家都站着，所以称为“站会”。

每个人在站会上主要是叙述一下昨天做了什么、今天会做什么，以及需要的支持等。同时，每个人更新小黑板上的相关内容，

Sprint Demo会议

Demo会议也是十分重要的一个会议。

主要是向PIG们展示当前阶段的项目成果。会议上应该保证明确地展示了本Sprint的业务目标。

这是一个重在沟通和反馈的过程。

Sprint回顾会议

这同样是一个非常重要的会议。因为这个会议的开展会帮助团队进步。

会议中会对本次Sprint的所有故事、度量、事件，进行以下三方面的归类：做得好的，做得不对的、改进意见。

（“做得不对的”表示：如果同样的事发生在下个Sprint，应该以不一样的方式来对待它。）

其它

想系统地学习Scrum，参见：Introduction to Scrum - An Agile Process

还有：《Scrum and XP from the Trenches》