分类目录敏捷管理

敏捷事关“整体团队”经验。我们在一起做计划、在一起编码、在一起测试、在一起检视过去，以便团队中的每一个人都能达成一致的共识。然而，随着项目增大，团队开始迷失在大堆的用户故事里，很难让每个人都能看到相同的全景图（big picture）。本文讨论了可视化全景图的各种方法。不仅可用于负责人和管理者，更可以用于每一个人。

在理想的情况下，敏捷团队应该针对当前迭代提出清晰的计划，而后续的发布计划可以较为粗略。而事实上很多情况是，团队在当前迭代只是急于实现下一步的小创意。他们完全忽略了全景图。通常会有这样一种情况：这张图保存在一个角色的脑中，比如团队领导、业务分析师、项目经理、产品经理、甚至是ScrumMaster。这往往是由于他或她没有真正地推动自组织所导致的。这一现象在某些情况下还是可以接受的，比如一个不重要的短期项目，但在许多情况下，这会造成恶劣的后果，当团队偏离轨道时他们也什么也察觉不到，因为他们觉得所有的工作都还在正常地运转。

阅读更多

什么是敏捷？

敏捷是创造并响应变化的能力。这是应对不确定的动荡环境并最终在其上成功的一种方法。

敏捷宣言的作者选择“敏捷”作为整个概念的标签，因为该词代表了对变化的适应性和响应性，这对他们的方法非常重要。

这实际上是在考虑如何才能理解当今环境中的情况，确定面临的不确定性并弄清楚如何适应这种情况。

什么是敏捷软件开发？

敏捷软件开发不仅仅是诸如Scrum，极限编程或功能驱动开发（FDD）之类的框架。

敏捷软件开发不仅限于结对编程，测试驱动的开发，站立，计划会议和冲刺等实践。

阅读更多

Below are the guiding practices that support teams in implementing and executing with agility:

阅读更多

| 何为技术领导力

技术领导力是什么呢？就一句话：带领团队承担企业经营使命。这句话的核心在于三点：

第一，是使命必达。何谓使命必达，就是这个问题到你这里，就必须终结掉，如果是你的问题，即使很困难，也要搞定，不要找客观理由；如果不是你的问题，你协同其他人也要搞定，最终你呈献给用户的，不是说这个问题是别人的问题，你去找他吧，我帮你们搭线，而是要通过你的努力，通过你协调各方之后解决问题的结果，把最终的结果给到你的用户。

其实当你把事情往外推的时候，你也在把你的职业机会也在往外推，比如你是一个系统或者一个产品的 Owner，如果只是关注自己的本身，几年后有可能你的视野和格局还是停留在这个系统或者产品本身上，但是如果你平时习惯于关注上下游系统，关注整个产品生态，关注公司的整个战略是什么？你做的事情处在战略的那个环节，你要解决这个问题，你需要协同那些干系方，需要什么样的配套资源来解决，你将会成长的非常快。

阅读更多

敏捷设计实践

从高级架构实践到低级编程实践，有一系列敏捷设计实践，参见图1。 这些实践中的每一个都很重要，如果您的团队要在敏捷设计方面有效，则每个实践都是必需的。

图1.敏捷设计实践。

阅读更多

1. What is TDD?

The steps of test first development (TFD) are overviewed in the UML activity diagram of Figure 1.  The first step is to quickly add a test, basically just enough code to fail.  Next you run your tests, often the complete test suite although for sake of speed you may decide to run only a subset, to ensure that the new test does in fact fail. You then update your functional code to make it pass the new tests. The fourth step is to run your tests again. If they fail you need to update your functional code and retest. Once the tests pass the next step is to start over (you may first need to refactor any duplication out of your design as needed, turning TFD into TDD).

Figure 1. The Steps of test-first development (TFD).

 

I like to describe TDD with this simple formula:

  TDD = Refactoring + TFD.

TDD completely turns traditional development around. When you first go to implement a new feature, the first question that you ask is whether the existing design is the best design possible that enables you to implement that functionality. If so, you proceed via a TFD approach.  If not, you refactor it locally to change the portion of the design affected by the new feature, enabling you to add that feature as easy as possible. As a result you will always be improving the quality of your design, thereby making it easier to work with in the future.Instead of writing functional code first and then your testing code as an afterthought, if you write it at all, you instead write your test code before your functional code.  Furthermore, you do so in very small steps – one test and a small bit of corresponding functional code at a time.  A programmer taking a TDD approach refuses to write a new function until there is first a test that fails because that function isn’t present. In fact, they refuse to add even a single line of code until a test exists for it.  Once the test is in place they then do the work required to ensure that the test suite now passes (your new code may break several existing tests as well as the new one).  This sounds simple in principle, but when you are first learning to take a TDD approach it proves require great discipline because it is easy to “slip” and write functional code without first writing a new test.  One of the advantages of pair programming is that your pair helps you to stay on track.

