소프트웨어 장인 - Part 1 : 이념과 태도 (1 ~ 2장) (Software Craftsman)

[1장] 21세기의 소프트웨어 개발

[고참 개발자] - p32

개발자 세계에 있어서 고참/신참의 차이는 '경험' 뿐이라고 생각한다. 그 외의 개발자로서의 태도와 임무는 동일하지 않을까?

 

[새로운 현실] - p33

이제 개발자들도 소통을 할 줄 알아야 한다. 더 이상 기술로'만' 승부해서는 안 된다.

[2장] 애자일 - p37

[절차적인 관점에서의 애자일 원칙] - p38

애자일 원칙에 따라 프로젝트가 '올바른 목표'를 향해 진행 중인지 확인시켜 준다.

빠른 피드백을 통해 더 이상 '이 산이 아닌가벼...' 같은 상황을 맞이해서는 안된다.

 

[기술적인 관점에서의 애자일 원칙] - p39

애자일 원칙에 따라 프로젝트 중 목표한 것을 '올바르게 실행'하고 있는지 확인시켜 준다

목표가 아무리 좋아도 실행이 엉망이면 프로젝트는 망한다.

 

[애자일을 따른다는 것] - p39

애자일 방법론들의 요지는 빠르고 짧은 피드백 루프이다.

 

<게임 체인저> - p41

개발자가 단순히 코딩만 하는 것이 아니라 프로젝트의 모든 것을 수행할 수 있게 해준다. 이것이야 말로 '게임 체인저'가 아닌가?

 

<피플 임파워먼트> - p41

애자일 방법론이 수평적인 계층구조를 이룰 수 있게 해주는 것 아닐까? 공동의 목표로 모두 서로에게 피드백을 줄 수 있는.

 

<프로페셔널의 진화> - p41

코드를 잘 작성하는 것은 기본. 저자는 여기에 테스트, 분석, 비즈니스에 대한 이해, 커뮤니케이션 능력, 보다 외향적인 성격을 요구한다.

프로페셔널한 개발자라면! 마땅히 그러하다. (노력해야지...)

 

[애자일 매니페스토] - p42 (책 발췌)

절차와 도구보다는 개성과 화합을, 방대한 문서 작업보다는 동작하는 소프트웨어를, 계약 조건에 대한 협상보다는 고객과의 협력을, 계획을 따르는 것을 넘어서서 변화에 대처하는 것을 더 가치있게 여긴다.

 

<'애자일 매니페스토의 원칙들'>

1. 가치있는 소프트웨어를 일찍, 지속적으로 전달하여 고객을 만족시키는 것을 최우선으로 한다.
2. 개발의 막바지 단계이더라도 고객의 요구사항 변경을 환영한다. 애자일 프로세스들은 변화를 활용하여 고객의 경쟁력을 높이는데 기여한다.
3. 동작하는 소프트웨어를 몇 주에서 몇 개월 단위로 자주 전달한다. 가능한 한 전달주기를 짧게 한다.
4. 비지니스 담당자들은 프로젝트 기간 내내 매일 개발자와 함께 일한다.
5. 프로젝트는 동기가 부여된 개인들로 구성한다. 그들이 필요로 하는 환경과 지원을 제공하고 프로젝트가 완료될 때까지 믿고 맡긴다.
6. 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 마주보고 대화하는 것이다.
7. 프로젝트의 진척도를 가늠하는 가장 기본요소는 동작하는 소프트웨어다.
8. 애자일 프로세스들은 지속 가능한 개발을 이끈다. 투자자, 개발자, 사용자들은 일정한 개발 속도를 계속 수용할 수 있어야 한다.

9. 기술적인 탁월함과 좋은 설계에 대한 지속적인 관심은 기민함을 높인다.
10. 단순함. 즉 하지 않아도 될 일은 최대한 하지 않아야 한다.
11. 최선의 아키텍처, 요구사항, 설계는 스스로 조직화되는 팀에서 나온다.
12. 개발팀은 정기적으로 일을 어떻게 하는 것이 더 효과적인지 되돌아 보고 그에 맞추어 일하는 방식을 조율하고 바로잡는다.

 

[애자일 격변기] - p44

- 백로그(해야할 업무 목록) 관리

- 사용자 스토리를 정의/분할

- 작업 일정

- 우선 순위

