Visual Studio 없는 소스관리

Posted in 프로젝트관리 // Posted at 2013. 3. 13. 14:22

현재 팀에서 사용하고 있는 소스 형상관리 툴은 TFS와 SVN 이다.

 

DB 스크립트나 일반 문서만을 다루는 사람들을 위한 소스 관리 환경이 필요했다.

Visual Studio를 사용하지 않는 사람들만을 위한 환경이 필요한 것인데...

 

언뜻, SVN이 적합하다는 생각이 들었다.

 

다만 윈도우 탐색기로 소스 관리하는 것과 더불어,

이들이 주로 사용하는 툴인 SSMS(SQL Server Management Studio)와 연결해서 좀 더 편한 관리를 할 수 있는 방법이 없나 하면서 TFS 관련된 플러그인 들을 찾아 봤다.

 

먼저. 아래 플러그인을 설치 하면 SSMS에서 TFS로 연결할 수 있게 된다.

http://www.techtree.co.uk/sql-server/management-studio-ssms/use-team-foundation-server-tfs-as-your-source-control-in-ssms/

 

툴을 설치하고 SSMS의 옵션에 아래 그림과 같이 소스 제어 플러그인을 설정할 수 있다.

그리고 이후 프로젝트 생성하고 TFS서버에 연결해서 관리하면 된다.

 

 

 

그리고 TFS도 (SVN 클라이언트 처럼)윈도우 탐색기를 통해서 소스 관리가 가능하다는 아래 글을 보고 설치 해 봤다.

http://support.microsoft.com/kb/2699161/ko

http://visualstudiogallery.msdn.microsoft.com/c255a1e4-04ba-4f68-8f4e-cd473d6b971f

 

음.. 그런데 기대 했던 것 보다 불편하다.

2번째 툴을 설치하고 탐색기를 보니, 일단 글과 다르게 아이콘 모양이 표시되지 않는다.

그러나 TFS와 연결된 폴더의 컨텍스트 메뉴를 보면 아래 그림과 같이 TFS 로 관리할 수 있다.

 

단 아쉬운 것은 TFS와 미리 연결되어 있는 폴더라야만 해당 메뉴가 나타난다.

SVN과는 달리 일반 폴더에 TFS 연결 부터 하고 싶을 경우는 지원하지 않나 보다.

 

 

Visual Studio를 같이 사용하지 않는 이상, 이런 방식의 TFS 사용은 별로다.

 

이것저것 대략 살펴보다, 빠른 결론 내린다.

SSMS의 SVN 클라이언트 플러그인을 설치하기로 한다.. ㅎㅎㅎ

 

http://www.zeusedit.com/agent/ssms/ms_ssms.html

 

 

 

 

 

 

 

'프로젝트관리' 카테고리의 다른 글

애매함의 불편함  (0) 2013.06.12
조직의 비전 vs 개인의 가치  (1) 2013.04.02
경험 관리하기  (0) 2013.01.04
인수 요구 산출물  (0) 2013.01.03
그 사람을 대신 할 사람은 없다  (0) 2013.01.03

submit

경험 관리하기

Posted in 프로젝트관리 // Posted at 2013. 1. 4. 15:04

경험은 돈으로도 살 수 없는 매우 소중한 재산입니다

 

공부를 많이 한 사람보다 경험을 많이 한 사람에게 실제적 지식을 얻을 수 있습니다.

 

프로젝트를 진행하고 시스템을 운영하다 보면, 참으로 다양한 경험을 합니다.

그 중에서 어떤 문제를 해결한 경험의 가치는 이루 말할 수 없이 값진 거란 생각이 듭니다.

 

특히 개발자들은 늘 버그를 수정하고 삽니다.

배운대로 개발을 하더라도, 잘 개발된 시스템일지라도.. 다양한 이유로 버그는 발생할 수 밖에 없지요.

 

이럴때면 개발자들은 문제점의 원인을 분석하고 여러 기법을 동원해 문제를 해결해 나갑니다.

이러한 고도의 지적 활동 경험은 매우 가치있는 지식입니다.

 

안타까운것은 이 중요한 지식이 담당 개발자의 머리속에만 저장되어 있다는 겁니다.

더 슬픈건, 담당 개발자의 머리속에서도 언젠가는 지워질게게 분명하다는 점입니다.

 

그래서 경험 지식을 관리하고 싶어 졌습니다.

 

6하원칙이면 좋겠네요

