央行报告:信用收缩成为制约经济金融主要矛盾_11花网赚

时间:2019-08-10 17:45 作者:11花网赚

在校学生手机兼职       本学期的敏捷软件开发课程要求学生自己组队(4人)使用Scrum方法开发一个项目。我们一队四人虽然以前没有实际scrum开发经验,但是靠课上以及参考资料的指导,还是在努力践行Scrum流程与思想。本文内容包括以下三部分:在校研究生践行Scrum的固有困难、我们的实践过程及过程中对流程的适应与改造、Scrum对于学生的一般性课程项目的潜在价值。 在校研究生践行Scrum的固有困难

       显然,Scrum实践已经默认了应用的团队是一个全日制工作的、工作技能熟练的开发团队。在此基础上,才有可能组建“全职能团队”,才有可能“把办公桌安排在一起”,并在旁边树立看板作为信息辐射器,让大家随时了解Sprint进度之类的信息。        而这些要求,对于在校研究生来说,并不现实。首先,大家选的课程并不相同,在大家的闲暇时间重叠不多的情况下,还有可能有其他活动占去这些宝贵时间。这导致能够做到一起工作、即时交流反馈的机会很少。其次,(由于本专业热门)一部分研究生本科并非本专业,基础薄弱,影响工作质量,本人所在团队就有这种情况。即使是基础较好的学生,如果课程项目提出了对新技术/框架的使用需求,也会变成基础薄弱的开发者,影响工作效率与质量。        综上所述,在校研究生践行Scrum的固有困难是“共同工作时间少导致交流受阻”与“水平不足、需要大量时间来学习和踩坑导致工作效率、质量低”。受这两个因素影响,在校研究生想要采取某些Scrum实践可谓困难重重。比如:由于工作效率低,人数也不多,所以几乎不可能支持结对编程;由于共同时间少,协作靠QQ群,所以请求到响应的时间间隔很长。 我们的实践过程及过程中对流程的适应与改造

       本团队从使用故事地图进行需求分析之后,便开始进入迭代开发阶段。从那时到假期有三周半,我们便决定把时间分成3个迭代,每个迭代持续一周。        首次会议包括对这三个迭代的功能点的大致划分以及对Sprint1的故事的分解、分工。在会议上,我们得到了以下商讨结果: 由于没有“客户参与”,验收标准就没法非常精确。虽然之前大致写了故事验收标准,但设计得复杂还是简单,要不要复杂的安全性保障机制等等,都没有说明。所以我们最终同意从流程中去掉每周展示会议,只要前后端调试成功,前端开发能够覆盖功能点即可。 由于共同开发时间不好找,所以“进度自行把握”,取消每日站会,不规定共同开发时间。 CI平台作为敏捷开发关键要素之一,应当尽快搭建并纳入使用。前端由于微信小程序的特殊性质,不使用CI。 两名同学开发SprintBoot框架的后端、两名同学开发微信小程序前端。协作依靠后端发布、更新api文档,沟通靠QQ群。 计划按照故事点的数目将所有故事平均分到三个迭代中去。第一次迭代完成优先级最高的1/3的故事点的需求。

       在这样的结果下,我们开始了Sprint1开发。本人与另一名同学A负责微信小程序前端。提出前端使用微信小程序形式的就是A同学,而本人其实并不熟悉微信小程序开发。在Sprint1的一周内,团队内的主要交流便是api文档的发布。以及在QQ群里对于api文档的少量修改要求。我们主要感受到的问题包括: “注册/登录”等辅助功能其实不比普通的业务故事的工作量要少,然而在故事地图里面没有写到这些功能。 后端SpringBoot技术比较简单,负责的B、C两名同学很快就完成了api设计与实现,配合CI自动部署,两天就完成了Sprint1的开发工作。而前端与其进度差异巨大。对于本人、B、C,学习微信小程序开发都是较大的工作量。这使得我们无法按照Scrum说明的“有余力的开发者应当主动承担更多任务”,给B、C分配前端任务。而我也几乎只是完成了微信小程序的大致学习。 由于没有共同工作时间、没有站会,交流只靠QQ群,所以当A发现了api设计不合理之处并在QQ群要求修改时,得到反馈的时间间隔相当长。 在上面1、2、3的情况叠加下,A几乎只完成了注册、登录功能。从前端来看,Sprint1的故事全都没有完成。

       对于以上问题,我们在Sprint1回顾会议上面进行了仔细分析,认为问题的根源是交流不畅。所以我们在Sprint2中进行以下流程改进: 根据每人的课程表,(虽然不容易,也要)规划出都有空闲的共同工作时间,即使每两天只能规划3小时,也能对于难度较低的本项目起到帮助。 每两天(与共同工作的频率一致)晚上11点在一间宿舍开一次站会,交流共同开发以及自己零碎时间开发的成果。 作为一种松散的要求,大家多看看QQ群,尽可能及时处理其他成员提出的要求。

       经过改进以后,我们在Sprint2工作效率上升明显。我们清空了Sprint1遗留下来的故事,也完成了Sprint2新计划的故事。虽然本人学习完成、效率提升对这个结果有贡献,但我们明显能够感到:共同工作、及时交流修改的流程确实为整体经验不足的团队带来了提升。        在Sprint2的工作中,我们仍然遭遇了一些开发上的障碍: 在后端同学更新完api文档之后,发布的是Markdown格式的。由于api的更新不是在共同工作时间完成的,更新时有时负责前端的同学在上课或者没带电脑只有手机,就不方便检查api的设计缺陷。如果后来忘记,就会一直等到前端开发到这个接口时,才会发现问题。这时修改又会耽误时间。 后端虽然写了单元测试,但由于对测试框架的不熟悉,发生过把request parameter当成request body(json)的情况,还测试成功了(说明实现代码写错了)。结果前端根据api开发,怎么也调不好,最终发现是后台开发经验不足导致。

