Agile

지능(INT)만 올리지 말고 민첩(AGI)도 올려라, 개발자여

Agile에 대해서 정리하겠습니다

Agile = 민첩한

한글로는 '애자일'이라고 씁니다

게임에서 흔히 접하는 Agility(민첩성)의 Agile이 맞습니다(Dex 말고)

 

 

애자일은 소프트웨어 개발 방법론 중에 하나입니다

 

[소프트웨어 개발 방법론]

/*

개발자들이 소프트웨어 개발을 계속하다 보니

특정 과정이 반복되는 게 느껴집니다

우당탕 닥치는 대로 맨땅에서 개발하는 거보다

 

해당 과정을 정립해서 개발을 수행하는 게 계획/설계하기에

좋은 방법이란 걸 알게 됩니다

소프트웨어 공학 내용이죠

 

그렇게 소프트웨어를 개발하는 여러 가지 방법을

상세하게 정리한 방법론이 나옵니다

 

종류

- 애자일 방법론

- 구조적 방법론

- 정보공학 개발 방법론

- 객체 지향 개발 방법론

- 워터폴 방법론

- 등등

*/

 

 

애자일 방법론은 뜻 그대로

민첩한 소프트웨어 개발 방법이란 의미일까요?

 

 

---

 

워터폴(Waterfall)

 

기존에 순차적으로 개발을 진행하는 워터폴 방법론(폭포수 모델)이 있었습니다

 

그림과 같이 소프트웨어 개발 프로세스가 폭포수의 흐름과 같은 형태이기 때문에 붙은 이름입니다

 

 

해당 방법은 1970년도부터 나타났으며 제조/건설 산업 현장에서부터 비롯했습니다

보다시피 선형적이기 때문에 선형 순차 모델 혹은 고전적 소프트웨어 생명 주기라고 합니다

 

 

당시 소프트웨어 개발은 아래와 같이 이루어졌습니다(워터폴 모델)

• 요구사항 분석(Requirements)
• 설계(Design)
• 개발(Development) - [or 구현(Implementation)]
• 테스트(Test) - [or 검증(Verification)]
• 배포(Deployment) - [or 유지보수(Maintenance)]

 

 

그럼 기존의 워터폴 모델을 두고 애자일 모델이 많이 쓰이는 이유는?

 

 

1년 정도 걸리는 프로젝트를 수행한다고 생각해보자

워터폴 모델의 경우

• 체계적으로 설계하고
• 각 단계별 사항대로 개발하고
• 단계가 명확해 문서화나 관리가 쉬우며
• 업무가 명확하며 각 맡은 분야를 수행하면 되므로 개발 속도가 빠름

 

이는 깔끔하고 문제가 없어 보이는 처리 단계지만 그건 개발자 입장에서의 이야기이다

 

 

문제 1--------------

대부분의 개발이란 '고객의 요구사항대로 소프트웨어를 만드는 것'이다

하지만 이 '요구사항'이란 건 고정되어 있는 것이 아니며

고객의 의견이 들어갈 수 있는 부분은 

첫 단계(요구사항) 혹은 마지막 단계(배포) 언저리 부분뿐이다

 

 

고객의 요구사항과 개발의 결과가 일치할 가능성은 제로에 가깝다

형태가 나오기 전까지 고객은 원하는 대로 진행되는지 알 수 없으며

형태가 나올 때쯤엔 사실상 무조건적인 피드백에 의한 수정이 생기는 것이다

--------------

 

문제 2--------------

혹은 시장이나 트렌드가 크게 변하여 개발이 끝나고 보니

1년 전의 설계는 목표한 성과를 이루기가 어려운 상황이 되었다

--------------

 

 

명확하며 빠른 프로세스를 가진 워터폴은

요구사항과 수정에 유연하게 대응하지 못하며

이를 위한 방지도 없으며 해결을 위한 비용이 크다

(기존에 만든걸 다시 설계하고, 다시 수정하고, side effect도 확인해야 하고, 다시 시험해야 하고...)

 

 

이건 마치 개발자가 단계적인 테스트 없이

소프트웨어 개발을 끝내고 나서

결과를 테스트해보는 것과 같이 위험하다

(어디서 잘못됐는지, 어딜 바꿔야 하는지, 바꾸면 어디에 문제가 생기는지 골 때린다)

 

 

결과적으로 일정과 고객의 만족을 맞추기가 어렵다

 

 

---

 

애자일(Agile)

 

위의 워터폴에서 부족한 것은 무엇일까?

• 고객의 피드백을 받기 어려움
• 받더라도 결과가 너무 진행된 후에 받아 적용하기 어려움

 