阅读更多

Agilists want to develop software which is both high-quality and high-value, and the easiest way to develop high-value software is to implement the highest priority requirements first. This enables them to maximize stakeholder ROI. Because requirements change frequently you need a streamlined, flexible approach to requirements change management: In short, agilists strive to truly manage change, not to prevent it. Three versions of this practice are presented:

• Product backlog (Scrum)
• Work item list (Disciplined Agile)
• Option pool (Lean)

1. Product Backlog: Simplistic

Figure 1 overviews the Scrum approach to managing requirements where your software development team has a stack of prioritized and estimated requirements which need to be addressed (Scrum calls this prioritized stack a “product backlog”). There are several important points to understand:

• New requirements are prioritized by your project stakeholders and added to the stack in the appropriate place.
• Fundamentally a single person needs to be the final authority when it comes to requirement prioritization. In Scrum, and Disciplined Agile Delivery (DAD) which adopts this role from Scrum, this person is called the product owner.
• Although there is often many project stakeholders, including end users, managers, architects, operations staff, to name a few and the product owner is responsible for representing them all.
• The stack/backlog is initially filled as the result of your requirements envisioning efforts at the beginning of the project (in Scrum they call this “populating the backlog”).
• Each iteration (a “sprint” in Scrum terminology) your team pulls an iteration’s worth of work off the top of the stack and commits to implementing it by the end of the iteration.
• Your project stakeholders have the right to define new requirements, change their minds about existing requirements, and even reprioritize requirements as they see fit.
• Stakeholders are responsible for making decisions and providing information in a timely manner. On some projects a business analyst, often in the role of product owner, may take on this responsibility. Whoever is in this role will need to work together with the other stakeholders to ensure everyone is represented fairly, often a difficult task.
• The priorities of non-requirement work items are either negotiated by the team with stakeholders or are addressed as part of slack time within the schedule. Many Scrum teams are now putting more than just requirements, such as defects, on their backlogs.

Figure 1. Scrum requirements management.

2. Work Item List: Disciplined Agile

The approach depicted in Figure 1 is fairly simplistic, a reflection of what I would consider agile construction level thinking. Figure 2 overviews a more disciplined approach which extends the approach described above to managing the work items. This approach is the default suggested by Disciplined Agile Delivery (DAD) both of which reflect the real-world realities faced by agile delivery teams. There are a few interesting improvements that you should consider:

• Go beyond functional requirements. We know that we do more than just implement new requirements each iteration, we often do non-requirement related work such as take training, review products of other teams, address defects (I believe that defects are simply another type of requirement) and so on. The point is that more than just requirements need to be on the stack, we really need work items.
• Take a risk-value approach. Disciplined agile teams recognize that there are common risks faced by development teams, risks which they want to address as soon as possible. Such risks include the need to come to stakeholder consensus early in the project, a risk which can be addressed through requirements envisioning and perhaps the development of a shared vision or project charter. Another common risk is the need to prove that your architecture strategy, identified via architecture envisioning, actually works. The most effective way to do this is to prove your architecture with working code by building an end-to-end skeleton, or steel frame, for your system which addresses the major technological risks faced by your team. Disciplined Agile Delivery (DAD) teams will look at their work item stack early in the project, typically during the Inception/”iteration 0“/”sprint 0” part of the project to identify requirements which exhibit these technically risky features. If these requirements aren’t at the very top of the stack, and they often are because risk and reward (value) have a tendency to be co-related, then they discuss the issue with their product owner and see if they can motivate that person (who is responsible for prioritization) to move those requirements to the top of the stack too. If a high-risk requirement is currently near the bottom of the stack then you should question whether that requirement is actually needed because chances are good you’ll never actually get around to working on it as higher priority work will always take precedent.
• Model a bit ahead. Because we know that all requirements, let alone work items in general, are not created equal we shouldn’t naively assume that we should just wait to pull an iteration’s worth of work off the top of the stack at the beginning of the iteration. What if a work item is very complex, requiring a bit more thinking that what generally occurs in iteration planning sessions? Disciplined agile teams will adopt the Look-Ahead Modeling practice and look an iteration or two down the work item stack and invest the time to explore complex upcoming work items to reduce their overall project risk. Modeling a bit ahead is called backlog grooming in Scrum, revealing some of the unnecessary conceptual coupling amongst practices in Scrum.

