“我有一个特别好的互联网创业想法， 就缺少一个程序猿帮我实现了”。 这句话去年很火，相信不少搞技术的朋友也都现实经历过，知乎上也有关于这个话题的帖子。拿出来说还是因为最近又碰到这样的类似问题。当一个非技术创业者有一个不错的想法的时候，且不论想法到底是不是好，假设它是极好的，那么下来他真的只是缺少一个程序猿吗？ 情况一：当你碰到了一个程序猿，你开启了画饼模式，“我想做的产品，XX牛叉……市场XX亿……A轮、B轮、C轮、上市……迎娶白富美……人生赢家，还等什么就差你的代码了！”。然而程序猿的内心可能是这样的：“哥，我是程序猿不是产品汪，你说的是啥？需求文档呢？原型呢？你到底是要做啥啊？能不能先给我迎娶白富美啊？” 原因分析：很多程序猿并不具备分析业务并转换成互联网产品的能力，尤其在大型机构或是外包团队中，由于细致分工之后，他们只是按照设计去实现具体代码的人，就像水电工按照设计师的水电...

年底了，相信很多企业都开始或已经完成了年终的考核工作，考核的方式多种多样，了解了一下身边的朋友，大体的节奏基本都是这样的：述职、组内投票（可能没有）、部门投票。 考核的结果总是几家欢喜几家愁，我们也总能听到各种各样的抱怨。这样的抱怨主要由于认可自己的员工没有得到大家的肯定，其根源无非是考核方式的公平性问题，投票的结果是不是能正确的反应员工的价值？ 为什么很多干死干活的员工没有得到大家的认可？我认为主要有两点： 熟人关系主导了投票结果。对于技术工作者来说，很大一部分人并不善于人际交往，这样熟人越多的人就越有优势。 不同工作之间的不了解加剧熟人关系对投票的影响。由于技术部门中不同小组的细分领域往往不能理解对方的工作，自然在投票的依据上就不会以工作内容为考量。 那这样的投票结果就是依靠熟人和博弈，并不能反映一个技术工作者真正的成绩。那么要怎么做才公平呢？在这里设想一种方案一起探讨，不喜...

Confluence的使用几乎贯穿了整个敏捷过程，如：在产品设计时编写产品需求，在会议讨论时编写会议笔记，在冲刺结束后编写冲刺回顾……Confluence自身也为这些需求提供了丰富的文档模板，本文就其提供的模板结合我们的使用做一个详细的介绍。 以下所有模板均通过Confluence点击“创建”（Create）出现的模板选择后创建，若有模板内容不适用的，管理员可通过“一般配置”–“全局模板和蓝图”功能中进行修改或者汉化。 产品需求 为你的产品或功能定义、追踪和确定范围需求 在产品需求中需要注意两个核心概念： Epic ： 产品的某个阶段，如：产品中加入社交功能 Story：在某个Epic下的各细节需求，如：用户评论、用户点赞 一篇产品需求对应一个Epic，一个Epic对应多个Story。Story的定义粒度尽可能的以一个功能点的规模来创建（通常一个功能点可以划分成一个前端...

准备把敏捷管理的专题在今年完成，主要谈一下Atlassian的实践，先做一下搬运工，讲去年写的两篇弄过来。 Dream big, work smart, deliver fast 使用Atlassian的产品已经有三年多，但是大部分主要以JIRA和Confluence为主，2015年年初加入一创业团队负责技术团队的搭建，从零开始通过部署Atlassian产品、制定开发流程，由于创业团队人手不够，自身也参与了大部分的开发工作，开始有一些考虑不周的地方，随着工作的展开不断调整，通过半年的努力也引来了第一轮的投资，可能创始人国企非技术出生背景的关系，在对技术团队的价值看待上分歧很大，最后还是选择了离开。机缘巧合，马上又加入了另外一个创业团队，依然主要负责技术团队的搭建。这次吸取了之前碰到的一些经验进行改进，并且加入其他一些想法。下面主要就这两次经历，简单谈一下Atlassian的使用...

由于最近想给白猫计划资讯站增加个小论坛，用来交流吐槽z之用。继续瞄准nodejs范围内的开源项目，多番考虑和选择之下准备选用Node.js专业中文社区的NodeClub。一方面支持一下那一批不断努力的国人，另一方面的确喜欢这个项目的风格。目前该功能在未完成，由于需要MongoDB和Redis，但是小众站点的量不会很大，第一考虑使用云上的小量免费服务，找到两家非常不错的供应商MongoLab和RedisLabs。 MongoLab MongoLab提供500MB免费的云端存储，Mongo目前版本为3.0.8，注册和使用都极其简单，非常适合数据不大或者处于试错阶段的项目使用。对于扩容直接通过购买收费空间之后，想更换服务商也可以通过非常容易的Import / Export Helper工具完成。下面说一下使用步骤： 第一步，注册账号。完成之后才能添加mongodb数据库（不需要信用卡信息...

上一篇，主要介绍了搭建OpenFire和Spark实现即时沟通平台，比较简单就能完成。由于团队间配合的特殊性以及无法访问外网等诸多原因，在 部署了Jira后，一直缺乏一种即时提醒的功能。只能依靠浏览器中定时刷新来查看是否有任务被分配。在完成了OpenFire和Spark插件后，就开始 着手设想是否可以通过Jabber协议，在Jira中有任务分派事件时，通过Jabber协议将事件信息转发出去的想法？在搜索了Jira插件后，发现有 一个插件正符合我的设想：Jabber Listener for JIRA。 下载地址:https://marketplace.atlassian.com/download/plugins/com.atlassian.jira.ext.jabbernotifier.jabber/version/12100 在JIRA上安装此插件后，需要做一些配置，这部分资料较少...

由于公司复杂的内部网络约束，使得部分人员之间无法通过企业内部定制的协作软件进行沟通，造成工作中的诸多不变。所以在内网中尝试使用OpenFire和Spark构建了实时协作平台。 OpenFire ： 基于Jabber协议的Java开源实时协作平台。可用其构建Jabber协议的实时协作服务器，处理来自不同遵循Jabber协议的客户端请求。 Spark：Jabber协议的开源客户端。 下载地址：http://www.igniterealtime.org/downloads/index.jsp OpenFire的安装非常简单，主要注意的是数据库的选择，若选择“标准数据库连接”时，注意补充数据库驱动包至openfire\lib目录下。不推荐使用内存数据库，容易因服务器意外宕机而丢失数据。 安装完毕后，访问管理页面：http://localhost:9090/ OpenFire提供了IM具备...

“有些事情不是看到希望才去坚持，而是坚持了才会看到希望”。一直很喜欢这句话，它也成了我每次失败之后安慰自己的最大法宝，这也使得我在技术学习的道路上越陷越深…… 在过去的2015年，充实、忙碌、收获满满。 年初的时候，在同学的邀请下，接触了一个非常不错的团队，受团队成员对工作热情的感染以及能在技术团队管理和架构上可以完全掌控的诱惑下加入了，也因为这个决定几乎透支了上半年的所有夜晚和周末。从技术选型到系统架构，利用敏捷管理和版本控制推进开发过程，部署自动化测试、构建、交付系统减少人力成本，最后到上云方案和运维，几乎将过去所有积累的各类经验筛选后一一付诸实践，并获得了不错的效果，在团队发展越来越好的同时，对技术团队的任务要求也就越来越大，时间上的矛盾也愈发激烈，但是在谈及对技术团队的维持和价值理解上存在太大的落差（可参考最近知乎上创始人与技术合伙人的撕逼大战），带着对技术劳动的敬畏和对...