看见的力量 – (I) 解题的思维

转载 2016年05月31日 22:22:55

本文转自台湾李智桦老师的博客,原文地址

这篇文章;已经梗了我三个多星期了。这期间飞了二次大陆做演讲、往返几个大城市做教授敏捷开发运用在精实创业的课程。教材内容都是简体的,它们始终没有机会在国内用上,心理常想着;无论如何我都要把它们翻成繁体中文,虽然国内没有人找我讲这个课程,没关系。就把它登在大众媒体,跟大家分享。(哈哈! 写了几回草稿,但旅行中杭州的云雾缭绕还有茶香美景并没有帮上忙,文章架构依然凌乱,倒不是没有头绪而是头绪太多。最后我决定改用分段的方式来跟大家分享,希望你能接受。)

【 看见的利器 】

※「看板方法」Kanban Method

可以让我们看到工作流程,然后依据半成品的理论来持续改善、管理流程。

※「用户故事地图」User Story Mapping

可以帮助我们阶层化使用者故事并整理出需求的全貌,让我们知道该从哪里开始来解题、动手实做项目。

※「影响地图」Impact Mapping

可以把业务目标跟产品功能串接起来,然后让客户、分析师及开发团队都能看见撰写的产品功能对业务的影响在哪里。
好了;这一系列文章就是在谈上面这三个东西,三个可以协助我们看清楚需求的工具(方法)。标题似乎可以改写成:如何运用这些方法来看见需求的本质。而想谈的问题是;藉助可视化 Visualize的力量来解决项目开发时需求变来变去的困扰。用一张图示,来说明这几个工具的运用时机。(一下子;轻轻松松便可以画完的图,但改用文字来描述起来还真是有一点麻烦。我想用如何思维解题,到过程的描述分析,然后在对应到想要完成的目标,最后是拿来辅助的工具来探索它。顺序就是依照下图最左侧的那一行【思维 – 过程 – 对象 – 工具】)作为一系列文章的起头。

the-power-of-visual

第一排;思维的方式

由「极度抽象」到「抽象」再到「明确」最后写成程序代码,达到「极度明确」的解题方式。

这是我惯用的一种解题方法。解题;一开始;要先后退个几步,让自己跟问题对象的距离先拉远一点,减少一些讯息数量的干扰,让自己的视野再加大一些,能看得更全面一点。目的是;设法看见全貌。这可是自己花了好多年的时间才纠正过来的习惯,避免患了一看到问题就急着思考如何解题的习惯,就是俗称的「工程师的视野」。

在抽象与明确之间徘徊解题 –持续优化

想办法先看到。当你经常受到需求改来改去的残害时,最好的解决方法便是让它提前优化,运用paper prototype 或其他成本较低的方式先行对问题的解答进行验证,针对产品功能是否解决了真正的业务需求进行模拟或假设式的确认。我习惯在这里来回穿梭,宁可多花一些时间在抽象与明确之间徘徊,也不愿意太快进入程序的撰写阶段(你可以先做未来展示时会用的PPT,或就手头的需求先整理一些Spec,不要急着收敛),这倒不是在逃避写程序,而是担心一旦开始写了些程序代码,要回过头修正假设错误的地方,就要多花一些功夫在修正程序逻辑上头,这要赔上许多时间,有些划不来。而且程序一旦改来改去,总让人觉得好像有一种坏味道油然而生(有些不卫生,不干净的感觉),还是慢慢来,一次做对比较干净舒服些。

倒推的方式是最常用的手法。也就是所谓的从最后开始(Start at the End)。先想象你已经完成文件上所陈述的功能了,然后回过头来看看问题是否真的被解决了吗? 试着问自己;用户因此就可以如同用户故事上所描述的「因为获得了他想要的功能,从此以后便能获得这样的利益了」。(当然,用影响地图在这里最为受用,请容我下次再补做说明)

