RDC의 독서 클럽 - 린 소프트웨어 개발의 적용

개발실에서 독서클럽을 통하여 읽은 책의 내용을 정리한 것입니다.

'린 소프트웨어 개발의 적용'이라는 책에는 우리가 간과하고 넘어갔던 많은 일들에 대해서 언급을 하고 있습니다.
이 책에서는 단순히 소프트웨어 개발 자체만을 가지고 예기를 전개 하지않고, 개발로 인하여 파생가능한 문제점 모두를 다루고 있습니다.
사실, 우리는 제품을 개발하는 회사에 몸 담고 있기 때문에 다른 파트에 있는 분들도 개발의 과정이라던지 자신과 연계된 부분에 대해서는 잘 알아야, 모든 일들이 원할하게 돌아가지 않을까 싶습니다.

앞으로 책을 보고 나면 계속 정리해서 올릴 예정이니 정리된 내용이나마 관심을 가져주셨으면 합니다.



다음은 4장까지의 중요하다고 생각하는 내용들입니다.

Ch.1 역사 (History), 20페이지, 30분 ¶

• 재고가 줄어들면 비용을 초래하는 낭비들이 드러난다.
• 부분적인 효율을 극대화하려는 노력을 멈추고 전체의 효율을 높여야 한다.
• 린 개발은 품질과 개발일정과 개발 생산성을 동시에 개선한다.
• 린 개발의 방식은 다음 네 가지가 필요하다.
  • 시스템 설계자의 기업가적 리더십
  • 전문 기술 인력
  • 책임 기반의 계획과 통제
  • 집합 기반 동시공학
• 현실적인 문제를 인정하자(권희웅)
  • 주변 요구를 무시하는 시스템을 만들지 말자...
  • 많은 요구사항을 처리할 수 있고 잦은 설계의 변경을 당연한 일이라고 인정하고이에 적합한 시스템을 만들자

Ch.2 원칙 (Principles), 28페이지, 37분 ¶

• 7가지 원칙
• 소프트웨어 개발에서 가장 큰 낭비는 사용하지않는 기능이다.
• 개발 후 버그를 찾기 위해 테스트하는 것이 아니라 개발단계에서 품질을 고려해야한다.
• 품질을 내재화하지 않으면 빠른 속도를 유지할 수 없다.
• 예측은 예측일 뿐이다. 예측을 하려하지 말고 사건이 발생하면 빠르게 대응할 수 있어야 한다.
• 설계 단계에서 모든 일을 정희하려고 하지 말자. 실질적인 설계하는 개발을 하면서 시작된다. (권희웅)
• 정말 중요한 오직 하나의 지표를 최적화하면 나머지 숫자들은 스스로 관리될 것이다.
  • 개발실 포커스 리포트를 작성하는데 중요한 얘기가 될 것 같습니다(권희웅)
• 고객을 떨쳐내는 프로세스를 만들지 말자.(권희웅)
  • 요구사항 처리에 있어서 복잡한 프로세스나 기간등의 문제로 고객에게 포기하게 만들지 말고 이를 빨리 들어줄 수 있는 시스템을 만들자
    • 개인적으로 내 주변의 모든 사람은 내 고객이라고 생각합니다.
• 스스로 자만하지 말자(권희웅)
  • 이삼년차 개발자쯤 되면 자신이 모든걸 다아는 전문가가 되었다고 생각한다.
  • 전문가라는 기준에 좀더 엄격한 기준이 필요하고, 이에 대한 교육이 필요하다...

Ch.3 가치 (Value), 26페이지, 35분 ¶

• 한가지를 정말 정말 잘하는 것이 최선이다.
• 고객만족도를 획기적으로 높이기 위해서는 매력품질을 높여야 한다.
• 해야 할 업무에 집중하라.
• 기술지원팀은 아마도 개발팀을 데려다가 설치를 시켜보고 싶을 것이다 :)
• 잘못될 수 있는 것은 잘못되고야 만다.
• 제품 개발팀도 비용대비 수익을 얼마나 냈는가로 평가받아야 한다.
• 제품의 가치를 만들기 위해서는 슈퍼맨이 필요하다(권희웅)
  • 한사람의 슈퍼맨이라는 말에는 동의 하지 않음

Ch.4 낭비 (Waste), 32페이지, 40분 ¶

• 복잡성은 콜래스테롤과 같다.
• 소프트웨어의 모든 기능을 탑재하는 것은 죄악이다.
• 개발자들이 필요하지 않은 코드를 만들어 내느것 보다는 차라리 인터넷 서핑을 하는 것이 낫다. ( 시스템 필요하지 않는 기능을 만들어내면, 시스템이 살아 있는 동안 비용을 지불하게 된다.)
• 잘 정의된 시장 요구가 있을 때 까지 개발자들은 어떤 기능도 구현해서는 안된다.
• 기능을 일찍추가 하지 않고, 나중에 추가할 수 있는 구조를 만들어라

앞으로 일어날 일들을 예상하여 이것저것 뭐든지 할 수 있도록 설정 가능한 애플리케이션 프래임웍을 만들어 내는 시도는 실패만 거듭해 왔다.

• 결함을 예방하기 위한 검사는 어느 프로세스에서나 절대적으로 필요하지만, 결함을 찾아내기 위한 검사는 낭비다.
• 복잡도 비용은 지수적으로 증가한다.
• 여러개의 작업을 동시에 처리하여야 한다면, 작업을 전환하는데 더 많은 시간을 소요한다.
• 시간 텀이 긴 프로세스는 시스템관점에서 상당한 낭비가 될 수 있다. 개발 요청의 사안에 관계없이 한달 이상의 시간이 걸리는 프로세스는 효용성 및 효율성이 없다. 즉각 대응할 수 있는 시스템으로의 전환이 필요하다.
  
• 개발자들이 오늘 만든 코드를 일주일 뒤에 테스트 한다면, 곧바로 테스트 하는 것에 비하여 많은 시간상 손실이 된다.