만화 해석 소프트웨어 개발 모델 : 고객이 실제 고객 대 예산을 원하는

HTTP : //blog.jobbole.com/113230/에서 이동

1913 년, 하나님의 미국의 산업 - 헨리 포드는 자동차 산업은 대량 생산의 시대를 입력 지금 한 세계 최초의 조립 라인을 발명했다. 도요타는 도요타 생산 시스템 (도요타 생산 시스템)뿐만 아니라 자동차 산업에 대한 고급 생산 및 경영 철학 많이 가져했다. 

고급 생산 및 경영 철학이 탄생 비록 후반의 대규모 산업 유일한 방법은 소프트웨어 산업 작은 워크샵을하지만, 개발은 소프트웨어 산업의 개발 및 관리 아이디어의 개발에서 혜택하는, 매우 빠른입니다. 그리고 자동차 산업이 성숙 개념을 많이 흡수. 

이제, 전환에서이 만화를 통해 우리를 보자,하고 소프트웨어 개발 모델의 변화의 역사를 이해하는.

 

개요

위에서 아래, 다섯 개의 객실이 이미지는 있습니다 폭포수 모델 (폭포), 애자일 개발 (민첩), 간판 (간판), 스크럼과 린 소프트웨어 개발 (린) . 

이 폭포 모델과 다른 오두막 별장뿐만 아니라 경계 외부 명확한 있으며, 여러 가지 다른 모델 안뜰처럼 불가분 관련, 단지 폭포와 애자일 개발 모델은 소프트웨어 업계는이를 거친 것을 보여준다 스테이지는, 간판 스크럼 린은 유연한 움직임에 해당하는 제품이다. 

OK, Keguan 안에, 우리가 첫 번째 방으로 찾아 주시기 바랍니다.

 

올드 Days-- 폭포 소프트웨어 개발

말을하는 것입니다 소위 폭포 모델은 소프트웨어 개발은 ​​특정 순서로 전개된다 (기존의 선형 생산 공정 : 전통적인 선형 생산 흐름을). 자동차 생산 라인과 마찬가지로, 각 부서로 각각 단일 채널 선형 흐름 전달의 조각을 확장하기 위해 직무, 작업을 수행합니다. → → → 제조 테스트, 네 단계의 수요 디자인 :이 그림을 보면, 일반적으로 나누어 져 있습니다.

在这个系统中，客户被排除在生产系统之外（围墙是密闭不透明的），它们只能从需求的接口人那里向系统输入需求（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曾在其博客中把这种心理表现称作“艺术家心结”。

 

모든 불필요한 것들 (ALL NON-ESSENTIALS가 OUT 던져 ) 현재 최소 가능한 제품에 적용 할 수 없습니다. 당신은 예술가의 (a의 걱정 수염 긴 모양) 훨씬 더 슬픈 아를 말할 

가능한 한 빨리 고객에게 제품을 제공 또는 생산에 배포뿐만 아니라, 또한 개발 운영 팀에, 지속적인 통합 (CI)를 기부, 생산 환경은 생산 (테스트 테스트 ) 개발 사례. 문제에 대한 초기 노출을 촉진 가능한 한 빨리, 지속적인 통합, 지속적인 개선 등의 수리, 그것이 좋은지 나쁜지 여부, 사용자로부터 피드백을 얻기 위해 가능한 한 빨리, 가능한 한 빨리 제품을 제공 할 수 있습니다.

 

작은 노란색 오리 - 샤프 눈 어린이 신발, 그것은 이미 테이블에 프로그래머의 가장 친한 친구가 볼 수 있습니다 추정된다. 당신은 작은 노란 오리를 몰라? : 그럼 당신은이 글을 읽어야합니다 "고무 오리 디버깅, 모든 프로그래머가 알아야 할"을 .

결론 

종종 소프트웨어 개발 및 관리, 그리고 실제 작업은 더 순수보다는 특정 유형으로 분류 할 수 없습니다. 심지어 같은 개발 모델, 또한 당신의 회사가 ~ 소프트웨어 개발을 어떻게 우리에게, 다른 팀의 실제 상황에 따라 변경 및 개선 경향이 

내 결심의 다른 견해가있을 경우, 또한 또는 당신은 또한 코멘트에 상호 작용을 환영, 그림에 새로운 의미를 참조하십시오!