Page tree
Skip to end of metadata
Go to start of metadata

Wiki에 작성된 내용은 여러분들이 자유롭게 수정이 가능하시니 좋은 의견이 있다면 커멘트를 적극적으로 달아 주세요 ^^;

 

Software Lifecycle 논의

Introduction

스터디에 참여하시는 다양한 분들이 각각의 조직에서 어떠한 생각들을 가지시고, 현재의 일들을 하고 계시는지 서로 공유하는 시간입니다.

다양한 분야 (솔루션, SI, SM, 모바일, 어플리케이션 개발 등)에서 일하시는 다양한 직종의 스터디원 분들의 조직이나, 개발환경,

개발생태 등을 논의하고, 서로가 개선할 점들에 대한 회고, 우리 조직에서 자랑할 수 있는 부분들, 시행착오를 통해 얻었던

값진 경험들을 공유하고 스터디의 방향을 잡아가는데 좋은 토대가 되었으면 합니다.

 

1. 우리가 속한 환경...

 1.1 나는 지금 어디에?? (개인)

  1. 내가 속한 업무 수행 분야 
    1. SI
    2. SM
    3. 솔루션 개발
    4. 개발 지원 등
  2. 개발 언어 및 도구
    1. Java, C, C++, C#
    2. Python, Scalar, ROR(Ruby on Rails)
    3. jsp, asp, php, html5, jquery, jstl, tiles
    4. RDBMS, No-SQL, Hibernate, myBatis

 1.2 우리는 어떤가요? (조직)

  1. 우리팀 Team의 조직 및 문화
    1. 팀장이 법이다! (수직적)
    2. 만민이 평등하고, 의견제시가 자유롭다~ (수평적)
    3. 그런거 없다. 각자 알아서 해나가자!
  2. 우리 Team이 사용하고 있는 개발 절차(방법론)
    1. 전통적 개발 방법론 (마르미 III, 관리기법1, CBD)
    2. 애자일 - 스크럼, 린...
    3. 자사 자체 개발 방법론
    4. 그런거 없다... 그냥 상급자의 경험에 의존해서
  3. 개발 절차
    1. 순차적 시스템 개발 (요구사항  정의 - 분석 - 설계 - 구현 - 테스트)
    2. 프로토타입 형태의 순환적 시스템 개발
    3. 비 절차적 시스템 개발 (분석 설계를 충실히 수행하지 않고 개략적인 내용으로 개발 시작)

 1.3 우리는 지금 삽질 중?

  1. 변화를 예측하고 막을 수 있는 것인가? 막을 수 없는 것인가?
    1. 경험을 쌓고 노력하면 변화를 예측할 수 있을까? 아니면 변화를 예측하는 능력이 높아질까?
    2. 경험을 쌓고 노력하면 천재가 될 수 있을까? 아니면 우리는 영원한 바보로 남을 수 밖에 없을까?
  2. 우리는 소프트웨어 변화에 어떻게 대처할 것인가?
    1. 변화하는 부분을 미리 예측해 변화가 발생하지 않도록 해야 하는가?
    2. 변화는 발생할 수 밖에 없기 때문에 변화에 발빠르게 대응하는 연습을 해야 하는가?

