2016년 12월 2일 금요일

UX 사례 연구 - 멀티 디바이스의 UX

다른 사용자 그룹을 위한 사용자 경험 공유 

지금까지는 개인 소유의 디바이스를 얘기하고 있지만, 최근에 다른 사용자 그룹 간 다양한 정보나 사회적 공유를 하는 것이 일반화되고 있다. 사회적 관계망(Social Network Service) 등과 같은 서비스를 통해 사용자 경험이 공유되고 있고, 이를 통해 많은 사용자가 서로의 사용자 경험을 공유하고 있다. 
UX 측면에서는 상호작용을 위해 보편화된 UI를 사용해서 UX를 설계하는 것이 좋고, 다른 서비스에서 주로 사용되는 UI와 UX를 반영하는 것이 사용자 입장에서는 편하다. 구글의 웹 사이트를 예로 보면, 구글은 검색이 주 기능이기 때문에 탐색 기능이 눈에 띄게 배치되도록 설계하였다(그림8). 

 <그림8> 구글의 웹 사이트 

출처: Google 


확장 가능한 참조 UX 만들기 

각 디바이스의 유형에 따라 지원 가능한 기능을 확인하고, 디바이스의 인터페이스에 따라 UX 원칙과 패턴을 정의하여 표준 UX를 만든다. 표준 UX에 따라 각 디바이스 별로 참조 UX를 만들어 디바이스에 반영되도록 UX를 설계한다(그림9). 


<그림9> 참조 UX 만들기  
출처: BBC 


모바일 우선 디자인 

소프트웨어는 PC용으로 개발된 후 모바일 용으로 변환되는 것이 일반적이었지만, 제약사항이 많고 사용자 경험에 집중해야 하는 모바일 용을 먼저 만드는 것이 UX 측면에서는 유리하다. 다양한 것을 모두 담을 수 있는 PC와 달리 모바일은 가장 우선순위가 높은 것부터 담을 수 있기 때문이다. 모바일 용을 만든 후에, 추가 기능을 넣어 테블릿이나 PC용으로 변환하는 것이 좋다. 

동기화 

여러 디바이스에서 동일한 서비스가 제공되는 멀티 디바이스의 UX 설계가 끝나고 나면 각 디바이스에 컨텐츠가 올바르게 돌아가는지 모든 디바이스에서 동기화를 확인해야 한다. 대개는 각 디바이스에서만 정상 동작을 확인하는데 멀티 디바이스의 경우는 동기화가 매우 중요한 확인 요소이다. 


기대 효과와 결론 

과거에는 소프트웨어의 중요 요소로 개발 역량을 우선시 했다. 하지만, 최근에는 사용자 경험을 중요시 하면서 소프트웨어의 기능 외에 사용자와의 상호작용을 중요시 하고 있다. 단순히 명령만 내리고 받은 명령만 수행하던 소프트웨어에서, 사용자에게 더 나은 사용자 환경을 제공하려는 요즘은 UX에게 요구하는 것들이 점점 많아지고 있다. 체계적인 UX 설계는 소프트웨어에 대한 사용자의 만족도를 높여주고 심화되는 사용자 경험으로 인해 또 다른 서비스를 창출하는 도구가 되고 있다. 




DevOps 환경 을 위한 시스템 & 프랙티스

Docker는 무엇인가

•2013년 3월에 등장한 오픈소스 리눅스 컨테이너 프로젝트
•컨테이너 기술을 기반으로 어플리케이션 패키징,설정,배포를 지원하는 경량의 가상화 솔루션

Docker,OpenStack 구글 트렌드 결과



Docker와 VM 비교


Docker 어떻게 패키징/ 배포를 지원하는가

•Image : 읽기 전용 파일 시스템, 바이너리 코드
•Container: 이미지가 실행된 것
•도커는 어플리케이션/서비스를 컨테이너에 넣어서 빌드/배포한다.



애자일과 전통적 개발방식의 조화

SW개발프로젝트사례-적용성과

•경영진은높아진개발팀의생산성과품질에만족함
•개발팀원들이업무에열정적으로임하면서업무만족도가향상됨
•개발진행상황의가시성이향상
•팀원들간의협력및팀워크가향상
•시장에맞는제품품질및상품성확보

SW개발프로젝트사례–팀원소감

•기존에는전체일정을산정하고개발하는데어려움이있었지만애자일방법적용후에는단기적으로명확한목표를세우고진행할수있었다.
•PM이팀원들과수직적관계에서업무를지시하고전달하는방식에서벗어나팀원들의역량을발휘할수있도록여건조성을하고, 스스로동기부여를하여업무를진행하므로업무수행능력도높아지는점장점을경험하였습니다.
•팀원간의활발한소통이개발에도움이되었음.
•이터레이션계획을상세하게짜서모두어떤일을하는지알게되어좋았다.
•회고를통해문제가되었던부분을해결할수있어서좋았음.
•저마다본인의업무에집중하고서로가서로를배려하게되었습니다.

SW 유지보수적용사례–적용효과

•개발업무진행상황의가시성향상
 –적용전에는개발자들이무슨일에보틀넥이걸려있으며어떤애로사항이있는지알기어려워팀장입장에서업무진행현황을일일이물어보아야파악할수있었는데지금은타스크보드와데일리미팅을통하여일일이물어보지않아도팀원들이어떤문제에애로사항이있으며어떤업무에버틀넥이있는지쉽게알개되었고당면한문제점들을바로바로해결할수있게되었다.
