Inception是由Luke Barrett(管理TW欧洲,2014在车祸中丧生) and Marc(“《Agile Experience Design》”)在2004年左右初始提出的
Jonathan Rasmusson (author of The Agile Samurai) and Jeff Patton (author of User Story Mapping) both worked at ThoughtWorks
2011正式整理完成,改名Inception.
ways of working。由于多方协作以及remote造成的时差,需要密切关注各种会议如何进行,找合适的时间进行,regular的进行,保证大家的上下文始终一致。同时也包括日常的敏捷实践,定义好某个feature是否ready的标准等。
估点。估点活动一般是放在快要结束的时候,即业务和user journey已经完成,需要开发在一起估点,最后根据这些点来确认我们要上线的时间要完成哪些功能,非常考验开发的经验和专业度,是否能从业务中嗅到风险,是否能根据前期所有的workshop的上下文中找到合理的业务需求,是否能提出关键性的问题,是否能说服大家你的观点是正确的,是否能准确快速地给出答案。最后一个活动非常有意思,有3~5轮测试,每一轮测试会问开发在一个星期内是否能完成,这时候我们是基于3对pair来做的,最后从这几轮中得到平均的点数,那么这个点数就是我们一个星期内可以完成的点数。以后的每一个迭代也会根据这个点数来把故事卡从backlog里面拖到ready for dev。话说我那个时候太怂了,总觉得会给团队埋坑,一直怀疑自己估点是否真的准确。事实来看,是非常准确的。项目做到现在,除了UX在block,其他的一切非常顺利,包括我们每一张卡没有delay,包括大家对tech的熟悉度也是按照正常的节奏来的。
我们2018年7月份刚刚去Budapest做过一次inception,对我的影响非常大,也确实学到不少的东西,这里分享出来。
What & Why
因为inception的周期一般是几个星期,但是Martinfowler为了快速看到他刚出生的宝宝,即创建了lean inception。
变化让交付变得困难(客户改了又改),所以需要拥抱变化,快速验证,消除假设,达成一致 帮助我们启动200+的项目。
在项目之初
来自客户的困户:
1.我有一个想法,想跟老板申请预算做这个项目,我得拿个东西show给他
2.我知道自己要啥,要做这样一个东西,但交给你们会做成什么样,我心里没谱
3.我不知道需要花多少钱,拿到什么样的东西,也不知道什么时候会拿到
交付团队:
1.这个项目背景是啥?,这些业务需求是如何确定下来的?
2.业务需求的优先级是什么? 他们负责人最关注的是什么?
3.客户环境下,技术上风险在哪儿? 客户还需要跟哪些系统集成?
对于长期的项目可能需要每三个月做一次inception,来验证各方对需求的理解是正确的。
涉及到一个非常重要的概念,MVP(Minimum Viable Product):
参与的人员
开发(developers), 产品经理/项目经理(product managers), 设计师(designers), 需求分析是(business analysts), 客户的stakeholder),要使用该产品的用户(user),等等。不同的项目可能参加的人是不一样的。
准备Agenda
在正式开始之前,必然要做些准备,比如agenda,即每天每个时间段要做哪些excersise,做哪些workshop,由哪些人来facilitate等等,agenda由PM起草,内部沟通讨论,呈现给客户,然后再根据客户的建议做一些修改,最终定稿。这个过程我印象中持续了三周,因为我们整个team加上客户有时差的关系,沟通成本非常大。实际上这个时候考虑的东西也很多,比如supplies,participants以及技术相关的等等。
从始至终都应该关注的
Glossary & Vocabulary。专业的词汇,不论是业务上的词汇还是集成系统的词汇,都应该从始至终都有所记录,并且应该每天都要有owner去整理。
Parking Lot。在整个inception的讨论或是workshop过程当中,难免会碰撞出有价值的idea,但是没有必要在MVP就做的,我们就需要随时讲这些内容放在parking lot里面,方便今后跟踪。
RAID。Risks, Assumptions, Issues, Decisions。在开发这个产品时,有哪些风险,比如时差可能进度变慢,比如集成的系统环境没办法及时ready;有哪些需求的实现需要假设,比如使用了该产品可以替换掉某些应用;有哪些问题还没有解决的,需要哪些人来协助解决的;过程中做了哪些决定,比如该产品只在某个地方使用,只给6个人使用等。
dev应该关注哪些
整个inception时间两周,team做了非常多的事情,我不可能把每一个细节都展现出来。我更在乎dev需要关注哪些,以及在下一次inception里面如何做的更好一些。
提问。首先,开发肯定是几乎全程都参加的,除了几个meeting需要技术和业务的分开来进行。不论是客户在介绍还是UX在介绍的时候,多注意思考,考虑周到一些,提出一些有意义的问题,帮助理清上下文,这个是非常重要的。
果断并自信。在inception结束的前两天会让开发进行粗略估点,这个估点当然也要考虑全面,关键是在估的时候要表现的更加自信和果断,不至于给别人一种不专业的感觉。
Archetecture。有一天的时间是我们负责展开workshop,但是需要甲方的IT部门协作来构成我们要做的应用的技术架构。因为这个时候乙方的了解是相对较少的,这个时候我们只是一个owner,帮助该产品绘制完整的技术架构图。其中包括使用到的第三方的系统,要特别注意某个系统的某个专家是谁,在真正开发的时候不至于不知道应该找谁去合作,一样的,还是要多提问。 最后形成system context。
CFR。Cross-Functional Requirements。当然业务需求是非常重要的,我们同时也要兼顾除了业务之外的一些偏技术方向的,需要effort来做的事情。举个列子,performance,一个应用的性能不是说做好了业务就能实现的,这个是需要长期的观察并enhance的。完整的CFR:
VPN。安全是非常重要的一方面,所以在开发客户项目的同时,所有的操作都应该在VPN环境下进行,比如gitlab的提交,查看看板等等,但是一般都会有性能问题。以及包括各种账号来进行登陆验证,甚至需要客户给开发团队配置客户的电脑来方便各种活动的进行。
Path to Production。从开发的角度,应用是如何一步一步从开发到上线,到给真实的用户使用的。
设计展示。作为前端开发,一定要关注这个环节,因为设计决定了后面的开发实现。这个难度比较大,一方面要考虑是否契合业务,另外一方面要考虑设计是否合理,对用户来说是否友好,要考虑极端情况,还要考虑可能发生的错误情况。但是这个展示并非非常细节的展示,有些问题可以问,有些细节的不影响大的方向的则不需要提问,否则显的太不专业。
ways of working。由于多方协作以及remote造成的时差,需要密切关注各种会议如何进行,找合适的时间进行,regular的进行,保证大家的上下文始终一致。同时也包括日常的敏捷实践,定义好某个feature是否ready的标准等。
估点。估点活动一般是放在快要结束的时候,即业务和user journey已经完成,需要开发在一起估点,最后根据这些点来确认我们要上线的时间要完成哪些功能,非常考验开发的经验和专业度,是否能从业务中嗅到风险,是否能根据前期所有的workshop的上下文中找到合理的业务需求,是否能提出关键性的问题,是否能说服大家你的观点是正确的,是否能准确快速地给出答案。最后一个活动非常有意思,有3~5轮测试,每一轮测试会问开发在一个星期内是否能完成,这时候我们是基于3对pair来做的,最后从这几轮中得到平均的点数,那么这个点数就是我们一个星期内可以完成的点数。以后的每一个迭代也会根据这个点数来把故事卡从backlog里面拖到ready for dev。话说我那个时候太怂了,总觉得会给团队埋坑,一直怀疑自己估点是否真的准确。事实来看,是非常准确的。项目做到现在,除了UX在block,其他的一切非常顺利,包括我们每一张卡没有delay,包括大家对tech的熟悉度也是按照正常的节奏来的。
7月份的inception我到现在都记忆犹新,确实从中成长了很多,当然也从我们PM和BA小姐姐身上学到了很多,她们考虑问题非常全面,英文非常好,无障碍沟通,我呢,就是发现自己想的太少,总觉得很多事情不是开发该管的就不关注了,这个观念是非常不正确的,总要学会面对各种问题,而不只是技术方面的。当然,英文还是要持续提高才好。这也是我第一次参加inception,表现确实不理想,当发现即便是tech lead表现也没有想象中的那么好的时候,我个人心里还是稍微安慰了一点,但是,不能让别人瞧不起的啊,特别是外国友人,所以即便非常专业,没有表现出来,那也是不专业的。期待下次可以做的更好。