读《大道至简》有感(五)

大道至简第五章--实现

这一章很多术语我不明白,只能知道个大概,但是这一章在其表面下,有个对着工作者的一个提醒,就是一切都是为了实现,而非必须有一个华丽的过程。

一:实现才是工程的目的

人们做事往往忘了初心,一个工程开始之前,肯定有个人在脑海里有个实现之后的场景,那就是那个人想要实现的目的。过去人们编程,凭着兴趣,凭着热情,将一个个的想象变成现实,然而现在编程有了规模化之后,好像走着模式化的道路,有着规规矩矩的过程,华丽的“演着”,到最后,实现却一拖再拖,甚至并未实现。那么,这一切都白费了。

我认为工程不需要过多的过场,至少工作者内心知道,应该怎么样才能简单直接地去实现目的,而非将精力花在偏远的地方。

二:过程并非死模型

照搬做事,最不符合当下多变的情况。过去大师们总结出一些模型,那并非是封在玻璃的画,让人们照着模仿,而是白纸之外的框架,让人们在有限的框内尽情发挥。过程并非死模型,过程也绝非完全控制,完全照着剧本上进行的,我们可以拥有个大概的方向,灵活又不至于昏迷了头脑。在模式下多变,才是根本。

我知道这个专业最有价值的,就是创新。学的东西虽然是死的,但具有灵活组合功能,好比“我的世界”这个游戏的创始人仅仅无聊,独自用java编出了闻名世界的游戏,又其游戏无限的可能萌生每个人的创意,最后微软花了二十多个亿去收购这款游戏。种种说明,达到目的,并非大做文章得去讲述它,而是简单明了地去实现它,就行了。

三:学骨子,而非学架子

学习是一直在进行的,当面对新的东西的时候,总是会从模仿是进行接触,人们总是从一开始就去学别人最好的,最后却什么也没学到。反而从基础学起的人,一步步地踏实地坚持了下去。在那些复杂繁华的东西背后,存在着最简单的道理或者原理,那才是精华,那才是他们创造的源泉。那么学习,就是学这个最精华的部分,最基础的部分,架子是我们去体会的,骨子才是我们融入头脑的,融入自身的。

四:工程是用来组织的

前面说过工程不是用来作为毫无用处的过场的,而是一个团体的组织,让实现目的有个更加高效的效率。有着目标后,工程就开始启动,各个人员各司其职,才不至于工作量的冲突或者丢失,这就是工程的目的。

编程工作中,最不需要的就是华而不实,这一章的目的,就是告诫大家,实现目的才是一切的根本。章节之首,写着“虚有其表耳”,这个道理,我现在能懂,写下这篇读后感,望多年后的自己,再次来此看一下自己写的所思所感,时时刻刻提醒自己。

时间: 2024-10-12 22:35:24

读《大道至简》有感(五)的相关文章

《用户故事与敏捷方法》阅读笔记01

用户故事与敏捷方法第一章是对用户故事的概览.      首先第一个问题用户故事是什么?用户故事描述了对用户.系统或软件购买者有价值的功能.用户故事由三个方面组成,包括1 .一份书面的故事描述,用来做计划和作为提示.2.有关故事的对话,用于具体化故事细节.3.测试,用于表达和编档故事细节且可用于确定故事何时完成.      然后第二个问题细节,故事的细节可以用另外的用户故事来描述,多个小故事远远胜于一个庞大的故事.书上将大的故事成为史诗故事,那些史诗故事可以分为多个小故事.例如将"用户可以搜索工作

《用户故事与敏捷方法》读书笔记

1.采用用户故事这一方法,是从写下两条信息开始的:每一个系统需要实现的目标和实现那个目标所需要的大致成本. 2.3C原则:"card.conversation.confirmation",任务卡片.交流.确认 3.大量预先的需求收集和文档会议很多方式导致项目失败.最常见的是需求文档变成软件开发的目的.应当只在对交付软件有用时才写需求文档. 4.对用户故事的最佳诠释:卡片包含故事的文字描述,然后需求细节要在"对话"中获得,并在"确认"部分得以记录.

读《用户故事与敏捷方法》有感(五)

今天,读到了次本书的第三部分--经常讨论的话题,用户故事不是什么,用户故事的优势与不良征兆. 第一,用户故事不是软件需求规格的指南,这种需求规格指南强调的是"系统应该--",而且对于需求规格指南而言,在写下需求之前,每个需求的成本是不可见的.典型的情况是,一个或几个分析师花两三个月时间(通常更长时间)编写出冗长的需求文档.随后把文档交付给程序员.这时程序员告诉分析师(消息会被转告给用户),完成项目要24个月,而不是分析师所希望的6个月.在这种情况下,分析师在编写团队没有时间开发的四分之

读《用户故事与敏捷方法》有感(四)

