- 博客(10)
- 资源 (1)
- 收藏
- 关注
RSS订阅原创 要能真正提升产品开发团队的效率与质量, 你必需要懂得如何 ”设计” 开发团队所需要的实践或框架
在 IT 这一行, 懂得而且能倒背如流 Scrum, SAFe, Use Case, Domain Driven Design, Test Driven Development, Behavior Driven Development, ATDD, Continuous Integration, Continuous Delivery, Microservices… 的人比比皆是。然而, 真正有用的实践是 "设计" 出来的, 不是 "读" 出来的。
2016-07-30 11:03:12
4242
原创 当团队所有的开发人员都能按照 User Story 所估算的人天交付时, 是不是就能保证版本交付的质量?
当团队所有的开发人员都能按照 User Story 所估算的人天交付时, 是不是就能保证版本交付的质量?答案有时是否定的; 甚至版本交付的质量有时还会越来越糟, 每况愈下。为何?因为….
2016-07-24 12:12:47
1074
原创 你的 Product Owner 的惯性行为, 已经决定了你的产品的成败
回顾这近二十年的敏捷、软件工程的旅程，我的收获相当的丰富；我面对面了许多不同层级的部门领导、数千位的团队成员。使我能不断的验证了 “人类惯性的行为“对团队开发效率与产品质量 （品味）的影响。
2016-07-24 10:17:26
833
原创 IPD (Integrated Product Development): 企业开发产品的核心框架
为何根本完全不了解 IPD 的过去，现在与未来的发展，却任意的批评 IPD的种种？只是因为所谓的互联网公司没有 IPD , IPD 就成为ㄧ种错误？IPD 就成为过街老鼠？唉，这世上为何总是充斥着些自认为不可ㄧ世的大师，却只是能散播些肤浅、毫无深刻观察、毫无深度思考的言论。我想，这是一个大家都懂得的 "Common Sense" ...”任何一个企业，当面对不可预知的市场变
2016-07-19 10:45:52
1477
原创 每日的站会, 决定了版本交付的效率与质量。但, 为何总是开不好?
站会对版本的的交付是非常重要，但往往流于型式，主要原因：1.开发，测试人员不具备 “思考”自身问题的习惯与能力。2.开发，测试人员没共同协作，制定 User Story开发完成的定义。3. 测试人员没能与开发人员协作，确定每日 User Story开发的状态。4. Product Owner 的管理能力不足，使团队纪律松散，互相信任不足。5. 团队成员只会作时间
2016-07-17 09:12:50
1085
原创 Product Owner 为何老是带不好团队?
Product Owner 正面且积极的看待团队开发人员能力上的问题，Product Owner 才能即时的淘汰不适任的开发人员。团队也才能真正的拥有效率，产品也才能真正的获得质量上的保证。借由 Story 场景树，Product Owner在 15 分钟内便可确定：开发人员是否真的具备能力去开发 User Story。但，为何 Product Owner 已借由 User Story
2016-07-11 00:01:24
1317
原创 微服务的边界 (粒度) 是 "决策", 而不是个 "标准答案"
微服务的边界 ，粒度是 "决策",而不是个 标准答案。许多人面对微服务时，往往都会纠结着一个问题：微服务太小？太大？其实，会纠结在这个问题上，最根本的原因便是误解了微服务粒度划分这件事的本质；微服务划分本身是 "架构设计"。也就是说微服务划分本身绝不是一个只讲"太大"或 "太小"标准答案的 "是非题"。而是需综合考量以下的因素，所作出的一个 "架构决策"：1. 市场业务的扩
2016-07-09 09:41:59
3854
原创 企业云存储团队在微服务生态系统下的敏捷分析，设计的工程实践
企业云存储团队，迈向微服务生态系统在产品级敏捷的基础下，跨入微服务生态系统的第一步...1. 以可视化，轻量级的工程实践，使架构师，开发骨干，测试人员可共同协作；从外部的视角，界定可快速响应外部业务变化的微服务边界，并分析此微服务边界对已有产品架构正面与负面的影响，以及在开发层面上所可能面临到的风险与挑战。2. 以 Story场景树分析微服务对外的接口；使微服务的接口更接近外部使用
2016-07-09 08:49:33
564
原创 构建微服务绝不是单纯的切割模块; 你可知道如何一步, 一步的构建微服务？
构建微服务架构就宛如是踏入一个新的领域；由这新领域所构建的微服务架构，我们最终不仅要能做到持续交付，更要能做到持续运维。所以，构建微服务架构绝不是单纯的切割模块。 而是要有步骤，有实践，有工具，去构建产品的 ”微服务生态系统”。构建微服务生态系统的步骤：步骤 1. 只从外部的视角分析; 将外部使用者、系统、设备的 ”独立行为” , 做为微服务的边界与微服务接口设计的唯一输入。
2016-07-06 23:22:19
584
原创 为何敏捷开发, 微服务对你和你的团队一点效益也没有?
不懂得如何做产品，就算懂敏捷又如何？不懂得分布式的架构、操作系统、业务场景，就算能熟背了什么是微服务又如何？也许是新的事物出现的太快，出现的太多，也许是搜索引擎太方便了，使得我们已没时间，更没耐心去探索新的事物背后真正的本质。而只愿意以一任意找到的标准答案，快速、省事的让自己能穿上新事物的外衣；站起来开个会，拍拍手就是敏捷，将产品模块切割就是微服务...更有趣的是，还会以专家的身分批评
2016-07-01 09:10:44
1951
精益敏捷开发的软件架构设计
2014-05-29
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人