동시 테스팅을 이용한 애자일 방법론의 스크럼 기반 개발 프로세스

애자일 개발 프로세스에 대해 제품의 품질을 높이며 동시에 시간의 낭비를 줄이는 방법으로 동시 테스팅을 이용한 스크럼 기반 개발 프로세스를 제안합니다 . 개발 프로세스 중심의 스크럼 조직 내에 테스트 엔지니어의 역할을 정의하고 , 테스트 설계 , 테스트 코드 개발 , 테스트 수행 및 스크럼 팀 간의 통합 관점에서 커뮤니케이션 및 이슈 관리를 수행하도록 하였습니다 . 이를 통해 결함생명주기의 지연시간이 줄어들고 , 릴리스 이후 결함이 감소하여 품질이 향상되었음을 확인하였습니다 .

애자일 방법론은 XP(eXtreme Programming), 애자일 모델링과 같은 실천 방법 중심의 접근 방식과 스크럼과 같은 프로젝트 관리 중심의 접근 방식으로 나눌 수 있습니다 . 이는 두 가지 접근 방식이 상호 보완적이라는 것을 의미하며 , 스크럼을 채용한 프로젝트가 XP 에서 제시한 실천 방법을 사용할 수 있다는 의미입니다 . 이를 위해 애자일 프로젝트 수행 시에 적용 조직과 프로젝트 특성에 맞는 상황과 제약사항 등을 파악하여 적절한 실천방법들이 조합될 수 있으며 , 계획 중심의 방법론과 같은 전통적인 방법론과도 하이브리드 화되어 사용되고 있는 추세입니다 .

M. Poppendieck 은 제조업의 낭비 유형 7 가지에 견주어 소프트웨어 개발의 7 대 낭비 유형으로 미완성 작업 , 가외 프로세스 , 가외 기능 , 직무 전환 , 대기 , 이동 , 결함 등으로 정의하였습니다 . 스크럼 개발 방법을 기준으로 낭비 요소 측면에서 주요 이슈를 살펴보면 , 타임박스 안에서 수행이 완료되지 않거나 , 결함으로 인한 재 작업은 다음 개발 차수 ( 스프린트 ) 에 반영하여 재 계획하기 때문에 실질적으로 낭비 요소를 줄이거나 예방할 수 있는 방법은 아닙니다 . 이를 해결하기 위해 공통적인 설계 , 관리 기능을 모아 스크럼의 스크럼 (Scrum of scrum) 팀을 구성하는 경우도 있지만 , 스크럼 프로세스와 중복이 불가피하기 때문에 가외 프로세스로 인한 낭비 요소가 될 수 있습니다 . 특히 , 스프린트 이후 발생하는 결함은 변경의 영향의 범위가 넓고 , 궁극적으로 제품 출시일의 지연으로 연결될 가능성이 높아 위험합니다 .

자세히 보기 →

클라우드 서비스 발전전략과 정책과제

최근 전 세계적으로 클라우드 서비스에 대한 국가전략 수립 , 산업육성 , 시장개발을 위한 움직임이 정부와 민간을 구분하지 않고 매우 활발하게 진행되고 있습니다 . 본고에서는 클라우드 서비스에 관한 최근의 해외 정책 동향과 국내 현황 분석을 바탕으로 우리나라 차원의 발전전략과 정책과제를 소개하고 , 향후 실천방안에 대해 논의합니다 .

클라우드 컴퓨팅 서비스 ( 이하 ‘ 클라우드 서비스 ’) 는 IT 자원의 이용방식을 ‘ 소유 ’ 의 개념에서 ‘ 임차 ’ 의 개념으로 전환하여 외부의 컴퓨팅 자원을 인터넷에 접속하여 사용하고 , 사용한 만큼 사용료를 지불하는 방식을 지칭합니다 . 그러나 이러한 정의에도 불구하고 클라우드 서비스는 매우 역동적으로 다양한 특화 서비스로 진화하고 있어 , 향후 클라우드 서비스의 개념은 지속적으로 새롭게 변화해 가리라 예상됩니다 .

컴퓨팅 시장 환경이 직접구축 방식에서 아웃소싱 방식으로 , 다시 클라우드 서비스 방식으로 전환되는 동기는 비교적 간단합니다 . 첫째 , 컴퓨팅 자원을 직접 구축하여 운영하는 것에 비해 최대 50% 정도의 비용절감을 가져 올 수 있습니다 . 둘째 , 이를 통해 자사의 핵심 역량에 집중하여 생산성 향상은 물론 , 비즈니스의 성과를 극대화할 수 있습니다 . 셋째 , 컴퓨팅 자원을 구축 , 운용 , 관리할 별도의 조직을 내부에 두지 않아도 되므로 , 조직의 슬림화를 꾀할 수도 있습니다 .

