关于“项目经理”面试遇到“敏捷开发”问题的回答的一点参考

敏捷开发的一些问题
说一下你对敏捷开发的理解,为什么要使用敏捷开发strong>
》瀑布模型的典型问题就是周期长,发布烦,变更难。
》敏捷开发就是快速迭代,持续集成,拥抱变化。
    所谓“敏捷”,顾名思义,可以通俗的理解为“短平快”,抽象点的可以说是“一种需求进化”。
采用快速迭代、循序渐进的方法进行软件开发,通过持续交付的方式不断的交付一个一个子系统,每个交付的子系统都经过测试,具备可集成可运行的特征(这也决定了大的项目在一开始就要被合理的规划和切分为多个子项目)。换个说法就是把一个大项目拆分为多个相互联系,但也可以独立运行的小项目,并分别完成。
    a) 因为敏捷开发的特征,将项目的大目标切分为N个小目标,使得每个目标都简单直观可达性更强。不管是客户、项目经理还是开发者本身,能快速的看到“成果”都是一种好事。化整为零的方式是一种更好的方式,就好像搭积木,将复杂事情简单化的,问题这个攻克,项目逐块交付。
    b) 对于客户而言,也有这样一个场景:我做过整体交付的项目,也带过持续交付的项目。同样跨度都是八九个月(你要能对应到你简历上的具体项目,别一问就穿了)。其中一个项目就是,我们分了4次迭代交付,前面几个月交付了一个版本。客户就推向市场下发给普通用户使用了,然后后面每隔一个月上了一块功能。这样对客户来说可以更快的抢占市场(我理解市场的时间价值成本是非常昂贵的)。不断的更新新的模块,从用户角度也能感知产品的升级带来的效果(这就是为什么我们有的APP产品要每隔1年左右做一个UI改版一样,明明业务没有什么改变,单也要换个皮,其目的就是为了用户,话说不在乎用户感受的项目经理和产品都是不合格)。
    c) 还有就是甲方一般都特别担心的质量问题:谁付钱谁忧虑这本就人之常情,敏捷开发逐步交付的成果“相对较小”,对于质量更容易量化,因为持续交付,问题可以提前发现提前解决。不合理的问题可以“提前转舵”,避免后续持续产生类似的问题。
    d) 因为敏捷开发的特性,使得团队互动性增强。因为互动性的增强,使得每个人都能相对收益。
    e) 劣势:上面说了敏捷注重人员的沟通,若项目人员流动大太,会给维护带来不少难度,特别项目存在新手比较多时,老员工比较累。需要项目中存在经验较强的人,要不在大项目中容易遇到瓶颈问题,对项目的把控者有更高的要求,或者在必要的时候公司有相对专业的人或团队给予指导和支持。
总结: 敏捷开发是是一个非常有价值的方式,特别适用于持续演进的项目(比如互联 产品或长期执行下去的项目)。对于短小交付就彻底结束的项目则不太适合。对产品对成本对成员有价值的东西,没有理由不用。
    严格来说敏捷开发由迭代+增量组成。持续交付的敏捷才是更有价值的,也就是上面说的不止迭代了,还可以不断的增量上新(用户可感知)。
由于敏捷开发可以不断试错,迎合市场的可以加强投入,反之可以淘汰。而不是等整个大而全的项目完整完成统一上线才发现就有些不合适了。

上面是叙述,下面的内容来自互联 ,供参考(要理解记忆和挑几点说就行了):

一、敏捷开发技术的几个特点和优势:
1.个体和交互胜过过程和工具
2.可以工作的软件胜过面面俱到的文档
3.客户合作胜过合同谈判
4.响应变化胜过遵循计划
二、敏捷开发技术的原则:
1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2.即使到了开发的后期,也欢迎改变需求。
3.经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好。
4.在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
5.围绕被激励起来的个人来构建项目。
6.在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。
7.工作的软件是首要的进度度量标准。
8.敏捷过程提倡可持续的开发速度。
9.不断地关注优秀的技能和好的设计会增强敏捷能力。
10.简单使未完成的工作最大化。
11.最好的构架、需求和设计出自于自组织的团队。
12.每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。
三、敏捷开发技术的适用范围
1.项目团队的人数不能太多
2.项目经常发生变更
3.高风险的项目实施
4.开发人员可以参与决策
四、其他条件
1.团队要小,人数超过一定规模就要分拆
2.团队成员之间要紧密协作,客户也要自始至终深度配合
3.领导们得支持。敏捷需要扁平化的组织结构,更少的控制,更多的发挥项目组成员的主动性
4.写代码时要有一定比例的自动化测试代码,要花时间搭建好源码管理和持续集成环境。

使用微服务进行敏捷开发要解决哪些问题strong>
    服务被颗粒化之后,就更适合容器化了,现在docker+springboot微服务组合比较常见。
服务多了,就要管理,管理代价就会提示,加上容器化之后容器可能随时升级被整体删除替代。加上springboot的打包方式(jar)和docker镜像的方式,使得配置可变性变的困难,文件存储、日志、配置、调度,这些都要提取进行统一管理,服务的注册发现可以使用Spring的Eureka,服务调用使用Feign,你熟悉dubbo的话也可以说。如果使用容器,有专业的运维可以上K8S一套进行容器编排更好。
    比如日志使用ELK,可以在docker内启动filebeat被动收集日志,也可以在项目中直接将日志写入Logstash、kafka、ElasticSeach都有方案(高可用的架构会带来复杂度,所以要根据项目实际业务情况选型决定,任何脱离业务的技术架构都是耍流氓)。
配置中心你使用过Spring Cloud Config 、Nacos、Disconf,现在使用Apollo(或其他,你熟悉哪个就说哪个,不过Apollo现在挺主流的),这2个东西你要简单了解下,更多的你要告诉对方你为什么用这个。或者为什么从A换成了B。
    调度中心,用xxljob就够用(如果你自研过也可以讲讲,根据自身情况介绍),也OK。
    公司有独立的文件系统,你知道的提一下就行,你也可以说你直接用的阿里云OSS(或其他你熟悉的NAS、fastdfs、ceph等等)。
    服务化之后,服务变多了。全链路跟踪也变的更为必要,这个你之前的方案是SpringCloudSleuth+Zipkin,你如果熟悉Jaeger也可以说。
    监控方面,SpringCloud的Hystrix Dashboard+ Turbine。
其他方面的,根据自己情况发挥,这些应该说了不少了。只要你理解了并描述清楚,基本也差不多了。
    不是每个人都可以全盘非常熟悉所有,对于会用和没有深入研究的。你可以根据自己的岗位来折中的回复对方。比如你是项目经理,你重点在项目成员、进度和质量把控,但是你持续关注技术,也会参与重点开发,平时重点解决团队内大家都不熟悉的技术(让开发人员更专注业务开发)。如果某块有很熟悉的团队成员,可以更好的利用团队成员的能力,把人用好对项目经理来说也很重要。
相关的问题可能性太多了,平时还是要多看资料,灵活的协调人和回答问题本身也是一种能力,所以面试上不仅仅只考验纯技术,其实是对一个人的综合判断。

有一句话是这么说的:敏捷是瓷器活,你得有金刚钻。字里行间都表达了对人的能力的要求。

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2019年7月18日
下一篇 2019年7月18日

相关推荐