문성준의 단단해지기

저번에 애자일 방법론의 간단한 개념에 포스팅을 했다면 , 

이번에는 애자일을 더 알아보기 위해 책을 한권 추천하려고 한다.

애자일 프랙티스

–밴캣 수브라마니암 , 앤디 헌트-

이 책은 애자일이 어떠한 것이고 전체적인 흐름과 소프트웨어 개발에 어떻게 적용되어 지는지에 대해 가볍게 읽기에 좋은 책이다.

중간중간 리뷰를 하자면 서문에 이러한 구절이 있다.

“용기를 내서, ‘ 위험을 무릅쓰고서라도(Damn the Torpedoes)’ 올바른 선택을 지속해 나간다면 프로젝트에서 성공한 자신을 발견하리라 믿습니다.”

여기서 올바른 선택은 무엇일까?

선택을 통해 완벽한 결과가 나와야 올바른 선택인지, 결과는 좋지않지만 과정적인 면에서 효과가 나왔다면 그게 올바른 선택인건지는 확답할 수는 없겠지만 다양한 소프트웨어 환경에서 올바른 선택이 무엇인지에 대해 방향성을 제시해 주는 책이다.

이 책에서 애자일 소프트웨어 개발은 다음과 같이 정의한다.

"소프트웨어는 늘 변하는 환경이다."

소프트웨어 프로젝트는 팀 내 개발자들의 숙련도와 훈련, 경쟁력에 의존한다.

이 부분을 보더라도 이 책에서는 소프트웨어의 다양성과 무궁무진한 변수를 항상 고려하고 염두해야한다고 보고있다.

이 책에서 애자일 정신의 기원을 알 수 있다. 

이 책의 저자인 앤디 헌트 또한 Agile Developer 의설립자로 유타주 스노버드에 모인 17명중 1명이다.

애자일 정신의 기원은 다음과 같다.

2001년 2월 경량 프로세스라고 막연히 불리며 떠오르던 경향에 대해 토론하기위하여 관심을 가진 사람들 17명이 유타주 스노버드에 모였다.

장황하고 , 부산물은 많고, 결과는 부실한 프로세스 때문에 프로젝트가 실패하는 것을 보아왔고, 방법론을 검토하는 좋은 수단이 있어야하는 필요성을 느꼈다.

이 17명은 ‘애자일’ 이라는 새로운 용어를 만들고 소프트웨어 개발에서 새롭게 집중해야할 접근 방법을 설명하기 위해서 애자일 선언을 공표하였다.

접근방법은 사람,(people), 협조(collaboration), 반응성(responsiveness), 동작하는 소프트웨어(working software)를 강조한다.

애자일 소프트웨어 개발 선언문

 

1.     ‘프로세스와 도구’ 보다는 ‘개인과 상호작용’을

 

2.     ‘포괄적인 문서화’ 보다는 ‘동작하는 소프트웨어’ 를

 

3.     ‘계약 협상’ 보다는 ‘고객과의 협력’을

 

4.     ‘계획 준수’보다는 ‘변화에 대응’을

 

왼쪽에 있는 것들에도 가치가 있지만, 오른쪽에 있는 것들에 더 가치를 둔다

 

더 많은정보는 http://agilemanifesto.org/

 

기원과 선언문에서도 볼 수 있듯이 애자일 접근 방법은 빠르게 반응하고 상호 협력하는 사람들과 논증 가능한 구체적인 목표를 결합하는 것이다.

애자일 실천방법은 어떻게 서술 했을까?

“ 애자일 개발은 고도의 협력적인 환경에서, 지속적인 조정을 위해 피드백을 사용한다.”

 

개발작업을 공유하며 일하고, 소프트웨어 비용을 지불할 고객과 가까이 일하고, 그들에게 시스템의 최신버전을 가능하면 빨리 그리고 자주 보여준다.

 

이 과정에서 피드백을 얻고, 자동화를 사용해서 끊임없이 프로젝트를 빌드하고 테스트한다.

 

이것을 리팩터링(refactoring) 이라 하고, 개발하면서 계속해야하는 것이다.

라고 서술되어 있다.

결국엔 리팩터링(refactoring)은 끊임없는 커뮤니케이션이다.

