인문과 공학의 사이 어느 중간쯤

요즘 계속 node.js 서버와 angular 클라이언트 시스템을 개발하느라 서브 프로젝트에 전혀 신경을 쓰고 있지 않은 상황이다. 어떻게 보면 역대로 기간대비 규모가 큰 프로젝트를 진행하고 있는 상황이라 시작할 때 기대도 많이 되었지만 부담이 없었던 것은 아니었다. 서버는 안드로이드, 아이폰 앱과도 연동이 되는 API 개발이 들어가야 했다. 말하자면 앱, 웹, 서버가 있고 웹과 서버는 내가 맡은 부분이었기 때문에 스크럼 방식으로 따지자면 나는 프로젝트 매니저 정도 되는 위치이다. 전반적인 프로젝트 관리 -- 특히 일정 관리나 요구사항 관리 및 인프라를 관리하는 -- 를 맡으신 분이 따로 계셨기 때문에 나는 비교적으로 클라이언트와의 직접적인 미팅이나 요구사항 관리를 하지 않아도 되어서 개발에 조금 더 집..

스크럼은 복잡한 프로젝트를 관리하기 위한 프레임워크다. 프레임워크는 뼈대, 골격이지 솔루션을 제공해주지는 않는다. 즉, 이 프레임워크를 사용하는 팀의 환경과 성격에 맞추는 과정이 필요함을 의미하는데 그럼 스크럼을 훌륭하게 실행할 수 있는 방법은 뭘까? "스크럼과 XP"의 저자 헨릭 크니버그는 결국 가장 빠른 방법은 누군가의 실패 경험을 딛고 일어서는 베스트 프랙티스 방법이라고 한다. 수많은 시도와 실패 끝에 최적화한 팀의 스크럼 방식을 배워가면서 빠르게 적응할 수 있다. 스크럼을 하며 겪은 노하우를 묶은 책에서 알려주는 몇 가지 스크럼을 하는데 알아두면 좋을 팁을 정리해보았다. 스크럼 프레임워크가 무엇인지에 대해서는 이전 글[SCRUM] 제품의 가치와 생산성을 동시에 생각하는 프로세스 방법론을 참고하자...

이 글은 스크럼 프로세스 프레임워크의 공식 문서을 요약한 자료입니다. 용어 제품 책임자, 개발팀, 스크럼 마스터, 스프린트, time-box, 제품증분 (increment), 제품 백로그, 스프린트 백로그 1. 스크럼이란? 제품을 생산적이고 창의적으로 배포하기 위해 복잡하게 얽힌 적응적 문제들을 다룰 수 있도록 하는 프레임워크 경험적 프로세스 관리론에 기반해서 지식이 우리가 이미 알고 있는 것에 기반한 의사결정에서 온다는 가정하에 예측을 최적화하고 위험요소를 제거하는 반복적이고 점진적 접근방법을 사용한다. 2. 스크럼 팀 스크럼 팀은 3가지 역할로 나뉜다. 제품 책임자 1명, 개발팀 3~8명, 스크럼 마스터 1명으로 각자의 역할을 보면 꽤 명확하다.2.1 제품 책임자 제품 가치와 결과물을 최상으로 만들 ..

Software Process는 비슷한 개념을 가지는 여러 가지 용어와 혼용되어서 사용된다. 예를 들면, Software Life Cycle, Software Development Methodology 또는 Software Method 같이. 그런데 사실 여기서 함정은 많은 사람들이 Methodology와 Method에 대해 착각하여 둘을 섞어서 사용하고 있다는 점인데,엄밀히 말하면 Methodology는 Method의 집합이고 어떤 방법이 아니라 방법을 위한 방법? 방법론이다. 이 기준에서 Methodology가 프로세스에 좀 더 적합하다는 생각이 들었다. 우리가 건물을 한 눈에 보기 위해 모형을 만들거나, 실제 상황을 쉽게 설명하기 위해 그림을 그리거나 실제 세계를 모델로 만드는 일들이 일상생활에서도..

대학원 첫 학기에 배웠던 디펜더블 소프트웨어 (Dependable Software, 이하 DSW)는 소프트웨어 공학에서도 믿고, 의지하며 쓸 수 있는 디펜더블 소프트웨어를 위한 기술에 대해 배우는 전반적으로는 소프트웨어 공학에 대한 기초지식을 배우는 시간이었다.기초라고 해서 신선하지 않다는 건 아니다. 강의 내용은 학부 컴공을 졸업했다고 해서 고개들기도 무색할 만큼 새로웠고, 재미있었다. 과거는 생산성과 기능에 모든 초점이 맞춰져 있었다면 앞으로는 Dependability (의존 가능성)에 더 많은 이목이 집중될 것이다. 자동차, 의류, 전기 등 사실 이런 분야들을 생각해보면 당연한 얘기이지 않나 싶지만 그만큼 우리 개개인이 요구하는 가치가 증가했다고 볼 수도 있을 것 같다. 그래서 이런 흐름에 따라 우..