1.用 Burndown Chart（燃尽图）可视化项目进展​

燃尽图用于衡量工作进度，它反映的是完成的工作量以及剩余的工作量之间的关系。

下面是一个简单的燃尽图示例，这里为了简单起见，假设总共有 100 个任务项要完成，需要 10 天的时间来完成它们。用纵轴表示 100 个任务项，用横轴表示 10 天。

对于任何一项工作，最理想的方式是每天以一致的速率进行。在这种情况下，意味着每天要计划完成 10 个任务（10天*10个任务等于100个任务总数）。

实际上，如果第一天只完成了五个任务，第二天完成了四个任务，第三天完成了两个任务，则进度落后于计划，因为实际完成数少于了计划数，后续团队需要努力赶上，在接下来的几天里，会完成比原计划更多的任务，在项目结束时，燃尽图可能会如下所示：

2. 更实际一点的示例​

• 横坐标表示一个时间周期，这里表示一个 sprint 周期（15天）
• 纵坐标：左坐标轴表示待完成的工作量，右坐标轴表示每日完成的工作量（小时数或故事点数）
• 三条折线：
  • Ideal Trend（绿色）：理想线，假设按照固定速率每天完成 25 （小时或故事点）的趋势线。
  • Remaining Effort（Actual）（蓝色）：实际的完成工作进度。
  • Trend Line（Actual）（红色）：实际完成工作进度的趋势线。
• Daily completed：实际每天完成的工作。
• 在第7天之前，蓝色线在绿色线上方，表示开发进度落后。从第7天蓝色线在绿色线下方，表示进度逐步追赶上来。

3. 燃尽图的类型​

有几种类型的燃尽图常用于敏捷项目管理：

• Sprint 燃尽图：这种类型的燃尽图跟踪一个 Sprint 中剩余的工作。它帮助敏捷团队在短迭代期间监控他们的进度，并确保他们在设定的时间范围内按计划完成 Sprint 目标。
• 产品 Backlog 燃尽图：与 Sprint 燃尽图不同，产品燃尽图表示整个项目剩余的总体工作。它提供了项目维度进度的视图，并帮助项目经理和团队跨多个 Sprint 或迭代跟踪工作的完成情况。
• 发布燃尽图：显示了产品发版的所有计划功能和需求的进度。

4. 燃尽图有什么好处？​

• 监控工作进度：允许敏捷团队跟踪项目的所有剩余工作并预测何时完成。
• 告警：当偏离计划发生时提醒团队，以便及时采取纠正措施。
• 决策影响：显示项目期间做出的决策的效果，并为未来的决策提供信息。
• 沟通：促进团队和利益相关者内部的进度沟通，确保每个人都了解情况。
• 估计：帮助根据当前进度和趋势估计工作何时完成。
• 动机：通过展示进度和提供绩效反馈来鼓励团队成员表现得更好。
• 透明度：通过明确比较计划和实际进展来提高透明度。
• 协作：通过让每个人在项目状态和目标上保持一致来促进有效的协作。

5.燃尽图的局限性是什么？​

燃尽图的其它局限性还包括：

• 工作质量：燃尽图不能反映已完成工作的质量，因为它们只关注已完成任务的数量。
• 具体挑战：它们可能不反映项目期间遇到的具体挑战，这些挑战可能会影响整体进度。
• 复杂性：一些项目可能过于复杂，以至于燃尽图无法有效跟踪进度，尤其是当团队要求严格遵守敏捷方法时。
• 团队成员的压力：如果进度慢于预期，燃尽图会产生过度的压力，影响团队士气和动力。
• 学习曲线：对于刚接触敏捷方法的团队来说，学习使用燃尽图在敏捷框架内准确估计工作和管理任务可能需要时间并引入复杂性。

6. 燃尽图和燃起图（Burnup Chart ）的区别​

主要区别在于它们如何表示项目进度。

• 红线表示总的工作量，可以看到第6天的时候，发生了变更，总的工作量由 100 变到了 120。
• 绿线表示当前完成的工作量，最后项目完成时，两条线应该相交。

7. 敏捷和看板方法相关书籍​

• Learning Agile: Understanding Scrum, XP, Lean, and Kanban 1st Edition December 23, 2014
• Lean from the Trenches: Managing Large-Scale Projects with Kanban 1st Edition December 21, 2011
  • 精益开发实战:用看板管理大型项目 2012-09-01