자세히 보기 →

개발자를 우군으로 만드는 에반젤리스트 (Evangelist) 전략

에반젤리스트 (Evangelist) 란 ?

에반젤리스트 (Evangelist) 는 직역한다면 기독교에서 말하는 신양을 전파하는 “ 전도사 ” 라고 할 수 있으며 , IT 분야에서는 자신들의 기술을 시장에 전파시키고 확산시키는 역할을 하는 사람들을 말합니다 . 에반젤리스트라는 용어는 애플컴퓨터에서 시작되었는데 , 소프트웨어 에반젤리스트는 맥킨토시 부서의 마이크 무레이 (Mike Murray) 가 , 기술 에반젤리스트는 애플의 마이크 보이치 (Boich) 가 처음으로 사용한 것으로 알려져 있습니다 . 에반젤리스트가 실리콘밸리에서 본격적으로 알려지기 시작한 것은 애플컴퓨터의 수석 에반젤리스트 (Chief evangelist) 인 가이 가와사키 (Guy Kawasaki) 를 통해서입니다 . 그는 1991 년도에 “Selling the dream: How to Promote Your Product, Company, or Ideas and Make a Difference Using Everyday Evangelism” 라는 책을 통해 에반젤리즘 (Evangelism) 은 의미 있는 명분 (Cause) 을 퍼트리고 꿈을 전달하는 것이라고 소개하였습니다 .

그는 이 책에서 “ 에반젤리즘의 본래 의미는 좋은 소식을 전달하는 것이다 . 애플컴퓨터는 수천 개의 사용자 그룹을 가지고 있습니다 . 이들은 돈을 받거나 고용되지 않았지만 다른 사람의 혜택을 위하여 맥 컴퓨터를 사라고 얘기합니다 . 이것이 영업과 에반젤리즘의 차이라 할 수 있습니다 . 영업은 나에게 좋은 것에 기반 하지만 , 에반젤리즘은 상대에게 좋은 것에 뿌리를 두고 있다 .“ 고 밝혔습니다 .

에반젤리스트의 역할은 일반 대중보다는 개발자와 같은 전문가 그룹에 신기술을 전파하고 관계를 유지하는 것입니다 . 단순하게 신기술을 소개하는 것뿐만 아니라 비전과 가치를 설명하고 무엇을 준비해야하는지를 알려 신기술이 시장에 흡수될 수 있도록 지원하는 역할을 수행합니다 . 아울러 외부 개발자 및 시장의 피드백을 내부 개발팀에 전달하여 제품이나 서비스가 개선되도록 돕는 일도 하고 있습니다 .

자세히 보기 →

[소프트웨어 프로세스 품질인증]

품질인증 기준 및 심사준비 가이드

1. 품질인증 기준

2. 심사 준비 가이드
   I. 소프트웨어프로세스 품질인증 제도
  II. 소프트웨어프로세스 품질인증 기준
 III. 소프트웨어프로세스 품질인증 심사
 IV. 소프트웨어프로세스 품질인증 획득

Summary

소프트웨어프로세스 품질인증 제도(이하 ‘프로세스 인증제도’라 한다.)는 소프트웨어 기업 및 개발조직의 소프트웨어프로세스(프로젝트 관리, 개 발, 지원, 조직 관리, 프로세스 개선) 품질역량 수준을 심사하여 등급을 판정하는 제도입니다.

프로세스 인증제도는 소프트웨어 및 정보시스템을 개발 관리하는 국내 소프트웨어 기업 및 개발조직의 소프트웨어프로세스 품질 향상과 신뢰성 확보를 목적으로 제정되었습니다. 소프트웨어프로세스 품질인증 제도는 소프트웨어프로세스 품질인증 기관(인증기관), 소프트웨어프로세스 품질인증 기준(인증기준), 소프트웨어 프로세스 품질인증 지침(인증지침)의 3가지 구성요소로 운영됩니다.

자세히 보기 →

성공적인 유저 인터페이스 디자인을 위한 8가지 기본원칙

애플리케이션을 개발하고, 출시한 뒤에 시장 반응에 의해 실망해 본 경험은 누구나 있을 것 입니다. 마케팅에 시간과 돈을 많이 투자한다고 해서 볼품없고 헷갈리며 불친절한 유저 인터페이스가 극복되는 것은 아닙니다. 즉, 유저 인터페이스가 애플리케이션의 성패를 좌우합니다. 예를 들어, 모두가 애플과 같이 될 수는 없으나 가장 친절하고 매력적이며 눈길을 끌고 간단한 유저 인터페이스를 지향할 수는 있습니다. 유저 인터페이스의 성공적인 원칙은 다음과 같습니다.

