'2009/03'에 해당되는 글 2건

  1. 2009.03.05 1.4 프로세스 모델의 목적
  2. 2009.03.05 1.3 스크럼(Scrum)

소프트웨어 생명주기에서 프로세스 모델의 목적은 “Feature – Quality – Time – Resource(사람과 비용)” 이 네 가지의 요소를 최대의 효과를 내기 위해서 이다. 이걸 잘하기 위해 소프트웨어 공학이 존재하고, 많은 개발 방법론과 기법들이 총 동원되고 있다.

 

제가 이 모든걸 다룰 능력은 되지 않고, 개발자에 좀 더 집중하기 위해 QA(Quality Assurance)에 좀 더 비중을 두고 이야기를 풀어 나갈 것이다.

 

소프트웨어 QA 우리말로 하면 품질 보증이 될 것 같다. 그럼 그 특성을 살펴보면, 소프트웨어 품질의 특성은 스티브 맥코넬의 “CODE COMPLATE 2”에서는 소프트웨어는 외적 품질 특성과 내적 품질 특성으로 나누어서 이야기 하고 있다.

 

외적 특성

정확성(Correctness), 유용성(Usability), 효율성(Efficiency), 신뢰성(Reliability), 무결성(Integrity), 적응성(Adaptability), 정밀성(Accuracy), 견고성(Robustness)

 

내적 특성

유지 보수성(Maintainability), 유연성(Flexibility), 이식성(Portability), 재사용성(Reusability), 가독성(Readability), 테스트 용이성(Testability), 이해성(Understandability)

 

중요하지 않은 게 하나도 없다.

 

여기서 집중하고 싶은 내용은 바로 실제 프로그래밍 과정에서 코드 테스트 디버깅과정을 효율적으로 일하는데 많은 시간을 할애 할 것이다.

 

작년 2008 3Heroes Happen Here 이라고 Visual Studio 2008 제품 발표회가 있었다.

이때 제가 발표한 내용이 실전 Visual Studio 2008 Agile Programming이라는 주제로 발표를 했었다.

그리고 2008 5월 동일한 주제로 월간 마이크로소프트웨어 잡지에도 기고한 내용이 있다.

이것 또한 참고하면 도움이 될 것 같다.

 

1장은 이쯤에서 마치고 2장으로 넘어가도록 하겠다.

 

Posted by SF공장장

스크럼을 이야기 하면 당연히 따라 나오는 것이 애자일 소프트웨어 개발(Agile software development)이다. 그 중 가장 대표적인 것이 "Extreme Programming" 이다.

이것을 또 작게 나누면, 프로그래밍 테크닉, 개발 프로세스, 프로젝트 관리 이렇게 세 부분으로 구분 할 수 있다.

스크럼은 애자일 개발 프로세스로 분류할 수 있으며, 여기에는 익스트림 프로그래밍과 FDD(Feature-Driven Development), ASD(Adaptive Software Development) 등이 포함된다.

 

스크럼이 최근 인기를 누리는 건 무엇 때문일까?

마이크로소프트 내에서는 왜 스크럼을 많이 사용하는 걸까?

 

제가 들은 바로는 마이크로소프트 내에서 스크럼을 많이 사용하는 건 처음부터 스크럼이나 다른 모델을 적용했다기 보다는 마이크로소프트 내에서 진행되고 있는 개발 형태를 분석하고 외부 전문가에게 보이니 이 프로세스가 스크럼과 아주 유사했다고 한다. 그래서 자연스럽게 스크럼의 장점을 마이크로소프트 내부 개발 프로세스로 정착 하는 과정에서 마이크로소프트는 스크럼만 한다더라 이런 이야기가 나오게 된 것 같다.

 

 

위의 리서치 자료는 2005년말 기준으로 마이크로소프트 내부에서 애자일 방법 적용과 다른 기업의 적용 결과를 보여 주고 있다. 국내에는 XP가 가장 인기가 있을 시기였던 것 같다. 마이크로소프트 내부를 보니 스크럼이 대다수를 차지하고 2위가 모른다라는 것이 재미있다. J

 

스크럼은 30일 이내의 개발 주기를 설정하고, 구현하거나 개선할 기능에 우선 순위를 부여하고, 개발 주기에 적용하거나 개선할 목록을 설정한다. 그리고 항상 팀 단위로 의사 소통을 하고, 매일 짧은 미팅을 통해 확인해 가는 과정이다.

 

스크럼을 통해 얻을 수 있거나 배울 수 있는 것은 무엇일까?

스크럼은 기술이 아니라 역할이 중심이다.

팀 단위 주기는 최대 30일을 넘지 않는 것이 좋지만, 개발자 개인은 한 주를 단위로 하는 것이 효율적이다.

개발 주기 별 단기 목표를 위해 노력해야 하고, 팀에 의한 팀의 성공과 실패만 있다.

워크 아이템은 4~16시간 정도가 적당하다.

완료라는 것은 개발, 테스트, 필요한 경우 문서, 테스트 샘플 작성 등을 포함한다.

매일 짧은 시간 미팅(15분 정도)은 아주 중요하다. 이 시간은 지켜져야 한다.

 

초보 개발자들은 거절을 잘 못한다. 자기가 다 할 수 있을 거라고 생각하고, 할 수 있다고 이야기 한다. 혹 매니저가 안될 것 같다고 이야기 하면 자기 실력을 의심한다고 아주 불쾌하게 생각하거나 낙심한다.

 

못한다는 것은 실력이 부족해서 못할 수도 있고, 방법이나 리소스를 몰라서 못할 수도 있고, 시간이 없어서 못할 수도 있다. 제가 볼 때 대부분의 경우는 두 번째나 세 번째 경우가 훨씬 많다.

 

대부분의 좋은 매니저들은 이 상황을 잘 알고 있다. 간혹 개발자들에게 이거 할 수 있어, 실력이 없어서 못하는 거 아니야. 이거 못할 거 같은데.” 이렇게 개발자들의 감정을 건드려 할 수 있다는 확답을 들으려는 사람이 있다. 그러고 뒤에 가서는 당신이 할 수 있다고 하지 않았냐?” 등으로 사람을 궁지로 몰아 넣는 경우가 있다.

매니저로서 정말 쉽게 살아가는 경우가 이런 경우다. 당신이 기능 정하고 일정 잡아서, 언제까지 보고해 라는 식으로……

한가지는 확실하다. 이런 매니저는 오래 못 간다.

근데, 회사에서 이 사람의 정치력이 아주 뛰어나거나 높은 곳에 인맥이 있다면이런 경우는

 

젠장, 회사 옮겨야 하나. T.T

 

다음 글은 이제 슬슬 이번 장을 마무리 하는 글로 넘어가도록 하겠다.

 

Posted by SF공장장

티스토리 툴바