ALM/Task Management 23

요구 사항 정의 프로세스도 변경해야...

기존의 개발 프로세스에서는 요구 사항을 받아서 개발하는 형태였는데, 이 요구 사항이 완벽하지 않다는 것은 누가나 알고 있고, 이를 전재로 해서, 변경 가능한 요구 사항을 기반으로 개발하는 프로세스가 애자일 프로세스 이다. 관리 관점 뿐만 아니라, 요구 사항을 수집하는 관점도 변화가 필요한데 요구 사항은 고객이 정해주는 것이 아니라, 스스로 정하는 것이다. 고객에게 요구 사항을 받은 것이 완벽하다고 판단하지 말고, 요구 사항이 부족한 부분은 Develop하고, 완벽하게 만들어 나갈것. 즉 고객이나 다른 사람에게 요구 사항 정의에 대해 의존하지 말고, 커뮤니케이션, 가정, 레퍼런스를 통하여 스스로 요구 사항을 정리할 수 있도록 해야 한다. 완벽하지 않은 요구 사항에 대해서는 1. 고객에게 요구 사항을 커뮤케..

ALM/Task Management 2011.12.05

개발자가 하루에 코딩하는 시간은? (Coding 시간 Estimation 공식)

어제 교육을 받으면서 애자일 기반의 방법론에서 개발 기간을 Estimation하는 기법을 배웠는데, 흥미로운 내용이 있어서 포스팅한다. 스크럼과 같은 Iterative 기반의 개발방법론을 사용할때, 각 Iteration이 약 4~6주라고 가정하자 이 경우에는 Interation의 10%는 Planning에 소요되고 25%는 Stabilization (Integration과 Bug 수정) 나머지 65%가 개발에 소요된다. 이 65%기간 동안 매일 25% 정도는 다른 잡무 (회의,코드리뷰등)에 소요되고 남는 시간인 75%만 개발 관련 작업에 사용되는데, 그중에서도 10%는 코딩전의 디자인에 소요된다. 그림으로 도식화 해보면 다음과 같다. Design 시간 = Coding 시간 * 0.1 실제 소요시간 (Cl..

ALM/Task Management 2010.10.01

Trac을 이용한 이슈기반의 팀 관리의 문제점

현재 진행하고 있는 프로젝트에서 Trac을 도입해서 사용하고 있습니다. Trac 뿐만 아니라 사실상 거의 모든 이슈 트랙킹 시스템을 이용하여 팀 일정 관리를 할때 공통적으로 생기는 문제 같은데, 팀관리에서 가장 중요한것은 어떤 TASK를 누가, 언제 하느냐 입니다. 이슈 트랙킹 시스템은, 어떤과 누가를 잘 추적할 수 있게 해줄뿐만 아니라 Comment등을 통한 History 기능으로 어떻게 하느냐까지 잘 관리할 수 있습니다. 그런데 문제는 "언제" 즉 시간에 대한 부분입니다. 이슈 트랙킹 시스템들은 대부분 Time Frame,Mile stone, Due date 식으로 대략 Task 단위의 시간을 제공합니다만, 프로젝트 관리에 있어서 간트 챠트만한것이 없습니다. 문제는 이 이슈 트랙킹 시스템들이 간트 챠..

ALM/Task Management 2009.05.19 (5)

코드리뷰 2.- 언제 어떤 리뷰 기법을 사용할것인가?

언제 어떤 코드 리뷰 기법을 사용해야 하는가? 그러면 이런 많은 코드 리뷰 기법 중에서 어떤 기법을 사용해야할까? 코드 인스펙션 코드 인스펙션의 전제는 전문성을 가지고 있는 인스펙션 팀이 일정한 프로세스와 패턴에 따라서 개선안을 찾는 작업이다. 즉, 고도로 훈련됨 팀과 기간이 필요하고, 어느정도 개발이 완료되어 있는 인스펙션 대상(시스템)이 있는 것을 전제로 한다. 인스펙션의 시기는 시스템이 개발되어 있는 시점인 Release이 유용하다. 필자는 두번의 Inspection을 권장하는데, 개발 초기에 비기능적인 구현을 끝낸 경우 1차 Inspection을 그리고, 개발이 끝난 후 시스템 테스트 (성능,확장성,안정성등)가 그것이다. 1차 Release는 주로 비기능적이고 Risk가 높은 부분을 구현하는 단계..

ALM/Task Management 2009.03.12 (1)

코드 리뷰 - 1. 코드 리뷰 기법들에 대한 소개

들어가기에 앞서서. 소프트웨어의 품질을 보장하기 위한 활동은 테스팅, 일일 빌드, 프레임웍의 사용, 개발 패턴들 수 없이 많은 방법들이 있다. 그중에서 개인적으로 생각하건데, 코드리뷰 만큼 적은 투자로 큰 효과를 얻을 수 있는 기법은 없는 것 같다. 이 문서에서는 코드리뷰에 대한 몇가지 기법에 대한 정리와 함께 적용 방법에 대해서 간단하게 소개해보고자 한다. 코드 리뷰의 시초는 Fagan에 의해서 소개된 코드 인스펙션에서 기인한다. 소프트웨어의 개발이 끝난후에, 전문 인스펙션팀이 정해진 프로세스와 패턴에 따라서 코드를 검증하고 Defect를 찾는 프로스를 코드 인스펙션이라고 한다. 코드 리뷰란, “코드를 실행하지 않고 사람이 검토하는 과정을 통하여 코드상에 숨어있는 잠재적인 결함(Defect)를 찾아내고..

ALM/Task Management 2009.03.11 (2)

Short Release와 회귀 테스트, Itertive and iteration 방법론의 사례

요즘 모회사의 차세대 시스템의 오픈을 막바지에 두고, 성능 향상 컨설팅에 나와 있습니다. 주로 하는 작업이 Code Inspection을 통하여 구조 개선 및 성능 개선을 하는 작업입니다. 그런데, 코드를 보면서 이해가 안되는 아키텍쳐가 종종 있습니다. 이런 의도가 아닐텐데 라던지.. 아키텍쳐 구성이 잘못되었다던지. 그런데 이미 구현이 끝나가는 단계에서 이런 아키텍쳐를 변경하기는 거의 불가능합니다. 알면서도 당하는 케이스라고나 할까요? 이미 여러 코드들이 동일 패턴으로 구현이 되어 있기 때문에, 공통부라면 어떻게 변경을 시도해보겠지만, 아키텍쳐적인 문제나, 통신 전문 같은 경우는 변경이 불가능합니다. 결국 울며 겨자 먹기로 CPU를 늘리거나, 다른 부분의 코드를 튜닝해서 목표 성능치를 내야 겠지요. 그런..

ALM/Task Management 2009.03.04 (8)