내가 사용한 애자일(1/2)

소프트웨어 마에스트로에서 애자일 프로세스를 경험하고 느낀점을 정리

 

소프트웨어 마에스트로를 하기 전의 ‘나’

• 소프트웨어공학을 배우면서 폭포수와 애자일의 차이를 이론적으로 배움
• JIRA를 사용해봤지만 애자일 위에서 사용해보지는 않았음

 

소프트웨어 마에스트로 초반의 ‘나’

애자일이 무엇인가?를 정의하려고 애썼다.. 아래는 내가 실제로 했던 고민들이다.

 

“회고를 잘하고 싶다..! 회고는 어떤 식으로 진행하는 것이 Best일까?”
“User Story, Task, SubTask의 차이점은 뭐지? 어떤 기준으로 나눠야할까?”
“User Story는 사용자는 OO 할 수 있다.. 이런식으로 작성해야한다는데 이렇게 작성하는게 맞나?”

멘토님께 유저스토리와 태스크의 사용법을 질문했던 Webex 메시지

 

이러한 궁금증을 해결하기 위해서 자유멘토링도 듣고, 워킹어스 유튜브도 여러번 돌려보면서 팀의 프로세스를 정의하려고 했다.

 

애자일이 무엇인가?

지금와서 깨달은 것은 "애자일은 정의할 수 없다! 팀이 만들어가는 것이다" 라고 말해주고 싶다.

 

애자일은 짧은 스프린트가 특징이다. 1~2주 동안 스프린트를 반복하면서 회고를 거치고 점진적으로 개선해가는 프로세스이다.

그렇기 때문에 계속 변경하고 개선할 수 있는 여지가 있다는 것이다.

 

팀원 A  : 인터넷 찾아보니깐 “User Story는 사용자는 OO 할 수 있다"처럼 작성해야한다는데 이렇게 작성하는게 맞나?”

 

대신 팀원과 의논하자

팀원 A : 우리 'User Story는 사용자는 OO 할 수 있다'로 일단 해볼까요?
팀원 B :  그렇게 해보시죠

 

만약에 이러한 룰이 불편하다면 회고 시간에 팀과 의논하는 것이다.

팀원 B : 우리가 저번에 정의한 User Story 네이밍이 너무 길어요
팀원 A : 이번엔 한 번 줄여볼까요?
팀원 C : 굳이 구분해야할 필요성을 못느끼면 그냥 User Story를 쓰지말고 Task만 써볼까요?

 

이런식으로 점진적으로 개선하는 방식으로 진행하는 것이 좋을 것이다.

 

사례 1:  데일리스크럼 시간 정하기

우리는 데일리스크럼 시간을 여러 번 바꿨다.

 

[데일리 스크럼 변화]

비동기/오후 12시 → 동기/오전 10시 → 동기/오후 10시

 

처음에는 디스코드로 데일리 스크럼 내용을 텍스트로 공유하는 방식으로 진행했다.

이후 동기 스크럼으로 전환하면서, 내가 아침 시간에 데일리 스크럼을 진행해보자는 제안을 했다.

정확한 기간은 기억나지 않지만, 1~2 스프린트 정도는 아침 스크럼을 유지했다.

 

나같은 경우에는 아침부터 오후까지 프로젝트에 시간을 썼던터라 유용했지만, 모두에게 최적의 시간은 아니었다.

그래서 회고 시간에 데일리 스크럼 시간에 대해 먼저 이야기를 꺼냈다.

그러자 팀원들로부터 아침에는 개인 일정이 있거나 생활 패턴상 맞추기 어렵다는 의견이 나왔다.

결국 팀원들의 의견을 반영해 프로젝트가 끝날 때까지 데일리 스크럼을 오후 10시에 진행하기로 합의했다.

작은 시도와 회고를 반복하면서 팀에 가장 잘 맞는 방식을 찾아가는 과정이 좋은 문화라고 생각한다.

 

스프린트 회고 일부분 발췌

 

애자일은 언제 좋을까?

조직의 입장, 팀의 입장, 개인의 입장으로 생각해볼 수 있을 것같다.

 

1. 팀의 입장에서 애자일 도입을 고려할 때: 팀의 규율이 정해지지 않았을 때

소프트웨어 마에스트로 프로젝트를 예로 들어보자

