敏捷开发有 4 种价值 和 12个原则

---------------价值-----------------------------

自然之路的原则: 尽早提供价值,经常提供价值(必须以创造价值为中心,而且价值必须是可见的)

一种观察软件开发过程的方法



价值就是那些我们想要的东西.

当软件发布时,它的价值才能体现cuiyaonan2000@163.com

价值实现后,要确保价值的正确性,就会验证价值.



最大价值(项目整体),最小价值(最小可市场功能特性)

一个软件产品应用的20/80 法则.(在计划时间里不可能得到所有想要的功能特性.)

每个人想要的功能特性都不同,但肯定没有人想要所有的功能特性



根据功能特性划分价值(假设功能特性,高度代表价值,宽度代表成本.能够很好的展示出功能的重要性)

价值最大化就是频繁交付小的,以价值为中心的功能特性

---------------价值-----------------------------



-------------------------根据功能特性 ----- 指导------------------

我们所得到的肯定要少于我们想要的.毕竟,我们想要实现所有的功能.

事实上,我们并不能实现所有的功能特性,我们需要正视这一事实,并进行相应的管理.而不是直至不理.同时需要对项目进行引导,而不

任由它发展.

我们想要的超出了我们的能力范围.这也是目标的本质.

我们以全有,或者全无来制定项目计划,视图去设计所有的功能特性,这使我们处于不利的境地.遇到问题后我们没有时间去改变,问题的暴露也只能在项目后期才能体现,前期毫无预警.且在后期的开发过程中,不能灵活调整.cuiyaonan2000@163.com

根据功能特性交付,使项目更具有可预见性(对比原始开发模式的图,和根据功能特性交付的图.可一眼看出差距)

-------------------------根据功能特性 ----- 指导------------------

---------------------------根据功能特性----组织-------------------

功能特性团队中,需要有一个 负责构建产品推动人

在构建功能特性团队过程中,肯定会有很多问题,比如不同功能特性团队之间的相互协调.可能会让开发进度变慢.这是一个过程,前期是个磨合的过程.但是只要功能特性团队在朝着好的方向发展,最终一个团队是能构建好的.(组建兴趣小组&实践社区  我很怀疑)cuiyaonan2000@163.com

关于我们并没有足够多的有经验的人(后端,前端,测试,ui交互):根据功能特优先级分配(组建兴趣小组&实践社区  我很怀疑)



组建实践社区:将原属于不同 功能构建团队的 开发 测试 交互,按照职责类型组成一个小组,由高级开发负责带领.

---------------------------根据功能特性----组织-------------------

---------------------------根据功能特性----计划-------------------

产品的愿景总是以伟大的想法开始,虽然朦胧却很诱人.愿景是产品的大思路,而不是小的功能特性.



计划本身是无用的,但做计划是必要的

(的确需要做计划,但并不需要详细列出一张什么时候发生事情的清单.我们可以在事情发生后在去做计划.太细的计划只能浪费时间)

尽早确定哪些核心功能特性必须尽快有,哪些功能特性不能没有

做计划能在仔细考虑了很多不好的想法后,我们才能得到几个不错的想法.

计划内容:  A确定项目的时间期限和开支预算 B优先开发最有价值的功能特性 C确保产品能够随时发布,并在结束时间停止

A确定项目总体预算与截至日期  B找到一位产品推动人来决定功能特性的开发顺序,  C组建一个能随时交付的团队

迭代/冲刺  大故事>小故事>任务(大产品>小产品)

团队工作量根据方法"昨日天气(yesterday's weather)"

将功能特性一直拆分到具有独立测试价值的故事.cuiyaonan2000@163.com

无论从商业角度还是管理角度,要获得最好的结果,需要明确各项工作是按时完成还是推迟进行.

每个迭代 不能吃的太多

在不进行估算的情况下进行估算:一般来说估算结果很可能是错误的.如果想认真的估算,一般来说都会很保守.且我们会把注意力集中在成本上,而忽略了价值.cuiyaonan2000@163.com

---------------------------根据功能特性----计划-------------------



---------------------------根据功能特性----构建产品-------------------

在一个短周期内,完整的构建一个小的产品

(在每个周期内,确定需要完成哪些功能特性,并清楚地说明如何测试它们,每一个迭代都是一个学习,

学习如何估算工作量,学习如何检查任务是否完成了.还能学习代码设计的能力)