이 책은 전체적으로 위에서 서술한 바와 같이 전체적인 애자일을 글로 느껴보고 싶은사람에게 추천을 하고싶고,

애자일 시작 -> 애자일 성장 -> 사용자들이 원하는 내용제공 -> 애자일 피드백 -> 애자일 코딩 -> 애자일 디버깅 -> 애자일 협력

으로 서술 되어 있다.

이 책을 읽다보면 마음에 와닿는 어구들이 많이 등장한다.

대표적으로 뽑자면

“개인 감정을 드러내지 말고, 프로다운 자세를 유지하자.” 라는 어구가 굉장히 마음에 들었다.

나는 6개월동안 두 프로젝트를 진행하였다. 프로젝트를 진행하며 좋은사람들을 많이 만났지만 아닌 사람도 있었다.

그런 사람들을 보면 존경심보다는 피하고싶은 느낌밖에 들지 않았는데 그런사람들의 공통점이

개인감정을 드러내는데에 역력한 사람이였다.

그 사람들은 개인감정을 드러내기위해 틈을 놓치지 않았고, 사람을 몰아세우기를 좋아했다.

아마 업무에 대한 스트레스를 감정소비로 해소하는 사람 같았다.

마치 책 한권을 읽었는데 프로젝트의 시작과 끝을 경험해보는 느낌도 들었다.

취직하면 책은 안읽을 것 같았는데, 찾아보니 재밌는 내용이 많았다.

소프트웨어가 기대한대로 동작하지 않는다면 어떻게 될까?

소프트웨어의 셀 수 없이 많은 특징 과 로직에 의해 방대한 양의 문제가 발생될 것이다.

그래서 소프트웨어개발 생명주기에도 "테스트" 단계가 들어가는 것이고,

또 이를 "유지 ,보수" 하는데에 많은 시간과 기술력을 투자하는 것이다.

소프트웨어의 개발, 유지보수, 운영시 테스팅의 역할

 

-       시스템이나 문서에 대한 엄격한 테스팅은 운영중 발생할 수 있는 문제 감소

 

-       소프트웨어 시스템의 품질을 높이는데 기여

 

-       계약 또는 법적 요구사항이나 특정한 산업 표준을 만족 시키기 위해 필요

이렇게 테스트 되어진 소프트웨어는 품질에대해 확신을 가질 수 있게된다.

"테스트 = 품질" 

결함이 극소수 이거나, 혹은 테스트 도중 결함을 확인하여 수정된 소프트웨어는 그만큼 품질에 확신이 들 것이다.

테스팅과 품질

 

-       기능적, 비기능적 소프트웨어 요구사항과 특성에 관련된 해당 소프트웨어의 품질을 , 발견된 결함(데이터)에 근거하여 측정 가능

 

-       테스팅으로 발견된 결함이 극소수이거나 없다면 소프트웨어 품질에 대해 확신을 가짐

 

-       올바르게 디자인된 테스트는 시스템의 전반적인 리스크 수준을 감소시킴

 

-       다른 프로젝트에서 발견된 결함의 근본 원인에 대한 이해를 바탕으로, 프로세스 개선, 동일 결함의 재발이 방지될 수 있어 , 차후 시스템의 품질 개선

(품질의 부연설명으로 기능적, 비기능적 소프트웨어 요구사항에 대해서는 다음에 포스팅 하려고한다.)

S/W 나 H/W , 올바르게 테스팅 하려면 기간을 어느정도로 측정 해야할까?

테스팅 기간

 

1. 리스크 수준을 고려하며, 비즈니스 제품 및 프로젝트 리스크, 시간과 비용 같은 프로젝트 제약사항을 고려해야한다.

 

2. 테스트된 소프트웨어나 시스템의 다음 개발로의 릴리즈 결정 또는 고객에게 넘겨주는 릴리즈 결정을 개발 프로젝트 관련자들이 내릴 수 

 

있도록 충분한 정보를 제공한다.

 

( 여기서, 릴리즈란 . 각 소프트웨어에는 우리말로 판(Version, Release)이라고 부르는 버전표시가 되는데, 이 버전이라는 것은 이 프로그램이 

 

얼마나 개선되었는가를 뜻하는 표시입니다. )

