정보, 통신, 기술/개발? 개발! 개발^^ 41

요구사항 변경에 대처하는 개발자의 자세

프로그램 개발에서 요구사항 변경은 피할 수 없는 운명과도 같다. 피한다고 피할 수도 없고, 그렇다고 당당하게 마냥 즐길 수도 없는 그런 존재이다. 프로젝트는 요구사항, 일정 그리고 인력 자원으로 시작한다. 최종 산출물은 당연히 훌륭하게 작동하는 소프트웨어다. 보통 일정과 인력 자원은 변경이 없으니, 흔들리는 요구사항에 따라서 흔들리는 것은 소프트웨어다. 보통의 클라이언트들은 요구사항을 계속 추가하고, 기존 요구사항을 자꾸 변경한다. 변경된 사항에 따른 일정 조절이나 추가 인력 자원 투입은 불가한 경우가 많으니 결국엔 요구사항에 충실하지 못한 소프트웨어가 나오고 만다. 예전에는 어떻게 요구사항을 고정할지에 대한 이야기를 했고, 요즘에는 어떻게 변경되는 요구사항에 맞출까를 많이 이야기한다. 처음 막연한 구상..

Two Track 개발팀 구성론

개발팀을 구성할 때 다음과 같이 하면 어떨까하는 생각이 듭니다. 하나의 제품 안에 2개의 팀을 구성하고, 설계 - 구현 - 검수 - 휴식을 번갈아 가면서 진행하는 것이죠. 검수와 설계 단계에선 두 팀의 상호작용을 최대한으로 해서 앞 버전의 검수와 뒤 버전의 설계를 같이 진행하고, 구현 자체는 각 팀에서 책임지고 진행하는 것이죠. 스텝별로 역할을 구성하면 다음과 같이 됩니다. PM은 쉴때가 없군요ㅡㅡ;; 생각해 보니 각 버전의 구현 단계에서 PM은 좀 쉬어도 될 것 같습니다^^;; 표 에서 숭~~ 숭~~ 비는 부분이 많아서 일 안 하고 뭐하나 하는 의문이 생길 수도 있지만, 이런 팀 구성의 의도는 잦은 릴리즈와 각 버전별 책임 강화 그리고 휴식을 통한 재충전입니다. 휴식은 정말 휴가가 되거나, 전체 기간 ..

SI 프로젝트 역할 구성

SI 프로젝트는 다양한 조직의 다양한 사람들이 함께 일한다는 점에서 웹포털 개발과는 다른 점이 있습니다. 여러 조직간의 이해가 충돌해 갈등이 발생할 여지가 높죠. 그래서 역할을 분명히 하고, 역할 책임자를 확실히 하는 것이 중요합니다. ** SI 프로젝트 역할도 프로젝트의 중심을 잡는 PM의 역할이 중요하고, PM은 의사결정권자에게 보고하고, 프로젝트의 여러 중요한 이슈에 대한 결정을 내립니다. 현업과의 원활한 의사소통을 통해 프로젝트가 현업의 요구사항을 충실히 반영하게 해야 하고요. PMO로 부터 여러 지원 사항을 받습니다. PM 은 업무설계, 개발설계, 개발의 3개 하부 조직을 운영합니다. 각 조직엔 해당 업무를 잘 아는 PL이 있어야 하고요. 각 PL이 실제 작업자들을 책임집니다. 이렇게 프로젝트를..

FireFox 3.0 설치

저도 FF3.0을 설치했습니다. 친MS 계열에. 오픈소스도 안 좋아하고, 여러 옵션을 유지하기에는 너무 게으른 성격이라 지금까지 IE 불편없이 계속 사용해 왔는데 사내에서 이제 FF도 지원해야 한다고 합니다. 새로 올리는 페이지들은 기본적으로 FF에서 작동을 확인할 거라는... orz... 전에 중요 서비스들에 일괄적으로 크로스브라이징한다고 해서 FF2.0 설치하고 한동안 실행도 안 시켰는데 한번에 점핑했네요. Firefox 기능 개요를 보니 재미있고 끌리는 기능들이 좀 있긴 하네요. http://www.mozilla.or.kr/ko/firefox/features/ 둘의 경쟁으로 점점 좋은 소프트웨어를 사용하게 되는 것은 좋죠. 경쟁 없이 협동했다면 진보와 혁신은 더 늦춰졌을까요?

MS REMIX08 방문기

어제는 간만에 휴가를 내고 MS 행사(?)를 댕겨왔습니다. 휴가를 낼것까지는 없었을지도 모르지만, 한가하게 세미나에 참석하고 싶은 마음에 그랬죠^^ 세미나 주제도 사실은 현장에서 제대로 익혔습니다. UX에 대한 MS의 전략과 제품 소개, 그리고 파트너와 개발자 정도로 요약이 가능하겠네요. ** MS REMIX08 아젠다. 오전세셔만 듣고 집에 와서 한가로이.... 오전 세션만 듣고 일어났습니다. MS의 제품(sliverlight와 WPF)은 아직 관심이 없어서 말이죠. 약간 늦어 도착하니 외국사람의 KeyNote가 한창이더군요. 아시아 총괄인가 했던 것 같습니다. 한국에 대한 경험도 다양한지 직접 찍은 사진들로 MS가 생각하는 UX에 대해 잘 설명하더군요. 그리고 김국현 부장의 Talk Show가 있었습..