在一个大型项目中,尤其是有许多用户角色的项目,确定用户故事有时让人无从下手.我发现最好的办法是考虑每一个用户角色,了解用户使用我么软件的目的. 所以编写故事的时候注意以下几点.第一,根据实现时间来确定故事规模,逆向专注于最需要你关注的领域.通常,这意味着要把注意力放在那些即将发生的事情上,而不是放在更远的将来才发生的事情上.对股市而言,要基于故事实现的时间跨度,以不同的层次来编写故事.例如,对于下面几轮迭代的故事,它们的大小应该能够安排进那几轮迭代中,而对于更遥远的故事,它们可能会更大,但精准度

用户故事与敏捷方法①

在读这本书之前,自己觉得有点好奇,用户故事指的是什么呢,读完之后,有了体会:用户故事描述了对用户.系统或者软件购买者有价值的功能.它由3方面组成:1>一份书面的故事描述,用来做计划和作为提示:2>有关故事的对话,用于具体化故事细节:3>测试,用于表达和编档故事细节且可用于确定故事何时完整. 它总共分为了五大部分来介绍: 第一部分是一些简单的概念或者使用故事的细节方面,比如如何编制用户故事,有哪些细节要求:在故事中找出用户角色模拟使用情节:怎样搜集到用户故事,通过各种途径:如何找到用户代理

《用户故事与敏捷方法》阅读笔记06

第八章 估算用户故事 故事点有一个很好的特性是团队可以定义自己认为合适的故事点,一个团队可能定义一个故事点为一个理想日的工作,也可能定义为一个理想周的工作.故事点有很多意义,所以故事点代表时间的模糊单位. 故事估算应该由整个团队集体来完成.故事估算属于团队集体有两个原因,第一个,还不确定团队中谁负责完成这个故事,第二个,团队决定的估算可能比个人估算更有用.在估算时,作者介绍了他所用的方法迭代的方式进行估算.在初步估算好后,成员进行讨论,然后进行下一轮的讨论,最终达成一致. 三角测量.估算一个故事

用户故事与敏捷方法读书笔记02

开发软件可以通过编写用户故事来确立开发的目标和方向.而在编写故事前首先要对所有用户进行分类,根据角色的不同属性进行分类.步骤为:1.通过头脑风暴,列出初始的用户角色集合:(要坚持‘已确认的角色代表的是单一用户’的原则)2.整理最初的角色集合:(确认角色之间的关系:用户角色定义的是人而不是外部系统)3.整合角色:(对于完全重叠的用户进行重新定义,舍弃对系统成功作用不大的角色)4.提炼角色(根据角色特征来建立角色的模型). 编写故事之前需要搜集故事,通过与用户沟通来发现故事.可以像用渔网捕鱼一样获取

《用户故事与敏捷方法》阅读笔记05

第13章 用户故事的优势 从上一章我们得知,处理需求的方法多种多样,但是我们为什么要选择用户故事?因为它会带来多种好处: ①用户故事强调口头沟通:自古以来,口头表达是十分重要的.而且相比于书面书写的易产生歧义,口头表述更见简单明了,需求文档也是如此. ②人人都可以理解用户故事:相比于一些墨守成规的软件需求里的技术术语,用户故事使用的语言更容易使用户理解,简洁明了,同时更能增强用户对故事的记忆. ③用户故事的大小适合做计划:其他类型的需求分析关联性太强,并且还比较笼统,大小不能称得上是易实现的适合

用户故事与敏捷方法阅读笔记二

第8章 估算用户故事 使用故事点 我们用“速率”(velocity)来代表一个团队在一轮迭代中完成(或期望完成)的故事点数.因此,务必保证每次迭代的故事点的度量是一致的. 如果用结对编程呢? 团队用不用结对编程,对故事点估算并没有影响.团队可以采用理想结对日或理想个人日来估算故事点,区别会表现在速率值上. 一些提醒 一个故事(可能是一个史诗故事)分解成一些小故事后,这些小故事估算的总和不需要与开始那个故事或史诗故事的估算相等. 类似地,一个故事分解成一些任务.这些任务估算的总和不需要与故事的估算

《用户故事与敏捷方法》阅读笔记03

第10章 迭代计划 制定出上一章的成果发布计划,我们可以顺利地将粗细度的故事分配到多伦迭代中.多伦迭代是发布计划的进一步激化,但只在迭代即将开始的时候才开始做迭代计划.为此,迭代计划会议必不可少,客户以及团队的所有人员都要参与其中.在这一过程,各个人员仔细讨论每个故事,从故事中分解出任务,开发人员承担每个任务的职责.这个会议是客户为团队调整故事的最佳时机,但是切记项目团队不要随意被客户打乱开发计划. 任务的大小没有强制的范围(例如:3小时到5小时).相反,从故事中分解任务,用来帮助估算或鼓励多个