敏捷项目参与的几点体会-Toy模板网

这篇具有很好参考价值的文章主要介绍了敏捷项目参与的几点体会。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

截至目前，参与过几个采用敏捷开发的项目，不论项目与否，单就敏捷而言，项目管理几乎都是失败的。有这么几点感受，特此记录一下：

1. 难以逾越的沟通天堑

敏捷项目最重沟通，但是在项目过程中最难的也是沟通。某个项目，基本上有三个最重要的沟通会：sprint plan会，每日站会，sprint总结会。

sprint plan会：每个sprint，每个人都有固定的story point需要完成，每个user story分配不等的points，每个开发再各自领不同的user story。就是这么个逻辑。好了，一个US，某个开发说需要10点，另外一个说5点够了。让说5点的开发领走，他不领。让说10点的开发领走，说5点的开发又坚持说10点太多。成了讨价还价了。1个小时会，通常没有3个小时开不完。

每日站会：主要是两个议题，大家都各自干了什么，有什么blocker没有。但是每次开会都变成了问题讨论会，你出一个solution，他出一个。你说服不了他，他不承认你。

sprint 总结会：PO提出开发给出的结果和预期不符，开发就反驳说需求不足或者自己就是这么理解的。一个US往往需要几个sprint才能最终交付。

2. 披着敏捷外衣的瀑布式开发

敏捷是拥抱变化的。但是变化意味着计划的不确定性。作为乙方，往往需要根据甲方给出的需求来进行评估。一旦出现大的变更，就很麻烦。多出来的时间谁买单？到底是乙方不理解需求导致的bug，还是甲方自己对需求进行了变更？往往都是模糊不清。结果还是按照瀑布式的来，甲方写需求文档，乙方解读再评估工作量，开发+测试，最终上线。只不过采用jira来记录一下需求和bug，和excel没有区别。

3. 迷失在变更森林中

接上条。曾经参与到一个项目中，是为了某企业搭建核心数仓，项目也算大。大家在项目中，创建了大量的实验性US。比如导入一个CSV，有的开发建了python US，有的建了ETL，有的建了这个，有的建了那个。没有人再关心项目整体了，什么时候上线，哪些功能是最基本应该具备的，都不关心了。拥抱变化吗。那就全是变化。最终一个好好的项目，干成了巨大的一个POC。令人唏嘘。

4. PO和Scrum Master成了弱势群体

PO本来应是个决策者的身份，但BU派出来的PO往往只能充当个协调人。PO本身有自己的工作要做，参加这个项目相当于是承担了更过的工作，没有什么主动性。PO自己对本部门的所有业务也不是很熟悉，如果需求是其他同事的业务，PO还需要带回部门内部去确认。如果需求之间有冲突，或者需要调整优先级，那么PO基本决定不了，最后只能都当高优先级处理，所有的需求都重要，都是无法或缺的。

Scrum Master应该是个掌舵者的身份，但往往沦落为PMO。就只能督促大家记录efforts和组织会议。Scrum Master和项目经理一样，看似有个“Master/Manager”的头衔，其实什么都管不了。既没有约束大家的权力也没有给予大家利益的权力。管理项目全凭人品，赶上合作的，大家买个面子，赶上不合作的完全不搭理。

PO也好，Scrum Master也罢，基本上都是低级别员工出任，Scrum Master甚至就是个乙方。也没有什么技术背景，在一堆自以为是的开发面前，及其的弱势。文章来源地址https://www.toymoban.com/news/detail-677008.html

到了这里，关于敏捷项目参与的几点体会的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！