애자일에 대해

yyj·2022년 12월 7일
0

생각

목록 보기
2/2

몇번이나 애자일에 대해 알아보았으나 도무지 이걸 어떻게 도입하고 어떻게 적용하는지에 대해서는 알지 못했다.

그도 그럴것이 제안서에 애자일 방법론을 적용해서 프로젝트를 수행하겠다고 했으나 실무에서 이에대한 행동은 물론이고 언급조차 없었다.

그러나 나는 프로젝트를 관리하는 리더의 입장에서 일을할때 일의 효율성과 옳바른 방법들을 고민하게되면서 어떤 부분에서는 애자일 원칙들과 들어맞는 부분이 존재한다는 것을 알고 놀랐다.

애자일에 대해 자세히 알아보고 더욱 발전시켜 어떠방식으로 해 나갈지 정리 해 보려 한다.

  1. 애자일 선언 원문
  1. 애자일 선언의 원칙들
    : 애자일 선언의 원칙들을 실무에서 어떤식으로 적용할지 주간적인 생각을 담았다.

    1) 가치있는 소프트웨어를 일찍, 지속적으로 전달하여 고객을 만족시키는 것을 최우선으로 한다.
    -> 애자일 방법론은 빠르고 짧은 피드백 루프를 가진다 더 빨리, 더 짧게 피드백 루프를 만들숭록 애자일스럽다고 한다. 피드백 루프가 빠를수록 대응할 기회를 얻고 그에대한 행동으로 프로젝트가 민첩해진다. 애자일은 이로서 문제를 드러나게 한다. 그럼으로 일찍, 지속적으로 전달한다.

    2) 개발의 막바지 단계이더라도 고객의 요구사항 변경을 환영한다. 애자일 프로세스들은 변화를 활용하여 고객의 경쟁력을 높이는 데 기여한다.
    -> 폭포수 방법론의 경우 분석/설계과정에서 나온 산출문서 부터 시작하여 여러가지 변화에 대응하기가 어렵다. 요구사항의 변경은 또 다른 리스크를 동반하기도 한다. 그러나 애자일스럽게 동작하는 소프트웨어를 우선순위로 둔다면 변화에 쉽게 대응할 수 있다. 또한 소프트웨어분야는 다른보다 더 쉽게 변화하고 그 주기가 짧아지고 있다. 시장에 맞추어 발빠르게 대응하는것은 고객의 경쟁력을 높이는 아주 중요한 요소이다.

    3) 동작하는 소프트웨어를 몇 주에서 몇 개월 단위로 자주 전달한다. 가능한 한 전달주기를 짧게 한다.
    -> 나는 요구사항이 항상 추상적으로 다가왔었다. 요구사항을 잘못이해하여 기능을 잘못 구현한 경우도 있었다. 그리하여 요구사항을 최소한으로 만족하는 프로토타입을 먼저 전달하고 확인 후 점차 개선하는 방향으로 진행한적이 있었다. 고객은 처음에는 귀찮아 하는듯 보였으나, 고객은 요구사항을 정확하고 빠르게 완성되가는것을 보고 아주 흡족해하였다. 또한 고객이 직접 개발과정에 참여하도록 유도한다는 점에서 더욱 만족해하였다.

    4) 비즈니스 담당자들은 프로젝트 기간 내내 매일 개발자와 함께 일한다
    -> 애자일은 결과물을 사용자에게 보여줌으로서 피드백을 통해 문제를 해결나간다. 여기서 사용자는 기획자, 투자자, 최종 고객 또는 비즈니스 담당자이다.

    5) 프로젝트는 동기가 부여된 개인들로 구성한다. 그들이 필요로 하는 환경과 지원을 제공하고 프로젝트가 완료될 때까지 믿고 맡긴다.
    -> 내가 이직을 고려시 첫번째 우선순위는 자율성이였다. 프로페셔널한 사람은 자율성을 자원으로 활용해 성과를 낸다. 또한 이것을 통해 스스로 동기를 부여하기도 한다. 나 또한 자율성을 보장받을때 내가 존중받는다는 느낌이 들고, 그로인해 스스로 책임감을 부여하게된다. 애자일이라는 것은 단순한 방법론을 넘어 개발자에게 좋은 소프트웨어를 만들수 있는 장인정신 또한 심어준다는 생각이 들었다.

    6) 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 마주보고 대화하는 것이다
    -> 어느 서비스 회사는 "잡담이 경쟁력" 이라고 한다. 누군가 말을 걸면 반드시 응해주어야 한다고 한다. 나 역시도 유사한 경험이 있다. 잡담을 나누다가 삼천포로 빠진 이야기속에서 해결의 실마리를 얻기도 하고, 술을 마시며 대화를 나누다보면 다른사람의 회사생활, 진행중인 프로젝트에 대한 이야기를 듣기도 하고 어떤 인사이트를 얻어가는 경우도 있다. 커뮤니케이션 수단이 단지 문서였다면 절대 불가능했을것이라고 생각한다.
    사람간의 얼굴을 보고 대화를 한다는것은 하나의 과정이며 그 자체로 문제를 드러나게 하는 수단이 되기도 한다. 또한 가장 빠른 피드백을 얻을수있는 수단이다.

    7) 프로젝트의 진척도를 가늠하는 가장 기본 요소는 동작하는 소프트웨어다.
    -> 폭포수 모델에서 분석/설계 과정에서 나오는 산출물은 요구사항이 변경되면 다시 처음으로 돌아가 무용지물이 되기 일수이다. 고로 동작하는 소프트웨어로 진척도를 가늠해야 한다(?)

    8) 애자일 프로세스들은 지속 가능한 개발을 이끈다. 투자자, 개발자, 사용자들은 일정한 개발 속도를 계속 수용할 수 있어야 한다.

    9) 기술적인 탁월함과 좋은 설계에 대한 지속적인 관심은 기민함을 높인다.
    -> agile(기민함)은 기술적 탁월함에 기반하고 있다. 이 방법론과 프로세스를 바꾸는 것은 기술적 탁월함이라는 것 없이는 오히려 독이 될 수 있다.

    10) 단순함, 즉 하지 않아도 될 일은 최대한 하지 않아야 한다.
    -> 불필요한 비용을 줄이고 빠른 피드백을 통해 민첩하게 반응 한다.

    11) 최선의 아키텍처, 요구사항, 설계는 스스로 조직화되는 팀에서 나온다.

    12) 개발팀은 정기적으로 일을 어떻게 하는 것이 더 효과적인지 되돌아보고 그에 맞추어 일하는 방식을 조율하고 바로 잡는다.

    참고 : 산드로 만쿠소 저권오인 역, 『소프트웨어 장인』, 권오인 옮김, 길벗(2015.09.25), p042-055.

profile
면접 떨어진 개발자의 블로그

0개의 댓글