• Kanban: Successful Evolutionary Change for Your Technology Business Blue Book ed. Edition April 7, 2010
  • 看板方法：科技企业渐进变革成功之道 2014-02-01

1. 用 Cumulative Flow Diagram（累积流图）可视化项目进展​

我们希望团队尽可能高效地工作，但是掌握事情的真正进展可能很有挑战性。累积流图是敏捷、精益、Scrum、看板和 SAFe 方法中使用的管理工具，用于随时间可视化和分析工作项流程。可以直观的了解团队的工作情况，以便可以弄清楚如何改进它。

2. 累积流图示例​

下面是一个累积流图的示例

累积流图纵轴（表示任务或工作项）、横轴（表示时间间隔）、不同的彩色线或带（表示各个开发阶段）

3. 累积流图可以反映的指标​

有四个主要的指标是我们应该关注的，通过了解和跟踪这些指标，可以识别流程效率低下的地方并进行改进。

• Lead Time 交货时间，任务从流程开始到完成的时间。它是一个重要的指标，因为它揭示了瓶颈在哪里，并提高了交付的可预测性。假设您在晚上8:00下了晚餐订单，您的订单在晚上8:30送达。在这种情况下，您的交货时间是30分钟。这是从您提出请求的那一刻起到您收到请求的这段时间。
• Cycle Time 周期时间，是完成一个任务花费的时间。假设厨房在晚上8:10收到了，厨师开始准备你的订单。你在晚上8:30收到食物；在这种情况下，你的周期时间是20分钟。这是处理你的订单所需的实际时间。
• WIP（Work in progress）进行中的工作（在制品）
• Throughput 吞吐量，团队在指定时间段内交付了多少工作

参考​

[1] Lead time and Cycle Time and the importance of Flow in Kanban
[2] Kanban Metrics: An Overview of the Most Important Kanban System Metrics to Track
[3] Cumulative Flow Diagram
[4] How to read a cumulative flow diagram
[5] What Is a Cumulative Flow Diagram?
[6] [PDF]The Ultimate Guide To Reading The Cumulative Flow Diagram

在项目实施过程中，会在各个时间阶段有各种可能的事项要与客户进行沟通或者谈判，通常可能主要是下面几项：

• 开发报价
• 交付里程碑与时间进度
• 系统的设计、架构、解决方案或技术实现方式
• 需求范围变更
• 日常工作的方式

需求范围变更，通常是这些事项中最主要的，也是对项目顺利交付影响最大的因素。

在与客户沟通谈判时，有一些原则、方式或方法可以遵循。

1. 定义明确的界限​

在项目启动阶段要与客户对一些基础事项形成一致意见，例如：系统的功能目标、总体的里程碑计划、处理接受变更的流程、验收的标准、输出的交付物等。与客户达成一致，这样就有了一个基础的界限边界。

在与客户进行沟通时我们就有了一个这样的基础。如果客户要求更改，要参考这些文件。根据项目的目标、时间来评估。这不是对客户说不，而是引导客户理解所涉及的影响，双方一起来做权衡。

2. 了解客户需求，提供替代方案​

可以通过提出开放式问题、积极倾听和总结客户的想法。仔细审查他们的要求、时间和预算，并澄清任何模棱两可或理解上的偏差。了解客户的需求将有助于使自己的建议与他们的期望保持一致，并向客户展示价值和可信度。

在对范围变更做出任何决定之前，评估它们对项目的影响。考虑这些变更将如何影响进度、资源和最终产品的质量。提议的变更是否与项目目标一致，是否值得额外的时间和精力。如果影响太大，可能需要找到一个折衷方案，在不过度资源投入的情况下满足项目目标。

面对迫在眉睫的最后期限，要确定任务的优先级。必须确定哪些功能或任务对项目的成功至关重要，哪些可以推迟或完全放弃。与客户一起根据任务的紧迫性和重要性对任务进行分类。这将指导我们就范围变更做出明智的决定。

当客户要求更改时，必须传达这将对项目时间进度和成本资源产生的影响。解释一个更改可能对项目的各个方面产生的连锁反应。使用清晰的非技术语言来阐明为什么更改可能需要额外的时间或预算。通过使后果具体化，客户更有可能理解额外资源或时间调整的必要性。

提供一个替代的方案，也许可以在系统上线以后的运行阶段再考虑逐步引入新的功能，也许那时的想法会跟现在不同。或者在产品的下一期开发中对其进行改进。与客户一块寻找可能的解决方案。