- 개발 진행 루프마다 구현된 기능을 시연

- 공동의 목표를 갖고, 피드백 루프 매커니즘이 관건이다.

 

[애자일 행오버] - p46

저자는 다음과 같은 원인들이 '애자일 행오버'를 일으킨다고 한다.

정체된 개발자 역량, 낮은 수준의 동기부여, 잔뜩 쌓여 있는 기술적 부채, 기술적 전문성 부족, 신뢰할 수 없는 릴리즈 절차, 불안정한 시스템, 늦은 버그 발견, 신뢰할 수 없는 데다가 비싼 테스트, 비효율적인 개발/디버깅/배포 주기, 오래 걸리는 빌드, 난해한 요구사항.

애자일이 위와 같은 요인을들 해결할 수는 없다는 것은 다들 알 것이다. '애자일'이라는 시스템을 탓하지 말자. (노력하자...)

 

<부분적인 전환> - p47

저자 또한 '애자일'의 실패는 어설픈 절차 전환에 있다고 말한다. 프로페셔널한 개발자들은 필수적이다.

 

<애자일 코치> - p49

저자는 다음과 같은 질문이 핵심이라고 한다. '애자일 전환이 개발자의 역량 향상에 얼마나 도움이 되었는가?'

사실 역량 향상에 도움이 될까 싶기는 하다. 하지만 '제대로 된' 개발자들이 '제대로' 일을 할 수 있게 끔 해주지 않을까?

매니저 마인드인 걸까...?

 

<새로운 기술적 실행 관례에 대한 거부감> - p50

검증되지 않은 실행 관례에 대한 두려움은 인정한다. 그리고 남들이 다하는 것이라고 꼭 해야하는 건 아니라고 본다.

하지만 적어도 최소한의 시도와 업계 표준을 따를 필요는 있다고 본다.

 

<소프트웨어 프로젝트를 바라보는 편협한 시각> - p52

기술에 뒤쳐지는 사람이 기술다루는 일을 결정해서는 안 된다. 명심하자.

 

<나쁜 소식만 있는 것은 아니다> - p53

빠른 깨달음만이 살 길이다.

 

[애자일과 소프트웨어 장인정신] - p54

이 책의 핵심으로 책 그대로를 발췌하고자 한다.

'애자일 방법론들은 가치에 따라서 일을 이해하고, 우선순위를 정하고, 관료주의와 낭비를 줄이고, 사람들에게 권한이양과 동기부여를 하고, 피드백 루프를 만들어 준다. 이것은 기업의 반응속도를 높이고 기민하게 하며,기업이 올바른 일을 하도록 돕는 것이다.
소프트웨어 장인정신은 소프트웨어 개발에 있어서의 프로페셔널리즘이다. 소프트웨어 장인정신은 개발자와 기업들이 일을 올바르게 수행하도록 돕는다.' 

 

[요약] - (책 발췌)

1. 애자일 소프트웨어 개발은 피드백 루프를 짧게 하고 변화와 고객의 요구에 빠르게 대응할 수 있는 기회를 준다.

 애자일 매니페스토에서는 분명하게 ‘절차와 도구보다는 개성과 화합을’ 중요시 함을 선언하고 있지만, 애자일 전환은 온통 절차와 도구로 끝나 버린다.

 기술적 탁월함의 개선 없이 절차만 개선하는 것은 무의미 하다.

2. 완전한 애자일 전환을 위해서는 프로페셔널 소프트웨어 개발자들이 필요하다.

 이들은 기술적 실행 관례, 기술적 전문성 그리고 관련 도구들을 마스터하고 있어야 한다.

 정기적으로 계속해서 배포되는 소프트웨어에 대해서도 높은 품질을 유지시키며, 완벽하게 테스트되고 쉽게 변경할 수 있는 소프트웨어를 개발할 수 있어야 한다.

3. 완전한 애자일 전환을 위해서는 기업들이 소프트웨어 장인정신을 품어야 한다.

 

[다음 장]

https://yrok.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%9E%A5%EC%9D%B8-Software-Craftsmanship-Part-1-%EC%9D%B4%EB%85%90%EA%B3%BC-%ED%83%9C%EB%8F%84-3-4%EC%9E%A5

소프트웨어 장인 - Part 1 : 이념과 태도 (3 ~ 4장) (Software Craftsmanship)