针对较头痛的问题,我通常会采用寄信给自己的方式,用email藉由时空的延迟隔离,来和自己交谈(一种自己给自己的回馈方式),用说交谈的方式来进行自我回馈,用这种稍稍客观的形式来提醒自己,让时间带来多一点的信息获得,也就是依靠延迟决策的方式(Decide as Late as Possible),让思维更为成熟一些(哈哈!很难说这种方式会有用,但一经养成习惯,心态便会稳定需多)。

明确到极度明确

第一步;先确认文件规格是正确的。我习惯先整理足够用来做coding用的文件规格(可以用测试案例(Testcase)或是单元测试来当作文件),先把测试的方案开起来做好命名,最后才是建立主程序项目,这里才是接下来的战场,这种方式有人就认为是TDD了,但我实际上只是要透过预做准备的动作,来多思考一次也就是击发二次思维(2nd thought)的动作而已。接着才是兴高采烈的进入coding 阶段。期许自己能够一次做对,让coding 变得更有趣,让code变得越简单越好(侦错)。

小结

针对上图所示,我们先谈第一排、所谓的「解题的思维」。解题;它没有标准,上面是我长期以来一直依据的Mary shaw 抽象解题法的使用心得。提供大家做参考,下一篇就会开始描述处理需求的「影响地图 impact Mapping」。会这么做,是害怕自己没有足够的时间做长篇大论,就以这种分段描述的方式,尽量抽空来做作功课了。


 

请关注微信公众号 【devopshub】,获取更多关于DevOps研发运维一体化的信息

qrcode_for_gh_b7c158df1fd1_430

举报

相关文章推荐

看见的力量 – (I) 解题的思维

本文转自台湾李智桦老师的博客,原文地址 这篇文章;已经梗了我三个多星期了。这期间飞了二次大陆做演讲、往返几个大城市做教授敏捷开发运用在精实创业的课程。教材内容都是简体的,它们始终没有机会在国...

《拆掉思维里的墙》摘录

1. 恐惧就是这样一个懦夫,当你触及他的底线,准备接受最坏的结果,然后准备跟他大干一场的时候,他早就不知道躲到哪里去了。很多我们担心的事往往不会发生,而认为不会发生的事却往往发生了,有句话叫接近胜利的...

精选:深入理解 Docker 内部原理及网络配置

网络绝对是任何系统的核心,对于容器而言也是如此。Docker 作为目前最火的轻量级容器技术,有很多令人称道的功能,如 Docker 的镜像管理。然而,Docker的网络一直以来都比较薄弱,所以我们有必要深入了解Docker的网络知识,以满足更高的网络需求。

看见的力量 – (II) 影响地图

本文转自台湾的李智桦老师的博客,原文地址 Impact Mapping 真是令人惊艳的可视化工具。等你看完这篇文章,你会爱上它的。 典故 继2011年6月Example of speci...
  • ups216
  • ups216
  • 2016-05-31 22:23
  • 1115

思索的力量

想写些东西证明自己的思考是有价值的。这些天一直在画板子->制版子->焊板子。想想自己这样的锻炼一门技术是否真的是对自己的以后有什么帮助,我心中一直都是希望成为一个写软件的高手,但是自学真的是很难,要由...

思维启发之意外的收获(发现自己思维局限和掀开二级指针的虎皮)

意外的收获(发现自己思维局限和掀开二级指针的虎皮)

探寻整合的力量

整合的力量

算法的力量万变不离其宗

作者-- 李开复 编程语言虽然该学,但是学习计算机算法和理论更重要,因为计算机算法和理论更重要,因为计算机语言和开发平台日新月异,但万变不离其宗的是那些算法和理论,例如数据结构、算法、编译原理...

奶牛的编号 - UPCOJ 3578

题目:题目描述 有N(1≤N≤1000)头奶牛,它们都被标上一个优先等级编号:1,2或3。用来表示它们喝水时的优先次序,编号为l的最优先,编号为2的其次,编号为3的最后。每天奶牛开始时排成一行,但总...

Paired Up - UPCOJ 3450

题目:题目描述 Farmer John finds that his cows are each easier to milk when they have another cow nearby f...

思维能力对于软件开发中的缺陷修复的促进作用

潜意识的思维 意识的逻辑推理  对于解决问题的能力的促进作用
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)