Figure 2. Disciplined agile work management process.

3. Option Pool: Lean

阅读更多

与流行的看法相反，架构是敏捷软件开发工作的一个重要方面，就像传统的工作一样，并且是扩展敏捷方法以满足现代组织的现实需求的关键部分。但是，规模敏捷的架构方式与传统主义者的方式略有不同。本文讨论以下问题：

1.迈向敏捷架构

体系结构提供了构建系统的基础，体系结构模型定义了体系结构所基于的愿景。架构的范围可以是单个应用程序，应用程序系列，组织，或许多组织共享的Internet等基础架构。

阅读更多

什么是MVP

MVP的概念是Eric Ries 《精益创业》里提出的概念。简单地说，就是指开发团队通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段。MVP对于创业团队来说是很重要的，可以快速验证团队的目标，快速试错。

创业后才真正接触并实践MVP原则的。在我理解里MVP有四个要素：

要抓住核心流程，MVP是一个过程

MVP要求我们抓住最核心的产品流程，剥掉多余的功能或者高级功能，只要主流程可以跑起来可以。完美并不是我们的目标，尽快得到用户的反馈才是我们的目标。

MVP并不是回答产品设计是否优雅，技术是否高效这样具体的功能问题，而是用来验证产品是否被用户接受，是否有人愿意为产品买单

那什么是最核心的产品流程？这要结合我们产品的核心目标来看。譬如一款电商产品核心目标就是让用户在产品上下单买东西。那核心流程就可能是：进入产品——挑选商品——下单付款——查询物流信息。那就围绕这个流程，剥离多余的高级功能（分享啊，评论啊，个性化推荐啊，积分啊这些都不要做）做一款MVP产品。

从这点来看，MVP不是一个产品，而是一个过程。不同阶段的MVP特点有所不同，关注的目标，甚至用户都可以不同。

阅读更多

在项目或者产品的交付与实施过程中，我们会遇到各样各样想得到，想不到的问题，从历史统计上来看，一大半的项目最终都以延期或者失败告终。如何做到风险的识别、预估、防范成了每个管理人员必须要经历的坎。

在项目管理中，通常会有几种核心风险：

• 生产率也即人均产出的变化（计划和实际操作之间的差距）；
• 项目需求范围的不断变更（初始协议以外的大量附加的需求）；
• 验收标准的不同理解（干系人对需求的共识的缺失）；
• 内部交付流程的缺陷（对任务工期的错误评估、低效工作方法的引入）；
• 核心人才的不断流失（人力资源的流失）。

这里来谈一谈风险的识别。

阅读更多

第一次接触敏捷是2000年初在摩托罗拉的项目中，想起那时候的结对编程，到现在回想起来仍然觉对对自己的帮助很大。后来陆陆续续经历过各种开发管理过程，究其本质，大都相似。

一、极限编程

极限编程（ExtremeProgramming，简称XP）是由KentBeck在1996年提出的。极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

1.1、XP的核心价值

XP的核心价值观是沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）、谦逊（Modesty）。 XP用“沟通、简单、反馈、勇气和谦逊”来减轻开发压力和包袱；无论是术语命名、专著叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。

阅读更多

在一家公司的技术部门或者在一家技术公司中，Code Review和测试一样，估计是最不受待见的东西了，大家都认为它很重要，可就是不愿意或者做不好。资深的瞧不上资历潜的，潜意识中息的代码是最好的思维总在作祟。

于我观察到的大部分软件开发团队来说，认真做Code Review的很少，有的流于形式，有的可能根本就没有Code Review的环节，代码质量只依赖于事后的测试。也有些团队想做好代码审查，但不知道怎么做比较好。

Code Review有什么好处？

很多团队或个人不做Code Review，根源还是不觉得这是一件有意义的事情，不觉得有什么好处。这个问题要从几个角度来看。

团队知识共享

