분류 전체보기 347

엔터프라이즈 환경에서 아키텍처 팀의 역할

- 이 글 역시 바로 전 글과 같은 맥락에서 작성을 했는데.... 고민의 시간과 작성 시간이 아까워서 블로그에 남겨본다. 프로젝트를 해요?~~~프로젝트 사업을 만든다, 고객의 요구사항을 듣는다,제안서를 작성한다, 요구사항 분석서를 작성한다, 고객의 요구사항 중 비기능 요구사항을 식별한다, 비기능 요구사항에 따른 기술구조를 선택하고 솔루션을 선택한다, 아키텍처를 설계하고 검증을 위한 선도 개발을 한다 , 개발 표준을 제시하고 개발 표준의 준수여부를 체크한다. 위의 일련의 행위를 통해서 프로젝트가 만들어지고 진행되어집니다. 프로젝트가 진행되다 보면 팀간의 상호 인터페이스에서 부딪히는 역할 문제와 책임문제에서 자유로울 수 없습니다. 그런 역할 문제와 책임문제를 의사결정 해주고 승인해주는 것은 누구의 역할일까요..

아키텍트의 역할과 자질에 대한 고찰

- 1년쯤 전에 써본 아티클인데... 부끄러운 글이지만,,, 그리고 꽤 짜집기를 했지만, 이 짧을 글을 쓴다고 안돌아가는 머리 고생하고 고민을 꽤 한 시간이 아까워서 이렇게 블로그에 기록으로 남깁니다. 다시 읽어보니까,,,너무 나열식이다. ㅎㅎㅎㅎ. 왜 아키텍트일까? 흔히 IT 아키텍처를 말할 때 비교하는 건축 도메인과의 비교를 해 보면 고객의 요구사항을 받고 뼈대를 잡고 그 뼈대에 필요한 것들을 쌓아서 고객의 요구사항을 구현한다. 몇 천년 동안 지어진 건축물을 보면서 노하우가 쌓이고 시행착오를 극복해온 건축쪽 도메인과 달리 소프트웨어 분야는 역사도 짧을 뿐더러 아키텍처 자체가 기업의 자산과 보안이 되는 관계로 공유가 그다지 많지 않다. 그나마 인터넷의 발달과 오픈소스의 발전 그리고 블로그의 기술 포스팅..

애자일 프로세스를 접하는 우리의 자세

주변에서 애자일을 도입해서 실패한 사례를 자주 접한다. 그리고 힘들었던 사람들도 많이 봤고... 일정 부분 겪는 부분도 있다. 고객들의 잘못된 받아들임으로 인해서 고생하는 SI 프로젝트의 사람들도 봤다. 그런데.... 그게 애자일을 잘못 받아들인 문제일까? 라는 생각을 해 보았다. 방법론의 문제일까? 애자일이 애초에 시작한 배경이 무엇일까를 생각해보면 답이 나온다. 수많은 프로세스에 따른 결과물. 그 결과물을 작성하기 위한 공정. 실제 프로젝트에 필요한 것이 무엇일까에 대한 고민. 이런 것들로부터 도출된 것이 애자일 프로세스이다. 그런데 ... 이런 프로세스를 공부한 사람들조차 도입할때는 프로세스만 도입한다. 그리고 명목을 입힌다. 그렇게 되면 무엇이 문제가 될까? 당연히 ... 형식만 입히게 되겠지. ..

개발의 즐거움 2012.03.31

소프트웨어 모델링에 대한 접근-1

1. DDD DDD 를 더 읽어봐야 알겠지만, 패턴화 시키고 , 분류법을 만들어주고 , 지켜야할 규칙에 대해서 공감한다. 그러나 접근법. 레베카가 주창하던 책임기반의 객체 식별 기법외에는 특별하게 다른 접근법이 없다 . 1.1. Object Design - 책임과 역할 기반으로 객체 설계를 해야 한다는 핵심 컨셉과 해당 컨셉의 분류와 더불어 인프라 객체/클래스 를 식별하는 과정에서 인사이트를 주던 책이었따. 2. applying uml and patterns( 크레이그 라만 ) 시스템의 가장 큰 행위를 식별하여 시퀀스로 접근한다. 그리고 점진적으로 d&q 한다. 여기서 우리에게 던져 주는 것이 있다. 3. RSM 시스템의 핵심 행위/목적 을 식별하고 그 행위를 통해서 Collaboration 을 도출하며..

전역상태와 public 메타포 - junitInAction2 에서

- JUnit In Action2 내용중 - 모든 사람이(클래스가) 자신의 친구들이(협력자들이) 누구인지 밝히고 있는 사회에 산다고 상상해보자. 조는 매리를 알지만, 매리와 조 모두 Tim 을 모른다는 것을 알고 있다면, 조에게 알려준 정보는 매리에게는 전달될 수 있지만, Tim은 절대 알 수 없다고 가정해도 안전하다. 이제 모두가 일부의 친구만 공개하고, 다른 친구들은 비밀로 하고 있는 사회를 상상해보자 . 그런 사회에서 여러분이 조에게만 알려준 정보를 Tim도 알고 있다면, Tim은 대체 어떤 경로로 이를 알게 되었는지 궁금해질 것이다. 여기가 재미난 부분이다. 만약 여러분이 관계를 만들어낸 ( 코딩한 ) 사람이라면, 여러분은 모든 종속성을 정확히 알고 있지만, 여러분 이후에 합류한 사람들은 모두 당..

개발의 즐거움 2012.03.13

strength test 다시보기

'강점혁명' 의 strength finder 를 통해서 조사했던 나의 강점 몇년 지났지만, 여전히 유효하다. 자신을 잘 알아야 한다. 나의 대표 테마들: Focus/초점: 초점 테마에 강한 사람들은 방향을 정하고, 끝까지 노력을 기울이고 목표를 위한 진로에서 벗어나지 않도록 필요한 수정을 가합니다. 이 사람들은 우선순위를 정한 다음 행동합니다. Learner/학습자: 학습자 테마에 강한 사람들은 배우고 계속 진보하려는 열망이 강합니다. 특히 이 사람들은 결과보다는 학습 과정에 흥미를 느낍니다. Significance/중요성: 중요성 테마에 강한 사람들은 다른 사람들에게 매우 중요한 존재가 되고 싶어 합니다. 이 사람들은 독립적이며 인정 받기를 원합니다. Self-assurance/자기 확신: 자기 확신 ..

자기계발 2011.12.28

프로젝트에서 하루의 일과를 통해서 보는 나의 현재

(하루의 풍광) 오늘도 회사에 출근해서 먼저 에버노트를 펼쳐 봅니다. 간밤에 내가 노트했던 것, 어제 노트했던 todo list , 업무 기록 등을 보면서 오늘 할일을 체크를 하죠 그리고 Things 를 통해서 애플기기간 연동을 통해서 업무들의 우선순위를 보게 됩니다. ( 그러고 싶습니다만, 아직 애플기기는 맥북뿐이라. ㅋㅋ ) 오늘은 온통 회의군요. 회의를 통해서 Action Item 이 도출되고 하루 하루 진척되어가는 것이 쌓여만 간다면, 각 구성원의 R&R 이 명확해지고 회의를 통해서 도출하고자 하는 결과만 명확하다면 더할 나위 없습니다. 회의를 할때는 항상 '회의주제'를 정하고 회의에서 의사결정되어야 할 기준이 되는 자료에 대해서 정리해서 들어가는 것은 필수입니다. 그렇게 각자 할일이 할당되고 자..

자기계발 2011.12.16