漫画解釈ソフトウェア開発モデル：お客様には、実際の顧客対予算をしたいです

ます。http：//blog.jobbole.com/113230/からの振替

1913年に、神の米国の産業界は-ヘンリー・フォードが世界初の組立ラインを発明し、自動車業界は今、大量生産の時代に突入してきました。トヨタは、トヨタ生産方式（トヨタ生産方式）を作っだけでなく、自動車産業のための高度な生産と経営哲学の多くをもたらしました。 

高度な生産と経営哲学は、後半の誕生が、ソフトウェア業界唯一の方法は、大規模な産業に小さなワークショップですが、開発は、ソフトウェア業界の発展と経営思想の発展の恩恵を受けている、非常に急速です。そして、これらは、自動車産業から成熟した概念の多くを吸収しました。 

さて、切り替えからこの漫画を通して私たちを聞かせて、そしてソフトウェア開発モデルの変化の歴史を理解します。

 

概要

上から下、5つの部屋にこの画像は、ある ウォーターフォールモデル（滝）、アジャイル開発（アジャイル）、看板（かんばん）、SCRUMとリーンソフトウェア開発（リーン） 。 

このウォーターフォールモデルと他のキャビンコテージに加えて、境界の外側に明確持って、いくつかの他のモデルの中庭のように、密接に関連し、ちょうど滝やアジャイル開発モデルは、ソフトウェア業界は、2つを経験してきたことを示していますステージは、かんばん、スクラムとリーンアジャイル運動の積です。 

OK、してください内部Keguanは、私たちが最初に部屋に入って見てみましょう。

 

旧Days--滝のソフトウェア開発

言うことである、いわゆるウォーターフォールモデルは、ソフトウェアの開発は、特定の順序で展開された（従来の線形の製造工程：伝統、線形生産の流れを）。自動車生産ラインと同様に、各部門としては、それぞれ、シングル・チャンネルのリニア・フロー・デリバリーの部分を拡大するためにその職務、作業を行います。→→→製造テスト、4段階の需要のデザイン：あなたはこの絵を見て、それが一般的に分割されています。

在这个系统中，客户被排除在生产系统之外（围墙是密闭不透明的），它们只能从需求的接口人那里向系统输入需求（Client places order）。正因如此，客户无法理解生产所需的费用以及为什么交付总是会延期，因此，也难免会闹出下面这样的笑话：

客户希望你造一辆汽车，却只愿意支付一辆自行车的开发成本。 

需求接纳后进入到设计阶段：

设计定型后，进入制造阶段：

在线性的生产系统中，或者说在瀑布开发模式中，需求和设计是不可以进行修改的。工人被安排在制造系统中一个个工位上，每个人仅负责一个部件的生产和装配，就像这位盘腿坐着的“I know HTML”大哥一样，HTML 开发者只需要负责 HTML 的开发而无需，也不应该关心软件的其他部分。

喂喂喂，这位老铁，不上班玩什么球啊？哎，您也别怪他，毕竟交付件（整车/软件）还没有完成开发，测试工作自然无法开展，当然得等着咯。这也是瀑布模型最大的弊端，下游工作的开展严格依赖于上游交付件的完成情况，这无疑是一种浪费，在争分夺秒的软件开发过程中，你能忍受这种浪费吗？

汽车完成生产和测试之后，一次性交付到客户手中，完成客户的全部需求。

走进新时代——敏捷开发模式

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

 

有点书面是吧，其实很简单，敏捷开发的一个前提假设是：用户不可能在产品开发之前，设计之初就完整、明确的提出需求。期望用户在开发过程中不变更需求是不现实的。用户在开发前提出的需求，可能并不是它们最终希望得到的。

在敏捷开发中，客户会参与到软件开发的整个流程中。整个开发过程不再是一堵不透风的墙，透明是关键（TRANSPARENCY IS KEY），但是，随着越来越多的用户参与进来，越来越多的问题也暴露出来了，越来越多不着调的需求也会被提出。

敏捷开发的另一个重要概念就是迭代，所谓迭代，就是不断对产品进行细微的、渐进式的改进（Small incremental changes）。

“先给您上个小号的尾翼，用着好我再给您换个大的~”

在敏捷开发中，生产不再是线性的，开发的同时还会进行测试工作，所有人都在同时工作。尴尬等待的日子一去不复返咯~

利用敏捷模式开发出的产品，相较于传统的软件交付方式，一个显著的特点是能够及时响应客户需求的变更，不断适应新的趋势。

这不，隔壁老王喜当爹了，之前定的法拉利显得有点不稳重，宝宝也没地方坐。我们的产品经理和开发人员快速响应，轿跑变商务也不是什么大问题~~ 当然，为谁辛苦为谁忙，客户爸爸们一定要买单呀！ 

什么？您问第一稿方案是什么样的？去翻垃圾桶吧！

 

一股来自东方的神秘力量——看板

相信各位也注意到了，相对于瀑布模式的井井有条，敏捷开发在灵活的同时，也带来了一定程度的混乱。 

就在这个节骨眼上，还得请这位来自东方的神秘人物——丰田看板大师（KANBAN SENSEI）给你点拨点拨。

KANBAN，不是汉语拼音，更不是英文缩写，它来自日语“看板”，カンバン的罗马拼写：Kanban。它正是丰田生产系统的一个重要概念：

看板管理，常作“Kanban管理”，是丰田生产模式中的重要概念，指为了达到及时生产（JIT）方式控制现场生产流程的工具。及时生产方式中的拉式（Pull）生产系统可以使信息的流程缩短，并配合定量、固定装货容器等方式，而使生产过程中的物料流动顺畅。

