Difffate的技术随笔

敏捷常见错误观念敏捷是特殊的，没有过程控制。敏捷使开发周期更短耗费更低。敏捷不需要做计划或者写文档。敏捷不需要前期设计。敏捷实施是无痛的过程。敏捷项目永远不会结束。敏捷意味着不确定性，不可预估。敏捷是银弹，是一切问题的解决方法。使用scrum，所以不需要修复程序，重构或者测试驱动开发。敏捷团队常犯的错误对敏捷的实施，心怀抵触或担心。缺乏有效的沟通

计划会议（Planning Meeting）参与者：整个团队，包括产品（Product Owner）、Scurm Master、Scrum Team（开发、QA）目的：Product Owner从Product Backlog中梳理出这期Sprint需要完成的Backlog，并与团队成员达成共识。注意区分userstory和backlog的区别，userstory可以是任何一个需求、想法，

最重要的人，最核心的是快速迭代，最厉害的是拥抱变化，最赞的是每个角色其实百分比参与项目。

1、传统的项目经理扮演的角色是项目的领导者、决策者、计划者，他是负责达成项目商业目标的人。而Scrum Master扮演的是教练、引导者、训练者的角色，他负责Scrum流程在团队中能够正常实施和执行。2、传统的项目经理负责团队成员具体任务的分工，而Scrum强调的是团队的自组织，自我管理，Scrum Master很重要的内容是帮助每个人的能力提升，不负责实际工作内容。-------

按照Scrum角色来划分，总结敏捷实现的一些现状：①Product Owner（应该类似公司开发经理）同客户协商决定众多案子的优先级排序，可行性分析(Plan Meeting)，根据开发同QA提供的估时提送计划，还有风险控制（发布是否可控），需要执行的user story转给Scrum Master。②Scrum Master（应该类似公司职能线组长），会制定每个案子实施的具体流程

价值观：沟通、简单、反馈、勇气、尊重最佳实践：Fine scale FeedBack结对编程；计划游戏；测试驱动开发；团队协作；客户测试Continuous process持续集成；重构或设计改进；小型发布Shared understanding编码标准；集体代码所有制；简单设计Sustainable pace每周40小时工作制Other

DevOps的三大原则：1、基础设施即代码（Infrastructure as Code）DeveOps的基础是将重复的事情使用自动化脚本或软件来实现，例如Docker（容器化）、Jenkins（持续集成）、Puppet（基础架构构建）、Vagrant（虚拟化平台）等2、持续交付（Continuous Delivery）持续交付是在生产环境发布可靠的软件并交付给用户使用。而持续部署

结对编程（英语：Pair programming）是一种敏捷软件开发的方法，两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）[1]。两个程序员经常互换角色。但是也可以采用owner/supporter模式，一个负责功能，另一个负责支持。实行步骤：1、结对组成；2、初始讨论(方案制定)；

说起微服务，首先要对比的是传统的单体应用。单体应用是最早的应用形态，不需要太关注整体性能，项目规模中小型时，开发和部署都挺方便。简单谈谈他的优缺点。单体应用优点：方便调试，代码都在一起；没有分布式开销，所有服务都在本地容器内；中小型项目可以快速迭代，不需要太多资源单体应用容易造成的问题：版本管理难：当项目规模变大时，代码容易产生冲突。稳定性差：局部服务有问题，可

敏捷管理说到底还是项目管理，对人的管理，强调自管理；自管理是个主动的过程，团队成员是一体的，主动拉任务、主动找问题、主动要求做的更好；敏捷真正实践，需要大家有共同的项目目标，团队能达到自组织的状态；敏捷对人的要求很高，当时他们的团队几乎能达到互为B岗；可以把敏捷的实践方法融合到现在的工作中，但是不能简单的认为现在就是完整/实际意义上的敏捷了，因为现在面对的问题是，人员在项目中流动太