2. 소프트웨어 라이프싸이클???

 2.1 소프트웨어 라이프싸이클(소프트웨어 생명주기)이란?

  1. 이 세상의 모든 일은 생명주기를 가지고 있다.
    1. 내가 치킨을 튀기던... 밥을 짓던... 화장을 하던... 모두 생명주기를 가진다.
    2. 우리는 IT를 하기 때문에 IT를 위한 방법론이 있는것 뿐!
  2. 소프트웨어에는 다양한 형태의 라이프사이클이 존재한다.
     
  3. 우리가 사용하는 소프트웨어 라이프싸이클의 기본 모델은 건설에서 가져온 방법이다??
    1. 건축의 역사는?
      -> 대략 BC 1100년 부터 현재까지 끊임 없이 발전
    2. 그렇다면 소프트웨어 방법론은?
      ->1980년 부터 구조적인 시스템 분석 및 설계 방법론이 사용됨 

 2.2 대표적인 소프트웨어 (개발) 생명 주기

  • 지금까지 많은 프로젝트의 경우 아래와 같은 방식으로 개발을 진행하는 경우 많았다. 아래와 같이 완전한 Waterfall 모습은 아니지만 앞단에서 상당히 많은 부분을 미리 결정한 후 다음 단계로 이동했다.
  • 아래와 같이 업무를 할 수 밖에 없는 이유는 조직 구조, 기존 업무 방식에 대한 선입견 등등 다양한 요인이 있을 것으로 생각한다.
    • 건설 메타포 - > 오랜 동안 위정자들이 검증된 건설에서의 개발방식에 의지하고 당연하게 여기고 있는 것 같음. 
    • 말랑말랑한 소프트를 하드한 건설에 빗대는것이 오류라고 생각함
  • 아래와 같은 방식으로 일 했을 때의 장점과 단점은 무엇일까?
    • 요구사항의 변경요청이 있거나, 개발 시 닥치는 돌발적인 변수에 대처 할 때 소극적인 자세를 유도한다고 생각함
    • 각단계 마다 넓게 보지만 자세하게 깊게 보지 못하게되는 것 같음
    • 각단계 간에 협조가 필요하기 때문에 일정 문제에서 자유롭지 못하고 뒤 단계 일정을 위해 배려하는마음( ? ) 이 생기는 것 같음

  • 위 업무 방식으로 아래와 같이 바꿀 수는 없을까?
  • 위와 같이 작업한다면 다음과 같은 흐름으로 작업할 수 있지 않을까? 
  • 위와 같은 방식으로 일하는 것이 현실에서 가능할까? 사람을 너무 기계적으로만 보는 것은 아닌가?
    • 숙련되고 손발이 맞는 팀이라면 가능할듯 -> 결국 개발팀 문화가 중요한 관건.....
    • 처음 개발하기 위한 마일드스톤 에 포함되는 기능들을 정의하고 적절한 크기로 잘라내는데 있어서 중용이 필요하다고 생각합니다.
  • 위와 같이 일할 경우 장점이 있을까?
    • 정해진 기간 내에 할 수 있는 일과 하지 못하는 일을 구별하는데 유용할것 같습니다..
  • 위와 같이 일하는 구조로 변경하기 위한 장벽은 무엇이 있을까?
    • 관리자들의 인식 개조가 필요
    • 지속적인 팀 빌딩이 관건이라고 생각합니다.

  • 일하는 방식을 바꾸면 위와 같이 일할 수 있지 않을까? 개발자의 관점에서만 봤을 때...

 2.3  우리가 Smart 해진다면, 고객도 Smart 해질까? (번외 Chapter)

  1. 우리의 주요 고객들은 과연 Smart 할까?
    • 내부 고객들 (사장님, 상무님, 이사님, 부장님, 팀장님 등등등)
    • 외부 고객들 (고객사, 클라이언트, 민원담당자)
    • 나 자신?
  2. 나중에 딴소리 없게 하기 위한 방법 들은?
    1. 위험 관리
    2. 이슈 관리
    3. 형상 관리
    4. 결함 관리

3. So-Hot  "애자일"

3.1 애자일의 정체는???

  1. 애자일의 목적
    • 고객은 Smart 하지 못하다.
    • UML을 백날 설명하고 이해시키려 해봐야... OTL 직접 화면을 보여줘야 이해한다.
    • 고객은 변덕쟁이... 설계도를 마음대로 바꾸면 난 어쩌라고?
    • 그렇다면 고객과 함께 요구사항, 설계, 구현을 검토해 모듈단위로 완성해 나가자!

       
  2. 애자일에서 인정하는 것들!
    • 고객의 요구사항은 "항상" 바뀐다.
    • 한번에 제대로 할 수 있다고 판단하지 마라.
    • 개발의 기간이 길어질수록 변경될 확률은 올라간다.
  3. 애자일 개발 방법론의 유형
    1. XP (eXtreme Programming)
      • 고객이 원하는 소프트웨어를 빨리 전달하자
      • 지속적인 리팩토링과 TDD를 통해 효과적인 요구사항을 반영하자
      • 짝 프로그램밍을 통해 의사소통을 원활히 하자
      • 의미없거나 쓰잘대기 없는 문서는 사절!
    2. 스크럼 (Scrum) 
      • 변화에 적응하지 못하면 도태된다! (민첩함이 생명) -> 경량화된 애자일 방법론
      • 스프린트를 통해 정해진 주기 (2주 ~ 1달)를 기준으로 결과물을 제시한다.
      • 상호간의 커뮤니케이션을 통해 실천 가능한 목표를 세우자!
      • BackLog, User Story
      • 반복적인 개발, 점증적인 개발...
    3. Lean 개발 방법론
      • 낭비를 제거하라!!
      • 대기를 최소화 하라! (개발자가 놀고 있어도, 대기 상태인지 조차 인지 못함 ㅠ_ㅠ)
      • 불필요한 이동 시간의 최소화 (결재 대기, 고객의 확정 지연, 디자인 협의 지연...)
      • 결함을 최소화 하라 (TDD, 리팩토링을 활용한 결함 최소화 - 식스시그마)
    4. 크리스털 패밀리
    5. ASD (Adaptive Software Development)

 

3.2 과연 우리에게 도움이 될까?

  1. 애자일 방법론 도입 시 고민 사항은?
    • 우리는 "자기주도적" 인가?
    • 팀장 및 팀원들은 얼마나 기민하게 움직일 수 있는가?
    • 새로운 문화나 트랜드에 민감하며, 변화에 능동적일 수 있는가?
  2. 애자일을 실천할 수 있는 방법?
    • 최대한 가까운 곳에서, 얼굴을 마주보며!
          ms-pnp_teamTable.jpg
    • 화이트보드, 게시판을 이용하는 방법
      agileTable.gif
    •  "팀장"의 "주도에서 "팀원"의 주도로...
    • 모든것은 스토리(백로그)를 목적으로 주기(스프린트)를 가지고  임하자.
    • 루즈해진다면, 그건 이미 "애자일" 스럽지 못하다.

 