학교, 나이, 경력 등 모든 것이 다른 사람들이 하나의 프로젝트를 하기 위해서 모였다.

 

이런 상황에서 어떤 Best Practice*를 들고와서 그대로 따르는 것보다 팀원들의 절충안을 찾는 것이 덜 고통스럽고 팀의 목표를 이루는데 효율적일 것이다.

 

* "OO에서는 애자일을 이렇게 쓴다"와 같이 다른 조직에서 사용하는 그라운드룰

 

2. 조직의 입장에서 애자일 도입을 고려할 때: 조직의 목표가 불확실할 때

애자일은 불확실성을 다루기 좋은 프로세스라고 생각한다.

 

만약 “우리가 A, B, C 기능이 있는 서비스만 만들면 성공할 수 있다” 라는 확신이 있다면 애자일을 도입할 필요는 없다.

요구사항을 미리 정의하고, 폭포수 방식으로 차례대로 구현해 출시하면 된다.

 

문제는 대부분의 경우 그렇지 않다는 점이다. 사용자와 시장의 반응은 예상과 다르다. 

"우리가 이 기능을 만들면 사람들이 좋아할까?"
"아직은 잘 모르겠네... 그렇다면 시장의 반응을 최대한 빨리 확인해보자"

 

그래서 모든 기능을 한 번에 만드는 대신 우선순위를 정하고, 짧은 스프린트를 통해 일부 기능만 먼저 출시한다.
A 기능을 먼저 적용해본다 → 반응이 좋지 않다..? → 방향을 바꿔 D 기능을 시도해본다.

 

이처럼 애자일은 조직의 목표가 명확하지 않은 상황에서, 목표를 고정시키는 대신 빠르게 검증하고 필요하면 수정할 수 있게 만든다.

 

3. 개인의 입장에서 애자일 도입을 고려할 때: 내가 성장하고 싶을 때

함께자라기에서 내가 가장 빨리 성장하는 방법은 최대한 많이 실패하는 것이라고 한다.

내가 한달 뒤에 실패한다고 했을 때, 뒤늦게 깨달을 것이다. ex) “이렇게 하지말걸..”

 

하지만 애자일은 짧은 스프린트와 회고 덕분에 가장 빨리 실패하고 가장 빨리 성장할 수 있다.

1~2주의 스프린트만에 실패하고 한 번 더 실패하고 개선할 수 있다.

그 과정에서 타인에게 피드백을 얻거나 다음 번에 내가 더 잘할 수 있는 방식을 고민하고 변경하면 N배 더 빨리 성장할 수 있다.

 

 

 

애자일에서 주의해야할 점: 애자일은 무조건 좋은 것인가?

그렇지않다. 난이도 높은 개발 프로세스라고 생각한다.

 

조직의 목표가 불확실하다고 해서 목표를 세우지 말아야 한다는 의미는 아니다.

애자일에서 중요한 것은 목표를 세운 뒤에도 필요하다면 빠르게 바꿀 수 있는 유연함이다.

 

문제는 이 유연함이 생각보다 큰 비용을 요구한다는 점이다.
경우에 따라서는 지금까지 구현한 기능이나 구조를 포기해야 할 수도 있다.

 

실제로 사용자의 반응이나 멘토님들의 피드백을 통해 방향성이 여러 차례 바뀌었고, 그 과정에서 팀이 혼란을 겪었던 때도 있었다.

 

결론

이번에 애자일 프로세스를 경험하고 느낀점은 어렵다와 아쉽다로 말할 수 있을 것같다.

이론으로 알고있으면서도 막상 적용하지 못했던 것도 많았고, 팀원들과 회고하면서 원하는 결과가 도출되지않았던 때도 있었다.

 

하지만 목표를 빠르게 바꿀 수 있는 유연함을 갖는 것이 `가치 있는 엔지니어`라고 생각한다.

함께자라기에서도 나오듯, 목표가 명확하고 변하지 않는 작업은 이제 인간보다 AI Agent가 더 잘한다.

 

• 내가 변화해야할 상황에 놓였을 때 얼마나 빨리 변화하는가?
• 목표가 변경됐을 때, 팀을 이끄는 사람으로서 팀원들에게 얼마나 빠르게 목표를 동기화 할 수 하는가?