一个开发团队中，水平有高有低，每个人侧重的领域也有不同。怎么让高水平的帮助新人成长？怎么让大家都对自己侧重领域之外的知识保持了解？怎么能有人离职后其他人能快速接手？这些都是团队管理者关心的问题。

阅读更多

什么是敏捷软件测试

敏捷测试的定义

Wikipedia对敏捷测试的定义：Agile testing is a software testing practice that follows the principles of agile software development.[1]

译文：敏捷测试是一种遵循敏捷软件开发原则的软件测试实践。这是通过一种敏捷的做事方法，可以让团队协作更紧密、工作效率更高，确保以可持续的速度频繁地交付客户所期望的业务价值。

敏捷测试与传统测试的区别

传统模式是把软件开发分为软件需求、软件开发（设计&编码）、软件测试、软件发布等阶段，一般利用里程碑的方式对各阶段进行明确定义。软件测试是研发过程中的一个阶段，而且一般都属于项目的最后阶段；测试团队都是立场比较明确，与团队之间的沟通以正式为主；测试以需求为依据，要求有需求规格，自动化测试不作为要求；测试计划做得比较详细，对测试活动都会做好周密的安排；需求方确定需求后，中间环节参与较少。

阅读更多

背景

工程师主要面对的是技术挑战，更关注技术层面的目标。研发团队的管理者则会把实现项目成果和业务需求作为核心目标。实际项目中，研发团队所需资源（比如物理机器、内存、硬盘、网络带宽等）的成本，很容易被忽略，或者在很晚才考虑。

在一般情况下，如果要满足更多的技术指标如并发量和复杂度等，或者满足峰值业务的压力，最直接有效的方法就是投入更多的资源。然而，从全局来看，如果资源成本缺乏优化，最终会出现如下图所示的“边际效用递减”现象——技术能力的提升和资源的增幅并不匹配，甚至资源的膨胀速度会超过技术能力的提升，从而使技术项目本身的ROI大打折扣。

从笔者十余年的工作经验来看，资源成本优化宜早不宜迟。很多管理者在业务发展的较前期阶段，可能并没有意识到资源成本膨胀所带来的压力。等到业务到了一定规模，拿到机器账单的时候，惊呼“机器怎么这么费钱”，再想立即降低成本，可能已经错过了最佳时机，因为技术本身是一个相对长期的改造过程。

阅读更多

第一次接触敏捷是2000年初的事情，从那时起到现在经历和使用过无数所过程管理工具，深刻体会到，简单、易用、高效才是敏捷工具选择的王道。这里推荐自己目前仍在推广和使用的 一款叫「Leangoo」管理工具！

虽然我自己的研发团队也一直在使用Leangoo，但是也一直没有写过关于Leangoo的介绍！

但是在这段时间的使用下，我发现leangoo一直在不断进步，无论是在功能上还是体验上！晚上思绪容易沉淀，现在就让我整理我们自己的使用方法，希望对你们有帮助！

阅读更多

在印度有这么一个神奇的团队，他们有5000名左右的员工，每天要运送20多万份餐，一份盒饭要经过3-4个人的手才能抵达目的地，交通工具只有火车，自行车，板车和双腿，没有任何单据，甚至都不需要客户填写地址。

在这样的状况下，每6百万次运送中只有1次错误，准时正确到达率却超过99.99999%，这远超六西格玛的标准。在业界，如果一个企业能达到 六西格玛，就说明它能接近完美地达成顾客要求。在这一点上，达巴瓦拉甚至远远超过了联邦快递等使用现代技术和工具的快递公司。

大家可能在想，能够把事情做到这么好，他们一定很贵吧？他们团队的管理水平这么高，是不是成员的基础素质很高？

阅读更多

每年到了年中或者年尾都要进行总结，项目每个关键节点结束的时候要进行总结，遇到突发事件解决以后，也要进行总结。

总结时，叫上团队成员，坐在会议室，开始冗长乏味的会议，大家痛苦的坐着，听着领导的表扬，发言，训话，这样大家痛苦一下午都没有结果。

那要如何做好总结呢？你可以试试复盘这个方法，这是一种快速有效地从经验中学习的结构化方法。

1 那什么是复盘呢？

复盘原本是一个围棋术语，指下完棋，棋手重新摆一遍下棋的过程，以探讨得失，总结当时有无更好的应对招数。

