Browsed by
标签：敏捷

开好回顾会议需要解决这四个问题

开好回顾会议需要解决这四个问题

Comments 0 Comment  25 Views

閱讀本文約花費: 20 (分鐘) 持续改进是敏捷的重要组成部分。无论一个敏捷团队今天多么出色，都要推动其团队成员去寻求未来变得更好的方法。而探索持续改进，正是迭代回顾会议的目的。 不幸的是，并非所有回顾会议都能实施得很好。许多团队往往很难开好回顾会议。在本文中，我将描述自己在回顾会议中看到的四个最常见问题，并提供解决问题的建议。   问题1：人们不诚实或不值得信任  对回顾会议最常见的抱怨之一是：人们没有提出真正的问题或人们不愿意承认他们的问题。如果人们不能在回顾会议上直言不讳，那么得到的评论也只能是“浪费时间”。 这或许是个真实存在的问题，但解决方案不是抛弃回顾会议，而是我们要关注如何让人们在回顾会议中变得更加诚实和开放。 您一定能采取一些措施来增强团队成员之间的诚实和互信。具体可以执行以下措施： 1）营造安全氛围 要营造安全氛围，因为只要缺乏安全感，人们就不会在回顾会议上畅所欲言。这就意味着——人们在回顾会议上说的话和发生的事都不会蔓延到会后，并且这一点已深入人心。 只要参加足够多的回顾会议，您就会偶尔看到情绪失控的情况，您还会听到不该重复出现的话语。在最近一次回顾会议上，就有一位程序员咆哮：“到底还要等多久，‘该死的DevOps组’才能执行部署工作？”。 他确实不应该那样说话。但换句话说，他能发泄出情绪，并且在发泄完后明白不能再这样与DevOps…

Read More Read More

团队间差异大，如何统一估算基准？

团队间差异大，如何统一估算基准？

Comments 0 Comment  42 Views

閱讀本文約花費: 9 (分鐘) 实施规模化敏捷时，组织管理多个Scrum团队时将面临更多的挑战。如果您已让多个团队工作于同一个项目，那么协作会变得更复杂，特别是估算的时候。 这些团队需要进行估算和制定计划，并基于计划来跟踪进度，以便PO能安排其工作优先顺序，在有成果物交付时与干系人进行交流。 但多个Scrum团队共同工作会带来更多的挑战，包括： 团队技能和经验水平都不同时，该如何处理？怎样才能在无需每位团队成员都参与的情况下准确估算工作？在不知道该由哪个团队来承接工作的情况下，怎样完成估算？ 我将与大家分享一个解决方案。但在此之前，让我们先来看看大多数组织在为多个Scrum团队做估算时都会犯的两个关键错误。   错误1：估算不能反映所有团队的能力 第一个错误往往发生在公司挑选一组人员来估算整个待办项时。这本身并不是一个坏主意（事实上稍后我会建议您这么做）。与让大团队每个人都参与每个待办项的估算相比，这样么做当然会更快、更高效。并且或许您还会认为，只要选择的人员合适，估算结果就会是富有见地的。 但这正是事情容易出错的地方，因为一旦缺乏熟悉即将开展的工作且能真正代表所有Scrum团队的人员，您就会得到基于非常片面和不准确的视角而生成的估算值。 不幸的是，目前许多公司正在发生这样的事情：估算数据由那些脱节于即将开展的工作及其实施团队的人员创建。 这样做的结果之一是：得…

Read More Read More

SpringCloud Alibaba——服务注册与发现（Nacos）

SpringCloud Alibaba——服务注册与发现（Nacos）

Comments 0 Comment  32 Views

閱讀本文約花費: 5 (分鐘) 一、Nacos简介 Nacos致力于帮助您发现、配置和管理微服务。Nacos提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。Nacos帮助您更敏捷和容易地构建、交付和管理微服务平台。Nacos是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。 安装Nacos 下载地址(版本：0.7.0) Linux：sh startup.sh? Windows：startup.cmd? 访问：http://127.0.0.1:8848/nacos，可以进入Nacos的服务管理页面： 二、SpringCloud整合Nacos 完成了Nacos服务的安装和启动之后，下面就可以编写两个应用（服务提供者与服务消费者）来验证服务的注册与发现了。 spring cloud的版本以及spring cloud alibaba的版本，由于spring cloud alibaba还未纳入spring cloud的主版本管理中，所以需要自己加入，添加依赖文件（父工程）： <properties><java.version>1.8</java.version><spring-cloud.version>Finchley.RELEASE</spring-cloud…

