本文目录导航：
矫捷开发的价值观
矫捷建模（Agile Modeling，AM）的价值观包含了XP（Extreme Programming：极限编程）的四个价值观：沟通、方便、反应、勇气，此外，还裁减了第五个价值观：谦虚。
矫捷开发是针对传统的瀑布开发形式的弊病而发生的一种新的开发形式，指标是提高开发效率和照应才干。
除了准则和通常，形式也是很关键的，多钻研形式及其运行可以使你更深档次的了解矫捷开发。
◆主张方便当从事开发上班时，你应当主张最方便的处置方案就是最好的处置方案。
不要过火构建（overbuild）你的软件。
用AM的说法就是，假设你如今并不要求这项额外性能，那就不要在模型中参与它。
要有这样的勇气：你如今不用要对这个系统启动过火的建模（over-model），只需基于现有的需求启动建模，日后需求有变卦时，再来重构这个系统。
尽或许的坚持模型的方便。
◆拥抱变动需求时辰在变，人们关于需求的了解也时辰在变。
名目启动中，Project stakeholder或许变动，会有新人参与，也会有旧人退出。
Project stakeholder的观念也或许变动，你致力的指标和成功规范也有或许出现变动。
这就象征着随着名目的启动，名目环境也在不停的变动，因此你的开发方法必定要能够反映这种事实。
◆你的第二个指标是可继续性即使你的团队曾经把一个能够运行的系统交付给用户，你的名目也还或许是失败的－－成功Project stakeholder的需求，其中就包含你的系统应该要有足够的鲁棒性（robust ），能够顺应日后的裁减。
就像Alistair Cockburn常说的，当你在启动软件开发的竞赛时，你的第二个指标就是预备下一场较量。
可继续性或许指的是系统的下一个关键颁布版，或是你正在构建的系统的运行和允许。
要做到这一点，你不只仅要构建高品质的软件，还要创立足够的文档和允许资料，保障下一场较量能有效的启动。
你要思考很多的要素，包含你现有的团队是不是还能够参与下一场的较量，下一场较量的环境，下一场较量对你的组织的关键水平。
方便的说，你在开发的时刻，你要能构想到未来。
◆递增的变动和建模关系的一个关键概念是你不用在一开局就预备好一切。
实践上，你就算想这么做也不太或许。
而且，你不用在模型中容纳一切的细节，你只需足够的细节就够了。
没有必要试图在一开局就建设一个囊括一切的模型，你只需开发一个小的模型，或是概要模型，打下一个基础，而后缓缓的改良模型，或是在不在要求的时刻摈弃这个模型。
这就是递增的思维。
◆令Stakeholder投资最大化你的project stakeholder为了开收回满足自己要求的软件，要求投入期间、金钱、设施等各种资源。
stakeholder应该可以选取最好的方式投资，也可以要求你的团队不糜费资源。
并且，他们还有最后的发言权，选择要投入多少的资源。
假设是这些资源是你自己的，你宿愿你的资源被误用吗。
◆有目的的建模关于自己的artifact，例如模型、源代码、文档，很多开发人员不是担忧它们能否够详细，就是担忧它们能否太过详细，或担忧它们能否足够正确。
你不应该毫有意义的建模，应该先问问，为什么要建设这个artifact，为谁建设它。
和建模有关，兴许你应该更多的了解软件的某个方面，兴许为了保障名目的顺利启动，你要求和初级经理交换你的方法，兴许你要求创立形容系统的文档，使其他人能够操作、保养、改良系统。
假设你连为什么建模，为谁建模都不清楚，你又何必继续烦恼下去呢？首先，你要确定建模的目的以及模型的受众，在此基础上，再保障模型足够正确和足够详细。
一旦一个模型成功了指标，你就可以完结上班，把精神转移到其它的上班下来，例如编写代码以测验模型的运作。
该项准则也可实用于扭转现有模型：假设你要做一些扭转，兴许是一个熟知的形式，你应该有做出变动的正确理由（或许是为了允许一项新的需求，或是为了重构以保障繁复）。
关于该项准则的一个关键暗示是你应该要了解你的受众，即使受众是你自己也一样。
例如，假设你是为保养人员建设模型，他们究竟要求些什么？是厚达500页的详细文档才够呢，还是10页的上班总览就够了？你不清楚？去和他们谈谈，找出你想要的。
◆多种模型开发软件要求经常使用多种模型，由于每种模型只能形容软件的单个方面，“要开发现今的商业运行，咱们该要求什么样的模型？”思考到现今的软件的复杂性，你的建模工具箱应该要容纳少量有用的技术（关于artifact的清单，可以参阅AM的建模artifact）。
有一点很关键，你没有必要为一个系统开发一切的模型，而应该针对系统的详细状况，筛选一局部的模型。
不同的系统经常使用不同局部的模型。
比如，和家里的修缮上班一样，每种上班不是要求你用遍工具箱里的每一个工具，而是一次性经常使用某一件工具。
又比如，你或许会比拟青睐某些工具，雷同，你可会偏爱某一种模型。
有多少的建模 artifact可供经常使用呢，假设你想要了解这方面的更多细节，我在Be Realistic about the UML中列出了UML的关系局部，假设你宿愿做进一步的了解，可以参阅白皮书The Object Primer -- An Introduction to Techniques for Agile Modeling。
◆高品质的上班没有人青睐烂糟糟的上班。
做这项上班的人不青睐，是由于没有成就感；日后担任重构这项上班（由于某些要素）的人不青睐，是由于它难以了解，难以降级；最终用户不青睐，是由于它太软弱，容易出错，也不合乎他们的希冀。
◆极速反应从开局采取执行，到取得执行的反应，二者之间的期间至关紧要。
和其他人一共开发模型，你的想法可以立刻取得反应，特意是你的上班采用了共享建模技术的时刻，例如白板、CRC卡片或即时贴之类的基本建模资料。
和你的客户严密上班，去了解他们的的需求，去剖析这些需求，或是去开发满足他们需求的用户界面，这样，你就提供了极速反应的时机。
◆软件是你的关键指标软件开发的关键指标是以有效的方式，制作出满足project stakeholder要求的软件，而不是制作有关的文档，有关的用于治理的artifact，甚至有关的模型。
任何一项优惠（activity ），假设不合乎这项准则，不能有助于指标成功的，都应该遭到查看，甚至敞开。
◆轻装行进你建设一个artifact，而后选择要保管它，随着期间的流逝，这些artifact都要求保养。
假设你选择保管7个模型，不论何时，一旦有变动出现（新需求的提出，原需求的降级，团队接受了一种新方法，采用了一项新技术...），你就要求思考变动对这7个模型发生的影响并采取相应的措施。
而假设你想要保管的仅是3个模型，很显著，你成功雷同的扭转要破费的功夫就少多了，你的灵敏性就增强了，由于你是在轻装行进。
相似的，你的模型越复杂，越详细，出现的扭转极或许就越难成功（每个模型都更“繁重”了些，因此保养的累赘也就大了）。
每次你要选择保管一个模型时，你就要掂量模型载有的消息对团队有多大的好处（所以才要求增强团队之间，团队和project stakeholder之间的沟通）。
千万不要小看掂量的重大性。
一团体要想过沙漠，他必定会携带地图，帽子，质地优异的鞋子，水壶。
假设他带了几百加仑的水，能够构想的到的一切求生工具，一大堆有关沙漠的书籍，他还能过得去沙漠吗？雷同的情理，一个开发团队选择要开发并保养一份详细的需求文档，一组详细的剖析模型，再加上一组详细的架构模型，以及一组详细的设计模型，那他们很快就会发现，他们大局部的期间不是花在写源代码上，而是花在了降级文档上。
最关键的是经过尽早和一直交付有价值的软件满足客户要求。
咱们欢迎需求的变动，即使在开发前期。
矫捷环节能够驾驭变动，坚持客户的竞争长处。
经常交付可以上班的软件，从几星期到几个月，期间尺度越短越好。
业务人员和开发者应该在整个名目环节中一直朝夕在一同上班。
围绕斗志高昂的人启动软件开发，给开发者提供适宜的环境，满足他们的要求，并置信他们能够成功义务。
在开发小组中最有效率也最有成果的消息传达方式是面对面的交谈。
可以上班的软件是进展的关键度量规范。
矫捷环节倡议可继续开发。
出资人、开发人员和用户应该总是维持不变的节拍。
对出色技术与良好设计的一直谋求将有助于提高矫捷性。
方便——尽或许缩小上班量的艺术至关关键。
最好的架构、需求和设计都源自自我组织的团队。
每隔必定期间，团队都要总结如何更有效率，而后相应地调整自己的行为。
什么是pmo
PMO(Project Management Office)普通称为名目治理办公室、名目治理中心或许名目治理部，是在组织外部将通常、环节、运作方式化和规范化，同时在组织内各机能间，为推进专案行进发生各种上班资源抵触时，担任协调整合的机能，所以是为了提高组织治理成熟度的外围部门，它依据业界最佳通常和公认的名目治理常识体系（PMBOK），并联合企业自身的业务和行业特点，为组织量身定制名目治理流程、造就名目经理团队、建设名目治理消息系统、对名目提供顾问式指点、展开多名目治理等，以此确保名目成功率的提高和组织策略的有效贯彻和执行PMO关注于与下级组织或客户的全体业务指标相咨询的名目或子名目之间的协调方案、优先级和执行状况。
PMO的性能和作用可以分为日常型职能和策略型职能。
1、建设组织内名目治理的撑持环境。
包含一致的名目实施流程、名目环节实施指南和文档模板、名目治理工具、名目治理消息系统。
2、造就名目治理人员。
在企业内提供名目治理关系技艺的关系培训。
3、提供名目治理的指点和咨询。
最大限制的集中名目治理专家，提供名目治理的咨询和顾问服务。
4、组织内的多名目治理和监控。
PMO一致搜集和汇总一切名目的消息和绩效，并对组织上层或其余要求这些消息的组织或部门启动报告。
5、名目组合治理。
包含将组织策略和名目关联，名目选用和优先级排定。
组合所关心的是适配、成效友好衡。
6、提高企业名目治理才干。
一方面经过 PMO所承当的日常性职能来贯彻和表现，另一方面把名目治理才干变成一种可耐久表现、不依赖团体行为的组织行为。
将企业的名目治理通常和专家常识整顿成适宜本企业的一套完整的名目治理方法论，在企业内流传和推行。
名目治理工具Masterlab,Teambition,worktile有什么区别，哪个最适宜互联网的矫捷开发？
名目治理软件简直没有任何实质的区别。
治理软件只要求掌握最外围的五大环节、四要素。
Teambition面板关于开发人员来说并不是很友好，它更适宜于要求少量文档迭代的工程名目治理。
互联网的矫捷开发要求自己去依据名目创立模板，但性能好后还是有可取之处。
Worktile面板式的操作，更偏差于团队治理，义务调配。
masterlab并不出色，但在你提供的三个选项内，他却是最好的。
由于它更方便、更方便、更片面。
统筹了一切软件开发所要求的性能。
面板、迭代、统计、报表、文档演绎、组织治理、优惠处置、义务调配等等等等。
所以，还是用MasterLab吧