那复盘用到企业里面，又称行动后的反思或者回顾，是目前知识管理实践中应用最为广泛的工具之一。复盘是一个简单而有效的过程，使团队从过去的成功中得到经验，在过去的失败中得到教训，以改进未来的表现。它是一个结合了技术和人为因素的快速报告工具，为团队提供一系列反思一个项目，活动，事件或者任务的机会，以便下次可以做的更好。

在联想，“复盘”是联想通过企业实践总结出的重要方法论，也是常出现在柳传志口中的高频词汇，已成为联想人的工作习惯，是企业文化中的重要方法论之一，是指工作做完了再回顾一遍，目的是不断检验和校正目标，不断分析过程中的得失，便于改进，不断深化认识和总结规律。在联想30年的成长过程中，复盘对企业的发展和组织智慧的积累都起到了重要作用。

华为有一种复盘方法叫“民主生活会”， 它是华为始终坚持的一种自我批判的方式，会议每三个月或者半年举行一次，要求全体中高管理层参与，包括任正非。

在日本丰田企业公司，复盘则是更为系统化的精益工作方法——A3报告， 就是把问题的源头、分析、纠正和执行计划在一种A3纸上表达出来并及时更新结构。A3报告已经成为一种标准方法，可用于总结并解决问题的方案，进行状态报告以及绘制价值流图。

在阿里巴巴，马云喜欢下围棋，用复盘这个方法来进行项目和人才的管理。阿里大复盘每年至少做两次，第一次复盘在每年3月份左右，第二次在十一左右。除了大型复盘，还有事件复盘和组织复盘。

在5月10号，阿里日集体婚礼上，马云做为证婚人表示：在阿里谈恋爱吵架以后是要复盘的，灵魂四问，要问为什么吵？吵什么？吵能解决问题吗？怎么能不吵？可见马云是多么喜欢复盘。

2 复盘跟一般的总结有什么不同呢？

1）结构化

复盘有形式和流程去保证有过程，有产出，有跟进。

2）导向性

复盘更强调学习，对于个人，团队与组织能力都是一种提升

学习有N种方式：向书本学、向身边人学、向自己过去的经验与教训学。而我们每天的工作中，每时每刻都在发生向自己过去的经验和教训学， 而复盘就是向自己学习的一种高效方法

3）参与性

复盘都团队成员集体全程参与，后续还伴随集体行动， 在这个过程中，个人，团队，组织能力都有提升。

3 复盘中存在的误区

1）搞复盘不是搞批斗

复盘是对事不对人，是为了后续提升人和组织的能力而做的，而不是秋后算账的手段。

有些领导在复盘的过程中，看到了很多失败的事情，然后就开始对发脾气，看是谁做的。 这样复盘一次，以后就再也没有人敢说话了。

2）报喜不报忧

很多人参与复盘时，因为种种原因，害怕暴露自己的不足，只说成绩，不谈缺点。这样实际上失去了学习、改进、提升的意义。

大家面子薄，都怕得罪人，然后开始互相吹捧，看着大家挺和谐，其实没有任意意义。

3）团队成员参与不够

在团队复盘会议中，每个人的参与程度不同，受到很多复杂而微妙的因素影响。主要症状包括：完全不参与；揣摩上级意图，不表达自己的看法；少数成员过于活跃，几乎主导了整个会议；相互指责，难以达成共识；“老打岔”，使讨论过程一再中断。

4 复盘前准备工作

1）参会人员的事先准备

“凡事预则立，不预则废”，在复盘会议开始之前，要做好所有准备工作，包括时间、地点的选择，设备与设施、数据与资料的准备，人员的协调与预热等。否则，很容易出现“该到的人没到”、缺乏相关资料、设备故障等问题。

还有就是对于每个到会的人，需要让他们提前思考，这里有三个问题可以考虑：

在这个项目，任务或者事件里

哪些是做的好的？

哪些是做的差的？

有什么改进的方法？

每个写三点，这样到会以后不会没有话说。 做到大家都参与。

2）主持人事先准备

团队复盘会议，本质上是一个结构化的团队学习过程，需要有效的引导。引导者必须保持中立，要关注团队互动的过程，通过提问、总结、调解等干预手段，确保会议按既定议程进行，并达到预期效果。

同时，引导者还要运用恰当的复盘形式和干预措施，营造适宜反思、学习、交流的氛围，确保参与者相互信任、开诚布公、实事求是、有效参与，并鼓励自我反思、深入探询。

所以支持者需要提前准好问题，这次项目的目的，目标等等。

阅读更多