그렇다면 이를 해결하기 위해서는

고객이 피드백을 할 수 있게 빠른 형태를 제공해야 하며

피드백에 민첩(Agile)하게 대응할 수 있어야 한다

 

 

워터폴은 한 턴으로 개발 과정을 마치지만

애자일은 한 턴을 짧게 여러 번 수행한다

 

 

한 턴은 Sprint라고 하며 각 Sprint는 약 2~4주가량으로 정해지며

Sprint 마다 최대한 형태를 먼저 갖추는 식(프로토타입)으로 개발되어

고객과의 피드백이 이루어진다

 

 

이러한 개발 방식의 변화로

고객의  피드백에 효과적으로 맞출 수 있으며

시장이나 트렌드의 변화에 빠르게 대처할 수 있다

 

 

또한, 각 Sprint마다 다양한 분야의 인원들이

빠르게 만나 여러 번 협력해 보기 때문에

새로운 시너지를 만들 기회도 생긴다

 

 

---

요구 사항이 복잡할수록 이런 상황이될 가능성이 높다

 

우와 그렇다면 애자일은 더 세련되고 항상 옳은 개발 방법인가?

 

그렇지 않다

개발 방법에 최상은 없으며 늘 그렇듯이 tradeoff가 있다

- tradeoff : a balancing of two opposing situations or qualities, both of which are desired

 

 

 

워터폴이 고리타분한 방식처럼 묘사되고 설명되었지만 애자일에 비한 장점이 있다

• 요구 사항이 간단/명확하며 수정할 거리가 없는 경우
• 시장이 변화할 거리가 경우
• 주어진 시간이 매우 짧은 경우
• 매우 빠른 결과를 보기 위한 경우
• 일반적으로 익숙한 개발 방법이다

 

애자일도 단점이 있다

• 개발 프로세스를 익히는데 시간이 걸린다(러닝 커브)
• 고객이 할 일이 많다
• 팀원 간의 높은 협력성이 요구된다
• 팀원의 자립성이 없는 경우 손해가 크다

 

물론 요구 사항에 대한 안정성은 이론적으로 애자일이 높은 게 당연할 것이다

 

 

실제로도 그럴까?

우린 공학자이므로 아래의 통계로 확인해보자

 

• Successfully - Meaning that the scope, goals, and objectives were met, the project was completed on time, and the project came in at or under budget
• Challenged - Meaning that at least one of the four conditions was not met - either the project was over budget, or it took longer than expected, or the scope, goals, and objectives were somehow compromised.
• Failed - A failed project is one that was either given up on or canceled.

 

프로젝트 타입에 따라 다르겠지만 일반적으로 예측한 통계가 나오며

요즘처럼 빠르게 시장이 바뀌는 상황에서 적절해 보인다

 

실제로 현재도 조금만 찾아보면

많은 기업이 애자일 프로세스에 익숙한 개발자들을 원하고 있다

 

---

애자일에 대해 더 알아보자

 

애자일은 스크럼이라는 이름으로 언급되어 왔으나 공식적으로는 2001년부터 시작합니다

 

 

당시 17명의 개발자들이 짧은 개발 기간, 경영진의 사전 계획/승인을 기반으로 한

워터폴 모델에 불만이 생기고

 

 

미국 유타주의 한적한 스키 리조트에 모여(TMI...)

애자일 선언문(Agile Manifesto)을 만든 것으로 알려졌다

 

 

기존 방식으로는 막대한 자금과 노력을 들여도

고객의 니즈를 만족시키기 어려우며

이는 곧 실패로 이어지기 때문에

 

 

고객과 시장의 변화에 민첩하게 반응하여

실패를 최소화하자는 것이다

 

---

 

애자일 선언문(Manifesto for Agile)

http://agilemanifesto.org/

Manifesto for Agile Software Development

 

 

애자일 선언문을 살펴봅시다

가장 먼저 가치 있는 4가지 주요 특성이 나옵니다

 

• Individuals and interactions over processes and tools
  • 개인과 개인 간의 상호작용이 프로세스 및 툴보다 우선
• Working software over comprehensive documentation
  • 작동하는 소프트웨어가 포괄적인 문서보다 우선
• Customer collaboration over contract negotiation
  • 고객과의 협업이 계약 협상보다 우선
• Responding to change over following a plan
  • 변화에 대응하는 것이 계획을 따르는 것보다 우선

 

애자일은 오른쪽도 중요하지만 왼쪽의 것들에 더 가치를 둡니다

협력, 결과물, 유연함을 중요시하고 있습니다

 

 

애자일의 12가지 원칙도 살펴봅시다

 

