2016년 7월 13일 수요일

SW영향평가제도 개요

1. SW영향평가제도란

공공과 민간간 불필요한 경쟁 및 SW산업 위축을 방지하기 위해 공공정보화사업 기획단계에서 민간시장 침해 등 SW산업 생태계에 미치는 영향을 평가하여 개선의견을 제시하는 제도

2. 대상사업

가 기관(소속기관 및 산하기관 포함)의 모든 정보화사업
기획, 구축, 운영 유지보수, 기타지원(정보화 정책지원)사업

2016년 7월 12일 화요일

애자일(Agile) 기술을 통한 미 공군 정보력의 진화

소프트웨어를 만드는 회사가 어느 정도 안정기에 도달하면 개발과 품질 프로세스에 대해 관심이 많아지는 것이 일반적이다. 완성된 소프트웨어가 계속 누적된다면 프로세스에 대한 필요성을 더 느끼게 된다. 좀 더 체계적인 형태로 소프트웨어를 만들고 관리하면 불필요한 요소가 줄어들고 품질이 더 향상될 것이라는 기대감 때문이다. 이처럼 소프트웨어 개발 프로세스에 대한 요구는 날로 증가하고 있지만 실제 적용을 통해 성공한 사례는 많지 않은 경우도 사실이다. 반드시 필요한 부분이기도 하지만 이로 인해 발생하는 관리적인 요소도 많다는 것이 적용 해봤던 회사들의 의견이다. 이번 회에서는 소프트웨어 개발 프로세스를 올바르게 적용해서 성공할 수 있는 방법이 무엇인지에 대해 사례를 보며 살펴보기로 한다. 사례 적용에 참여했던 ㈜Coocon의 한용만 박사를 만나 자세한 사항을 들어본다.

Q: 사례를 살펴보기 전에 소프트웨어 개발에 프로세스가 필요한 이유에 대해 간략히 설명해 주시죠.

소프트웨어를 개발하기 전에 준비하는 것은 생각보다 많습니다. 일반적으로, 요구사항과 인프라 환경, 그리고 제반 사항이 모두 적힌 RFP나 제안서를 보면서 준비를 하게 되는데요. 프로세스가 필요한 이유를 두 가지 관점으로 말한다면 먼저, RFP나 제안서에 적힌 요구사항대로 잘 만들고 있는지 계속 확인을 하면서 진행을 하기 위해서입니다. 아무래도 오랫동안 개발 일정이 지나고 많은 개발 작업을 하다 보면 본의 아니게 놓치는 경우가 당연히 생겨납니다. 이러한 경우를 방지하기 위해 사용하게 되고요. 또 한가지는 개발되는 과정을 체계적으로 정리하려는 목적도 있습니다. 이렇게 정리된 것으로 품질이나 나중에 재사용에서 유용하게 쓸 수 있습니다. 정리하자면, 고객 관점에서도 필요하고 개발팀 관점에서도 필요한 것이기 때문에 프로세스는 소프트웨어 개발에서 반드시 필요한 요소입니다. 각 회사의 개발 노하우나 프로세스를 표준화 한 것이 개발방법론입니다.

Q: 프로세스는 소프트웨어 개발에서 매우 중요한 요소로 보이는데요. 그런데, 많은 개발자들이 프로세스나 개발방법론에 대해 거부감을 나타내는 경우가 많습니다. 그 이유는 무엇일까요?

한마디로, 프로세스나 개발방법론에 문서 작업이 많기 때문입니다. 대개의 개발자들은 소프트웨어 개발만 하기를 소망합니다. 개발자들에게 프로세스나 개발방법론은 문서 작업만 하는 불필요한 일이라고 생각할 수 밖에 없지요. 많은 학자나 전문가들이 이를 해결하기 위해 많은 노력을 했지만 개발자 입장에서는 해결할 방법이 없는 것이 맞는지 모릅니다. 그래도, 최근에는 애자일과 같은 다양한 방법들이 나오면서 조금씩 해소가 되는 중이라고 볼 수 있습니다.

이러한 거부감을 해결할 포인트는 개발자에게 불필요한 것을 하지 않게 하는데 있습니다. 매우 어려운 문제이기도 하지만 프로세스나 개발방법론을 적용해야 한다면 불필요한 문서 작업만 줄여도 개발자의 불만은 매우 줄어들 겁니다. 개발자 입장에서도 문서 작업이나 개발 외 작업이 필요하다라는 공감대를 갖도록 하는 것이지요.

사용자 스토리 워크샵 사례 연구 - 비전 수립 & 피쳐 정의 편

사용자 스토리 워크샵(User Story Workshop)은 사용자(고객)와 개발자 간의 커뮤니케이션을 강조하면서 서로 원하는 것이 무엇인지 빠르고 정확하게 찾아내려 한다. 그리고, 그 중에서 가장 강조하는 부분은 공감대 형성이다. 사용자 스토리 워크샵에서는 만들고자 하는 소프트웨어의 비전과 비즈니스 목적에 대해 공감대를 가져야 한다. 이전의 개발 프로젝트에서 많은 프로세스와 산출물로도 커뮤니케이션이 잘 되지 않았던 가장 큰 이유가 바로 공감대 형성의 시간이 없었기 때문이다. 이번 회에서는 사용자 스토리 워크샵의 비전 수립과 비즈니스 목적을 정의하는 방법과 이 것이 피쳐 정의에 어떤 영향을 미치는지 살펴보기로 한다. 명확한 비전 공유로 애자일 기반 프로젝트의 성공률이 높아지기를 기대한다.

사례 연구 전 확인 사항