•통합테스트단계에서발생하는결함감소
 –평균적으로QA팀에서개발팀으로매달8~9여건정도의크고작은재작업요청이있었으나애자일을적용하고나서부터는1~2건정도로줄어든상태이며그나마도마이너한작업이되어품질이많이향상되었다. (70% 이상감소)
•개발과정의효율성이높아지고생산성향상
 –상호간의협업증대로월별처리건수향상(50%이상향상)



2016년 12월 1일 목요일

원격 개발센터의 장단점 분석

Q: 분석과 설계를 온-사이트에서 하는 방법도 괜찮지 않을까요? 

설계서에는 프로그램명세서가 있어서 개발만 하면 더 편할 수 있을 것 같은데요? 옳은 지적입니다. 그런데, 내부적인 회의에서 개발자가 업무를 모르면 유지보수가 어렵다는 이야기가 나왔습니다. 분석과 설계를 하지 않았기 때문에 업무를 이해하기는 당연히 어렵고, 업무 설명을 위해 한국에서 중간 관리자를 보내는 방안도 고민했는데, 이러다 보니, 아키텍트도 보내고, 품질담당자도 보내고, 인프라 담당자도 보내야 하고, 마치 해외 프로젝트를 하는 것과 똑같더라고요. 본질이 바뀐 겁니다. 그래서, 가장 기본이 되는 것으로 다시 생각하자고 의견을 모았습니다.


<그림3> 원격 개발센터의 이상적 모델의 예 





출처: 한국정보화진흥원 


그림3은 원격 개발센터의 이상적인 모델인데, 온-사이트에서는 요구사항만 명세화하고 원격 개발센터에서 프로젝트를 수행하는 모델입니다. 이러한 모델은 고객이 개발하는 곳을 볼 수 없기 때문에 부가적인 업무가 없어지고 개발자들은 개발에 전문성을 높일 수 있습니다. 하지만, 요구사항 명세서 하나만으로 개발에 필요한 정보를 모두 알 수 없기 때문에 실제 적용하기는 조금 어려운 부분이기도 하지요. 최근에는 이러한 모델에 소프트웨어공학 요소를 포함시켜 해결을 해보자는 노력도 있기는 합니다(그림4). 


<그림4> 소프트웨어공학적 요소가 적용된 원격 개발센터 


Q: 그림4의 경우는 어떠한 요소가 들어갔는지 설명을 부탁 드립니다. 

그림3이 적용되기 어려운 이유는, 첫째 온-사이트와 원격 개발센터 간의 의사소통이 문서만 왔다갔다 하면서 끝난다는 것이고, 둘째는 요구사항 명세서가 매우 불명확할 것이라는 것, 마지막으로 원격 개발센터가 테스트를 마쳐도 온-사이트에서 잘 돌아갈 것인가 하는 것입니다. 이런 부분을 보완하기 위해 애자일을 도입해서 커뮤니케이션과 반복, 점진을 통해 원활한 의사소통이 이루어지도록 하고, 사용자 스토리 워크샵을 적용해 요구사항을 온-사이트와 원격 개발센터 모두에서 이해할 수 있도록 수준을 높이고, 마지막으로 TDD(Test Driven Development)를 통해 온-사이트와 원격 개발센터의 테스트 케이스를 동일화하여 문제 발생 여지를 줄이는 노력을 하게 됩니다. 




DevOps 환경 을 위한 시스템 & 프랙티스

빌드/배포 시스템

배포 솔루션


JARVIS 모듈 아키텍처




애자일과 전통적 개발방식의 조화

SW 개발에서 나타나는 전형적인 이슈와 문제점

1.프로젝트일정및태스크공수추정의신뢰성부족
2.업무성과및품질불량으로관리자와팀원간의갈등발생
3.수동적인팀원들의자세및낮은사기
4.프로젝트및팀구성원들간의소통및협력부족
5.요구사항의불확실성과잦은변경
6.개발산출물및업무회의과다
7.고객및사용자의참여부족
8.진척상황의불투명성

1. 프로젝트일정및태스크공수추정의신뢰성부족

•전형적인일정및공수추정형태
–소수의개발리더(전문가)를중심으로단독추정
–경영진및고객이제시한일정에WBS를끼워맞추는형태로일정개발

•문제점
–리더가본인이나잘하는사람을기준으로공수를추정하다보니항상프로젝트공수가부족
–개인의편차가심하며공수추정의신뢰성이떨어짐
–알려지지않은(Unknown)리스크를고려한일정버퍼가부족

•애자일해법
–전문가집단추정(Planning Poker )기법을활용하여평균공수를추정함으로써추정의신뢰성을향상
–평균공수추정에따른일정산정과알려지지않은(Unknown)리스크를고려한일정버퍼삽입

2. 업무성과및품질불량으로관리자와팀원간의갈등발생

•전형적인갈등상황
–팀원은리더의일방적지시에따라업무를진행하다보니해당업무에대한완료기준이서로상이함
–태스크초기일정미준수에따른비난이나질책이발생
–팀원이수행한태스크점검시결함이자주발생하는것에실망

•애자일해법
–스프린트계획시고객및리더, 팀원이함께토론하여해당업무혹은요구사항에대한완료기준을명확하게설정함(Test Driven)
–리더는태스크일정수행의불확실성을인식하고태스크장애요소해결에집중
–업무수행에대한책임을개인책임보다는팀책임으로설정하고
–완료조건에크로스및QA테스트검증포함