2020年05月_zhang_qxian

原创用户故事地图学习笔记（四）：如何创建用户故事地图

如何创建用户故事地图用户任务是构建故事地图的基本模块使用目标层级的概念，可以帮助汇总小任务或分解大任务。隐喻：石头，砸成小石头后仍是石头故事地图通过从左到右的叙事流来组织。补充细节探索替代故事。细节、替代、变化和异常都成故事地图的主体。保持流动。提取故事地图的主干。高层故事。活动组成故事地图的主干。使用切分来识别和特定结果相关的所有任务和细节。此时活动卡片不要移动。概念总结：任务是描述人们做什么事情的动词短语任务有不同的目标层级故事地图中的任务被布置在从左到右的叙事主线

2020-05-22 16:46:18 557

原创用户故事地图学习笔记（三）开局，中局和终局

对产品故事进行首次讨论，应聚焦于如何具象化产品的机会。需求其实很可能是一个假想，那么唯一可行的做法是验证想法是否具备可行性。验证的方法很多，比如和客户、用户深入交谈，观察他们目前做事的行动，不断和他们反馈，用手绘线框图（Axure）和高保真模型实现解决方案的具象化，并以此和客户/用户进行沟通。通过原型和用户测试来验证产品方案是否真的有用，有价值，并能够质疑用户所说的内容，然后在开发过程中学习（Scrum），迭代乃至最终发布。必须要始终记得，交付给客户/用户的是可用产品。基于验证的学习循环：开发-（最小可

2020-05-22 16:41:04 313

原创用户故事地图学习笔记（二）：一组好问题

计划，为了更少的开发故事地图帮助大型组织建立共识。贯穿各个团队的产品发布地图，可以帮助团队以可视化的方式展示依赖关系。大型用户故事地图解析：1、故事地图的主干在顶部；2、地图要涵盖整个发布计划；地图要涵盖贯穿多个用户和系统的叙事主线。提前发现可能造成损失的潜在风险是好事而不是坏事需求范围并没有蔓延，而是我们对需求的理解更深刻了。要做的事情太多，如何排定优先级？聚焦于系统外的预期成果来决定系统内需要什么功能！！聚焦于成果，即产品发布后用户能使用和感知的东西，切分发布计划应该以成果为导向【针

2020-05-22 16:33:16 329

原创用户故事地图读书笔记（一）两个最重要的认识

两个最重要的认识：使用用户故事的目的不是为了写出更好的用户故事产品开发的目的不是开发出产品。使用用户故事的目的是最终达成共识，而达成共识最高效的方式就是面对面，借助于可视化手段来讨论，并用卡片、照片或者视频等做好备忘，以便于后续能够回忆起当时讨论的场景。不要试图去写完美的文档，不同的人对同一段文字的理解可能有天壤之别。如果从更高的层面上来讲，你的工作是改变世界（或多或少），因此软件本身并不是重点。重点在于outcome，即软件本身给用户带来了什么样好的改变。对于软件来说，想要开发的功能，总比.

2020-05-22 16:24:47 324

原创演进式架构学习笔记（六）：未来已来

演进式架构的未来基于AI的适应度函数。这个方向后续指的关注。如何能够把AI和研发过程联系起来？是崇尚简单粗暴管理，还是崇尚智能自动管理？目前有无可用开源工具或者平台支撑？生成式测试。需要继续什么了解。目前的基本理解，生成式测试不同于单元测试（也有类似的地方）。单元测试是指定明确的输入输出+断言来判断程序的正确性，生成式测试是程序自动生成输入+断言来判断程序的正确性。为何要构建演进式架构呢？有什么充足的理由吗？显然，首先要评估是否值得付出额外的时间和精力来构建可演进的架构。其次，可以看看有哪些衡量因

2020-05-19 14:16:38 270

原创演进式架构学习笔记（五）：实践演进式架构

第8章实践演进式架构一、组织全功能团队。敏捷软件开发中的最佳实践之一。这里主要需要关注运维角色。围绕业务能力来组织团队。产品高于项目。产品生命周期长于项目。增加团队成员责任感的最佳方式，就是负责到底。应对外部变化。一个有效的方法是，采用消费者驱动契约的模式。这个模式和SOLID中的依赖倒置很类似。就是Client来定义契约，Service来实现这个契约。相当于构建一张安全网，对这些契约进行适应度测试。但必须清醒的认识到，这需要团队具备一定的成熟度才可以。团队成员之间的连接数。N(N-

2020-05-19 14:15:27 243

原创演进式架构读书笔记（四）：陷阱与反模式

演进式架构的陷阱和反模式反模式：供应商为王。即以供应商提供的架构为核心来组织自身业务，被供应商掌控全局。类似于20200517的HW事件，美国通过掐断半导体晶圆片的供给（非禁止，要许可）。也就是说，如果你的商业帝国强烈依赖于第三方供应商（尤其是不可替代），那么可能大厦一夜即倾。陷阱：抽象泄露。所以重要的抽象，在某种程度上都会泄露。随着技术栈的不断变化，如何保证业务在技术不断发展时还能保持一定的稳定性？当然，重建几乎是不可避免的，但如果能在重建时付出的代价较小，显然对组织的研发效率是具备正面效应的。

2020-05-19 14:13:52 201

原创演进式架构学习笔记（三）：演进式数据及构建可演进的架构

第五章演进式数据数据库脚本管理策略：目前项目采用的策略是合适的，即保留每个产品版本的基础全量脚本，同时添加从上一版本到目前最新版本的升级脚本。最新的全量版本包含了最新的升级脚本。这样的好处是，如果是升级场景，在不迁移数据情况下，仅通过升级脚本即可完成升级。在新系统部署时，则运行全量脚本。在存在大量数据库操作的时候，微服务的限界上下文如何确定？因为数据库是整个系统的强力耦合点，因此单纯构建一个数据库微服务，第一直觉是不合适的。个人觉得，应该是先从业务领域入手，服务要围绕业务来构建。当需要操作数据库时，

2020-05-19 14:08:52 392

原创演进式架构学习笔记（二）：架构量子及架构模式

架构中的耦合。首先需要看到，耦合是复杂系统必然的属性之一，就像生物的细胞一样，必须相互交换信息才能体现出正常的功能。但不合理的耦合却是要极力避免的。我们常说高内聚低耦合。内聚是通过业务语义的关联来组织的，那么内聚带来的，往往是模块化（物理形式往往是DLL或者服务）。文中提到了具有高度功能内聚并可独立部署的组件可使用架构量子来隐喻。这里需要注意的是，如果想能够真正独立部署，往往离不开数据库，框架或者其他第三方组件，而在架构设计时，显然这种是最需要延迟决策的部分。因此，架构量子更多是从结构性元素的完整性来考虑，

2020-05-19 13:58:14 408

原创演进式架构学习笔记（一）：架构评估及适应度函数

适应度函数，本质上就是一组评估函数，用以评估架构在不同维度上的表现，并从全局角度进行平衡，从而实现增量和引导式演进。简言之，其实就是能够构建出一套架构监控机制。适应度函数，并不一定全部采用自动化手段，甚至某些维度不可能采用自动化手段。评估函数的确定，和问题域密切相关。需要识别出关键维度和相关维度。架构特性---适应度函数----探索式架构设计工程效率提升（CI）----这里联想到百度的工程效率部。微服务架构，让我联想到Erlang的进程，所有进程都是独立的，相互不耦合，仅仅通过消息进行通讯。

2020-05-19 13:51:13 879

zhang_qxian的专栏