비전 수립의 필요성

공감대를 형성한다는 것은 같은 목표를 가지고 같은 방향으로 나아간다는 것을 의미한다. 하나의 목표와 방향을 비전으로 나타낼 수 있다(그림1). 이렇게 정해진 비전은 소프트웨어 개발 프로젝트가 종료될 때까지 가급적 변해서는 안 된다. 비전이 변경된다는 것은 개발 프로젝트 구성원들의 공감대가 깨진다는 것을 의미하기 때문이다.

2016년 7월 11일 월요일

사용자 스토리 워크샵에서 해야 할 일

사용자 스토리 워크샵은 최초 스프린트 시작 전에 수행하는 것이 일반적이다. 스프린트에서 수행해야 하는 단위를 사용자 스토리 단위로 수행함으로써 사용자 관점의 개발이 가능하기 때문이다. 사용자 스토리 워크샵을 마친 후 스프린트 계획을 수립하고 개발과 평가를 수행한다. 평가에 따라 스프린트를 반복 수행하게 되는데 기본적인 반복은 사용자 스토리 워크샵을 마치면서 정하는 것이 좋다(그림5).

<그림5> 사용자 스토리 워크샵과 스프린트(개발) 수행

그림5에서 보는 것처럼 사용자 스토리 워크샵은 스프린트 수행을 위해 필요한 것들을 정리해야 한다. 사용자 요구사항을 명확히 해야 하고, 요구사항을 구현할 때 나타날 수 있는 위험 요소(Pain Points), 애자일 기반으로 접근하는 프로세스, 형성된 공감대를 소프트웨어에 담기 위한 방법, 개발을 위한 액티비티 등을 정의한다.

사용자 스토리 워크샵에서는 스프린트에서 역할별로 해야 할 일도 구분해서 정리해야 한다(그림6). 그림5에서 나타난 기능(Feature)들을 대상으로 역할별로 참여해야 하는 범위와 해야 할 일을 자세하게 정의해야 스프린트를 수행할 때 어려움이 없다. 그림7이 QA(Quality Assurance)가 해야 할 일을 정의한 예이다. 해당 항목들은 누가, 언제, 어떻게 할 것인지 세부적으로 정의되어 있다.

사용자 스토리 워크샵의 티밍 방향

SI에서는 티밍을 개발 프로젝트 시작 전에 해서 종료 할 때까지 유지하는 것이 일반적이다. 중간에 문제가 발생하지 않는다면 바꿀 이유가 없다고 생각하지만 프로젝트 수행 중에 보면 많은 팀원들이 역할을 바꿔가며 업무 수행하고 있는 것을 쉽게 볼 수 있다. 이 것은 잘못된 것이 아니라 상황에 따라 적절한 역할이 필요하다는 것을 보여주는 사례로 봐야 한다.

사용자 스토리 워크샵을 하는 시점은 언제라고 정해지진 않는다. 원하는 시점에, 필요한 시점에 할 수 있다. 일반적으로, 애자일 프로젝트가 수행될 때 스프린트(Sprint) 단위로 진행되는데, 첫 번째 스프린트가 시작되기 전에 하는 경우가 많다. 스프린트의 범위가 정해지면서 필요한 역할자도 함께 구성되어야 하기 때문이다.

사용자 스토리 워크샵에서 정하는 티밍은 스프린트가 시작하면서 각 역할을 수행하게 한다. 그림4는 Thoughtwork사에서 제시하는 티밍 가이드이다. 코어팀(Core team)을 중심으로 티밍이 이루어지는데 경우에 따라 확장팀(Extended team)의 역할도 참여를 시킬 수 있다.

<그림4> Thoughtwork사의 티밍 가이드

출처: Thoughtwork

사용자 스토리 워크샵의 기본 사상

애자일의 인기가 높아지면서 애자일 개발 방식을 지원하는 개발 도구가 많이 나오고 있다 아틀라시안(Atlassian), 액소소프트(Axosoft) 등이 대표적이다. 이러한 도구는 코드에 나타난 오류나 작업량을 지속적으로 추적할 수 있게 해주고 개발 진행 상황을 체계적이고 자세하게 알 수 있도록 도와준다. 하지만, 개발에 필요한 사항을 공유하는 것이기 때문에 사용자와 개발자 간의 간극은 쉽게 줄어들지 않는다. 사용자 스토리 워크샵은 사용자와 개발자 간 생각의 차이를 없애주는 것에 가장 큰 목적이 있다(그림2).

<그림2> 사용자 스토리 워크샵의 목적

개발 프로젝트에 참여하는 사람들이 소프트웨어를 다르게 생각하면 안되기 때문에 이에 대한 공감대 형성이 사용자 스토리 워크샵에서 가장 먼저 해야 할 일이다. 공감대가 형성한 후 공감대를 실체화 하면서 사용자 스토리(User Story)를 만든다(그림3).

<그림3> 사용자 스토리 워크샵 프로세스의 예

사용자 스토리의 관점은 개발자가 아닌 사용자 관점이다. 따라서, 애자일도 마찬가지지만 사용자 스토리 워크샵에서 가장 중요한 점은 사용자가 반드시 참여해야 한다는 것이다. 사용자가 없는 상태에서 사용자 스토리를 작성하는 것은 기존 SI 개발 방식과 크게 차이가 없다고 봐야 한다. 사용자를 사용자 스토리 워크샵에 참여시키고 사용자가 가지고 있는 생각을 좀더 많이 알아내기 위해서는 효율적이고 체계적인 티밍이 필요하다.

피드 구독하기: 글 ( Atom )