细化产品愿望: 我们需要相信业务团队能够弄清楚他们到底需要什么.

总是将价值可能最大的任务列为下一个目标

每个迭代必须修复所有的缺陷

---------------------------根据功能特性----构建产品-------------------



---------------------------同时构建功能特性与基础-------------------

理想状态是在 交付的时候我们能够完成所有的功能特性

A: 基础优先意味着能够进入市场的功能特性减少(延缓项目进展的同时,减少产品价值)

B: 在构建功能特性的同时构建相关的基础还是(将功能特性做到极致是错误的.可能并满足需求,切回浪费时间)

C: 首先构建简单而使用的版本,在多次迭代中不断完善每个功能特性(最小可行产品)cuiyaonan2000@163.com

如何选择功能特性的最佳组合需要考验 产品推动人的能力.以期满足随时都能够发布一个可用的产品.

---------------------------同时构建功能特性与基础-------------------



---------------------------零缺陷与良好的设计---------------------------



产品构建是在不断发展和变化的设计基础上,由数量不断增长,能够正确运行的功能特性组成.

需要及时了解 哪些功能特性已经完成,且完成的质量怎么样.

因为功能特性是逐渐增加和完善的,同时设计也是逐渐改进的.

若不能保持设计处于良好的状态,轻则影响项目进度,重则导致项目失败.(如果放任设计退化,项目进度肯定会变慢)

2个层面的测试:业务测试,开发测试

测试不但会减慢开发速度,发而使其变得更快.(减少错误,同时使错误更快地被发现)



好的设计,就是对相应的扩展更容易.

软件开发的本质就是要求我们进行测试和重构.



---------------------------零缺陷与良好的设计---------------------------

--------------------------如何衡量价值-----------------------

敏捷要求我们基于价值决定做事情的先后顺序.

选择价值就是选择对我们重要的东西,所谓价值就是我们想要的东西.

价值是 对客户有用 或者 在商业上有用 等角度考虑我们看重的东西.



为什么不要根据数据进行决策:

A首先我们并非真的知道数据 

B其次,大的差别很重要,小的差别不重要 cuiyaonan2000@163.com

C最后不同类型的价值不具可比性(不同时期的价值取向不一样)



--------------------------如何衡量价值-----------------------



--------------------------如何让软件真正运行-------------------

如何尽快的开发一个软件:

    A专注于我们看中的东西

    B不时地开发出真正的软件

    C逐步构建我们想要的产品

    D学习需要的计划,管理以及技术方面的能力

    

--------------------------如何让软件真正运行-------------------

--------------------------组建强大的团队------------------------

请求管理人员确保团队成员知道要做什么,然后让他们自己去搞清楚怎么做.

自主,专精,目的 为提高员工满意度和工作效率的三大驱动力.

--------------------------组建强大的团队------------------------



-----------------------------使用五卡法进行初步的预测--------------------

第一步:列出三到五个最重要的 "史诗级" 组成部分.用一句话描述

第二步:将第一步的卡片模块细化到三至五张更小的卡片上.使每一张片的内容更具体,更明确,范围更小

第三步:重复第二步知道确定最后的卡片,团队成员能在一周内完成.

-----------------------------使用五卡法进行初步的预测--------------------



------------------------------管理的五大要素----------------------

计划,组织,人员配备,领导,控制(传统的的,敏捷全靠自主~~~~~高效的团队才行)

敏捷: 授权 的重要性(自主,专精,目的)

以结果为导向评价工作的好坏.

不要以培训,监督等手段 促使员工更加努力的工作(自主,专精,目的)

------------------------------管理的五大要素----------------------



 

    

                    

                    

                    
                    
                    
   
这是学习笔记的第 2088 篇文章

  今天下午在思考几个问题，工作的本质是什么？DBA的核心价值是什么？有哪些工作是DBA不可取代的？在整理的过程中，也有了一些心得体会。小程序-杨建荣的学习笔记
   首先DBA这个职位全称是Database Administrator，其实这里有一个问题，我们总说数据库管理，这里的管理可以manage,那么administion和manage的区别大吗，如果查看字典会发现administrator的含义其实相对来说范围更窄一些，有点偏行政人员，而manage的概念和范围要更宽泛一些，换言之，DBA带给我们的含义其实已经悄然发生了变化，在行业里第三个字母A有几种说法，一种是Architecture,即数据架构师，还有一种是Analysis,即数据统计/分析师。
   对于DBA来说，如果要说核心价值，不妨换一个问题，即哪些工作是DBA专业的事情，从我的理解来说，有以下几件：