Read More Read More

如何写出无法维护的代码

如何写出无法维护的代码

Comments 0 Comment  66 Views

閱讀本文約花費: 17 (分鐘) 酷壳里有很多我觉得很不错的文章，但是访问量最大的却是那篇《6个变态的Hello World》，和它能在本站右边栏“全站热门”中出现的还有“如何加密源代码”，以及编程真难啊等这样的文章。可见本站的读者们的偏好，我也相信你们都是“身怀绝技”的程序员。所以，今天给大家推荐这篇文章，相信一定能触动大家的兴奋点。 这篇文章的原文在这里（http://mindprod.com/jgloss/unmain.html），我看完后我想说—— 什么叫“创造力”，创造力就是——就算是要干一件烂事都能干得那么漂亮那么有创意的能力。什么叫“抓狂”，抓狂就是——以一种沉着老练的不屈不挠的一本正经的精神一点一点把你推向崩溃的边缘。 我把文章节选了一些，也并没有完全翻译，简译一下，也加入了一些自己的调侃。对于有下面这些编程习惯的朋友，请大家对号入座。另外，维护程序的朋友们，你们死定了！！ If builders built buildings the way programmers write programs, then the first woodpecker that came along would destroy civilization. （如果建筑师盖房子就像程序员写程序一样，那么，第一只到来的啄木鸟就能毁掉我们的文明）~ Gerald Weinberg&…

Read More Read More

《microservice & serverless》的一点感想

《microservice & serverless》的一点感想

Comments 0 Comment  50 Views

閱讀本文約花費: 6 (分鐘) 超哥是来自Amazon的顶级的架构师，经历了Amazon整个向微服务架构迁移的过程，以及向serverless的演化过程，有着极其丰富的经验，年过40，一直站在技术的最前沿，始终保持对技术的执着追求和热情，是名副其实的技术大牛，能与之一起工作，荣幸之至！今天超哥给我们分享的主题《microservice & serverless》，是超哥实际工作经验的一些分享，也为公司架构的演化提供了新的思路和指导。 microservice（微服务）这个可能是这些年最火的一种架构设计了，频繁地出现在各种技术大会上，各大互联网巨头纷纷向这种架构演化，很多小的互联网公司也往这些概念上去靠，大有一种不做微服务就要落伍的趋势。事实上，很多对于微服务的理解比较粗浅，盲目的微服务化甚至会带来更多的负面影响。 目前Amazon内部运行着超过2w过微服务，但是这些微服务并不是凭空产生的，在这之前，运行的服务都是超大的单体服务，但是随着业务的发展，这种服务在整个研发的pipeline（设计→研发→编译→测试→发布→部署→运维）中都出现了一些问题。设计阶段，老的单体服务会给我们带来一些技术限制，比如有些技术只有python语言的实现，但是我们的服务使用java开发，这样我们不得不拿出一个更复杂的设计去解决类似的问题；研发阶段，随着开发人数越来越多，代码冲突的问题越来越多，我们…

Read More Read More

阿里玄难：面向不确定性的软件设计几点思考

阿里玄难：面向不确定性的软件设计几点思考

Comments 0 Comment  30 Views