프로젝트 리스크의 수준을 고려하고, 제품 품질에 관해 조금만 더 신경을 쓴다면

기획 및 설계 단계에서 부터 목소리가 커질일은 없을 것이다.

여러 직무를 담당하고 있는 프로젝트 팀원끼리 좋은 커뮤니케이션을 형성 하고, 프로젝트를 진행할 수 있을 것이다.

*피드백은 언제나 힘이 됩니다.*

요즘 읽고 있는 책인데 흥미로운 구절이 있어 적어 보았다.

개발자를 위한 단위 테스트라는 책인데 아직 다 읽지는 못하고 초반에 테스트 관련 내용, 테스트 단위 개발의 필요성만 읽은 상태이다.

읽다가 버그 수정 비용의 증가라는 것을 따로 책에 구분에 놓았길래 흥미가 있어 몇자 적어본다.

<<버그 수정 비용의 증가>>

 

버그 수정 비용은 평균적으로 얼마나 될까? 런던에서 열린 ‘XP Day 2009 컨퍼런스’ 에서 마크 스트리에벡 ( Mark Striebeck) 은 구글에서 결함을 수정하기 위해 지연된 시간을 비용으로 계산해서 공개 하였다.

 

구글이 측정한 바로는 프로그래머가 버그를 만들자마자 즉시 수정한다면 $5 를 쓴 것이다. 같은 결함을 프로젝트 전체 빌드 때 발견하면 비용은 $50이 된다. 만약 통합 테스트까지 살아남으면 $500로 증가하여 시스템 테스트에 이르면 $5000까지 치솟는다.

 

이러한 수치만 보더라 하더라도 문제는 가능한 빨리 발견해야 한다는 건 이론의 여지가 없다.

 

$5 -> $50 -> $500 -> $5000

초기에 발견하지 못하면 1000배 가까이 손해가 발생된다. 만약 초기에 발견하고 완료를 했다면 $4995 는 

회사입장에서 회식비, 보너스로 들어갈 수 도 있는 적지 않은 돈이다.

시스템 테스트까지 발견되지 못한 버그는 어떤 것 들이 있을까?

* 피드백 환영 입니다 *

애자일 소프트웨어 개발(애자일 개발 프로세스)

(Agile software development)

애자일 방법론은 소프트웨어 개발 방법에 있어 아무런 계획이 없는 개발 방법과 

계획이 지나치게 많은 개발 방법들 사이에서 "타협점"을 찾고자 하는 방법론이다.

less doucment - oriented 즉, 문서를 통한 개발방법이 아닌

cord - oriented 실질적인 코딩을 통한 방법론이다

과거의 개발 프로세스와 다르게 앞을 예측하지 않고, 일정한 주기를 가지고

끊임없이 프로토 타입을 만들어 낸다.

그때 그때 필요한 요구를 더하고 수정하여 하나의 소프트웨어를 개발한다.

-개발배경-

"소프트웨어 개발 자체가 다른 공학적인 프로세스와 큰 차이가 있음을 인지한 것"

소프트웨어는 유동적이고 개방적이다. 요구사항 변경에 따른 작업량은 예측 불가하다.

객체지향적인 기술을 기반으로 하고 제한된 시간과 비용 안에서 정보는 불완전하고,

예측은 불가능하다는 전제.

그 전제아래에 합리적인 답을 내는 것이 애자일 개발 프로세스 이다. 

*피드백 환영입니다*

SDLC(Software Development Life Cycle)

"시스템 엔지니니어링, 정보 시스템 또는 소프트웨어 공학에서 정보 시스템을 계획, 개발 , 시험, 채용 하는 과정을 뜻하는 용어"

소프트웨어 개발 생명 주기는 하드웨어부터 소프트웨어 까지 넓은 범위에 적용 가능

대게 요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 운영(유지보수) 단계로 구성되어 있다.

테스트 엔지니어는 테스트를 최종적으로 결함이 없는 제품이 나와야 좋겠지만

"이 과정에서 SDLC 에 관한 각각의 파트들을 이해하고 있다면 실 업무에서 훨씬 더 유용하게 테스팅을 진행할 수 있다."

*피드백 환영합니다*