1）数据库技术选型
2）数据备份恢复
3）数据库架构设计
4）数据库高可用
5）数据库升级
6）数据迁移
7）SQL性能优化
其中除了第7件事情之外，前面的6件细细想来，业务方似乎都不会太关心这部分的内容，他们能够参与的角色部分是比较有限的，也就意味着这些技能虽然是专业的内容，但是专业到业务同学无法感知，会形成一种无为的错觉。
而且在云计算依然成熟的今天，带给数据库运维管理工作的变化也有着较大的冲击和挑战。
在这个部分，我已经把安装部署的工作完全舍弃掉了，因为这是再简单不过的事情，公有云对标的是一种资源服务，这个资源包括服务器资源，网络资源，数据库资源等，很多额外的成本也打包进去了，比如机架位成本，电费，网络带宽费用等等，是一个统一对外的价格包。
  当然包括阿里云，腾讯云，AWS,现在的资源服务其实是最底层的基础服务，在数据库层的服务还包括：数据库选型，备份恢复和高可用。而回到刚刚的那本的DBA专业的工作内容，就会发现，除了架构设计和SQL优化，其实公有云服务已经能够基本覆盖业务需要的大部分范围了。 
  而反过来说，如果一个公司就几个数据库，使用了公有云服务，基本能够满足日常业务发展需求，那么DBA存在的意义就不是很大，而如果你有成百上千套环境，需要大量的维护管理工作，那么这些就需要专业的管理。可以举几个例子，比如权限管理，如果没有统一的规范规则，那么用户很可能是dev_user,那么成百上千套环境都是这种混乱模式，简直不可想象，如果业务同学拥有drop，truncate权限，可以任意变更和操作数据，那么数据安全就是一个很大隐患，对于业务侧数据管理缺少既定的机制和策略来保证，那么整个数据库管理就会是一锅粥。