针对这些问题,我们在Sprint2回顾会议上,研究出了一些解决办法: 每次上传更新的api,也在QQ群里传一份pdf格式的,保证前端开发者即使只有手机也能及时检查。这样有机会使一些api修改提前。 除了自动化的单元测试,也使用Postman软件进行每个接口的测试。Postman测试用例可以导入导出。当后端开发自测成功,便导出易读易理解的Postman测试用例集合给前端开发,保证两组人对于api有着共同理解。

       接下来我们将开始Sprint3的开发。在本迭代内,我们有可能会继续调整流程,使得流程更加适合我们的具体情况。 Scrum实践对于学生的一般性课程项目的价值

       在本次Scrum实践中(虽然项目还没有结束),我们体会到了许多Scrum实践对于我们课程项目的价值: CI工具的使用。我们使用了Jenkins对系统后端进行了自动构建部署,每当Github代码更新,便集成一次。这使得我们在初期本来跌跌撞撞的开发有了一丝光明。过去开发C-S架构项目,调试时可能需要频繁修改,也就伴随着频繁的手动构建部署,令人不胜其烦。这次我们部署好Jenkins一套,虽然SonarQube只起到了令人心烦的作用,但其它部分都实打实地减少了我们的工作量。甚至当测试出现问题(unstable build)或部署失败(failure),还能自动发邮件提醒。 短迭代周期确实降低了修改成本。虽然我们目前只完成了两次迭代,但由于后端开发经验不足,api频繁修改。令人欣慰的是,由于每个迭代新增的故事点数目可控,新增的api数量也可控,这样犯错范围小,影响范围小。这样在迭代结束时,本迭代内的设计缺陷都能够修复,下一次迭代对之前api的影响很小,后端数据库设计每次修改幅度小,前端实现修改幅度也小。我们的项目才能够快速进步。如果按照以前一次设计完所有接口,开发时到处都是问题,可能所有接口会因此修改多遍,相应的前端开发也会严重受阻。 多迭代周期配合任务看板降低了拖延症发生风险。如果粗放地将三周半时间划为一个长Sprint,将所有故事点一次全放进看板,那么即使合理设置了截止时间,团队成员在看到长长的任务清单,也会望而生畏,想把任务往后拖。这种情况一般只发生与学生团队,不影响职业开发者(毕竟被老板开了就没饭吃了)。一个迭代周期任务未完成的看板(尤其是变成红色的日期)能给学生带来更大的危机感,促使学生在下一个迭代进行努力工作。同时,迭代的顺利完成会成为对团队成员的激励,使其更有动力接受下一次的挑战,治愈拖延症。这对于职业开发者也适用。

  原标题:央行:信用收缩成为制约经济金融主要矛盾,以银行永续债为突破口补充资本

  8月9日,中国人民银行发布今年第二季度货币政策执行报告(以下称《报告》)。《报告》显示,银行是信用创造的主体,是货币政策传导的中枢。2018年经济下行和社会信用收缩压力一度加大,信用收缩成为制约经济金融运行的主要矛盾,重要原因之一是受到资本约束。

  针对银行资本水平不足的问题,央行表示要以银行永续债为突破口补充资本,用改革的办法增强金融服务实体经济的可持续性。对此,人民银行与银保监会、财政部、全国人大法工委等部门反复沟通,还与巴塞尔委员会直接征询确认,在现行法律、监管和会计框架下探索出一套可行模式,将永续债的到期日设为银行的存续期,解决了永续债既要符合公司法关于债券有期限的要求、又不能有固定期限以符合作为一级资本的监管规定之间的矛盾。

  人民银行以永续债发行作为突破口,缓解银行支持实体经济面临的资本约束,并创设央行票据互换工具(CBS),将合格的银行永续债纳入央行操作担保品范围,为银行发行永续债供支持。截至2019年7月,中国银行、民生银行、华夏银行、浦发银行、中国工商银行五家已合计发行2300亿元永续债,另有13家银行拟发行超过4700亿元永续债,市场预期明显改善,金融可持续支持实体经济能力不断增强。