研发管理
文章平均质量分 77
尘世间一名迷途小码农
热衷于用技术思维去解决问题,厌恶低效,热衷自动化和智能化,释放人的创造性。
InfoQ博客:www.infoq.cn/u/justyman
展开
-
如何做好技术选型和分析决策
一、前言技术人一般都喜欢研究技术,但是如果你问他一般技术选型到底怎么做,估计他一下子懵掉了。因为一般来说,技术人可能更关注于学习什么新技术,反而更少去了解怎么选择一种合适的技术手段去解决业务问题。因为平时日常工作也需要涉及到这块领域,因此心里一直想想总结一下,毕竟作为一个十几年的老司机,在做技术选型的时候如果完全都是随心所欲的话,那就真的太水了吧。首先,技术选型它会涉及到方方面面的因素,例如市场上的人员招聘难度、技术组件的社区活跃度、文档丰富程度、具体落地案例、后期运维复杂度、人员学习成本等原创 2021-06-27 10:03:08 · 1146 阅读 · 0 评论 -
由一张精益MVP图所浮想联翩
有感于之前听到的关于迭代开发的看法,我特意把上面这张精益MVP的图贴出来,一起看图说话。1、每个阶段的交付对用户来说都是有意义的,对吗?这个观点本文不打算详述论证或者长篇吹捧,做过精益或者碰过敏捷的同仁也知道这种方式的重要性;2、每个新的环节代表的是对部分旧模块的推倒-重建。但是这个重建是从0到1的重建吗?我跟大家罗列一下细节:第二阶段【滑板变成滑板车阶段】这里发现就多了个方向盘,目的是提升用户安全性(防摔)和用户便利性(方向控制从用身体重心控制转向用双手控制),...原创 2021-04-10 00:07:47 · 244 阅读 · 2 评论 -
关于产品研发管理-《培思的力量》
一、前言之前得益于公司内部也在积极探索如何做产品研发管理,在领导的推荐下看了《培思的力量》这一本书,想结合一下PACE谈谈对产品开发管理的一些个人理解。PACE(Product And Cycle-time Excellence),中文称为“产品及周期优化法”,它是美国PRTM公司在上世纪80年代中后期提出,当时主要是受到了日本公司实行了“基于准时制(JIT)”方法而取得的竞争优势所迫使美国公司所产出的一套产品开发流程。当然后来IBM基于PACE的基础上又发展出了IPD(Integra...原创 2021-01-17 10:22:41 · 2078 阅读 · 0 评论 -
共享服务中心建设原则-《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》
一、前言今天重看了《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》的第4章-共享服务体系搭建。书中所描述的共享服务中心,提到的实际上包含两个层次。 其一,底层的PaaS能力,它用于解决企业中整体系统群的架构在分布式、可用性、高可用性、实时监控等方面上的需求; 其二,通用的业务能力,我的理解实际上就是建设SaaS,目的在于将企业核心能力下沉共享,加速企业创新速度。 这里也想针对第二个:通用的业务能力的建设聊一下对它的一个理解。二、共享服务中心建设历程...原创 2020-10-07 16:51:46 · 1946 阅读 · 2 评论 -
【读书笔记二】《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》
目录第三章分布式服务框架的选择一、淘宝服务化历程二、“中心化”与“去中心化”服务第三章分布式服务框架的选择一、淘宝服务化历程截止到2007年,淘宝已经拥有超过500人的技术团队规模,整个淘宝网站是一个几百兆字节的WAR包,功能模块超过200个。几百人维护一个WAR包的模式,带来了以下几个主要问题: 项目团队间协同成本高,业务响应越来越慢。 应用复杂度已超出人的认知负载。各种业务互相交错,已经没有一个人能完全清楚每个功能或流程的细节,毕竟人的认知...原创 2020-10-02 23:42:29 · 353 阅读 · 1 评论 -
聊一下《技术力量-一线技术团队成功启示录》
一、前言最近有幸拜读了《技术力量-一线技术团队成功启示录》的第一篇-Team Leader团队管理/组织发展,该篇从组织架构、团队管理、效能提升、敏捷转型这四个方面展示了10位来自不同行业、不同领域的专家的不同看法,貌似形态各异,实则殊途同归。二、康威定律梅尔.康威于1968年提出的“任何组织在设计一套系统时,所交付的设计方案在上都与该组织的沟通结构保持一致。”,这句话就是后来的康威定律。 从微软的Office性能团队项目经理杨珂的分享中看到之所以其性能团队能够成功,我看...原创 2020-09-29 12:51:18 · 523 阅读 · 0 评论 -
【读书笔记一】《企业 IT 架构转型之道 - 阿里巴巴中台战略思想与架构实战》
目录第一章阿里巴巴集团中台战略引发的思考一、思考二、共享事业部发展史三、企业信息中心发展的症结1、“烟囱式”系统建设模式2、业务支持一直是企业信息中心的组织职能第二章、构建业务中台的基础-共享服务体系一、服务需要重用和业务滋养二、共享服务体系是培育业务创新的土壤三、共享服务体系赋予业务快速创新和试错能力四、组织矩阵改变会带来组织效能的提升第一章阿里巴巴集团中台战略引发的思考一、思考Supercell这家游戏公司真的是“神奇”的公司...原创 2020-09-01 13:52:31 · 467 阅读 · 0 评论 -
再谈引入YAPI接口平台的好处
目录前言1、团队内形成契约关系2、方便自测,真正的前后端分离,真正的“解耦”3、每日构建(Daily build)的基础4、“与时俱进”的接口文档后话前言之前说到因为复盘到团队之前的故障很多是跟接口有关的,因此近期也在团队内部引进试用YAPI这个接口管理平台。用了大概几周吧,也找了团队的同事了解了一下具体的效果。那这类平台有个什么样的好处呢?1、团队内形成契约关系我特意画了个前后对比图(个人比较喜欢可视化还有彩色系的东西,让人心情...原创 2020-08-23 14:40:25 · 1569 阅读 · 0 评论 -
【DevOps】我们忽视了Daily Build(每日构建)吗?
一、什么是Daily Build?每日构建,简而言之就是每天把当前最新的代码集合拉取下来,然后进行编译构建并进行自动化的冒烟测试,然后通过某种形式把构建结果进行系统性展示给相关干系人。这是持续集成的其中一项最佳实践,最早出现在微软,我个人认为这是放之四海而皆准的一个原则,只是不同公司的实际操作会有异同。它的目的不是在于减少构建失败的次数,而是要尽早发现问题,降低解决问题的成本。二、为什么要做Daily Build?1、可以让同事从日常工作中养成质量意识。为什么会这样说呢?实际上我翻阅过.原创 2020-08-15 18:30:57 · 2687 阅读 · 0 评论 -
【DevOps】Jenkins持续集成流水线(中)
目录前言一、集成静态代码扫描工具(FindBugs)二、集成自动化单元测试(Jacoco)1、前置条件三、集成代码质量管理平台(SonarQube)前言承接上一篇:Jenkins持续集成流水线(上)当我们的持续构建流水线的基本骨架构建完毕后,接下来我们要集成单元测试覆盖率(Jacoco)、静态代码扫描工具、及代码质量管理平台(SonarQube),通过一键构建并生...原创 2020-08-01 23:22:02 · 916 阅读 · 3 评论 -
结果【outcome】大于产出【output】
结果大于产出著者 Martin Fowler译者尘世间一个迷途小码农想象一下一个团队在编写购物网站的技术团队。如果我们在看这个团队的产出的时候,我们或许会考虑上个季度产出了多少个功能,或者一个跨功能模块的度量(如页面加载时间)。然而,一个对于结果的度量将应该考虑度量所增加的营收,或者所减少的产品支持电话数量。聚焦于结果而不是产出,将会使得团队倾向于构建那些有助于提升软件用户和客户效率的功能特性。就好像任何专业活动一样,我们这些从事软件开发的人想要了解是什么使得我们更有...翻译 2020-05-20 11:56:56 · 992 阅读 · 0 评论