梅森上校的博客 业精于勤荒于嬉，形成于思毁于随。

Scrum实施过程中曾遇到的那些“坑”作为一名Scrum Master，你在敏捷项目中采用Scrum时，遇到过哪些“坑”？不妨来讨论一下。1. Product Owner 不给力有时候，存在Product Owner与其它团队成员之间缺乏交流，彼此不够信任，Product Owner事先制定好了开发计划，要求开发团队在规定的时间内完成已经确定的功能交付，而具体的功能还不确定（需要一个渐进明细的过程）。这样从一开始，就已经存在了障碍。我遇到过各种各样的Product Owner，其中有一种跨.

Scrum 中的3-3-5-5Scrum中的3-3-5-5概括了Scrum中的：3中角色、3个工件、5个事件和5种价值观。3个角色（Roles）产品负责人（Product Owner） Scrum Master Scrum 团队3个工件（Artifacts）Product Backlog Sprint Backlog Increment5个事件（Events）Sprint计划会议（Sprint Planning） 每日Scrum会议（Daily Scrum） Sprint

最近在项目执行过程中，检查项目执行的进度时，与几位Test Lead就测试估算进行探讨。由于环境的复杂性，业务的复杂性，测试者的资源与测试工作量相配比，显得每位测试者的工作量大，测试执行过程比较紧张。所以导致的结果是测试执行的计划有所延误，测试者经常需要加班。于是要求Test Lead加强测试工作量的估算。结果问题来了，如何进行有效的测试估算？这里暂且不谈如何进行有效的测试估算，首先谈一个重要的观点

How should QA testers participate in the requirements definition process? 质量测试人员如何参与需求定义过程？说明：在本文中为了尊重作者的原文，所以将 QA testers 翻译为测试人员。尽管这个翻译看起来比较别扭。 有一些组织/公司会将测试者归结到SQA部门，但是在大多数组织中会严格区分SQA、SQC和Tester的角色

今天读了一篇博文是关于谈论“软件开发的核心”，博客原文地址为： http://kb.cnblogs.com/page/535278/作者首先提出了一个问题：「我们一直这样做开发，时间做久了，便忘了当初的本意。」有关软件系统开发，我们谈些什么？我们谈过程，编码规范、开发流程、同行评审、结对编程、持续集成，从瀑布到敏捷再到极限编程。我们谈架构，企业级、J2EE、容器化、SOA（面向服务架构）、Mi

作为一名职业项目经理（PM，Project Manager）或者团队领导（TL，Team Leader）不要试图去控制团队中的每个人的思想和行为，因为那几乎是不可实现的；但是可以通过有效的目标管理来让所有人达成一致。目标就是项目管理中的灯塔。

基本内容 - 管理心理学理论期望理论（Expectancy Theory），又称作 ”效价-手段-期望理论“。

百度百科上对ORID的描述：即焦点呈现法（Focused Conversation Method），是一种通过催化师（主持人、引导讲师）引导来开展的结构化汇谈（会议、交谈）形式。该方法常被用作对事实进行分析和感觉某一工具和方法。（O实践-客观事实、R感受-客观反射、I意义-事实分析，D行动-基于事实的下一步行动）

[敏捷开发实践] 用Sonarqube评估系统中的 Technical Debt （技术债）Sonar中技术债务的计算基于SQALE（Software Quality Assessment based on Lifecycle Expectations，基于生命周期期望的软件质量评估）方法学。Sonarqude Docs 7.9https://docs.sonarqube.org/lat...

You Can’t Manage What You Don’t MeasureYou can’t manage what you don’t measure. It is an old management adage that is accurate today. Unless you measure something you don’t know if it is getting better

一篇谈论Scrum的好文章，值得一看在世界杯的历史上，这个团队是最成功的，曾获六次冠军。在荷兰女子曲棍球队主教练Marc Lammers演讲中，我意识到为什么这个团队可以取得如此卓绝的成就。她们的成功，在很大程度上，要归功于教练 Marc的执教方式。Marc Lammers发现了可以令团队释放全部能量的秘诀，大家不仅像一个整体一样齐心协力，每个人作为团队的一份子也各尽所能；而这一切都以意想不到

今天上班，机器出了一点小故障，所以在等待修复机器时，在网络上看到了这篇文章。通读一下，感觉写的非常有道理，所以转载，与大家共同分享。        其实，编程久了，技术做久了，的确不能将自己当成写代码的工具。技术人员需要了解业务，需要深入业务，更需要结合自己擅长的某一个行业或者领域进行后续的职业发展规划，否则死守着技术，很快就会进入衰老期。没有技术不行的，但是当做到一定的阶段，就像文章的作者所

一、 什么是项目    所谓项目，简单地说，就是在既定的资源和要求的约束下，为实现某种目的而相互联系的一次性工作任务。一般来说，项目具有如下的基本特征：1、 明确的目标其结果只可能是一种期望的产品，也可能是一种所希望得到的服务。项目管理论坛2、 独特的性质每一个项目都是唯一的。3、 资源成本的约束性项目经理圈子每一项目都需要运用各种资源来实施，而资源是有限的。4、

简介　　是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。词源

I remember it like it was yesterday. It was the year 2000, Dr. Pargas was standing at the front of our data structures class talking about some data structure-y topic while an SSH session was projecte

概要软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。介绍软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论

敏捷建模（Agile Modeling，AM）的价值观包括了XP的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。 沟通　　建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的project stakeholder之间的沟通。 简单　　画一两张图表来代替几十甚至几百行的代码，通过这种方法，建模成为简化软件和软件（开发）过程的关键。这一点对

比较几种常见的软件开发过程模型的特点、优缺点、和适用情况： 一、瀑布模型 瀑布模型的特点：1、  简单、直观、易用2、  开发进程比较严格，一个阶段接着一个阶段顺序进行3、  模型中没有反馈，上一阶段任务完成，进入下一个阶段以后，下一个阶段不会对上一个阶段的工作作出反馈4、  模型执行过程中需要严格控制5、  允许基线和配置早期接受控制6、  一个新的项目不

基本概念         极限编程（ExtremeProgramming，简称XP）是由KentBeck在1996年提出的。kent仔细的观察和分析了各种简化软件开发的前提条件、可行性以及面临的困难后，引入了这套新的软件开发观念。 极限编程诞生于一种加强开发者与用户的沟通需求，让客户全面参与软件的开发设计，保证变化的需求及时得到修正。要让客户能方便地与开发人员沟通，一定要用客户理解

比较一下3种常用的、基本的也是非常重要的软件开发过程模型：瀑布模型、RUP统一过程模型、螺旋模型。        瀑布模型、RUP统一过程模型、螺旋模型3种模型虽然都是对软件生命周期管理的方法，相互之间也存在一定关系，但3种模型的应用环境和特点却相差很多。　　例如瀑布模型强调开发的阶段性，强调早期计划及需求调查，强调产品测试，但其带来的结果往往是系统交付客户之后才发现原先对于需求的理解

统一软件开发过程RUP的核心工作流RUP中有9个核心工作流，分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中