也许最终我们可以同意这些额外的变更工作，但要协商延长最后期限或额外付款来支付额外的工作。这期间是有非常多的谈判技巧可以运用（参见下面小节 5. 学习利用一些谈判技巧）。

3. 寻求客户高层利益相关者的支持​

客户的高层利益相关者才是对项目具有决定权，要让高层利益相关者充分了解项目当前的情况，了解其真实的想法，并寻求支持。

4. 寻求商务支持​

最后，也需要保持一定程度的灵活性。在软件项目管理中，变化通常是不可避免的。虽然管理范围变化很重要，但过于僵化会给客户关系带来不好的影响。

当处于僵局时，需要寻求商务支持，大量事实表明，事情在商务层面沟通时，仿佛进入了另一个维度，很多难题也有了解决办法。

5.学习利用一些谈判技巧​

罗杰·道森（Roger Dawson）作为国际首席商业谈判大师，以其丰富的谈判经验和深刻的洞察力，创作了广受欢迎的谈判指导书籍《优势谈判》。这本书不仅在全球销量超过1000万册，而且被广泛应用于各种商业和日常谈判场合。

书中介绍了一些谈判技巧，以下是部分标题摘录:

开局谈判技巧

• 开出高于预期的条件：强调在谈判开始时提出高于自己期望的条件，以争取更多的谈判空间。
• 永远不要接受第一次报价：阐述为何不应立即接受对方的首次报价，并探讨如何有效应对。
• 学会感到意外：通过表现出对对方条件的惊讶，来影响对方的谈判策略。
• 避免对抗性谈判：倡导通过合作而非对抗的方式来解决分歧。
• 不情愿的卖家和买家：利用“不情愿”的策略来增强自己的谈判地位。
• 钳子策略：通过要求对方做出改变来逐步缩小双方的差距。

中场谈判技巧

• 应对没有决定权的对手：识别并应对那些没有最终决策权的谈判对手。
• 服务价值递减：讨论在谈判过程中逐步减少让步的价值。
• 绝对不要折中：解释为何折中往往不是最佳解决方案，并探讨更有效的策略。
• 应对僵局：提供解决谈判僵局的方法和技巧。
• 应对困境：讨论在谈判中遇到困境时的应对策略。

终局谈判策略

• 白脸—黑脸策略：分析并应对这种常见的谈判技巧。
• 蚕食策略：在谈判即将结束时提出小要求，以逐步达到自己的目标。
• 如何减少让步的幅度：探讨在谈判中如何以最小的让步换取最大的利益。
• 收回条件：在必要时收回之前提出的条件，以重新掌握谈判的主动权。
• 欣然接受：学会在适当的时候接受对方的条件，以达成双赢的谈判结果。

在 Kubernetes 中不提供负载均衡的实现，网络负载均衡器的实现依赖于云厂商（阿里云、腾讯云、华为云、AWS、Azue 等），如果是自建集群，而不是选择这些公有云厂商提供的 Kubernetes ，在创建 Service 时，我们只能使用类型是 NodePort 和 ExternalIPs 的服务用做外部访问。

我们希望自建集群也能简单便捷的方式对集群外部暴露服务，MetalLB 这个项目正是为了解决这个问题。

先决条件​

安装前有几个先决条件需要查看，特别是网络插件（CNI）的兼容性支持。

官网的安装文档 MetalLB Installation

安装​

修改 kube-proxy 参数

kubectl edit configmap -n kube-system kube-proxy

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
  strictARP: true

安装MetalLB

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.8/config/manifests/metallb-native.yaml

查看命名空间下的组件都正常运行

kubectl get all -n metallb-system

定义要分配给负载均衡器服务的IP地址并配置 2 层通告。

sudo cat > metallb-config.yaml << EOF
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
  - 10.10.0.150-10.10.0.200
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: example
  namespace: metallb-system
EOF

kubectl apply -f metallb-config.yaml

测试​

kubectl create deployment nginx --image=nginx
kubectl expose deployment nginx --type=LoadBalancer --port=80

# 可以看到这里分配的地址是 10.10.0.150
kubectl get svc

curl http://10.10.0.150

参考​

[1] 创建外部负载均衡器
[2] 组件工具 kube-proxy
[3] IPVS vs. IPTables for kube-proxy in Kubernetes
[4] Comparing kube-proxy modes: iptables or IPVS?