유저 (User) 를 이해하라

만약 사용자를 설득하기 원한다면, 유저의 마음을 이해하는 것이 필요함. 즉,‘ 사용자는 누구인가’에서 시작해서‘유저는 무엇이 필요한지’를 생각한다면 거기에서부터 작업은 향상됨.

단순한 것이 아름답다

유저 인터페이스를 디자인할 때 단순함은 핵심임에 따라 유저 인터페이스에 화려함을 덧붙이기 전에‘ 이것이 필수적인가’또는‘이것이 인터페이스에 실질적으로 어떤 것을 덧붙여주는가’를 스스로에게 질문해야 함. 가장 좋은 유저 인터페이스 디자인은 가장 단순한 것임.

색 (Color) 을 현명하게 사용하라

색은 특히‘행동의 촉구’가 되도록 제작된 특별한 요소들로 관심을 이끄는 분명한 방법임. 빨간색이 좋은 예로, 빨간색은 행동의 색으로‘지금 다운로드’, ‘지금 플레이’, ‘여기를 클릭’에 주목할 것을 요구하나 빨간색은 또한 위험의 의미와 연관되어 있기 때문에 빨간색을 남용하면 안 됨.

일관성을 유지하라

당신의 유저를 안심시킬 수 있기 때문에 일관성은 필수적인 것임 . 폰트와 레이아웃에서부터 언어와 주제에 이르기까지 일관성은 모든 곳에서 요구됨.

처음 사용하는 유저를 도와줘라

처음 사용하는 유저를 사용안내 비디오테이프에 맡기거나 , 유저가 거의 방문하지 않는 헬프 데스크로 보내는 대신 , 유저를 안내할 수 있는 “ 온디멘드 (on demand)” 설명서를 첨부하는 것이 좋음 . 이러한 설명서는 GPS 나 관광가이드와 같은 역할을 하는 것으로써 , 앱의 핵심적인 특징들 사이로 유저를 호위하거나 유저가 임무를 완수하도록 도와줌.

유저의 성과를 인정하라

유저가 숙달되는 순간 , 인터페이스는 유저에게 보상하고 유저의 성과를 인정해야 함 . 더 이상 복잡한 과제에 실패하게 하지 말고 , 유저는 비교적 빨리 키보드를 손쉽게 사용하고 인터페이스의 복잡한 측면을 사용하는 것에 익숙해지도록 해야 함.

시험하고 반복하라

계속적으로 변하는 유저 인터페이스 때문에 유저를 멀어지게 만드는 것은 결코 바람직한 것이 아니지만 , 5 년 동안 똑같은 유저 인터페이스를 유지하는 것 역시 바람직하지 않기 때문에 경쟁자들이 앞서게 될 것임 . 모든 사람이 웹사이트의 특별한 디자인에 애착을 가질 수 있으나 , 그것들은 때때로 수정되고 업데이트되고 손질될 필요가 있음.

포기하지 말라 

유저 인터페이스 디자인은 예술이자 과학임 . 최고의 유저 인터페이스를 디자인하고자 할 때 모든 가변성과 더불어 문제들에 직면할 것임 . 첫 번째 , 두 번째 , 세 번째 그리고 아마 네 번째 장애물조차 걸려 넘어진다고 해서 , 이것이 프로젝트를 계속해서는 안 된다는 것을 의미하는 것은 아님.

자세히 보기 →

Predicting Software Quality: SW 품질 예측 방법

품질은 SW 개발에 있어 탁월한 설계 , 사용용이성 , 속도 , 안정성 , 보안 , 정확성 등을 생각나게 하는 긍정적인 단어입니다 . 이러한 속성들 중 몇 가지는 측정가능하고 , 몇 가지는 주관적이라 할 수 있습니다 . 우리는 이러한 요소들을 통틀어 품질이라고 부릅니다 . 보편적인 이 관점에서 결함이 적을수록 높은 품질을 의미합니다 . 결함 /KLOC(kilo lines of code), 평균고장수명 (Mean time to failure) 과 같은 척도 (measure) 는 이러한 개념을 가지고 있습니다 . 유용한 척도의 결과 값이 좋으면 소프트웨어에 문제가 없다는 것을 나타내고 , 품질이 좋다고 이해합니다 .

용인되는 수준의 품질은 부수적인 결함들이 많다는 것을 의미하진 않습니다 . 중요한 것은 소프트웨어 패키지가 특색이 많고 , 많이 사용되어지고 , 적당한 가격을 가지는 것입니다 . 이것들로 판매자는 이익을 내고 시장 지배력을 가집니다 . 패키지를 사용하면서 사용자들이 부딪히는 문제들이 패키지를 사용하지 않는 것보다 낮은 수준일 때 , 제품의 품질을 용인되는 ( 받아들일 만한 ) 수준이라고 합니다 .

