The better ways of developing software Kevin Kim hckim@invesume.com
Introduction Software Developer 2
Introduction Agile Coach 3
Introduction 오픈소스커뮤니티 하모니카 Goal 개방형 OS 의한국어사용자접근성을높여개방형 OS 환경보급확산을위한프로젝트 ( http://hamonikr.org ) History 2006 2014 2015 2016 2017 하모니카 Beta 하모니카 RC 하모니카 2.1 64bit RC1 하모니카커뮤니티배포판 (2014.11.27) (2015.02.17) 하모니카 2.1 32bit RC1 Moordev Mate 64bit (2016.01.25) 1.0(2017.12.11) 하모니카 RTM (2015.07.15) 하모니카키아나 (Qiana) 하모니카 2.1 로사 RC1 하모니카커뮤니티배포판 Moordev Mate 64bit 1.0 4
Introduction 오픈소스거버넌스컨설팅및교육 5
Software Development Methodology 6
Software Engineering 소프트웨어공학 소프트웨어공학 (SE, Software Engineering) 은소프트웨어의위기를극복하기위한방안으로연구된학문이며여러가지방법론과도구, 관리기법들을통하여소프트웨어의품질과생산성향상을목적으로한다. 1968 년 NATO 회의에서소프트웨어의위기를타개해야한다는의견이나왔고처음으로소프트웨어공학이라는용어가사용되었다 소프트웨어의위기를극복하기위한방안으로연구된학문이며여러가지방법론과도구, 관리기법들을통하여소프트웨어의품질과생산성향상을목적 7
Software Engineering 소프트웨어개발방법론과프로젝트관리 - 소프트웨어개발방법론은마케팅과같이성공을위해서해야할여러일들에대한전략적인측면의일 (Strategic Discipline) - 프로젝트관리는영업과같이성공을위한운영적인측면의일 (Operation Discipline) Waterfall, OOP, CBD, UP, Agile PMBOK, PRINCE2 8
Software Engineering Different Goal 소프트웨어개발방법론 사용자의요건을명확히하기위한최선의방법은? 품질표준에맞추기위해서해야할일은? 각각의애플리케이션을지원하기위하여필요한기술은? 프로젝트관리 팀구성은어떻게하는것이좋은가? 일이얼마나걸릴것인가? 목표대로진행되는일의기준은? 9
Software Engineering Waterfall 소프트웨어개념 요구사항분석 시스템개발에필요한태스크들을한눈에파악할수있다. 각단계의완료정의가매우명확하다. 대규모시스템개발프로젝트의프레임워크를제공한다. 아키텍처설계 상세설계 구현과디버깅 실제시스템개발패턴에맞지않는다. 이전단계에대한오류수정및추가개선이용이하지않다. 종종엄청난양의문서작업을야기한다. 시스템테스트 10
Software Engineering Real world 최소한프로그램을개발하여내놓는면에서는가장빠른방법이다. 프로그래머들은이방법을가장선호한다. 관리자의입장에서이러한방법을사용하는프로그래머가가장능률이뛰어난것으로보인다. 시스템명세서 ( 없을수도있음 ) 짜보고고치기 출시 ( 못할수도있음 ) 프로그램의유지및개선이어렵다. 프로그래머의시간과노력이가장비효율적인방법이다. 시스템상의오류, 누락, 개선요구사항이발견되었을때는이미늦었다. 오류에대한검증및수정이불가능할정도로많이발견되는경우가종종있다 11
Software Engineering Another Methodology 초기개념 초기프로토타입설계와구현 승인받을때까지프로토타입개선 프로토타입완성과출시 프로젝트의산출물을정의하기어렵다. 기존의일정계획을적절히수정하여적용하여야한다. 12
Software Engineering Another Methodology 하지만나선형모델은프로젝트기간이오래걸린다. 반복단계가길어질수록프로젝트관리가어렵다. 또한위험관리가중요한만큼 " 위험관리 " 전문가가필요. 13
Think together 14
범위, 일정, 비용의준수 가장중요한가치는무엇인가? 초기에설정한업무범위와일정, 비용은모두준수했지만시장에서별로가치가없는제품을만들거나조직에서아무도사용하지않는시스템을만든다면이프로젝트는성공인가? 시장및고객에게무엇이가치가있는지에따라신축성있게조정해야한다. 15
일정과예산의합리성 일정과예산은정확하게추정할수있나? 개발자마다생산성이다르다는것은대부분알고있는사항이지만비용산정에처음부터정확하게반영할수는없다. 소프트웨어공학포털 https://goo.gl/8wuzpp 프로젝트시작전에는생산성차이를추정하여반영하고프로젝트를수행하면서오차를계속줄여나가야한다. 하지만, 비용산정을프로젝트시작전에한번하고계약후에는하지않는경우가대부분이다. 초기에하는비용산정은추정일뿐이다. 프로젝트가시작되면예측하지못한변수와다양한외부요인으로얼마든지달라질수있다. 불확실성의원추 (Cone of uncertainty) 16
요구사항의정의 모든요구사항은반드시구현해야하나? 발주자들은초기에요구사항을상세하게제시하기어렵기때문에포괄적인요구사항을정해놓고발주한다. 요구분석 46.3% 그리고업무범위에서변경되는상세요구사항의변경들을개발업체가모두수용해주기를바란다. 이러한문화가개선되지않으면고객과애자일개발방법론을적용하기는어렵다. 프로젝트실패의원인 17
상습적야근의생산성효과 야근하지않으면열심히일하지않는다? 제조업중심으로발전한우리나라의산업구조는업무성과가투입시간에비례한다고여기는경영자가많은것이우리사회의현실. 근무시간에설렁설렁일하고늦게퇴근하는사람이더열심히일하는사람으로평가받는오류. 소프트웨어개발은사무실에오래있는다고성과가나타나지않는다. 지식서비스산업은고도의집중력을요구하거나다양한커뮤니케이션을해야할때가많다. 단기간의야근은생산성증대를가져올수있지만장기적인야근은생산성향상이되지않는다. 18
기존프로젝트수행방식의한계 프로젝트초기에구체적인요구사항을도출하기어렵다. 프로젝트중간에발생하는요구사항의변경을반영하기어렵다. 프로젝트과정중중간산출물을많이요구한다. PM 중심의명령과통제방식때문에구성원은수동적으로바뀌고, 커뮤니케이션은매우부족하다. 19
고객의요구사항변경요청 더이상요구사항은변경되면 절대안됩니다! 20
Agile Methodology Scrum Kanban 21
Agile Methodology 22
What Is Agile? http://agilemanifesto.org/principles.html 2001 년 2 월, 애자일연합 (Agile Alliance) 이라는그룹에서 애자일선언문 이라는공동의선 언서를만들어냅니다. 이문서는지금까지도애자일소프트웨어개발의기초원칙과정신으로 이야기되고있는중요한선언서입니다. 아래는해당선언서를번역한내용입니다. 우리는, 소프트웨어를개발하면서그리고또한다른사람의개발을도와주면서소프트웨어를개발하는더나은방법들을찾아나가고있다. 이작업을통해다음과같은가치를추구하게되었다. 프로세스나도구보다는개인과상호작용을, 포괄적인문서보다는작동하는소프트웨어를, 계약에대한협상보다는고객과의협력을, 계획을고수하기보다는변화에대응을더욱가치있게여긴다. 이말은, 전자도가치가있긴하지만, 우리는후자쪽에더많은가치를둔다는것을의미. 23
12 Principles of Agile 1. 우리의최우선순위는, 가치있는소프트웨어를일찍그리고지속적으로전달해서고객을만족시키는것이다. 2. 비록개발의후반부일지라도요구사항변경을환영하라. 애자일프로세스들은변화를활용해고객의경쟁력에도움이되게한다. 3. 작동하는소프트웨어를자주전달하라. 두어주에서두어개월의간격으로하되더짧은기간을선호하라. 4. 비즈니스쪽의사람들과개발자들은프로젝트전체에걸쳐날마다함께일해야한다. 5. 동기가부여된개인들중심으로프로젝트를구성하라. 그들이필요로하는환경과지원을주고그들이일을끝내리라고신뢰하라. 6. 개발팀으로, 또개발팀내부에서정보를전하는가장효율적이고효과적인방법은면대면대화이다. 7. 작동하는소프트웨어가진척의주된척도이다. 8. 애자일프로세스들은지속가능한개발을장려한다. 스폰서, 개발자, 사용자는일정한속도를계속유지할수있어야한다. 9. 기술적탁월성과좋은설계에대한지속적관심이기민함을높인다. 10. 단순성이 -- 안하는일의양을최대화하는기술이 -- 필수적이다. 11. 최고의아키텍처, 요구사항, 설계는자기조직적인팀에서창발한다. 12. 팀은정기적으로어떻게더효과적이될지숙고하고, 이에따라팀의행동을조율하고조정한다. 24
Advantages of Agile 1. 변경이포용됨 : 계획주기가짧으면프로젝트중언제든지변경사항을수용하고수락하는것이쉽습니다. 수주잔고를수정하고우선순위를다시정할수있는기회가항상있기때문에팀이수주내에프로젝트변경사항을도입할수있습니다. 2. 최종목표가명확하게정의되지않은프로젝트에대해서는민첩합니다. 프로젝트가진행됨에따라목표가밝혀지고개발은이러한진화하는요구사항에쉽게적응할수있습니다. 3. 더빠른고품질제공 : 프로젝트를반복단위 ( 관리가능한단위 ) 로분해하면팀이고품질개발, 테스트및공동작업에집중할수있습니다. 반복할때마다테스트를수행하면버그를확인하고더빨리해결할수있습니다. 또한고품질의이소프트웨어는일관되고연속적인반복으로더빨리전달될수있습니다. 4. 강력한팀간상호작용 : Agile은빈번한의사소통과대면인터랙션의중요성을강조합니다. 팀은함께일하고사람들은프로젝트의책임을맡을수있습니다. 5. 고객은전달되는작업을보고입력을공유하고최종제품에실제영향을미칠수있는많은기회를얻습니다. 그들은프로젝트팀과긴밀히협력하여소유권을얻을수있습니다. 6. 지속적인개선 : 민첩한프로젝트는전체프로젝트에서사용자및팀원으로부터피드백을유도하 므로학습한교훈은향후반복을개선하는데사용됩니다. 25
Disadvantages of Agile 1. 납기일을고정하기어려울수있습니다. 애자일프로젝트관리자는종종작업우선순위를재지정하기때문에원래배포예정이었던일부항목이완료되지않을수도있습니다. 2. 팀은지식이있어야합니다. 애자일팀은일반적으로작기때문에팀구성원은다양한영역에서고도로숙련되어야합니다. 3. 초기적응기간 - Agile은개발팀이완전히프로젝트에전념할때가장성공적입니다. 애자일프로세스전반에걸쳐적극적인참여와협업이필요하며이는전통적인접근방법보다시간이오래걸립니다. 또한개발자가프로젝트의전체기간을확약해야한다는것을의미합니다. 4. 문서는무시될수있습니다. 포괄적인문서보다작업소프트웨어를선호하므로일부팀원은문서작업에만집중하는것이덜중요하다고느낄수있습니다. 애자일팀은문서와토론사이에서적절한균형을찾아야합니다. 5. 최종제품은매우다를수있습니다. 초기애자일프로젝트는최종계획이없을수있으므로최종제품은원래의도했던것과많이다르게보일수있습니다. 애자일은매우유연하기때문에진화하는고객피드백을기반으로새로운반복이추가될수있습니다. 이로인해최종산출물이매우달라질수있습니다 26
The Agile Development Cycle 1. 계획 : 아이디어가실행가능하고실현가능한것으로간주되면프로젝트팀이모여기능을식별합니다. 2. 요구사항분석 : 이단계에서는비즈니스요구사항을파악하기위해관리자, 이해관계자및사용자와의많은회의가필요합니다. 3. 설계 : 시스템및소프트웨어설계는이전단계에서식별한요구사항을토대로작성됩니다. 4. 구현, 코딩또는개발 : 이단계는기능을만들고테스트하고배포를위한반복일정을계획하는것입니다 5. 테스트 : 코드가개발되면요구사항에대해테스트를거쳐제품이실제로고객의요구사항을충족시키고사용자이야기와일치하는지확인합니다. 6. 배치 : 테스트가끝나면제품을고객에게제공하여제품을사용할수있도록합니다. 그러나배포는프로젝트의끝이아닙니다. 고객이제품사용을시작하면프로젝트팀이해결해야할새로운문제가발생할수있습니다. 27
Methodologies to Implement Agile 익스트림프로그래밍 (Extreme Programming, XP) : 익스트림프로그래밍 (Extreme Programming) 은진화하는고객요구사항에대한품질과응답성을개선하기위한소프트웨어개발유형입니다. XP의원칙은피드백을포함하고, 단순성을가정하고, 변화를수용합니다. Lean Software Development (LSD) : 린 (Lean) 소프트웨어개발은 7 가지원칙, 즉낭비를제거하고, 학습을확대하고, 가능한한늦게결정하고, 가능한한빨리전달하고, 팀에권한을부여하고, 무결성을구축하고, 전체를볼수있는특징이있습니다. Kanban : 일본에서 ' 시각적기호 ' 또는 ' 카드 ' 를의미하는 Kanban은 Agile을구현하는시각적프레임워크입니다. 현재시스템에대한작고지속적인변경을촉진합니다. 그원칙은다음과같습니다 : 워크플로우를시각화하고, 진행중인작업을제한하고, 플로우를관리및강화하고, 정책을명시적으로만들고지속적으로향상시킵니다. Scrum : Scrum은 Agile을구현하는가장보편적인방법중하나입니다. 그것은결코변하지않는일련의역할, 책임및회의를따르는반복적인소프트웨어모델입니다. 스프린트는대개 1 ~ 2 주간지속되므로팀이소프트웨어를정기적으로제공할수있습니다. 기타 Feature-driven development (FDD), Adaptive system development (ASD), Dynamic Systems Development Method (DSDM), Crystal Clear 등의방법론도있음. 28
What is the better way to Agile 29
Scrum Methodology 30
Scrum Methodology Scrum은 Agile의하위집합이며 Agile을구현하기위한가장널리사용되는프로세스프레임워크중하나입니다. 복잡한소프트웨어및제품개발을관리하는데사용되는반복적인소프트웨어개발모델입니다. 1 ~ 2 주간지속되는스프린트 (sprint) 라는고정길이반복을통해팀은정기적인종지에소프트웨어를제공할수있습니다. 각스프린트가끝나면이해관계자와팀구성원이만나다음단계를계획합니다. Scrum은절대변하지않는역할, 책임및모임을따릅니다. 예를들어스크럼은스프린트계획, 데일리스탠드업, 스프린트데모및스프린트회고와같은각스프린트에구조를제공하는 4 가지의식을요구합니다. 각스프린트동안팀은작업게시판이나번다운차트와같은시각적게시물을사용하여진행상황을보여주고점진적피드백을받습니다. 31
Advantages of Scrum 투명성과프로젝트가시성향상 : 매일회의를통해팀전체에서누가무엇을하고있는지잘알고많은오해와혼란을피할수있습니다. 문제는사전에확인되어팀이해결하기전에해결할수있습니다. 팀책임성증대 : 스크럼팀에게무엇을언제어떻게해야하는지알려주는프로젝트관리자는없습니다. 대신팀은각스프린트에서수행할수있는작업을집합적으로결정합니다. 그들은모두협력하고서로를도우며협업을개선하고각팀구성원이독립적으로활동할수있도록합니다. 변화를수용하기쉬운짧은스프린트와지속적인피드백으로변화에쉽게대처하고적응할수있습니다. 비용절감효과증대 : 지속적인의사소통을통해팀은모든문제와변화가발생하자마자이를인식하여비용을절감하고품질을향상시킵니다. 작은덩어리로기능을코딩하고테스트함으로써지속적인피드백이있으며실수를고칠때까지일찍수정될수있습니다. 32
Disadvantages of Scrum 범위초과의위험성 : 일부스크럼프로젝트는특정종료일이없어예상한범위를초과하는업무가발생할수있습니다. 완료날짜가없으면이해관계자는계속추가기능을요청하려고할수있습니다. 팀은경험과헌신을요구 : 정의된역할과책임으로팀은성공을위해스크럼원칙을숙지해야합니다. Scrum Team에는정의된역할이없으므로 ( 모든사람이모든것을처리합니다.) 기술적인경험이있는팀구성원이필요합니다. 또한팀은매일스크럼회의에전념하고프로젝트기간동안팀에머무를필요가있습니다. 스크럼마스터의존성높음 : 스크럼마스터는프로젝트매니저와매우다릅니다. 스크럼마스터는팀에대한권한이없습니다. 그또는그녀는자신이관리하는팀을신뢰해야하며그들에게무엇을해야한다고말하지않아야합니다. 스크럼마스터가팀을제어하려고하면프로젝트가실패합니다. 33
Roles in Scrum 제품소유자 : 스크럼제품소유자는자신이무엇을만들고싶은지에대한비전을가지고있으며팀에그비전을전달합니다. 제품소유자는비즈니스및시장요구사항에중점을두어모든작업을우선시해야합니다. 스크럼마스터 : 미팅을조직하고로드블록및문제를처리하며제품소유자와협력하여제품백로그가다음스프린트에대비할수있도록보장해야합니다. 또한스크럼마스터는팀이스크럼프로세스를따르는지확인합니다. 팀구성원에대한권한이없지만프로세스에대한권한이있습니다. 스크럼팀 : 스크럼팀은 5 명에서 7 명으로구성됩니다. 전통적인개발팀과달리프로그래머, 디자이너또는테스터와같은별개의역할은없습니다. 모두가함께일련의작업을완료합니다. 스크럼팀은각스프린트에대한계획을소유하고있습니다. 그들은각반복에서얼마나많은작업을완료할수있을지예상합니다. 34
Steps in the Scrum Process 백로그수정 / 정리 : 한스프린트가끝나면팀과제품소유자가만나서다음스프린트준비가되었는지확인한다. 팀은관련이없는사용자스토리를제거하거나, 새로운스토리를작성하거나, 스토리의우선순위를재평가하거나, 사용자스토리를작은태스크로분리할수있습니다. 이 ' 그루밍 ' 회의의목적은관련성이높고상세한항목을포함하고프로젝트의목표를충족시키는항목만백로그에포함되도록하는것입니다. Daily Scrum meetings : Daily Scrum 은 15 분간의스탠딩미팅으로각팀구성원이자신의목표와쟁점에관해이야기합니다. 데일리스크럼은매일스프린트중에발생하며팀을계속추적하도록도와줍니다. 스프린트검토모임 : 각스프린트가끝날때팀은스프린트검토회의에서완료한작업을제공합니다. 이회의에는보고서또는 PowerPoint 프레젠테이션이아닌실시간데모가있어야합니다. Sprint 회고 : 각스프린트가끝날때팀은 Scrum 이얼마나잘작동하고있는지파악하고다음스프린트에서변경해야할사항에대해이야기합니다. 팀은스프린트중에무엇이잘되었는지, 무엇이잘못되었는지, 어떻게다르게할수있는지에대해이야기할수있습니다. 35
Steps in the Scrum Process 활동프로젝트계획수립이터레이션제로제품백로그도출및관리릴리즈계획이터레이션계획일일스탠드업미팅 작업고객은목표, 제약조건및성공지표를포함해프로젝트가필요한이유를식별하고이를프로젝트이해관계자와합의. 개발프로세스가시스템아키텍처와함께정의된다. 최초릴리즈계획합의. 충분한사용자스토리가첫번째이터레이션을위해작성. 프로젝트에참여할모든사람과지원인프라준비. 이터레이션계획을수립하기전에제품백로그에충분한사용자스토리들을확보해적절한부분집합이다음이터레이션에서의구현을위해선택될수있도록선정. 최초릴리즈계획에대한변경및확장. 향후릴리즈의내용은고객및사용자요구사항뿐만아니라기술적제약사항및의존성을기반으로결정. 제품책임자는일반적으로릴리즈계획및사용자스토리우선순위기반으로해당이터레이션에서구현하고자하는사용자스토리를선택. 팀은선택된사용자스토리구현을위해요구되는노력을추정. 이터레이션백로그의내용이합의된후팀은스토리인도방법을계획. 매일 15분으로제한된시간동안모든팀원이이미팅에참석. 각팀원은팀리더의도움을받아지난미팅이후에달성한것, 다음미팅전에달성하고자하는것및작업진행에방해가되는모든것을공유. 팀리더는보고되는진행상황과작업상황판이일치하는지확인. 36
Steps in the Scrum Process 활동개발스토리테스팅인수테스팅회고미팅배포운영및유지보수 작업이터레이션백로그에있는사용자스토리를설계하고코드화. 개발자는사용자스토리와관련된요구사항을완전히파악하고팀리더와의합의로문서화된관련설계를작성. 사용자스토리는이설계에기반해코드화되고단위테스트가작성되며정적분석을통과한코드는빌드 (build) 에포함된다. 이터레이션백로그에있는사용자스토리에대해테스트. 리스크에기반한접근법을활용해관련된 ( 기능적및비기능적 ) 테스트를수행. 가장높은리스크의테스트케이스는테스트를자동화해회귀테스트자동화. 인수기준에기반한인수테스트가팀에의해개발돼인수테스팅을수행하도록사용자에게제공. 사용자는피드백을제공. 매이터레이션이종료될때개발프로세스 ( 및기타지원프로세스 ) 에대한잠재적개선사항을식별하고합의. 배포동안팀은소프트웨어를생산환경에설치하고확인. 사용자와함께작업해사용자의새배포물인수를지원. 시스템사용의지원, 시스템변경에대한요구사항대응 37
Tools and Methods in Scrum 스크럼보드 : 스크럼작업보드로스프린트백로그를시각화할수있습니다. 보드는다른형태를가질수있습니다. 전통적으로인덱스카드, Post-It 노트또는화이트보드가포함됩니다. 스크럼보드는일반적으로수행할작업, 진행중인작업, 완료등의세가지범주로나뉩니다. 스크럼팀은전체스프린트동안보드를업데이트해야합니다. 사용자스토리 : 사용자스토리는고객의관점에서소프트웨어기능을설명합니다. 여기에는사용자유형, 원하는내용및원하는이유가포함됩니다. < 사용자의유형 > 으로서 < 목표를달성할수있도록 > < 작업수행 > 을원한다의구조로작성 번다운차트 : 번다운차트는모든수행된작업을나타냅니다. 백로그는일반적으로가로축을따라시간과함께세로축에있습니다. 남은작업은스토리포인트, 이상적인날, 팀일또는기타메트릭으로나타낼수있습니다. 번다운차트는계획에따라일이진행되지않는경우팀에경고하고의사결정의영향을보여줍니다. 38
Scrum board in Scrum 39
User story in Scrum 사용자는이메일로로그인할수있다. 사용자는견적요청후안내메일을받을 수있다. 출처 : http://www.codeproject.com/articles/674450/agilesoftware-development-steps-to-work-with-requ 40
burndown chart in Scrum 41
extreme Programming(XP) 42
extreme Programming, XP Practices Whole Team Planning Game Customer Tests Small Releases Simple Design Test-Driven Development Pair Programming 43
Waterfall 44
What Is Waterfall? Waterfall 방법론은순차적인선형프로세스를따르며소프트웨어엔지니어링및 IT 프로젝트를위한시스템개발라이프사이클 (SDLC) 의가장보편적인버전입니다. 간트차트 ( 각작업의시작날짜와종료날짜를보여주는막대차트유형 ) 를사용하여가끔계획됩니다. 단계중하나가완료되면개발팀은다음단계로이동합니다. 팀은처음부터전체프로세스를시작하지않고이전단계로돌아갈수없습니다. 그리고팀이다음단계로넘어가기전에요구사항을검토하고승인해야할수도있습니다. The Waterfall 모델은변화가너무비싸거나때로는불가능할수있는고도로구조화된환경인제조및건설산업에서시작되었습니다. Waterfall에대한최초의공식적인설명은 1970 년기사에서 Winston W. Royce가결함이있는소프트웨어모델에대해설명. 45
Advantages of Waterfall 간편한사용및관리 : Waterfall 모델은각프로젝트마다동일한순차패턴을따르므로사용하기쉽고이해하기쉽습니다. 팀은 Waterfall 프로젝트를진행하기전에사전지식이나훈련이필요하지않습니다. 폭포수모델은단단한모델입니다. 각단계마다구체적인결과물과검토가있으므로관리및제어가쉽습니다. Waterfall의모든단계에시작점과종료점이있으며, 이해관계자및고객과의진전을쉽게공유할수있습니다. 코드를작성하기전에요구사항과디자인에중점을두어팀은마감기한이누락될위험을줄일수있습니다. 잘문서화된접근법이필요합니다. Waterfall에서는모든단계에대한문서화가필요하므로코드및테스트의논리를보다잘이해할수있습니다. 또한향후프로젝트이해관계자가특정단계에대한세부정보를볼필요가있는경우에도산출물이도움이됩니다. 46
Disadvantages of Waterfall 변경사항을쉽게수용할수없습니다. 일단팀이단계를완료하면되돌릴수없습니다. 이들이테스트단계에도달하고요구사항단계에서기능이누락되었다는것을알고있으면되돌아가서수정하는것이매우어렵고비용이많이듭니다. 단계를마치지않으면마지막까지소프트웨어가제공되지않습니다. 결과적으로이해관계자는수명주기의후반부까지작업소프트웨어를보지못하게됩니다. 정확한요구사항을수집하는것은어려울수있습니다. Waterfall 프로젝트의첫번째단계중하나는고객및이해관계자와대화하고요구사항을식별하는것입니다. 그러나프로젝트초기에원하는것을정확히찾아내는것은어려울수있습니다. 종종고객은조기에원하는것을모르고대신프로젝트가진행됨에따라요구사항을파악하고식별합니다. 47
Stages of Waterfall 48
Kanban 49
What Is Kanban? Kanban 은 ' 시각적표시 ' 또는 ' 카드 ' 의일본 어입니다. Agile을구현하는데사용되는시각적프레임워크로서시점및수행을보여줍니다. 현재시스템에대한작고점진적인변경을권장하며특정설정이나절차가필요하지않습니다. Kanban은 Toyota Production System 및 Lean Manufacturing에서영감을얻었습니다. 1940 년대도요타는슈퍼마켓의재고가얼마나많은지를모델화하여엔지니어링프로세스를개선했습니다. 소프트웨어팀에서칸반은개발작업중 (WIP) 이재고의개념대신사용되며팀의시각간판보드에 ' 빈공간 ' 이있을때만새작업을추가할수있습니다. Kanban은 WIP의양과팀의역량을조화시켜유연성, 투명성및산출물을향상시킵니다. Kanban은 Agile의한가지방법입니다. 50
About the Kanban Board 51
Advantages of Kanban 유연성향상 : 칸반은진화하는유동적인모델입니다. 설정된기간이없으며새로운정보가들어올때우선순위가재평가됩니다. 낭비감소 : 칸반 (Kanban) 은낭비를줄이고팀이불필요한작업을하거나시간을낭비하지않도록보장합니다. 이해하기쉽다 : Kanban의시각적특성은매우직관적이고배우기쉽도록도와줍니다. 팀은완전히새로운방법론을배울필요가없으며 Kanban을다른시스템위에쉽게구현할수있습니다. 전달흐름개선 : Kanban 팀은고객에게작업흐름을최적화합니다. 사이클시간최소화 : 사이클시간은팀작업흐름을통해작업을이동하는데걸리는시간입니다. Kanban 프로젝트에서전체팀은작업이프로세스를통해신속하고성공적으로진행되도록보장합니다. 52
Disadvantages of Kanban 기한이지난보드는문제를일으킬수있습니다. 팀은간판보드를최신상태로유지해야하며, 그렇지않으면부정확한정보를처리합니다. 오래된보드를기반으로한작업이완료되면다시궤도에진입하기가어려울수있습니다. 팀은보드를지나치게복잡하게만들수있습니다. 간판보드는분명하고읽기쉽도록유지되어야하지만일부팀구성원은보드에적용할수있는 ' 새로운기술 ' 을배워서다양한변경을하기도합니다. 일정예상어려움 : Kanban에대한자주생기는불만은일이언제완료될지모른다는것입니다. Kanban 보드의열은단계별로표시되며 ( 진행, 완료, 완료 ) 각단계와관련된시간대가없으므로단계가얼마나오래지속될수있는지실제로알수없습니다. 53
Principles of Kanban 워크플로우시각화 : 모든작업을표시함으로써초기문제를식별하고협업을돕습니다. 진행중인작업제한 (WIP) : 작업진행제한 (WIP 제한 ) 은보드또는각워크플로우의각열에대한최소및최대작업량을결정합니다. WIP에제한을두면속도와유연성을높이고작업우선순위를낮출수있습니다. 흐름을관리하고향상시킴 : 칸반 (Kanban) 보드전반에걸친작업흐름 ( 작업이동 ) 을모니터링하고개선해야한다. 명시적프로세스정책 : 모든사람들은어떻게작동하는지, 실제로 ' 행해진것 ' 이무엇인지를이해해야합니다. 지속적으로개선됨 : Kanban 방법은작고지속적인변경을권장합니다. 칸반시스템이갖추어지면팀은문제를식별하고이해하고개선을제안할수있습니다. 팀은흐름추적, 주기시간측정및작업품질향상을통해효율성을측정합니다. 54
XP Agile 55
Agile vs Waterfall 56
Agile vs Scrum 57
Kanban vs Agile 58
Kanban vs Scrum 59
When You Should Use Waterfall 범위의변경은기대하지않고고정된가격계약으로작업하고있는경우 프로젝트는매우간단하거나여러번해본적이있는경우 요구사항은잘알려져있고고정되어있을때 고객이원하는것을정확하게미리알고있는경우 질서정연하고예측가능한프로젝트로작업하고있는경우 60
When to Use Agile 스크럼은애자일프로세스의한프레임워크이므로둘다공통점이있습니다. 애자일을사용해야하는지먼저이해하는것이필요합니다. 그런다음애자일방법론이효과가있는것처럼보이면애자일의어떤프레임워크를사용할것인지선택할수있습니다 ( 스크럼은하나의프레임워크입니다 ). 다음과같은경우 Agile을사용하는것이좋습니다. 최종제품이명확하게정의되어있지않음 클라이언트 / 이해관계자가범위를변경할수있어야함 변경사항이전체프로세스중에구현되어야함 개발자가적응가능하고독립적으로사고할수있음 빠른배포를위해최적화해야하는경우 61
When to Use Scrum 프로젝트요구사항이바뀌고진화하는경우 지속적인피드백이필요한경우 작업의대부분을수행하는방법을파악해야하는경우 고정된날짜에커밋할필요가없는경우 프로젝트팀이자율성을원하는경우 정기적으로소프트웨어를제공해야하는경우 62
When to Use Kanban 반복을요구하지않는프로젝트 언제든지배포할수있는것을원하는경우 팀이변화를선호할때 팀이가시성과잘어울릴때 팀의배포흐름을개선하고싶을때 이해하기쉬운시스템을찾고있을때 63
I walk slowly, But I never walk backward. - Abraham Lincoln 64