- 博客(16)
- 资源 (1)
- 收藏
- 关注
原创 微服务产品级敏捷设计的初衷
微服务产品级敏捷,设计的初衷, 绝不是肤浅的快速交付。而是要能使团队可持续改善,打造ㄧ永远幸福的团队文化与永远世界第一的产品。
2016-09-29 07:05:03 935
原创 微服务产品级敏捷: 微服务架构设计
微服务产品级敏捷主要是结合了敏捷开发与软件工程, 以团队自主与协作的方式, 共同打造一可快速响应市场变化与对客户产生最大正面影响的微服务架构产品。微服务产品级敏捷总共涵盖了, 整个微服务架构产品的生命周期; 从微服务产品设计到微服务运维管理。
2016-09-25 09:22:29 1107
原创 微服务架构设计 第七步: 分析微服务对外 API
每一个微服务中的实体应能只明确代表微服务中的某个单一的业务概念; 同样的, 微服务中的某个业务概念应也只能由微服务中某个单一的实体所代表。
2016-09-22 21:23:13 1231
原创 微服务架构设计 第六步: 微服务的 User Stories 的分析、设计与定义完成
设计出微服务中的 User Story 每个业务流活动步骤的表格式测试用例; 经由此表格式测试用例, 便可定义出: User Story 每个业务流活动步骤, 其 “开发完成” 的定义。
2016-09-12 00:34:38 1022
原创 微服务架构设计 第五步: 微服务的 User Stories 的拆分与澄清
在微服务产品级敏捷中, 特性负责人, 不应只是传递微服务的需求, 而应该是要能说服开发与测试人员, 能认同 User Story 的价值, 并使开发与测试人员能从产品外部的视角, 清楚明白: 外部使用者、系统、设备或事件所期望 User Story 完成的定义或标准为何?
2016-09-11 18:55:36 1608
原创 微服务架构设计 第四步: 分析微服务架构依赖与风险; 开发微服务最关键的一步
特性负责人必需与架构师, 开发骨干人员, 测试经理, 资深测试人员协作, 认真的分析因架构上的依赖, 对微服务 (functional services) 在执行集成测试或独立发布、独立部署上, 所可能带来的风险为何? 并深度的思考, 应该有怎样的 A计划? B计划? 才能消除或降低因为架构上的依赖, 所导致的风险; 这一步真的很关键, 往往会决定微服务开发的成功或失败....
2016-09-11 12:01:44 2012
原创 微服务架构设计 第三步: 微服务的架构方案
当特性负责人, 与团队中各不同领域的成员; 架构师, 开发骨干人员, 测试经理, 资深测试人员; 共同的协作, 针对每个 functional services, 反覆的推敲、分析, 直到获得大家都认可的, functional services 这类微服务的边界上下文 (Bounded Context) 后, 特性负责人与架构师, 开发骨干人员, 测试经理, 资深测试人员应该就会对下列的微服务的
2016-09-10 23:41:42 1503
原创 微服务架构设计 第二步: 分析微服务的边界上下文 (Bounded Context)
经由基本流, 扩展流与异常流的组合, 所构成的业务场景切片, 是否就能形成 functional services 这类微服务的最佳边界上下文 (Bounded Context) ?要能回答这个问题, 需先思考....
2016-09-10 18:12:28 4004
原创 微服务产品级敏捷案例: 以敏捷开发的模式, 做好真正的微服务
我们真的已经找到了, 如何以敏捷开发的模式, 做好真正的微服务...只是谈谈鸡汤,开开会,估估没人会真正开心的工作量,站起来拍拍手的敏捷,对任何团队、任何人是ㄧ点帮助都没有的。敏捷应该是(而且已经是证明的)要和软件工程无缝的结合的;使得团队能将市场、行销、研发高效的协作、自主的管理,共同的打造能适应变化、对外部的世界产生最大正面影响的产品 (产品架构)。
2016-09-09 18:44:58 3708
原创 微服务架构设计 第一步: 从特性到业务场景
为何需要微服务? 目的只有一个: 比竟争对手能更快的响应市场的变化与客户的诉求。所以, 微服务的分析与设计, 必需要掌握两个核心的原则:1. 从外部的业务场景, 驱动微服务的分析与设计。2. 经由微服务分析与设计出的微服务架构, 必需是能演进与能扩展的架构。
2016-09-08 22:16:54 2141
原创 产品为何总是做不好 (六): Product Owner 惯性的行为
当 Product Owner 有这些惯性的行为时, Product Owner 仍无视风险的存在, 而只是会要求开发人员赶快写代码,测试人员赶快测试;即使风险已像大象般, 明显且重大, 紧急的呈现在眼前; 即使开发人员根本还搞不清楚到底要写些什么?测试人员根本还搞不清楚到底要测什么?
2016-09-03 10:23:35 820
原创 产品为何总是做不好 (五): 头痛医头,脚痛医脚
我们已经历了数十年软件开发的岁月,但,我们对如何去 "设计" ,我们团队自身真正所需要的工程实践、工作模式时,还是显得那么的无知。
2016-09-03 09:48:50 527
原创 产品为何总是做不好 (四): 只願意很聰明的去做 ⋯ 亮點實踐
只是学了别人的工程实践,就宛如是将别人穿过的衣服,鞋子,直接拿来穿在自己的身上;上半身穿了 Google 的衣服,下半身穿了 Amazon 的裤子,接着再穿上爱立信的鞋子。
2016-09-03 09:35:29 503
精益敏捷开发的软件架构设计
2014-05-29
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人