- 언제

- 어디서

- 무엇이

- 왜

- 어떻게

- 누가

 

언제 어떤 문제가 어디서 발생했으며 왜 그러한 문제가 나타났는지, 그래서 누가, 어떻게 해결했는지입니다.

 

개발자의 경험 지식을 DB화하여 체계적으로 관리하면 좋은 점이 많습니다.

- 그 자체가 새로운 지식입니다.

- 인수인계를 받거나 신규 직원이 들어왔을 때 해당 시스템을 보다 빨리 습득할 수 있습니다.

- 유사한 형태의 개발을 진행할 때, 버그를 수정할 때  참고하면 버그 발생률을 현저히 저하시킬 수 있습니다.

- 잊어버렸던 과거 지식을 필요할 때 언제든 다시 불러올 수 있습니다.

 

KMS라는 거창한 솔루션이 필요한게 아닙니다. 그냥 카테고리화 할 수 있고 검색할수 있고 약간의 템플릿을 구성할 수 있는 게시판이면 족합니다.

 

 

 

'프로젝트관리' 카테고리의 다른 글

조직의 비전 vs 개인의 가치  (1) 2013.04.02
Visual Studio 없는 소스관리  (0) 2013.03.13
인수 요구 산출물  (0) 2013.01.03
그 사람을 대신 할 사람은 없다  (0) 2013.01.03
아무나 = 아무도 ?  (0) 2012.04.12

submit

인수 요구 산출물

Posted in 프로젝트관리 // Posted at 2013. 1. 3. 18:50

외부 시스템을 인수 받아서 운영을 해야 할 경우, 전달 받아야 할 산출물을 생각해 봤다.

 

유스케이스 명세서, 기능 차트, 제품 백로그와 같은 실제 구체적 산출물은 개발 방법론 혹은 프로세스에 따라 달라지기 때문에 필요한 항목과 설명을 우선하고 예시로 산출물을 제시한다.

 

또한 자체 개발일 경우 개발 과정에서 산출되어지는 산출물은 배제되었다.

 

필요 항목 설명
프로젝트 착수/수행 계획 프로젝트 착수 시점에 원가, 비용, 범위등의 계획을 포괄적으로 기술한 문서
요구사항 정의 시스템 사용 주체(현업)의 요구사항을 정리한 문서(기능/비기능 요구사항 전체)
기능 정의 요구사항을 기반으로 시스템이 제공해야 하는 기능을 종합적으로 정리한 문서
용어 정의 업무 및 시스템에 사용되는 비즈니스 용어를 설명한 문서
정책 정의 시스템이 반영하고 있는 업무 정책을 설명한 문서
시스템 아키텍처 시스템의 전체적인 구성과 흐름, 관계를 포괄적으로 기술한 문서
개발표준 정의 프로그래밍 코드/구조 등 공통 규칙 및 프레임워크, 공용 라이브러리, 개발 환경 등을 정리한 문서
프로세스 흐름 특정 업무처리(특히 복잡한 프로세스)에 대한 수행과정의 흐름을 도식화한 문서
구성요소 관계 클래스, 객체, 컴포넌트의 구조와 관계를 도식화한 문서
인터페이스 명세 시스템이 외부로 오픈한 기능에 대한 인터페이스를 정리한 문서
화면 기획 UI가 있을 경우 화면 구성 및 시나리오를 정리한 문서
DB ERD 데이타베이스의 개념/논리/물리 ERD
DB Object 명세 데이터베이스에 생성된 각종 객체들에 대한 상세한 명세를 기술한 문서
CRUD 매핑 데이터의 입력/수정/삭제/조회에 따른 테이블 영향을 매트릭스로 매핑한 문서
시스템 구성 시스템의 물리적 장비(네트워크, 서버 등) 구성을 도식화한 문서
외부 시스템 연동 명세 3rd Party 컴포넌트 및 외부 시스템 연동 관계 및 방법을 정리한 문서
품질 테스트 결과 단위/통합 테스트, 성능/보안 테스트 등에 대한 시나리오와, 결과 등을 체크한 문서
시스템 운영 지침 설치, 배포, 데이터 관리, 배치 작업, 수명 주기 등 시스템 유지관리에 필요한 항목을 정리한 문서
시스템 사용 가이드 시스템을 사용 주체(현업)를 위해 작성된 사용 설명서
시스템 개선 계획 미해결 요구사항 및 시스템의 개선이 필요한 항목(들)을 정리한 문서
이해관계자 정의 시스템 개발/운영과 관련된 이해관계자를 정리한 문서
프로젝트 완료 보고 프로젝트 완료를 공식적으로 승인한 문서

 