就好比游乐场里面的海洋球，如果海洋球代表的是相应的数据，那么我们如何有效的管理这些海洋球就是一个类似的问题，如果从这些海洋球里面找到你需要的数据。
所以我们需要好好考虑下自己目前的状态，既然我们是数据库管理员，那么管理就是一个很重要的切入点。我的脑海里不由得闪现了一个名词：生命周期管理。从我目前的认知理解来看，我认为这个是DBA工作的核心价值。
这里的生命周期管理范围是比较大的，我可以把它分为实例生命周期，对象生命周期，数据声明周期和SQL生命周期四个维度。 
其中实例生命周期正是目前的公有云服务成熟和优势所在，而相反是很多私有云或者公司自建的虚拟化服务不够成熟和健全的部分。
权限生命周期主要会关联数据安全和数据规范，其中数据安全就是因需所配，同时可以追溯变更历史，数据库规范则是做一些相关的命名规范等，总体来说，这是一套权限总线。
对象生命周期管理涉及的范围很容易理解：数据库对象，简单来说，是那些DDL操作，其中以Create操作的优先级最高，而且风险最低。而Alter操作的复杂度最高，风险较高，Drop操作的复杂度最低，风险最高，在这方面我们要提高Create的效率，这里就会关联SQL审核和SQL自动化上线。Alter操作的复杂度最高，则会关联数据备份恢复和数据变更的专业化处理，如online DDL,Drop操作的风险最高，则可以通过构建回收站来降低这类操作的风险。
数据生命周期管理是目前工作中大家最容易忽视，而且是最有价值的。在这方面操作的复杂度不高，但是可以这个层面影射出很多方面工作的必要性和价值。比如数据操作无非是一些增删改的操作，如果从数据的变更情况来说，我们完全可以做到数据冷热分离的处理，冷热分离带来的最大好处就是让我们可以集中精力去完成那些额待解决的事情，可以延伸出几个方面的关联。
冷热分离和高可用相关，比如一个业务有100张表，但是热表只有10章，那么我们考虑高可用方案的时候可以优先恢复那10张表的数据，就可以覆盖最多的业务范围，从而实现业务高可用。
冷热分离和备份恢复相关，我们可以针对业务特别来优化所谓的热表，在数据恢复时优先恢复哪些热数据，尽快恢复业务，可以把表根据数据变化情况进行细化，比如把流水型日志表改造为分布式或者无事务的处理方式。 
冷热数据分离和优化相关，比如可以格外关注表的数据变更和写入效率，集中进行优化改进。
而SQL生命周期管理主要面向的是查询语句，可以根据业务特点把这些相关的表归类为几类：opr（运维管理），ref(数据字典），app(应用数据表），sec（安全权限相关表），同时引入SQL指纹和SQL生命周期管理，慢查询管理等。
后续会展开一篇继续来聊一聊。
相关链接：
个人新书 《MySQL DBA工作笔记》

                
  

                    

服务（Service）的本质就是提供服务消费者期望的某种功能，服务的价值体现在两个方面：服务本身的质量和寄宿服务的平台应付消费者的数量，并发（Concurrency）的关注的是第二个要素。WCF服务寄宿于资源有限的环境中，要实现服务效用的最大化，需要考虑如何利用现有的资源实现最大的吞吐量（Throughput）。提高吞吐量就某个寄宿的服务实例（Service
 
Instance）来说，一个重要的途径就是让它能够同时处理来自各个客户端（服务代理）的并发访问。WCF实现了一套完整的并发控制体系，为你提供了不同的并发模式。
  
我经常说软件架构是一门权衡的艺术，需要综合考虑各种相互矛盾的因素，找到一种最优的组合方式。提高单个服务实例允许的并发访问量能够提高整体吞吐量，这样的理论依赖于一种假设，那就是服务端所能使用的资源是无限。我们知道，这种假设无论在什么情况下都不会成立。如果我们并发量超出了服务端所能承受的临界点，整个服务端将会崩溃。所以，WCF一方面需要允许让单个服务实例并发处理接收到的多个请求，同时也需要设置一道闸门控制并发的数量。WCF的流量限制（Throttling）体系为你创建了这道闸门。
  
[第1篇] WCF 并发（Concurrency）的本质：同一个服务实例上下文（InstanceContext）同时处理多个服务调用请求  
并发的含义就是多个并行的操作同时作用于一个相同的资源或者对象，或者说同一个资源或者对象同时应付多个并行的请求。对于WCF的并发来说，这里将的“资源或者对象”指的就是承载服务操作最终执行的服务实例（Service
 Instance）。而WCF将服务实例封装在一个称为实例上下文（InstanceContext）对象中，所以WCF中的并发指的是同一个服务实例上下文同时处理多个服务调用请求。  
WCF服务端框架一个主要的任务是将接收到的服务调用请求分发给激活的服务实例，调用相应的服务操作并返回执行结果。也就是说，服务操作的执行最终还是会落实到某个具体的服务实例上。《WCF技术剖析（卷1）》的第9章对WCF的实例化机制进行了深入的剖析，从中我们知道在WCF服务端框架体系中，激活的服务实例并不是单独存在的，而是被封装在一个被称为实例上下文（InstanceContext）对象中。WCF提供了三种不同的实例上下模式（Per-Call、Per-Session和
 Single）实现了不同的服务实例上下文提供机制。 
所以，WCF并发框架体系解决的是如何有效地处理被分发到同一个服务实例上下文的多个服务调用请求，这些并行的调用请求可能来自不同的客户端（服务代理），也可能相同的客户端。
  
[第2篇]并发中的同步--WCF并发体系的同步机制实现  
在《WCF 并发的本质》中，我们谈到了WCF提供的三种不同的并发模式，使开发者可以根据具体的情况选择不同的并发处理的策略。对于这三种并发模式，Multiple采用的并行的执行方式，而Single和Reentrant则是采用串行的执行方式。串行执行即同步执行，在WCF并发框架体系中，这样的同步机制是如何实现的呢？
  
[第3篇]实践重于理论——创建一个监控程序探测WCF的并发处理机制  
于WCF的并发是针对某个封装了服务实例的InstanceContext而言的（参考《并发的本质》《并发中的同步》），所以在不同的实例上下文模式下，会表现出不同的并发行为。接下来，我们从具体的实例上下文模式的角度来剖析WCF的并发处理机制，如果对WCF实例上下文模式和实例上下文提供机制不了解的话，请参阅《WCF技术剖析（卷1）》第9章。  
为了使读者对采用不同实例上下文对并发的影响有一个深刻的认识，会创建一个简单的WCF应用，并在此基础上添加监控功能，主要监控各种事件的执行时间，比如客户端服务调用的开始和结束时间，服务操作开始执行和结束执行的时间等等。读者可以根据实时输出的监控信息，对WCF的并发处理情况有一个很直观的认识。
 [源代码从这里下载]  
[第4篇] 并发与实例上下文模式: WCF服务在不同实例上下文模式下具有怎样的并发表现  
由于WCF的并发是针对某个封装了服务实例的InstanceContext而言的，所以在不同的实例上下文模式下，会表现出不同的并发行为。接下来，我们从具体的实例上下文模式的角度来剖析WCF的并发，如果对WCF实例上下文模式和实例上下文提供机制不了解的话，请参阅《WCF技术剖析（卷1）》第9章。  
在《实践重于理论》一文中，我写一个了简单的WCF应用，通过这个应用我们可以很清楚了监控客户端和服务操作的执行情况下。借此，我们可以和直观地看到服务端对于并发的服务调用请求，到底采用的是并行还是串行的执行方式。接下来，我们将充分地利用这个监控程序，以实例演示加原理分析相结合的方式对不同实例上下文模式下的并发实现机制进行深度剖析。
  
[第5章] 回调与并发: 通过实例剖析WCF基于ConcurrencyMode.Reentrant模式下的并发控制机制  
对于正常的服务调用，从客户端发送到服务端的请求消息最终会被WCF服务运行时分发到相应的封装了服务实例的InstanceContext上。而在回调场景中，我们同样将回调对象封装到InstanceContext对象，并将其封送到客户端。当服务操作过程中执行回调操作的时候，回调消息最终也是分发到位于客户端封装回调对象的InstanceContext。从消息分发与并发处理的机制来看，这两种请求并没有本质的不同。接下来，我们通过《实践重于理论》中的实例，综合分析WCF对并发服务调用和并发回调的处理机制。  
[第6篇] ConcurrencyMode.Multiple 模式下的WCF服务就一定是并发执行的吗：探讨同步上下文对并发的影响[上篇][下篇]  
《上篇》通过一个具体的实例演示了WCF服务宿主的同步上下文对并发的影响，并简单地介绍了同步上下文是什么东东，以及同步上下文在多线程中的应用。同步上下文在WCF并发体系的内部是如何影响服务操作的执行的呢？这实际上涉及到WCF的一个话题，即线程的亲和性（Thread
 Affinity），下篇将为你剖析WCF线程亲和机制的本质。  
[第7篇] 控制并发访问的三道屏障: WCF限流(Throttling)体系探秘[上篇][下篇]  
WCF是一个基于多线程的消息监听、接收和处理框架体系，能够同时应付来自相同或者不同客户端的服务调用请求，并提供完善的同步机制确保状态的一致性。一方面，我们期望WCF服务端能够处理尽可能多的并发请求，但是资源的有限性决定了并发量有一个最大值。如果WCF不控制进入消息处理系统的并发量，试图处理所有抵达的并发请求，一旦超过了这个临界值，整个服务端将会由于资源耗尽而崩溃。
  
所以，我们需要在WCF的消息接收系统和消息处理系统之间设置一道道屏障，将流入消息处理系统的请求控制到一个最佳的范围，以实现对现有资源的有效利用，从而达到确保服务的可用性和提高整体吞吐量的目的。WCF的流向限制（Throttling）为你设置了这些屏障，你可以根据现有的软硬件环境对该闸门准入的并发流量进行动态的配置。
 



作者：蒋金楠 

微信公众账号：大内老A

微博：www.weibo.com/artech

如果你想及时得到个人撰写文章以及著作的消息推送，或者想看看个人推荐的技术资料，可以扫描左边二维码（或者长按识别二维码）关注个人公众号（原来公众帐号蒋金楠的自媒体将会停用）。

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

原文链接


        
        
                
    

    
 
一切工具本质上都是“时间的折叠”。任何一个好的工具，本质上都是一个时间的容器，它里面储存了别人的时间。折叠进去的时间越多，价值就越大。让人时间的自由度越大的工具，价值就越大。
 
易经里讲，君子藏器于身，待时而动。所谓的器，就是技能及使用技能的能力。而这些技能，是让你度过一生和明晓道理的依凭。——德鲁伊
http://www.zreading.cn/archives/6821.html

转载于:https://www.cnblogs.com/feng9exe/p/10667736.html