閱讀本文約花費: 19 (分鐘) 在纷繁复杂的业务发展中，变化已成为了唯一的不变。如何保障基础设施的安全、高可用性，同时提供高效的创新支持？今天，阿里副总裁、业务平台事业部掌门人玄难，结合阿里巴巴业务平台建设和个人多年大型软件设计经验，提炼成几点思考，希望对大家的软件架构设计有所启发。 玄难 阿里副总裁 业务平台事业部掌门人 特别说明：本文中所说的软件都指代面向最终用户的偏业务的软件，不包含操作系统、中间件等系统软件。 1、软件发展的几个阶段 软件工具和信息化阶段：软件最早是为了数值计算，以工具的形态出现的。包括PC时代我们非常熟悉的Excel，Word这些好东西。以及典型的企业内部管理的信息系统，例如：企业流程审批、进销存管理系统等等。互联网服务阶段：随着PC互联网兴起，淘宝、QQ、Google、新浪这些全新的互联网服务逐步进入了我们的日常生活。社会基础设施阶段：随着移动互联网、IOT、人工智能的出现和高速发展，各种各样的软件进入社会经济生活的方方面面，软件之间相互连接，构成了一个纷繁复杂的生态系统，变成了不可或缺的社会基础设施。 随着软件形态的变化，过去非常高效的系统架构和组织形态遇到了全面的挑战。因为我们所处的环境已经从量变到质变，突破临界点，产生了本质的不同。 阿里巴巴就是这个过程中的典型代表。从过去单一的电商业务演变成了复杂的经济体，没有了确定性的业务边界，蓬勃发展的业务…

Read More Read More

深入浅出了解 OKR（十）：OKR 在敏捷转型中的实践

深入浅出了解 OKR（十）：OKR 在敏捷转型中的实践

Comments 0 Comment  36 Views

閱讀本文約花費: 12 (分鐘) 敏捷转型（数字化转型）是现在非常多的传统企业加快“上线”的有力抓手，也是传统企业在现代竞争中必须要迈出的一步，否则无法适应激烈的竞争。 我在企业敏捷转型里，经常使用的是我自己总结的一个“组织敏捷转型地图”和“团队敏捷转型地图”模型，并以此为核心内容在 2019 年北京的的 Regional Scrum Gathering 大会上做了名为《团队黑客》的主题分享。 未来组织 我对未来组织有自己的想法，未来组织一定是“业务敏捷化”、“管理游戏化”和“组织社区化”三位一体的。要达到这个理想状态，必然经历组织敏捷转型和团队敏捷转型。 组织敏捷转型地图 在“组织敏捷转型地图”中，我定义了组织达到敏捷组织会有 5 个大的阶段： 组织转型 这个阶段组织开始启动转型工作，组织开始进行动员，做一些组织、架构等方面的调整和变化，企业文化也会被重新定调。 业务重构 组织转型的动机大部分都是战略驱动的，但是落地一定会回归到业务上，业务存在的方式、方向都会有一些变化，这个时候对业务的梳理、重构、定义就非常重要。要找到重点突破的业务，也要对业务的北极星指标、衡量体系产生明确的定义。 产品创新 业务重构后，产品方面的调整和创新也会随之而来，业务会被分解到不同的产品上去实现，各种产品规格就会确定下来。同时在产品层级也会要求进行不同的组合、融合和创新，某些项目型的团队，也会走向产品化…

Read More Read More

深入浅出了解 OKR（九）：OKR 和 Scrum 共舞

深入浅出了解 OKR（九）：OKR 和 Scrum 共舞

Comments 0 Comment  32 Views

閱讀本文約花費: 9 (分鐘) 作为熟悉敏捷的高手，你也许已经发现 OKR 在很多方面和我们熟悉的 Scrum 有非常多的理念和做法高度重合。 现在可以拿出一张纸一支笔，尝试自己做一下分析，有多少是类似的，有多少是有不同的，有什么可以做融合，然后再看看和我的分析有多少差异。 Scrum 的困境 在使用 Scrum 的时候，我们会经常碰到如下的挑战吗？团队只聚焦功能和任务，而不关注价值产品发展和公司战略脱节团队总是忙于紧急的事情，重要的事情优先级很低团队对价值认可不直接，需要 PO 做转化产品的结果（Output）难以说明白，只能通过进度的衡量团队一直进行开发，团队的成果（Outcome）难以衡量，取得的效果道不清说不明 问题来自于哪里呢？我们看看下图，核心要回答几个问题： 战略落地为什么会是瓶颈？产品和特性的敏捷解决了什么问题？PO 的位置在哪里？团队向上看的视角触达的层级是哪里？ 大部分团队都是“近视眼”，视角都被限制在了“产品”和“特性”层，使得团队对于业务不熟悉，对战略不清楚。产品和特性层级的敏捷，只能解决交付问题，提升产品的响应能力，但业务层级的敏捷，非常难达到。大部分的 PO，都是“产品设计”角度出发，是“产品设计师”和“产品管理者”，都很难触达战略，做到真正的“产品拥有者”。 如何破局呢？好的 PO 可遇不可求。使用“规模化敏捷”框架，看起来能够触达，但是挺复杂，学习成…