산출물 예시는 아래와 같다. 좀 과한 느낌? 필수와 옵션으로 나누면 될터이다.

 

마지막으로.. 이런 건 정답 없다!

 

프로젝트 착수 보고서, 프로젝트 수행 계획서 등
요구사항 정의서 등
기능 차트, 제품 백로그, 유스케이스 명세서 등
용어사전, 용어집 등
업무 정책 정의서 등
논리, 물리 시스템 아키텍처 등
네이밍룰, 코딩 규칙서, 개발환경 정의서 등
액티비티,시퀀스 다이어그램, 플로우차트, 업무 흐름도 등
클래스,객체, 컴포넌트,패키지 다이어그램 등
프로토콜 연동 명세서, 인터페이스(API) 연동 명세서, 연동 가이드 등
UI 스토리보드, 화면 설계서 등
개념, 논리, 물리 ERD
Table, Stored Procedure, View, Trigger 명세서 등
CRUD 테이블 매핑표
네트워크, 서버 구성도. 서버 스펙 정의서 등
3rd Party 제품 매뉴얼, 외부 시스템 연동 가이드 등
시스템 성능 지표, 테스트 시나리오 및 결과서, 체크리스트 등
설치,배포 가이드, 배치작업 명세서, 데이터 보관/백업/복구 정책 등 운영자 가이드 등
시스템 사용자 매뉴얼 등
미해결 요구사항 목록, 결함/오류 보고서, 시스템 개선항목 정의서 등
이해관계자 리스트 등
프로젝트 완료 보고서 등

'프로젝트관리' 카테고리의 다른 글

조직의 비전 vs 개인의 가치  (1) 2013.04.02
Visual Studio 없는 소스관리  (0) 2013.03.13
경험 관리하기  (0) 2013.01.04
그 사람을 대신 할 사람은 없다  (0) 2013.01.03
아무나 = 아무도 ?  (0) 2012.04.12

submit

그 사람을 대신 할 사람은 없다

Posted in 프로젝트관리 // Posted at 2013. 1. 3. 18:46

 

그 자리를 대신 할 사람은 많지만, 그 사람을 대신 할 사람은 없다

프로젝트를 관리하다 보면, 제일 어렵고도 중요한 것이 사람이라는 생각이 듭니다.

 

유용한 많은 기법과 방법론들, 자동화된 각종 도구들이 많은 업무를 깔끔하게 처리해 주지만

'결국 일은 사람이 하는 거다' 라는 말 처럼 사람이 근간이지요.

 

모든 프로젝트 팀이 혹은 모든 팀의 구성원이 높은 열정을 지속하기 힘든 게 현실입니다.

 

업무의 비전, 당면한 처우, 상대적 박탈감과 같은 다양한 사건들이 항상 우리의 열정을 끌어 내리려 합니다.

 

문득 책일 읽다가 좋은 표현을 봤습니다.

'그 자리를 대신 할 사람은 많지만, 그 사람을 대신 할 사람은 없다'

 

말 장난 같은 이 말을 가만히 들여다 보면, 참 감동되는 말입니다.

 

'자네 아니라도 그 일 할 사람 많어!!!' 라는 일침을 가하기 전에 생각해 보아야 할 문제입니다.

 

실제로 그 일 할 사람은 많을지 모릅니다. 그게 현실이다 보니 직업 불안정성은 언제, 어디나 있죠.

(죄송합니다. 저도 가끔 이와 유사한 말을 내뱉은 적이 있습니다)

 

그런데 좀 더 본연으로 들어가 보고 싶습니다.

업무가 아닌 사람을 먼저 보고 싶습니다(음.. 대선 후보 같은 말이네요...)

 

그 사람 만이 가진 능력, 개성은 아무도 대체할 수 없습니다.

 

박애주의냐구요?... 아닙니다.

저는.. 성과지향, 경쟁을 통한 쟁취, 현실적.. 이런 단어들과 친숙한 사람입니다.

 

다만,

사람에 대한 이해와 공감을 선행하고 그 사람만의 개성과 능력을 발휘할 수 있도록 도움을 주는 것이 관리자가 갖추어야 할 덕목이라는 말을 하고 싶은 겁니다.

 