KANBAN要求把开发中的任务，以 TODO List 的方式表现出来：

形式可以是即时贴，也可以是可视化软件等等。

在制造业中，看板也是非常重要的管理方法。也有将其称为目视化管理的。

 

SCRUM 又是什么？

Scrum原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。争球双方各有8个队员参与，各方出3名前锋队员，并肩各站成一横排，面对面躬身互相顶肩，中间形成一条通道，其他队员分别站在后面，后排队员用肩顶住前锋队员的臀部，组成3、2、3或3、4、1阵形。然后，由犯规队的对方队员在对阵一侧1码外，用双手低手将球抛入通道，不得有利于本队。当球抛入通道时，前排的3对前锋队员互相抗挤，争相踢球给本方前卫或后卫队员，前卫和后卫队员必须等候前锋将球踢回后，方可移动。

在敏捷开发领域，SCRUM是一种迭代式增量软件开发过程，它包括了一些预定义的角色：

• 产品负责人 Product Owner

产品负责人负责维护订单

• Scrum主管 Scrum Master
  

SCURM Master 对整个SCRUM 过程负责，不惜一切代价（AT ANY COST），保证团队的工作时间和计划。

 

• 开发团队 Team 

在 SCRUM 过程中，开发团队通常会进行冲刺 （Sprint），一个冲刺周期的长度通常是2-4周。

在这个冲刺过程中，开发小组专注于完成一组订单项的开发。比如：制造一个发动机

对于KANBAN 和 SCRUM，有人说 KANBAN vs SCRUM，也有人说 KANBAN+SCRUM，究竟谁是谁非，我看只有适合自己团队的才是最好的，毕竟方法和流程是为业务服务的。就这篇漫画来看，SCRUM + KANBAN 是两个避免混乱的好方法。

来来来，兄弟们，我们来开一个关于减少站会的站会~~

 

精益软件开发

第二次世界大战结束后，丰田公司前社长丰田英二曾经去美国汽车城底特律对福特生产线进行了考察，尽管福特高效的大规模生产线给他造成了很大的冲击，丰田英二还是非常理智的认识到了当时日本制造业所面临的困难。经济萧条，资源短缺，小批量差异化的需求使他不能盲目的引进这种大规模的生产方式，随后丰田公司发明并实践了一系列的管理和生产方法，这些方法在后来被统称为精益生产和管理方式（lean）。 

精益生产的思想， 简单来说就是Just In Time（JIT），也就是说，只在必要的时候，按照需求的量，仅生产必要的产品，杜绝浪费。

Eric Ries曾在《精益创业实战》中提出MVP（minimum viable product）概念，意即“最简可行产品”——用最快、最简明的方式建立一个可用的产品原型，这个原型要表达出你产品最终想要的效果，然后通过迭代来完善细节。

 

精益软件开发不再像传统的软件开发一样，耗时几年才向客户交付完整的软件。取而代之的是，优先建立一个最简可用的原型产品投放市场或交付到客户手中。

一辆最简可用的汽车是什么样子的呢？不就是四个轮子、一个方向盘、一个座椅然后一起装在底盘上么。能开、能停、能转弯不就是汽车嘛。让客户先享受到产品带来的收益是最重要的。

 

BUT!!! 

你看，这里还有一位失落的大叔

尽管MPV 的概念听上去是如此的简单，可是实施起来却没有那么容易。

 

因为在设计产品原型的过程中，很多设计师是这么做的：把他们认为的产品应当具备的功能罗列出来，然后一一排除，排定优先级，决定哪个功能要在最初的版本中出现，而哪个可以靠后一些。但设计师们往往无法真的只把最必要的功能留在初级版本中——因为诱惑太多。设计师们总希望把很cool、很有惊喜的小细节带给用户来博取赞叹，但从全局来看，其实把某些功能刻意强加进产品，是会削弱产品整体流畅性的。Mr Jamie曾在其博客中把这种心理表现称作“艺术家心结”。

 

すべての不要なものは、（すべての非ESSENTIALSがOUTスローされます ） 現在の最小利用可能な製品に適用することはできません。あなたはアーティストが（の心配のひげの長い見て）ずっと悲しいああを持っていることを言って 

、できるだけ早くお客様に商品をお届けたり、生産に展開に加えて、またDevOpsチームに、継続的インテグレーション（CI）を拠出、生産環境は、生産の（テストのテスト）開発プラクティス。、それが良いか悪いか、ユーザーからのフィードバックを得るために、できるだけ早く、できるだけ早く商品をお届け問題への早期の曝露を促進するために、できるだけ早く修復し、継続的インテグレーション、継続的な改善。

 

小さな黄色いアヒル-シャープ目の子供の靴は、それがすでにテーブルの上に、プログラマの親友が見られる推定されます。あなたは少し黄色いアヒルを知らないのですか？そして、あなたがこの記事をお読みください： 「ラバーダックのデバッグを、すべてのプログラマが知っておくべき」 。

結論 

ソフトウェアの開発と管理の実際の仕事、そして多くの場合は、純粋に特定のタイプよりも多くに分類することができません。でも、同じ開発モデル、また、あなたの会社は、それは〜ソフトウェア開発でどのように教えてください、異なるチームでの実際の状況に基づいて変更や改善傾向にあり 

ますが、私の決意の異なる見解を持っている場合、また、またはあなたはまた、コメントで対話を歓迎し、図に新たな意味を参照してください！