软件开发一般分为 问题收集，需求分析、软件设计、开发、测试上线几个阶段。我将会以我过去的学习和经验从需求分析阶段开始谈起。
在我们开发软件产品之前，我们先要问自己几个问题。我们的目标群体是哪些人？它的核心功能是什么，满足了用户什么样的痛点需求？如果这些没想好，我想很难去开发好一款好的软件产品。然后就是我们应该考虑它有什么样的价值，它能给公司或者说老板股东们带来多少价值或者商业机会。
在需求分析阶段，你会发现需求不是一个，或者两个，而是很多个，它们是来自不同人的需求，而我们应该如何权衡呢？我们可以从需求的紧急程度、用户的量级、投入的回报比、风险等角度考虑。假如，这几个参考仍然不能做出选择，应该按照公司或者部门的战略发展方向走，让最高领导人帮忙选择和推动。
明确需求，将用户的需求转化成产品功能，划分功能模块，对轻重缓急的进行排序，最终转化为版本计划。 一般以两周作为一个版本迭代周期（非APP版本）。若是需求变更，需要召开会议，讨论是否新变更能够加入当前版本迭代周期里。会议时间视紧急情况而定。同时，一般不允许在迭代第二周插入或者变更需求。
在我们需求功能模块确定之后，我们的一个版本里面，包含哪些内容呢？假如我们一个迭代开发团队有2个前端、1个后端开发人员。有A 、B 、C三个功能，一个迭代，10个工作日。
前端：
A需要5天，B需要10天，C需要五天，
后端：
A需要3天，B需要8天，C需要4天
最终，虽然B功能前端开发已经完成，但是后端开发资源不足，可能我们会选择A、C功能进入本次版本发布。B将进入下一个版本发布。假如A、B、C都不能进入版本发布，可能功能模块任务还可以拆得更小。总之每次版本发布不应该是空内容。
上述还涉及到一个重要的过程，那就是对于功能点复杂度和开发工时的评估。我们可以对一个功能复杂度划分为1、3、5、8个点。一开始，我们可以选择以前的一个开发任务作为参考，比如，列表从单个条件支持多个条件筛选。大家开始投票，假如多数投成3个点，那就按照此任务作为3个点 的标准（后面可不断优化），将其他需求与其比较、投票。最终我们会得到所有需求的功能点的总和（有什么用，接下来会提到）。另外，一般对于8个点的功能，可以继续拆分成更小的点。所以通常不会有直接8个点的任务。
对于一个功能发布所需的开发量、工时，不能片面的按照前端人员，或者后端人员去评估。而是两者结合。因为一个功能的完全交付时间，应该是按照最长的一方工时做为最终的完成时间。
综上所述，我们按照先前的假设，可能会得到一份这样的迭代开发计划表：
最后，走完对应的测试、上线流程，发布版本上线通知。同时，我们会得到一个版本里的功能点总数。这个点数可以作为衡量团队开发水平的一个参考依据，当一个team在一个开发周期内完成的点数越高，他们的能力越强，当他们完成的点数有明显的提升时，说明团队的水平提升了或者大家最近加班比较多。另外强调，功能点数并不是代表所需的开发量。比如实现一个复杂的算法和修改1000字段的颜色样式，后者开发量虽然大耗时长，但是并不复杂。但是仔细想想，为什么这个团队一直选择做一些复杂度低的工作。只能说明一个问题，他们的能力有待提高。
网友评论