3.3 애자일은 마법의 도구가 아니다 oT^To

  1. 팀원 모두가 주도한다?
    • 결론은 모두 다 한사람의 몫을 충분히 해낼 수 있어야 한다. (개발뿐만이 아닌, 일정의 통제 등..)
    • 팀원 각각의 장단점 및 역량, 수준, 성실도 등을 팀장은 모두 파악하고 관리할 수 있어야 한다. 
      (물론 팀장 주도로 일이 진행되는 것은 바람직 하지 않다.)
    • 우리는 끊임없이 성과물을 제출하고, 그것에 대한 기탄없는 비판을 받을 준비가 되어 있을까?
  2. 우리의 사고는 과연 "애자일" 스러울까?
    • 팀장은 팀의 중심으로 변덕스러운 일정과, 목표치에 대한 상세한 분석, 결과물에 대한 검토를
      수행할 수 있는 "슈퍼맨"인가?
    • 고객은 애자일 프로세스에 대한 충분한 이해 및 학습이 되어 있는가?
    • 1년 이상의 긴 사업인 경우 처음의 마음가짐이 끝까지 이어질 수 있는가?
    • 우리의 Owner는 애자일 프로세스를 이해할 지식 및 마음의 준비가 있는가? 

※ 최근에 콰이어트(quiet)라는 책을 읽었다. 

    1. 이렇게 적극적으로 소통하고 협업하게 하는 것이 외향적인 사람들에게는 좋을지도 모르겠지만 내향적인 사람들에게도 효과가 있을까?
    2. 자본주의 사회에서 외향 지상 주의로 가고 있는데 그 일환으로만 바라보고 있는 것은 아닌가?
    3. 콰이어트 책 보다가 애자일이 모든 사람에게 맞을까라는 생각이 들어서 남겨본다.

 ※ 애자일 참고 자료 : http://keisus.mooo.com:5000/fbsharing/3xyd0IDj

  • No labels

3 Comments

  1. 스터디때에 예전에 들었던 사례를 코멘트 드리려 했는데 시간여유와 문맥에 맞지 않는 등으로 전하지 못하고 이렇게 위키에 코멘트를 달아봅니다 (smile)

    해외 게임개발사에서 근무하셨다가 오신 분이 그때의 환경을 알려주셨던 얘기입니다.

    위 그림에서 보면 jira를 통한 태스크관리가 있는데 그때 근무했던 곳에서는 이 jira같은 협업관리툴을 이용할 때에

    해당 태스크에 대해서 자신이 생각하는 점수같은 것을 주었다고 합니다.(플래닝 포커 카드인지는 모르겠습니다...)

    그리고 자신이 현재 진행중인 업무에 대한 일정도 같이 작성해주었다는데,

    그렇게 하다보니 일정등을 고려했을 때 가장 적합한 팀원이 해당 태스크를 처리하게 된다고 합니다.

    물론 작은 기능은 1인이 되겠구요, 그렇지 않은 경우에는 비슷한 경험을 함께 했던 사람들을 태그를 달듯이 했다고 하네요.

    이게 가능했던 이유는 우선 신입직원이 없었고 다들 수년을 함께 작업해왔기에 서로를 잘 알고 있는 환경이었다고 합니다.

    그리고 또한 저에게 말씀을 전해주신 분같은 경우엔 외부에서 온 인력이라 자신을 어필하기 위해 더욱 그 협업관리툴을 도전적으로 이용했다고 하네요.

    1. 경험 공유 좋네.

      스터디 때 이야기 되었으면 좀 더 구체적으로 질문하고 답변을 들을 수 있는 기회가 되었을텐데 조금 아쉽기는 하네. 하지만 네가 공유한 내용을 보니까 상당 부분이 지난 번에 나왔던 이야기들과 비슷한 부분이 있는 듯하다. 아무래도 사람들이 좀 더 즐겁게 계획적으로 일하는 방법에 대한 고민은 비슷 비슷한 듯하다. 개발자들이 좀 더 주도적으로 책임감을 가지고 자신이 하고 싶은 일을 할 수 있는 환경을 만들면 일은 자연스럽게 잘 되는 듯...

      아마도 대부분의 사람들이 이 내용은 머릿 속에 가지고 있지만 실천은 잘 하지 못한다는 것이 문제이지 않을까는 생각이 드네. 알고 좋겠다는 생각이 들면 실천해야 하는데 이 실천이라는 것이 생각만큼 쉽지 않잖아.

      1. 두번째 단락의 '머릿 속에 가지고 있지만 실천은 잘 하지 못한다는 것이 문제이지 않을까' 너무나 공감합니다 ㅠㅠ

        제가 그런 친구중 한명이거든요... ㅎㅎ; 정말 배워야할 것은 여러 기술도 기술이지만 열정과 실천하는 성실함이겠어요 ㅠㅠ