자세히 보기 →

사용자경험 분석 시 범하기 쉬운 5가지 흔한 실수

애자일 소프트웨어 개발 방법론을 사용할 때, User Story를 사용해서 대부분의 요구사항을 수집합니다. User Story는 "의사소통 대상과 대상별 요구사항“의 간결한 형태와 수락기준으로 구성됩니다. User Story는 간결하지만 잘 작성하는 것이 무척 어려운 작업입니다. User Story 작성 시 흔히 범하는 5가지를 실수를 검토해봄으로써 올바른 User Story 작성법을 살펴보도록 합니다.

[5 가지 흔한 실수들]

1. 단일 사용자를 위한 User Story

• 예 : “ 사용자로써 나는 광고를 관리할 수 있기 원한다 . 왜냐하면 기한이 만료되고 실수가 있는 광고를 제거할 수 있기 때문이다 .”
• 언뜻 보면 모든 요소가 있어서 User Story 로 별 문제가 없어 보임
• 특색에 맞게 사용자를 살펴보면 광고관리를 이해하고 수행하는 사용자는 광고 조정을 하는 포탈 관리자나 모든 광고 목록을 가지고 상황에 따라 광고들을 교체하는 광고주들을 뜻함
• 페르소나나 역할을 놓치고 있음

2. 제품 소유자를 위한 User Story

• 예 : “ 제품의 소유자로써 나는 광고를 지울 수 있는 시스템을 원한다 . 왜나하면 사용자들이 광고를 지울 수 있기 때문이다 .”
• 모든 요소들이 있지만 뭔가 어색함
• ‘ 당신이 무엇을 원한다 . 당신은 그것을 가지고 있다 ’ 는 형식으로 User Story 를 쓰는 사람이 단지 하고 싶은 행위에 초점을 두고 있으며 , 사용자 기대에 대한 단서를 주는 역할이나 페르소나가 없음

3. 개발자를 위한 User Story

• 예 : “ 개발자로써 나는 폴더 위젯을 재배치하기를 원한다 . 왜냐하면 나는 폴더 위젯을 유지하고 싶기 때문이다 .”
• 기술적인 백로그 (Technical backlog) 나 기술적인 요구사항의 대표하는 예임
• 이와 같은 User Story 는 기술적 채무 (Technical Debt) 으로도 불리며 , 기술적 채무는 소프트웨어 업데이트 , 리팩토링 (Refactoring), 프레임웍의 교체와 같은 유지보수 관련 필수적인 일을 포함함
• 고객을 위한 가치를 대변하지는 않고 , 애자일 관점에서 매 주기의 마지막에 비즈니스적 가치를 수반해함
• 역할에 페르소나를 붙여 사용자관점에서 기술하는 예로 ‘ 상업적인 사용자로서 나는 동시에 여러 검색을 할 수 있는 시스템을 원한다 . 왜냐하면 나는 일을 좀 더 빨리 하고 싶기 때문이다 .’ 를 둘 수 있음
• 수락기준들은 향상을 측정 가능하고 테스트 가능하도록 정의해야 함
• 예 : ‘ 한 사용자가 동시에 5 가지 검색을 할 수 있음 ’

4. 고객을 위한 비즈니스 가치나 혜택이 없음

• 예 : “ 상업 광고주로써 나는 필터링 옵션을 원한다 ”
• 역할도 있고 니즈도 있지만 이유와 비즈니스 가치가 없음

5. 수락기준이나 만족조건이 없음

• 수락기준이 없는 것은 개발업무를 잘못 정의하거나 잘못된 평가로 시작해서 전체를 오류덩어리로 만들 수 있음
• 이해부족으로 Story 가 테스트를 통과하지 못할 수도 있고 Test Case 가 다른 기준들을 적용할 수도 있음
• 수락기준은 요구사항을 명확하게 이해하고 주기별 결과물을 받아들일지는 결정하는 중요한 역할을 함
• 수락기준을 만드는 좋은 방법은 '~ 한다면 어떻게 될까 ?(What if ... ?)', ' 어디서 (Where) ...?', ' 언제 (When) ... ?', ' 어떻게 (How) ... ?' 와 같은 질문을 해보는 것임
• 예제들을 사용해서 가정들을 제거해서 간결하게 만들어보면 Story 가 세련되어지고 재구성되고 좀 더 작은 Story 로 나뉘어질 것임 

자세히 보기 →