- 项目启动
4月中旬，接到指示，需要于5月10日完成一个紧急任务，这个项目是为一位核心客户打造一套具备公众号，后台和大屏显示系统相关的完整系统，而此时，我们的团队构建还并没有完成，意味着我们需要实现的将是一个超出现有团队实际能力的项目。
当然，团队能力本身衡量就是一件并不容易的事情。如同从海绵中挤水分，也许从表面上看没什么内容，但挤一挤总能挤出许多精华来，尤其是在职场中成长，总必须经历一番考验，把自己的潜力逼出来，才能真正成长。
当然，我依然根据实际情况进行了一番风险评估，主要包括一下几个方面：
1，团队资源匮乏，尤其是缺乏有经验的开发者
2，大华摄像头以前没对接过，存在技术的不确定性。
3，团队没搞过公众号开发。
4，时间太紧，质量可能是个问题，有可能影响公司商誉。等会，
显然，风险评估是项目启动前必须做好的关键。尤其是这个项目，承载着相关方的许多目标，包括是我们团队的第一个正式项目，无论是老板也好，公司同事也好，甚至加入团队的成员们也好，其实都想知道我们这个团队到底行不行，能不能承受足够的压力。
显然，团队成员们都需要通过这个项目证明自己的能力，进而证明团队的能力。
二 技术选型
在完成项目启动会后，我们跟客户进行了一番沟通，明确了项目团队中大家关心的问题，并开始着手技术选型，框架，业务分析，代码实现。
在进行技术选型中，我基于公司长期积累的角度，选择了.netcore+vue.js的组合型技术栈，框架使用了abp作为我们的开发框架。
虽然在实际过程中，有人提出了abp开发框架提供了一系列重量级的组件，对我们这样的团队来说可能会扩大技术风险，平白增加项目的时间。但实际过程中，该选型并没有造成想象中那么严重的问题。主要原因大概有以下几点：
1，abp无论如何依然是.net技术栈中最受欢迎，公认设计最优雅的面向领域驱动设计的框架。哪怕我们不用领域驱动的思想，也不影响我们使用abp的轮子。它的轮子确实太灵活方便了，运用妥当定然能给我们带来不少好处。
2，即使我已经从事了十年开发，却依然觉得要设计一套权限认证系统远比想象中的复杂。
事实上这是一个普遍认可的观点，看起来权限认证几个表就能搞定这个问题，其实并非如此。例如abp的权限认证包括了如下复杂的逻辑结构。
在介绍领域驱动设计的一本书《Microsoft.Net企业级应用架构设计》这本书中，作者也表达了同样的观点：
即使已经写了多本asp.net的书，创建基于角色的UI基础设施以及相关的成员系统耗费比预期更多的功夫。
事实上，对于我们这样的项目，关键不是选什么框架，而是选一种能够满足当前需求，又能在未来给公司带来积累的框架和技术体系，而abp和abpvnext恰好如此。小项目可以用abp，大项目则可以考虑后者。或者都可以采用后者。
三，项目过程控制
当这个项目拿到时，我们面临短期看似无法完成的较多量需求，难免会存在选择困难证。究竟是做A，还是选B，还是做一个成年人应该选的，两者都选？
显然，我们的精力有限，只能有所取舍。
在现代软件工程中，瀑布模型，快速原型开发模型，增量/迭代型模型都是我们在项目选型过程最基础的选择。如果采用瀑布模型，显然不符合我们的实际情况，因为没有足够的资源，不太可能花时间写文档；快速原型也同样如此，花时间做一个完整的demo，那也不太可行，尤其是甲方已经确定了原型之后，已经具备开发实例功能的前提。
在这个模块优先级选择之中，我个人认为，虽然B端系统这个部分需求很多，优先把它搞定，能够让我们集中精力解决其他问题，但对用户来说，是否真的如此？
业务价值的评估是我们进行功能优先级评定的第一要素。如同一个价值滑条，同时摆在一个刻度上，永远只有一个功能。
于是，我们将公众号，大屏作为第一迭代。并安排足够的资源优先完成此模块。当然，资源其实依然并不足够，但大家都知道，资源不足才是项目最普遍的现象，在现有资源范围充分利用，才是成立项目组的目的。
我们引入了持续集成的概念，要求把更早的交付当作核心目的。为了实现这个目标，我们采取了如下措施：
收集需求，以低保真原型图指导软件开发，除个别页面要求美观外，其他页面以满足可用性为准
前后端设计模拟数据，前端就可以开始联调了。
划分迭代周期，确定发布节奏。
UI先行开发，同步后端开始设计接口和模拟数据的格式，用后端不用直接与前端联调，而是使用测试驱动先行的方式开发后台逻辑。
四，总结
当然在实际操作过程中，我们并没有采用测试驱动开发的红绿重构开发实践，这使得我们没有足够的保障措施来确保代码质量，而且由于项目团队普遍经验不足，也意味着我们在未来的演进过程中，将面临许多严重问题。
在这个项目中，我们采用了合理的迭代划分；让售前，设计驻场确保需求的澄清；采用了开发分支和功能分支分离的模式是我个人认为值得复用的经验。
由于时间缘故，在下一篇文章中，再讨论一下这个问题。