프로그램 프로젝트의 과제

프로그램 프로젝트의 우울한 현실은 원칙의 차이에 있습니다. 프로그램의 원칙은 다음과 같습니다. 1. 에러와 버그가 없게 안전할 것 2. 보수가 용이한 틀로 구현할 것 3. 기능이 작동할 것 반면에 프로젝트의 규칙은 다음과 같구요. 1. 일정을 지킬 것 2. 자원을 아낄 것 3. 기능이 작동할 것 에러와 버그가 없게 안전하고 보수가 용이한 틀로 구현하면서도 일정을 지키고, 자원을 아끼면서 기능이 작동하게 하는 것이 프로그램 프로젝트의 과제이죠. 이 원칙들은 상이하고 대치되기도 합니다. 일정을 지키고, 자원을 아끼면서 에러와 버그가 없고, 보수가 용이한 틀로 만드는 것은 정말, 정말 매우 어려운 작업입니다. 보통 일정, 자원, 프로그램 품질, 보수 용이성과 같은 항목 중에서 취사 선택을 하게 됩니다. 일정을..

개발직군에 문서 도우미 역활

개발직군에는 개발자를 도와주는 TA(technical assistant)가 있습니다. 기술 도우미(?) 정도로 풀어 설명할 수 있는 것으로 개발에 있어 중요한 기술적 이슈가 발생했을 때 개발자를 도와 문제를 해결하는 역활입니다. 전 이와 비슷하게 DA(document assistant)가 있으면 좋겠다고 생각합니다. 문서 도우미로 코드를 문서로 전환해 주는 역활이죠. 프로그램은 코드로 표현됩니다. 하지만, 코드를 분석하는 것은 쉽지 않은 일이고, 프로그램의 작동을 이해하고 있어야 하는 기획자에겐 많이 어려운 일이죠. 따라서 많은 경우 문서화 작업을 진행합니다. 하지만, 아쉽게도 여러가지 이유로 문서는 적절하게 유지 되지 못하는 경우가 발생합니다. 아예 갱신이 안 되거나, 갱신이 되더라도 작성자가 바뀌고,..

일정관리의 희비

Case 1. 20MD의 작업이 진행된다. 오픈은 꼭 20일 후에 완료해야 하는 작업이다. 개인별로 하루중의 40%가 신규 개발에 투입된다고 판단되어 20MD를 0.4로 나눈다. 혼자 하면 50일이 걸린다는 예상. 3명이서 17일만에 완료하도록 개발자를 배정한다. Case 2. 30MD의 작업이 진행된다. 오픈은 꼭 10일 후에 완료해야 하는 작업이다. 10일 후에 완료하기 위해 작업 분량을 조절한다. 20MD가 남았다. 10일 후에 완료한다고 보고 하기 위해 개발자에게 10MD만에 하라고 명령한다.(혹은 설득한다??) --------------------------------------- Case1의 개발자는 행복하다. 일을 제시간에, 정확한 서비스로 완료하기 위해 열심히다. 하루의 60%는 시존 서비..

4. 개발과 관리 지원 툴 - 프로젝트 관리의 다섯번째 규칙

0. 나눠서 정복하라 - 프로젝트 관리의 첫번째 규칙 1. 프로세스 정립 - 프로젝트 관리의 두번째 규칙 2. 시나리오 작성 - 프로젝트 관리의 세번째 규칙 3. 공통 요소 정리 - 프로젝트 관리의 네번째 규칙 수정이 빈번하고, 하나의 수정이 여러 곳의 수정을 연달이 일으키는 경우, 이런 수정 작업을 지원하는 툴을 꼭 갖추고 있어야 한다. 이슈와 소스 관리, 도움말 생성 툴을 흔히 접할 수 있는 이유는 이러한 요구 사항과 소스, 그리고 도움말의 경우 수정이 빈번하고, 하나의 수정 사항이 여러 곳에 영향을 끼치기때문이다. 툴을 사용하는 것은 개발과 관리를 용이하게 하고, 작업 중의 문제 발생의 여지를 줄인다. SP의 템플릿을 일괄 변경해야하는 작업이 생겼을 때 수천개의 SP를 수동으로 처리할 것인지, 자동..

3. 공통 요소 정리 - 프로젝트 관리의 네번째 규칙

0. 나눠서 정복하라 - 프로젝트 관리의 첫번째 규칙 1. 프로세스 정립 - 프로젝트 관리의 두번째 규칙 2. 시나리오 작성 - 프로젝트 관리의 세번째 규칙 프로젝트와 관련된 모든 항목은 관리되어야 한다. 단어는 단어 사전으로 정리하고, 처리 흐름과 기능은 프로세스로 정리한다. 디자인과 소스도 정리되어 관리된다. 그리고 이 모든 요소에 대한 데이타, 메타 데이타를 생성하고, 관리한다. 메타 데이타의 1) 항목을 정리하고, 2) 정리된 요소를 통합한다. 통합은 각 영역에서 공통인 요소를 찾아 합치고, 비공통인 항목들을 최대한 공통으로 흡수하는 작업이다. 단어의 사용에서, 처리 흐름과 기능 상에, 디자인적인, 코드적인 측면에서 공통 부분을 찾아낸다. 디자인은 공통 디자인 템플릿으로, 소소도 공통인 부분을 공..

반응형