- 博客(67)
- 收藏
- 关注
RSS订阅原创 用户故事地图学习笔记（四）：如何创建用户故事地图
如何创建用户故事地图用户任务是构建故事地图的基本模块 使用目标层级的概念，可以帮助汇总小任务或分解大任务。隐喻：石头，砸成小石头后仍是石头 故事地图通过从左到右的叙事流来组织。补充细节 探索替代故事。细节、替代、变化和异常都成故事地图的主体。保持流动。 提取故事地图的主干。高层故事。活动组成故事地图的主干。 使用切分来识别和特定结果相关的所有任务和细节。此时活动卡片不要移动。概念总结：任务是描述人们做什么事情的动词短语 任务有不同的目标层级 故事地图中的任务被布置在从左到右的叙事主线
2020-05-22 16:46:18
512
原创 用户故事地图学习笔记（三）开局，中局和终局
对产品故事进行首次讨论，应聚焦于如何具象化产品的机会。需求其实很可能是一个假想，那么唯一可行的做法是验证想法是否具备可行性。验证的方法很多，比如和客户、用户深入交谈，观察他们目前做事的行动，不断和他们反馈，用手绘线框图（Axure）和高保真模型实现解决方案的具象化，并以此和客户/用户进行沟通。通过原型和用户测试来验证产品方案是否真的有用，有价值，并能够质疑用户所说的内容，然后在开发过程中学习（Scrum），迭代乃至最终发布。必须要始终记得，交付给客户/用户的是可用产品。基于验证的学习循环：开发-（最小可
2020-05-22 16:41:04
287
原创 用户故事地图学习笔记（二）：一组好问题
计划，为了更少的开发故事地图帮助大型组织建立共识。贯穿各个团队的产品发布地图，可以帮助团队以可视化的方式展示依赖关系。大型用户故事地图解析：1、故事地图的主干在顶部；2、地图要涵盖整个发布计划；地图要涵盖贯穿多个用户和系统的叙事主线。提前发现可能造成损失的潜在风险是好事而不是坏事需求范围并没有蔓延，而是我们对需求的理解更深刻了。要做的事情太多，如何排定优先级？聚焦于系统外的预期成果来决定系统内需要什么功能！！聚焦于成果，即产品发布后用户能使用和感知的东西，切分发布计划应该以成果为导向【针
2020-05-22 16:33:16
305
原创 用户故事地图读书笔记（一）两个最重要的认识
两个最重要的认识：使用用户故事的目的不是为了写出更好的用户故事 产品开发的目的不是开发出产品。使用用户故事的目的是最终达成共识，而达成共识最高效的方式就是面对面，借助于可视化手段来讨论，并用卡片、照片或者视频等做好备忘，以便于后续能够回忆起当时讨论的场景。不要试图去写完美的文档，不同的人对同一段文字的理解可能有天壤之别。如果从更高的层面上来讲，你的工作是改变世界（或多或少），因此软件本身并不是重点。重点在于outcome，即软件本身给用户带来了什么样好的改变。对于软件来说，想要开发的功能，总比.
2020-05-22 16:24:47
293
原创 演进式架构学习笔记（六）：未来已来
演进式架构的未来基于AI的适应度函数。这个方向后续指的关注。如何能够把AI和研发过程联系起来？是崇尚简单粗暴管理，还是崇尚智能自动管理？目前有无可用开源工具或者平台支撑？ 生成式测试。需要继续什么了解。目前的基本理解，生成式测试不同于单元测试（也有类似的地方）。单元测试是指定明确的输入输出+断言来判断程序的正确性，生成式测试是程序自动生成输入+断言来判断程序的正确性。为何要构建演进式架构呢？有什么充足的理由吗？显然，首先要评估是否值得付出额外的时间和精力来构建可演进的架构。其次，可以看看有哪些衡量因
2020-05-19 14:16:38
246
原创 演进式架构学习笔记（五）：实践演进式架构
第8章实践演进式架构一、组织全功能团队。敏捷软件开发中的最佳实践之一。这里主要需要关注运维角色。 围绕业务能力来组织团队。 产品高于项目。产品生命周期长于项目。增加团队成员责任感的最佳方式，就是负责到底。 应对外部变化。一个有效的方法是，采用消费者驱动契约的模式。这个模式和SOLID中的依赖倒置很类似。就是Client来定义契约，Service来实现这个契约。相当于构建一张安全网，对这些契约进行适应度测试。但必须清醒的认识到，这需要团队具备一定的成熟度才可以。 团队成员之间的连接数。N(N-
2020-05-19 14:15:27
213
原创 演进式架构读书笔记（四）：陷阱与反模式
演进式架构的陷阱和反模式反模式：供应商为王。即以供应商提供的架构为核心来组织自身业务，被供应商掌控全局。类似于20200517的HW事件，美国通过掐断半导体晶圆片的供给（非禁止，要许可）。也就是说，如果你的商业帝国强烈依赖于第三方供应商（尤其是不可替代），那么可能大厦一夜即倾。 陷阱：抽象泄露。所以重要的抽象，在某种程度上都会泄露。随着技术栈的不断变化，如何保证业务在技术不断发展时还能保持一定的稳定性？当然，重建几乎是不可避免的，但如果能在重建时付出的代价较小，显然对组织的研发效率是具备正面效应的。
2020-05-19 14:13:52
191
原创 演进式架构学习笔记（三）：演进式数据及构建可演进的架构
第五章演进式数据数据库脚本管理策略：目前项目采用的策略是合适的，即保留每个产品版本的基础全量脚本，同时添加从上一版本到目前最新版本的升级脚本。最新的全量版本包含了最新的升级脚本。这样的好处是，如果是升级场景，在不迁移数据情况下，仅通过升级脚本即可完成升级。在新系统部署时，则运行全量脚本。在存在大量数据库操作的时候，微服务的限界上下文如何确定？因为数据库是整个系统的强力耦合点，因此单纯构建一个数据库微服务，第一直觉是不合适的。个人觉得，应该是先从业务领域入手，服务要围绕业务来构建。当需要操作数据库时，
2020-05-19 14:08:52
375
原创 演进式架构学习笔记（二）：架构量子及架构模式
架构中的耦合。首先需要看到，耦合是复杂系统必然的属性之一，就像生物的细胞一样，必须相互交换信息才能体现出正常的功能。但不合理的耦合却是要极力避免的。我们常说高内聚低耦合。内聚是通过业务语义的关联来组织的，那么内聚带来的，往往是模块化（物理形式往往是DLL或者服务）。文中提到了具有高度功能内聚并可独立部署的组件可使用架构量子来隐喻。这里需要注意的是，如果想能够真正独立部署，往往离不开数据库，框架或者其他第三方组件，而在架构设计时，显然这种是最需要延迟决策的部分。因此，架构量子更多是从结构性元素的完整性来考虑，
2020-05-19 13:58:14
380
原创 演进式架构学习笔记（一）：架构评估及适应度函数
适应度函数，本质上就是一组评估函数，用以评估架构在不同维度上的表现，并从全局角度进行平衡，从而实现增量和引导式演进。简言之，其实就是能够构建出一套架构监控机制。适应度函数，并不一定全部采用自动化手段，甚至某些维度不可能采用自动化手段。评估函数的确定，和问题域密切相关。需要识别出关键维度和相关维度。架构特性---适应度函数----探索式架构设计工程效率提升（CI）----这里联想到百度的工程效率部。微服务架构，让我联想到Erlang的进程，所有进程都是独立的，相互不耦合，仅仅通过消息进行通讯。
2020-05-19 13:51:13
827
原创 vsftp乱码问题解决
一、问题现象：Android端用Java写的代码，将本地文件通过FTP上传到vsftp服务器，文件名中的中文显示乱码。二、问题定位：1）首先要知道，FTP传输协议中，默认编码方式为ISO-8856-1。不管本地中文编码采用什么方式，最终上传到FTP前，必须要统一转成ISO-8856-1，这样FTP服务器才能正常还原出原来的编码方式。2）客户端编码方式要和服务器的编码方式完全一致。比如服...
2019-08-30 15:46:43
5048
1
原创 关于接口隔离（ISP）
接口隔离原则（Interface Segregation Priciple，ISP），简单说来就一句话，即不能强迫客户依赖于和他无关的接口。从本质上来讲，ISP就是隔离变化的波及范围。如果变化波及到了本身并不使用这些变化者功能的地方，这本身就是非常可怕的。对于修改和新增功能无法预测，对于大型项目来说是一场灾难。 在《敏捷软件开发：原则、模式与实践》中提到，“胖类会导致它们的客户...
2019-05-16 15:50:48
369
原创 继承这回事
开放封闭原则（OCP）是面向对象的核心原则之一，而OCP背后的支撑机制是抽象和多态，这两者又是以继承作为承载。因此继承的重要性就不言而喻。继承的定义，Barbala Liskvo说的很明白，“如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1代换o2时，程序P的行为没有变化，那么类型S是类型T的子类型。”换句简单点的话说，就是子类型必须能够替换掉其...
2019-04-25 08:54:10
199
原创 论编程哲学的重要性
一谈哲学，好像和编程没什么关系。而且这种虚无缥缈的高大上抽象思维领域，怎么和写代码这种更接近于逻辑和数学的操作关联起来？其实不尽然。我们说，任何的编程语言和设计思想，都是作者对于现实世界的理解在软件领域的投射。首先举一个大家编程中最常见的概念：面向对象。面向对象最初起源于对于人体细胞的隐喻（https://blog.csdn.net/zhang_qxian/article/details/...
2019-03-14 13:49:04
750
原创 两个逻辑题
近期遇到两个逻辑题，感觉有点好玩，发上来以作记录。1、给定9个球，其中一个质量比其他8个球要轻（或者重），给定一个天平，问最少几次可以把这个轻球找出来。2、给定一组大小长短不一的乐高积木，以及一个天平，如何把这组乐高积木按照重量从轻到重排列出来。第一题，只要把9个球分成3组，两组先比较，重量轻的一组，必然包含了轻球。再对这组的三个球，抽取两个，如果相等，必然是第三个球，否则轻者就是轻球...
2019-03-08 15:33:42
212
原创 面试时关键的几个方向
1、把学过的项目好好整理，总结，尤其是从中学到了什么技术，遇到过什么困难，是如何解决的，要条理清晰的讲出来。2、频繁跳槽的，一般都直接pass。企业不是让你来刷经历的，是让你能够在为公司创造价值的同时，能提升自身价值。因此选择公司需要谨慎。3、把基础知识掌握好。由于面试的公司所从事的业务，和你目前的业务可能差别很大，框架也可能有很大差异，因此为对所有面试者提供公平的竞争，一般都侧重于基础知...
2019-02-21 11:09:10
325
原创 会编程能改变什么？
昨日一朋友携家带口到上海来度假，晚上一起聚餐。席间聊天，本来家长里短，突然画风一变。朋友说，以前搞软件开发多年，做事情的思路对现在工作帮助很大。比如会想怎么把一份手工做的事情，通过写点代码，把它变成自动化。举例说，他们要维护成千上万台机器，配置各不相同，要安装各种操作系统。因机器配置不同，就需要人工填写一些模板，然后把模板导入到待装的机器上，再启动安装。以前都是手工完成，做一个模板，动辄要几天时间...
2018-05-07 08:52:24
496
原创 从某地产公司的激进谈软件开发
前几天看到一则触目惊心的朋友圈，大概意思是，某地产商董事长下达红头文件，要求设计院接到营销户型配置及设计要求后，当天内通宵出图，而且还算了一笔账，一万块，可以让一个设计师干十天，也可以让五个设计师白加黑，通宵干一晚。当然，这事情真假与否自有良心对作俑者进行拷问，当某一天出了事情之后自有法律进行严查，但这种触目惊心涉及居民生命的事情，实在让人瞠目结舌。由此想到软件开发。相信不少人有过这种悲催的经历，...
2018-04-25 09:02:05
306
1
原创 浅谈软件测试的核心价值
一谈到软件测试的核心价值，很多有经验的测试工程师，第一反应就是软件测试的目的是为了质量保证。质量保证和软件测试，其实从概念上是有区别的。QA的很大部分的工作，主要是从事于流程的定义和改进，软件测试则需要真刀真枪的去实干。软件测试的核心价值，从我个人角度理解，需要抓住两个要点。第一是需求。软件的首要目标，就是满足业务需求。没有功能的软件，毫无测试的必要性。那么很显然，软件测试的首要目标，就是要保证软...
2018-03-30 21:29:20
7280
2
原创 LinkedBlockingQueue与ArrayBlockingQueue
近期在项目开发中，遇到一个性能问题，导致文件解析效率无法满足性能要求。经过代码走查后，发现使用的线程安全队列是ArrayBlockingQueue。由于ArrayBlockingQueue实现的队列中的锁是没有分离的，即生产和消费用的是同一个锁，从而导致多线程访问此队列时，存在资源竞争，导致并发能力不足。针对此情况，从网上查找相关资料后，对ArrayBlockingQueue和LinkedBloc...
2018-02-27 15:47:33
445
翻译 The Onion Architecture（洋葱架构） part4
In 2008, I coined a new pattern name called Onion Architecture. You can read the previous parts here: part 1, part 2, part 3. Over these four years, I’ve spoken about this pattern at user
2018-01-22 08:53:39
620
翻译 The Onion Architecture（洋葱架构） part3
In my previous installments, I described what has become my approach to defining the architecture for an application. Based on feedback, I've modified my diagrams a bit to reduce ambiguity and emphas
2018-01-19 15:21:25
1138
翻译 The Onion Architecture（洋葱架构） part2
In part 1, I introduced an architectural pattern that I have named "Onion Architecture". The object-oriented design concepts are not new, but I'm pulling together a lot of techniques and conventions
2018-01-19 14:27:03
1084
翻译 The Onion Architecture（洋葱架构） part1
链接：http://jeffreypalermo.com/blog/the-onion-architecture-part-1/I've spoken several times about a specific type of architecture I call "Onion Architecture". I've found that it leads to more maintaina
2018-01-19 13:57:07
1351
翻译 The Clean Architecture（干净的架构）
Uncle Bob 13 Aug 2012 Architecture CraftsmanshipOver the last several years we’ve seen a whole range of ideas regarding the architecture of systems. These include:在过去几年中，我们已经看到了关于系统架构的各种观点，如下所示：Hexag
2018-01-17 15:52:12
2569
原创 邓辉关于《架构的尖叫》一文的看法。
邓辉：2011.10.10在建筑行业，除了Arhcitect外，还有个很重要的角色，叫structural engineer，这个角色考虑的问题是实现的经济性，Architect主要解决布局和用的问题。在软件中，Architecture是个很含糊的概念。如果我们把范围做点局限的话，在软件中Architecture应该首先提供整个系统的Shape，这个Shape应该是由如何使用这个系统提
2018-01-15 09:50:28
519
翻译 架构的尖叫
Screaming Architecture架构的尖叫 uncle bob 30 Sep 2011 ArchitectureImagine that you are looking at the blueprints of a building. This document, prepared by an architect, tells you
2018-01-13 13:34:58
519
翻译 The Cost of Code?
代码成本昨天在#SCNA(北美2010软件技术大会)的一个专题小组讨论会上，@chadfowler提出了这个问题：“有多少项目是因为程序的原因而失败？”我想，他的潜台词是，造成项目失败的主要原因是业务问题，而非技术问题。今天早上我把这个问题发布在了微博上。很快就有了回复，几乎所有人都认为导致项目失败的原因中，业务问题是罪魁祸首。完全没错，项目会因为成本，需求，进度计划，管理等问题而
2018-01-13 10:10:45
368
转载 Beyond Agile Programming
没有什么能代替对问题本身的透彻认识，除非中了头彩。没有什么解决方案能放之四海皆准，在某一场合的最佳方案，可能在别处偏偏是最差的。好方法通常具有一定的普遍适用性，熟悉以往的成功案例，可以温故而知新。解决之道不光是掌握方法，还得掌握时机，这样就能随机应变，让方法来适应问题，而不是削足适履。就算懂得再多方法和时机，实战不会根据现有知识来出题，很多领域前人也未曾探索，还是谦虚第一。
2017-12-12 08:47:33
264
转载 六角架构
六角架构作者：Alistair Cockburn 原文链接：http://alistair.cockburn.us/Hexagonal+architecture 译文原链接：http://www.codeweblog.com/%E8%AF%91-%E5%85%AD%E8%A7%92%E6%9E%B6%E6%9E%84-hexagonal-architecture/
2017-04-17 08:47:42
1179
翻译 Do Hard Things---做困难的事情
重新整理翻译这篇文章，仍然有所感慨。我们在一些平庸的想法中沉寂太久了，每日的重复性工作毫无创意，但又不知道怎么改变。这样年复一年的过去，当有一天你发现自己老了，失去了市场竞争力了，才知道类似CRUD的项目把你坑惨了。如果你早点读到这篇文章，或许会醒悟的更早一点。
2017-01-24 09:23:43
1320
1
原创 大数据综述
作者按：本文写就于2014年初，一晃3年已过。大数据已经从最初的理论研究，逐渐产业化，并已服务于各行各业。“棱镜门”事件的持续发酵，深刻揭露出科技领先大国利用信息技术的优势，有计划、有步骤地采集各国的“数字DNA”。由此可见，数据本身的重要性，已经超过了传统的信息产业、工业产业，逐步在国家安全等更高领域得以体现。 根据国外机构的测算，全世界数据总量以每两年翻一翻的速度递增，最近两年
2017-01-20 08:35:13
1568
2
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人