• Our highest priority is to satisfy the customer
  through early and continuous delivery
  of valuable software.
  • 우리의 최우선 순위는, 가치 있는 소프트웨어를
    일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
• Welcome changing requirements, even late in
  development. Agile processes harness change for
  the customer's competitive advantage.
  • 비록 개발의 후반부일지라도 요구사항 변경을 환영하라.
    애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이
    되게 한다.
• Deliver working software frequently, from a
  couple of weeks to a couple of months, with a
  preference to the shorter timescale.
  • 작동하는 소프트웨어를 자주 전달하라. 두어 주에서
    두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
• Business people and developers must work
  together daily throughout the project.
  • 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에
    걸쳐 날마다 함께 일해야 한다.
• Build projects around motivated individuals.
  Give them the environment and support they need,
  and trust them to get the job done.
  • 동기가 부여된 개인들 중심으로 프로젝트를 구성하라.
    그들이 필요로 하는 환경과 지원을 주고 그들이 일을
    끝내리라고 신뢰하라.
• The most efficient and effective method of
  conveying information to and within a development
  team is face-to-face conversation.
  • 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장
    효율적이고 효과적인 방법은 면대면 대화이다.
• Working software is the primary measure of progress.
  • 작동하는 소프트웨어가 진척의 주된 척도이다.
• Agile processes promote sustainable development.
  The sponsors, developers, and users should be able
  to maintain a constant pace indefinitely.
  • 애자일 프로세스들은 지속 가능한 개발을 장려한다.
    스폰서, 개발자, 사용자는 일정한 속도를 계속 유지
    할 수 있어야 한다.
• Continuous attention to technical excellence
  and good design enhances agility.
  • 기술적 탁월성과 좋은 설계에 대한
    지속적 관심이 기민함을 높인다.
• Simplicity--the art of maximizing the amount
  of work not done--is essential.
  • 단순성이 -- 안 하는 일의 양을
    최대화하는 기술이 -- 필수적이다.
• The best architectures, requirements, and designs
  emerge from self-organizing teams.
  • 최고의 아키텍처, 요구사항, 설계는
    자기 조직적인 팀에서 창발한다.
• At regular intervals, the team reflects on how
  to become more effective, then tunes and adjusts
  its behavior accordingly.
  • 팀은 정기적으로 어떻게 더 효과적이 될지
    숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

 

위의 내용은 원칙이라 딱히 정리할 게 없네요

애자일은 반복으로 인한 습관으로 길들이는 게 중요합니다

위의 선언문은 반복적으로 읽어 두는 게 큰 도움이 됩니다

 

 

---

 

 

나는 이때까지 애자일을 했을까..?

 

석사 병특으로 회사에 입사하고

신입사원 프로젝트 개발 및 발표 이후

석사 인력이다 보니 R&D 업무를 주로 수행하였습니다

 

기술 조사, 분석, 세미나 위주의

선행 기술 프로젝트에 계속 투입되었다가

 

핵심 개발 프로젝트도 참여하고부터는

애자일에 대해 모른 상태로

매 SPRINT 마다 개발을 수행했습니다

 

사수님이 스크럼이란 단어를 사용하시길래

조용히 찾아보니 현재 회사에서 수행하는 방식이

애자일이었습니다...ㅋㅋ

 

아무것도 모르고 맞춰했던 게 부끄럽기도 했지만

그 점 때문에 오히려 자연스럽게 익숙해진 게 아닌가 생각이 듭니다

 

저희는 주로 Confluence, JIRA를 활용하여 협업하였으며

대부분 4주 단위의 Sprint를 수행했고,

별일 없으면 일주일마다 팀 회의를 수행하며 간단한 피드백을 받았으며

Sprint를 마치면 본부단위로 발표를 진행했습니다

 

선행 개발 프로젝트에서는 주로 기술 스터디 위주였고

주어진 일정이 너무 촉박해

코드 리뷰를 너무 적게 했다는 점이 좀 아쉬웠습니다

 

회사 분위기가 수평적이지가 않아서

껍데기만 애자일인 느낌..? 을 지울 순 없었습니다

당시 팀에서 저 말고는 모두 경력이 15년이 넘는 베테랑분들이어서 배우고 따라가기에 급급했네요

 

애자일의 원칙이 더 습관화하고 보편화되어

저도 다른 개발자들도 함께 성장할 수 있는 기회가 많아지면 좋겠네요

 

[reference]

https://www.eetasia.com/agile-approach-to-soc-design-verification/

Agile Approach to SoC Design Verification - EE Times Asia

https://www.soldevelo.com/blog/is-agile-always-the-best-solution-for-software-development-projects/

Is Agile always the best solution for software development projects? - SolDevelo Blog