Read More Read More

深入浅出了解 OKR（八）：OKR 的催化剂：持续性绩效管理 CFR

深入浅出了解 OKR（八）：OKR 的催化剂：持续性绩效管理 CFR

Comments 0 Comment  35 Views

閱讀本文約花費: 11 (分鐘) 我们已经看到了 OKR 的威力，但是学习到的还仅仅只是 OKR 的外在形式，接下去我们要看看 OKR 的内在。 OKR 的核心假设有 2 个： 公司的中长期目标（以年\季度为代表）是正确的员工的内驱动力是被激发出来的 目标设定的正确性是 OKR 无法保证的，但是内驱动力却可以通过 CFR 的框架来促动。CFR 是持续性绩效管理（Continuous Performance Management，CPM）的实现工具，代表了对话，反馈，认可，其中： 对话（Conversation）：管理人员与员工之间真实的、高质量的交流，旨在对绩效提升起到驱动作用。反馈（Feedback）：同事之间面对面进行双向沟通或通过网络进行交流，以评估工作进展情况并探讨未来的改进方向。认可（Recognition）：根据个体所做贡献的大小施以对等的表扬，表彰。 所谓的持续性绩效管理是区别于传统绩效管理的。传统绩效管理通常按照年度进行，划分为如下几个环节： 绩效计划绩效辅导绩效考核绩效面谈绩效改进 但在实际执行中，往往就剩下了所谓的绩效考核，绩效考核中又是以 KPI 为代表，这样 KPI 就成了绩效管理的代名词。传统绩效管理的周期长，成本高，绩效提升效果差。再加上来自通用 GE 的“强制分布”，很多公司每年都会进行“降薪”和“淘汰”，这更让绩效管理声名狼藉。 绩效管理从根本上说，…

Read More Read More

深入浅出了解 OKR（七）：OKR 导入，如何让组织和团队高效使用

深入浅出了解 OKR（七）：OKR 导入，如何让组织和团队高效使用

Comments 0 Comment  26 Views

閱讀本文約花費: 8 (分鐘) 我们对 OKR 的有了基本认知后，接下去我将带领大家讨论几个深度话题，主要讲几个内容： OKR 导入：如何在团队和组织层级导入 OKR，如何完成试点、过渡和推广阶段；CFR 应用：CFR 如何与 OKR 共同作用，提升团队的内驱力；OKR 与 Scrum：OKR 和 Scrum 有非常多的相似点，如何让 OKR 和 Scrum 进行融合？OKR 与敏捷转型：敏捷转型中 OKR 能够带来的作用和效果是什么？带来什么样的价值？ OKR 的应用其实是在各个层级都可以用的，从个人的尝试，团队级的使用，到部门层级或者组织层级都是可以的，并没有什么严格的限定和顺序。 中大型企业 OKR 落地方案可以有多种多样的方式： 整个公司范围；在公司及高层管理者团队；试点团队先行再推广；个别事业部或者团队单独的项目上； 但是在部门层级和组织层级的使用，需要获得的支持和资源是不同的，这里我们一般称为“导入”过程。 在组织层面导入时，和大部分的变革和改进一样，为了降低失败的概率，我们基本上在开始时采用“试点”方式，在一个团队范围内先开始尝试使用，然后取得效果和认可后，再向部门层级进行多团队的试点。在试点完成后，如果高层对于效果认可，可以进一步的进行向全员的推广。 如果没有十足的转型经验和把握，不推荐从上到下的一次性转变，这个过程的混乱和资源消耗是很多组织层面导入 OKR 失败的…

Read More Read More