노력 해야죠.

 

 

'프로젝트관리' 카테고리의 다른 글

조직의 비전 vs 개인의 가치  (1) 2013.04.02
Visual Studio 없는 소스관리  (0) 2013.03.13
경험 관리하기  (0) 2013.01.04
인수 요구 산출물  (0) 2013.01.03
아무나 = 아무도 ?  (0) 2012.04.12

submit

아무나 = 아무도 ?

Posted in 프로젝트관리 // Posted at 2012. 4. 12. 15:05

'아무나 하면 된다'에 아무나가 과연 누구일까?

 

프로젝트를 진행하다 보면 특정 그룹에 업무를 부여할 때가 있다.

근데 그 그룹에 특정 1인을 지목하기가 애매한 경우 그룹 전체에 부여하게 된다.

 

그러나 그 일은 한 사람이 맡아서 하면 될만한 일일 경우 간혹 다음 공식으로 귀결되는 경우가 있다

 

"아무나 = 아무도"

 

즉 아무나 하면 된다는 것은 아무도 하지 않는다는 씁쓸한 결과이다.

 

초등학교때 교과서에 이런 글이 기억날 것이다.

 

어느 화목한 가정에서 아버지가 가족이 모두 모인 저녁 시간에 바지 밑단을 좀 잘라 줬으면 하고 부탁했다. 그날 밤 엄마는 물론이고 자식들도 스스로 자신이 솔선수범하여 그 일(바지 밑단을 자르는 일)을 해 버리는 바람에 아침에 아버지는 반바지가 되어 버린 바지를 입어야 했다. 이 일을 자랑스럽게 여긴 아버지는 옆집 아저씨한테 이 말을 하자 그 옆집 아저씨도 자기도 한번 가족을 테스트(?) 해보 싶어졌다.

 

옆집 아저씨도 가족이 다 모인 저녁에 바지 밑단을 잘라 줬으면 하고 부탁했다.

다음날 아침, 설레이는(?) 맘으로 바지를 입어 봤더니 바지는 여전히 길게 축~ 늘어져 있던게 아닌가. 옆집 가족은 일종의 화목하지 않은 가정의 사례로 '누군가 하겠지' 하고는 다른사람에게 떠 넘긴 것이다.

 

이 이야기는 가족의 화목이라는 주제를 다룬 것이지만 여기서도 '아무나=아무도' 현상이 보이는 것이다.

 

프로젝트를 진행하다 보면 모든 팀이 한 가족처럼 화목(?)하지는 않다. 화목하지 않은 근원 이유를 제거하는 것이 가장 좋지만 여기서는 그러한 원론적인 해결을 논하려 하는 것이 아니다.

 

'아무나' 라는 애매한 설정이 결국 아무도 하지 않는 현상에 초점을 맞추려 한다.

 

심리학에 보면 '다수의 무지'라는 것이 있다.

수십명의 목격자가 지켜보는 가운데 처참하게 살해된 살인 사건에서의 교훈으로 '모두의 책임은 아무의 책임도 아닌 상태'가 되어버린다는 것이다. 그래서 위험한 상황이 발생하면 그냥 '도와 주세요'가 아닌 '그기 누구 나 좀 도와주쇼!'가 되어야 한다는 것이다.

 

특정 그룹이지만 특정인이 하면 되는 일은 그 일을 할 사람을 분명하게 지목해 주는 것이 좋다.

 

물론 위의 화목한 가정처럼 "아무나 = 전부다"의 공식이 성립하는 분위기라면 (바지 밑단이 과도하게 잘린 사소한 실수를 제외하고는) 더할 나위 없이 좋겠지만 우리네 프로젝트 환경이 꼭 그렇지는 않다는 것이다.

 

누구를 탓하기 이전에 좀더 정확하고 명확한 업무 부여가 필요하며 나아가 프로젝트에 참여하는 모든 구성원이 스스로 솔선수범하여 일을 척척 해 나가는 것이 중요하다.

 

그것이 프로젝트의 재미이지 않겠는가...

 

 

'프로젝트관리' 카테고리의 다른 글

조직의 비전 vs 개인의 가치  (1) 2013.04.02
Visual Studio 없는 소스관리  (0) 2013.03.13
경험 관리하기  (0) 2013.01.04
인수 요구 산출물  (0) 2013.01.03
그 사람을 대신 할 사람은 없다  (0) 2013.01.03

submit