From 6e675a04104061480b03ae25f5618aeae1c7db1c Mon Sep 17 00:00:00 2001 From: nebulaBdj Date: Fri, 4 Oct 2024 18:35:21 +0900 Subject: [PATCH 1/6] =?UTF-8?q?1=EC=9E=A5=20=ED=99=A9=EB=8F=99=EC=A4=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\355\231\251\353\217\231\354\244\200.md" | 39 +++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 "1\354\236\245/\355\231\251\353\217\231\354\244\200.md" diff --git "a/1\354\236\245/\355\231\251\353\217\231\354\244\200.md" "b/1\354\236\245/\355\231\251\353\217\231\354\244\200.md" new file mode 100644 index 0000000..c3e9182 --- /dev/null +++ "b/1\354\236\245/\355\231\251\353\217\231\354\244\200.md" @@ -0,0 +1,39 @@ +## 1장 21세기의 소프트웨어 개발 + +### 중요하다고 생각한 내용과 나의 생각 + +31p + +매일 코드를 작성하는 일은 행복이었다. 그떄 이후로 아침에 눈을 뜰 때마다 오늘 할 일이 하고 싶어 기대되는 일만 하기로 스스로와 약속했다. + +→ 자신이 하고 싶어 하는 일을 하는 것은 정말 중요하다고 생각합니다. + +→ 여기서 생각난 질문이 있는데 여러분은 ‘자신이 잘하는데 재미가 없는 일’과 ‘자신이 잘하는 것 같지는 않지만 재밌는 일’이 있다면 어떤 것을 선택하실 건가요?? + +32p + +이제 개발자들은 개발뿐만 아니라 다음과 같은 여러가지를 할 수 있어야한다. + +- 고객과 대화하기 +- 테스트/배포 자동화하기 +- 전체 비즈니스에 영향을 미칠 기술 선정하기 +- 지리적으로 분산된 팀들과 협업하기 +- 고객을 도와 필요한 작업을 정의하기 +- 우선순위 선정하기 +- 진척 상황 보고하기 +- 변경사항과 기대일정 관리하기 +- 잠재 고객 및 파트너에세 제품 소개하기 +- 사전 영업 활동 지원하기 +- 개발 일정과 비용 산출하기 +- 채용 면접하기 +- 아키텍처 설계하기 +- 비기능적 요구사항과 계약 조건 검토하기 +- 사업 목쵸 이해하기 +- 주어진 여건에서 최적의 결정하기 +- 새로운 기술 주시하기 +- 더 나은 업무 방식 찾기 +- 고객에게 가치 있는 상품이 전달되고 있는지 고민하기 + +소프트웨어 개발자가 소프트웨어 개발 업무만 하면 되던 시정른 지나갔다. + +→ 다양한 역량을 갖춘 개발자가 되어야 계속 발전하는 산업 속에서 살아남을 수 있을거라고 생각합니다. From ec1597075a03cb7f631a9e7d43da41fbf0cab50e Mon Sep 17 00:00:00 2001 From: nebulaBdj Date: Sun, 6 Oct 2024 22:39:44 +0900 Subject: [PATCH 2/6] =?UTF-8?q?2=EC=9E=A5=20=ED=99=A9=EB=8F=99=EC=A4=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\355\231\251\353\217\231\354\244\200.md" | 95 +++++++++++++++++++ 1 file changed, 95 insertions(+) diff --git "a/1\354\236\245/\355\231\251\353\217\231\354\244\200.md" "b/1\354\236\245/\355\231\251\353\217\231\354\244\200.md" index c3e9182..da99e49 100644 --- "a/1\354\236\245/\355\231\251\353\217\231\354\244\200.md" +++ "b/1\354\236\245/\355\231\251\353\217\231\354\244\200.md" @@ -37,3 +37,98 @@ 소프트웨어 개발자가 소프트웨어 개발 업무만 하면 되던 시정른 지나갔다. → 다양한 역량을 갖춘 개발자가 되어야 계속 발전하는 산업 속에서 살아남을 수 있을거라고 생각합니다. + +## 2장 애자일 + +### 중요하다고 생각한 내용과 나의 생각 + +_38p_ + +애자일은 절자적인 부분과 기술적인 부분 두 종류로 나눌 수 있다. + +**절차적인 관점에서의 애자일** + +팀과 조직이 어떻게 구성되고 협업해야 하는지에 대한 것들 규정 + +- 회의 방식 +- 구성원 각각의 역할 +- 요구사랑 파악 방법 +- 작업 진척 속도 파악 방법 +- 점진적/반복적으로 일할 때 취하는 방식 +- 진행 상황을 개발팀 밖의 관계자에게 전달하는 방식 +- 비즈니스 피드백 방식 + +⇒ 팀에 정말로 중요한 것, 비즈니스에 가치가 있는 것에 집중 + +결론적으로 **팀이 올바른 목표를 향해 진행 중인지 확인** + +**기술적인 관점에서의 애자일** + +개발, 확장, 유지보수, 제품을 출시하면서 겪는 어려움들에 대해 특정한 기술적 관례나 기술 자체를 매우 구체적으로 가이드 + +ex) TDD, 페어 프로그래밍, 지속적인 통합, 단순한 디자인 원칙 등 + +결론적으로 **목표한 것을 올바르게 실행하고 있는지에 대해 안심할 수 있게** 함 + +**애자일의 의미** + +- 민첩하다고 해서 애자일을 실행하고 있는 것은 아니다. +- 빠르고 짧은 피드백 루프에 대한 것 + - 더 빨리, 더 짧게 피드백 루프를 만들수록 애자일해진다. +- 애자일은 문제 자체를 해결해주지 않는다 문제를 드러나게 한다. +- 특정 기능의 상용화 가능성을 일찍 알게 된다면 투자에 대한 위험도 줄일 수 있다. + +→ 애자일 방식을 채택한 이유에 대해 정확하게 이해하며 이번에 진행하는 밋업 프로젝트에 어떻게 적용하면 좋을지 생각할 수 있게 도움을 주는 내용이었습니다. 문제를 빠르게 찾아내는 것이 목표에 빠르게 다가가는 것에 큰 도움이 될것이라고 생각합니다. + +→ 하지만 잘못된 피드백 주기 선정으로 사소한 문제를 해결하는 과정에 시간을 뺏기면서 오히려 목표에 다가가는 길이 흐려지게 되면 안된다고 생각합니다. 적절한 애자일 주기를 선정하는 방법은 무엇이 있을지 궁금합니다. + +_40p_ + +그저 계획에 맞춰서 지시 받은 일만 하는 것이 아니아, 비즈니스와 고객 가치 창출에 개발자들이 직접 함여하는 것도 매우 중요하다고 주장한다. + +→ 비즈니스 임팩트를 지닌 코드를 작성하는 것이 정말 중요하다고 생각합니다. + +_41p_ + +기업들은 단순히 특정 분야만이 아닌 다방면에 걸친 저문가를 찾고 있다. 코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 요건이다. + +_42p_ + +**애자일의 12가지 법칙** + +1. 가치 있는 소프트웨어를 일찍, 지속적으로 전달하여 고객을 만족시키는 것을 최우선으로 한다. +2. 개발의 막바지 단계이더라도 고객의 요구사항 변경을 환영한다. 애자일 프로세스들은 변화를 활용하여 고객의 경쟁력을 높이는 데 기여한다. +3. 동작하는 소프트웨어를 몇 주에서 몇 개월 단위로 자주 전달한다. 가능한 한 전달주기를 짧게 한다. +4. 비즈니스 담당자들은 프로젝트 기간 내내 매일 개발자와 함께 일한다. +5. 프로젝트는 동기가 부여된 개인들로 구성한다. 그들이 필요로 하는 환경과 자원을 제공하고 프로젝트가 완료될 때까지 믿고 맡긴다. +6. 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 바업은 얼굴을 마주보고 대화하는 것이다. +7. 프로젝트 진척도를 가늠하는 가장 기본 요소는 동작하는 소프트웨어다. +8. 애자일 프로세스들은 지속 가능한 개발을 이끈다. 투자자, 개발자, 사용자들은 일정한 개발 속도를 계속 수용할 수 있어야 한다. +9. 기술적인 탁월함과 좋은 설게에 대한 지속적인 관심은 기민함을 높인다. +10. 단순함, 즉 하지 않아도 되는 일은 최대한 하지 않아야 한다. +11. 최선의 아키텍처, 요구사항, 설계는 스스로 조직화되는 팀에서 나온다. +12. 개발팀은 정기적으로 일을 어떻게 하는 것이 더 효과적인지 되돌아보고 그에 맞추어 일하는 방삭을 조율하고 바로잡는다. + +_44p -_ 안타깝게도 ‘애자일’이 과거에 일하던 방식의 그저 새로운 이름이 된 듯 싶다. + +_45p -_ 이러한 변화에도 불구하고 좋은 소프트웨어를 빠르게 공급하지 못하고 있는 것이 현실이다. + +→ 이번 밋업 프로젝트에서 TDD 방식을 도입해 애자일 방식으로 개발 및 프로젝트를 진행할 예정인데, 위와 같이 기본 방식의 그러 새로운 이름이 되지 않게 노력해야 겠다는 생각이 들었습니다. + +_48p_ + +애자일의 모든 절차들에는 기술적 탁월함이 전제되어 있다. + +도요타가 성공할 수 있었던 중요한 요인은 절차를 개선하는 것뿐만 아니라 자동차의 품질에 이미 충분한 역량과 그를 뒷받침하는 노력이 있었기 때문이다. + +→ 기술적 탁월함을 갖추기 위해 노력해야겠다는 생각이 들었습니다. + +_53p_ + +절차와 결과물 둘 다 중요하다는 점을 강조하기 위함이다. + +_54p_ + +소프트웨어 장인정신은 여러 기술적 실행 관례를 활용하고 정교하고 솜씨 있게 짠 코드의 중요성을 강조함과 동시에 코딩을 넘어서 고객의 더 많은 부분을 도울 것을 강조한다. → 일을 올바르게 수행하도록 돕는다. + +→ 앞으로 이 책을 읽으면서 소프트웨어 장인정신을 품기위해 꾸준히 노력해야 겠다고 생각했습니다. From 886db405f5cc1a8da35783f8ed5e0c621ba3ea9d Mon Sep 17 00:00:00 2001 From: nebulaBdj Date: Tue, 8 Oct 2024 16:46:06 +0900 Subject: [PATCH 3/6] =?UTF-8?q?2=EC=9E=A5=20=ED=99=A9=EB=8F=99=EC=A4=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\355\231\251\353\217\231\354\244\200.md" | 95 ------------------- .../\355\231\251\353\217\231\354\244\200.md" | 94 ++++++++++++++++++ 2 files changed, 94 insertions(+), 95 deletions(-) create mode 100644 "2\354\236\245/\355\231\251\353\217\231\354\244\200.md" diff --git "a/1\354\236\245/\355\231\251\353\217\231\354\244\200.md" "b/1\354\236\245/\355\231\251\353\217\231\354\244\200.md" index da99e49..c3e9182 100644 --- "a/1\354\236\245/\355\231\251\353\217\231\354\244\200.md" +++ "b/1\354\236\245/\355\231\251\353\217\231\354\244\200.md" @@ -37,98 +37,3 @@ 소프트웨어 개발자가 소프트웨어 개발 업무만 하면 되던 시정른 지나갔다. → 다양한 역량을 갖춘 개발자가 되어야 계속 발전하는 산업 속에서 살아남을 수 있을거라고 생각합니다. - -## 2장 애자일 - -### 중요하다고 생각한 내용과 나의 생각 - -_38p_ - -애자일은 절자적인 부분과 기술적인 부분 두 종류로 나눌 수 있다. - -**절차적인 관점에서의 애자일** - -팀과 조직이 어떻게 구성되고 협업해야 하는지에 대한 것들 규정 - -- 회의 방식 -- 구성원 각각의 역할 -- 요구사랑 파악 방법 -- 작업 진척 속도 파악 방법 -- 점진적/반복적으로 일할 때 취하는 방식 -- 진행 상황을 개발팀 밖의 관계자에게 전달하는 방식 -- 비즈니스 피드백 방식 - -⇒ 팀에 정말로 중요한 것, 비즈니스에 가치가 있는 것에 집중 - -결론적으로 **팀이 올바른 목표를 향해 진행 중인지 확인** - -**기술적인 관점에서의 애자일** - -개발, 확장, 유지보수, 제품을 출시하면서 겪는 어려움들에 대해 특정한 기술적 관례나 기술 자체를 매우 구체적으로 가이드 - -ex) TDD, 페어 프로그래밍, 지속적인 통합, 단순한 디자인 원칙 등 - -결론적으로 **목표한 것을 올바르게 실행하고 있는지에 대해 안심할 수 있게** 함 - -**애자일의 의미** - -- 민첩하다고 해서 애자일을 실행하고 있는 것은 아니다. -- 빠르고 짧은 피드백 루프에 대한 것 - - 더 빨리, 더 짧게 피드백 루프를 만들수록 애자일해진다. -- 애자일은 문제 자체를 해결해주지 않는다 문제를 드러나게 한다. -- 특정 기능의 상용화 가능성을 일찍 알게 된다면 투자에 대한 위험도 줄일 수 있다. - -→ 애자일 방식을 채택한 이유에 대해 정확하게 이해하며 이번에 진행하는 밋업 프로젝트에 어떻게 적용하면 좋을지 생각할 수 있게 도움을 주는 내용이었습니다. 문제를 빠르게 찾아내는 것이 목표에 빠르게 다가가는 것에 큰 도움이 될것이라고 생각합니다. - -→ 하지만 잘못된 피드백 주기 선정으로 사소한 문제를 해결하는 과정에 시간을 뺏기면서 오히려 목표에 다가가는 길이 흐려지게 되면 안된다고 생각합니다. 적절한 애자일 주기를 선정하는 방법은 무엇이 있을지 궁금합니다. - -_40p_ - -그저 계획에 맞춰서 지시 받은 일만 하는 것이 아니아, 비즈니스와 고객 가치 창출에 개발자들이 직접 함여하는 것도 매우 중요하다고 주장한다. - -→ 비즈니스 임팩트를 지닌 코드를 작성하는 것이 정말 중요하다고 생각합니다. - -_41p_ - -기업들은 단순히 특정 분야만이 아닌 다방면에 걸친 저문가를 찾고 있다. 코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 요건이다. - -_42p_ - -**애자일의 12가지 법칙** - -1. 가치 있는 소프트웨어를 일찍, 지속적으로 전달하여 고객을 만족시키는 것을 최우선으로 한다. -2. 개발의 막바지 단계이더라도 고객의 요구사항 변경을 환영한다. 애자일 프로세스들은 변화를 활용하여 고객의 경쟁력을 높이는 데 기여한다. -3. 동작하는 소프트웨어를 몇 주에서 몇 개월 단위로 자주 전달한다. 가능한 한 전달주기를 짧게 한다. -4. 비즈니스 담당자들은 프로젝트 기간 내내 매일 개발자와 함께 일한다. -5. 프로젝트는 동기가 부여된 개인들로 구성한다. 그들이 필요로 하는 환경과 자원을 제공하고 프로젝트가 완료될 때까지 믿고 맡긴다. -6. 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 바업은 얼굴을 마주보고 대화하는 것이다. -7. 프로젝트 진척도를 가늠하는 가장 기본 요소는 동작하는 소프트웨어다. -8. 애자일 프로세스들은 지속 가능한 개발을 이끈다. 투자자, 개발자, 사용자들은 일정한 개발 속도를 계속 수용할 수 있어야 한다. -9. 기술적인 탁월함과 좋은 설게에 대한 지속적인 관심은 기민함을 높인다. -10. 단순함, 즉 하지 않아도 되는 일은 최대한 하지 않아야 한다. -11. 최선의 아키텍처, 요구사항, 설계는 스스로 조직화되는 팀에서 나온다. -12. 개발팀은 정기적으로 일을 어떻게 하는 것이 더 효과적인지 되돌아보고 그에 맞추어 일하는 방삭을 조율하고 바로잡는다. - -_44p -_ 안타깝게도 ‘애자일’이 과거에 일하던 방식의 그저 새로운 이름이 된 듯 싶다. - -_45p -_ 이러한 변화에도 불구하고 좋은 소프트웨어를 빠르게 공급하지 못하고 있는 것이 현실이다. - -→ 이번 밋업 프로젝트에서 TDD 방식을 도입해 애자일 방식으로 개발 및 프로젝트를 진행할 예정인데, 위와 같이 기본 방식의 그러 새로운 이름이 되지 않게 노력해야 겠다는 생각이 들었습니다. - -_48p_ - -애자일의 모든 절차들에는 기술적 탁월함이 전제되어 있다. - -도요타가 성공할 수 있었던 중요한 요인은 절차를 개선하는 것뿐만 아니라 자동차의 품질에 이미 충분한 역량과 그를 뒷받침하는 노력이 있었기 때문이다. - -→ 기술적 탁월함을 갖추기 위해 노력해야겠다는 생각이 들었습니다. - -_53p_ - -절차와 결과물 둘 다 중요하다는 점을 강조하기 위함이다. - -_54p_ - -소프트웨어 장인정신은 여러 기술적 실행 관례를 활용하고 정교하고 솜씨 있게 짠 코드의 중요성을 강조함과 동시에 코딩을 넘어서 고객의 더 많은 부분을 도울 것을 강조한다. → 일을 올바르게 수행하도록 돕는다. - -→ 앞으로 이 책을 읽으면서 소프트웨어 장인정신을 품기위해 꾸준히 노력해야 겠다고 생각했습니다. diff --git "a/2\354\236\245/\355\231\251\353\217\231\354\244\200.md" "b/2\354\236\245/\355\231\251\353\217\231\354\244\200.md" new file mode 100644 index 0000000..2737e99 --- /dev/null +++ "b/2\354\236\245/\355\231\251\353\217\231\354\244\200.md" @@ -0,0 +1,94 @@ +## 2장 애자일 + +### 중요하다고 생각한 내용과 나의 생각 + +_38p_ + +애자일은 절자적인 부분과 기술적인 부분 두 종류로 나눌 수 있다. + +**절차적인 관점에서의 애자일** + +팀과 조직이 어떻게 구성되고 협업해야 하는지에 대한 것들 규정 + +- 회의 방식 +- 구성원 각각의 역할 +- 요구사랑 파악 방법 +- 작업 진척 속도 파악 방법 +- 점진적/반복적으로 일할 때 취하는 방식 +- 진행 상황을 개발팀 밖의 관계자에게 전달하는 방식 +- 비즈니스 피드백 방식 + +⇒ 팀에 정말로 중요한 것, 비즈니스에 가치가 있는 것에 집중 + +결론적으로 **팀이 올바른 목표를 향해 진행 중인지 확인** + +**기술적인 관점에서의 애자일** + +개발, 확장, 유지보수, 제품을 출시하면서 겪는 어려움들에 대해 특정한 기술적 관례나 기술 자체를 매우 구체적으로 가이드 + +ex) TDD, 페어 프로그래밍, 지속적인 통합, 단순한 디자인 원칙 등 + +결론적으로 **목표한 것을 올바르게 실행하고 있는지에 대해 안심할 수 있게** 함 + +**애자일의 의미** + +- 민첩하다고 해서 애자일을 실행하고 있는 것은 아니다. +- 빠르고 짧은 피드백 루프에 대한 것 + - 더 빨리, 더 짧게 피드백 루프를 만들수록 애자일해진다. +- 애자일은 문제 자체를 해결해주지 않는다 문제를 드러나게 한다. +- 특정 기능의 상용화 가능성을 일찍 알게 된다면 투자에 대한 위험도 줄일 수 있다. + +→ 애자일 방식을 채택한 이유에 대해 정확하게 이해하며 이번에 진행하는 밋업 프로젝트에 어떻게 적용하면 좋을지 생각할 수 있게 도움을 주는 내용이었습니다. 문제를 빠르게 찾아내는 것이 목표에 빠르게 다가가는 것에 큰 도움이 될것이라고 생각합니다. + +→ 하지만 잘못된 피드백 주기 선정으로 사소한 문제를 해결하는 과정에 시간을 뺏기면서 오히려 목표에 다가가는 길이 흐려지게 되면 안된다고 생각합니다. 적절한 애자일 주기를 선정하는 방법은 무엇이 있을지 궁금합니다. + +_40p_ + +그저 계획에 맞춰서 지시 받은 일만 하는 것이 아니아, 비즈니스와 고객 가치 창출에 개발자들이 직접 함여하는 것도 매우 중요하다고 주장한다. + +→ 비즈니스 임팩트를 지닌 코드를 작성하는 것이 정말 중요하다고 생각합니다. + +_41p_ + +기업들은 단순히 특정 분야만이 아닌 다방면에 걸친 저문가를 찾고 있다. 코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 요건이다. + +_42p_ + +**애자일의 12가지 법칙** + +1. 가치 있는 소프트웨어를 일찍, 지속적으로 전달하여 고객을 만족시키는 것을 최우선으로 한다. +2. 개발의 막바지 단계이더라도 고객의 요구사항 변경을 환영한다. 애자일 프로세스들은 변화를 활용하여 고객의 경쟁력을 높이는 데 기여한다. +3. 동작하는 소프트웨어를 몇 주에서 몇 개월 단위로 자주 전달한다. 가능한 한 전달주기를 짧게 한다. +4. 비즈니스 담당자들은 프로젝트 기간 내내 매일 개발자와 함께 일한다. +5. 프로젝트는 동기가 부여된 개인들로 구성한다. 그들이 필요로 하는 환경과 자원을 제공하고 프로젝트가 완료될 때까지 믿고 맡긴다. +6. 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 바업은 얼굴을 마주보고 대화하는 것이다. +7. 프로젝트 진척도를 가늠하는 가장 기본 요소는 동작하는 소프트웨어다. +8. 애자일 프로세스들은 지속 가능한 개발을 이끈다. 투자자, 개발자, 사용자들은 일정한 개발 속도를 계속 수용할 수 있어야 한다. +9. 기술적인 탁월함과 좋은 설게에 대한 지속적인 관심은 기민함을 높인다. +10. 단순함, 즉 하지 않아도 되는 일은 최대한 하지 않아야 한다. +11. 최선의 아키텍처, 요구사항, 설계는 스스로 조직화되는 팀에서 나온다. +12. 개발팀은 정기적으로 일을 어떻게 하는 것이 더 효과적인지 되돌아보고 그에 맞추어 일하는 방식을 조율하고 바로잡는다. + +_44p -_ 안타깝게도 ‘애자일’이 과거에 일하던 방식의 그저 새로운 이름이 된 듯 싶다. + +_45p -_ 이러한 변화에도 불구하고 좋은 소프트웨어를 빠르게 공급하지 못하고 있는 것이 현실이다. + +→ 이번 밋업 프로젝트에서 TDD 방식을 도입해 애자일 방식으로 개발 및 프로젝트를 진행할 예정인데, 위와 같이 기본 방식의 그러 새로운 이름이 되지 않게 노력해야 겠다는 생각이 들었습니다. + +_48p_ + +애자일의 모든 절차들에는 기술적 탁월함이 전제되어 있다. + +도요타가 성공할 수 있었던 중요한 요인은 절차를 개선하는 것뿐만 아니라 자동차의 품질에 이미 충분한 역량과 그를 뒷받침하는 노력이 있었기 때문이다. + +→ 기술적 탁월함을 갖추기 위해 노력해야겠다는 생각이 들었습니다. + +_53p_ + +절차와 결과물 둘 다 중요하다는 점을 강조하기 위함이다. + +_54p_ + +소프트웨어 장인정신은 여러 기술적 실행 관례를 활용하고 정교하고 솜씨 있게 짠 코드의 중요성을 강조함과 동시에 코딩을 넘어서 고객의 더 많은 부분을 도울 것을 강조한다. → 일을 올바르게 수행하도록 돕는다. + +→ 앞으로 이 책을 읽으면서 소프트웨어 장인정신을 품기위해 꾸준히 노력해야 겠다고 생각했습니다. From 87f0b04063df195979df126323fe2e12c5a60f94 Mon Sep 17 00:00:00 2001 From: nebulaBdj Date: Thu, 31 Oct 2024 20:34:05 +0900 Subject: [PATCH 4/6] =?UTF-8?q?5=EC=9E=A5=20=ED=99=A9=EB=8F=99=EC=A4=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\355\231\251\353\217\231\354\244\200.md" | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 "5\354\236\245/\355\231\251\353\217\231\354\244\200.md" diff --git "a/5\354\236\245/\355\231\251\353\217\231\354\244\200.md" "b/5\354\236\245/\355\231\251\353\217\231\354\244\200.md" new file mode 100644 index 0000000..6bd5e1e --- /dev/null +++ "b/5\354\236\245/\355\231\251\353\217\231\354\244\200.md" @@ -0,0 +1,26 @@ +## 5장 영웅, 선의 그리고 프로페셔널리즘 + +### 중요하다고 생각한 내용과 나의 생각 + +107 +우리는 프로페셔널하지 못했다. 우리가 왜 그 일을 하는지 스스로 묻지 않았다. 고객이 실제로 무엇을 원하는지 이래하려 하지 않았고, 다른 대안을 제시하지도 않았다. 고객을 만날수도 없기는 했지만, 요구사항에 대해서 질문을 하지도, 실행할 수 없다는 이야기도 하지 않았다. 우리는 그냥 주어진 환경을 있는 그대로 두고, 무작정 일을 밀어 붙였다. 그때는 그것이 프로페셔널이라고 생각했다. +우리가 노예처럼 일할 때, 영업, 비즈니스 부서 사람들은 항상 정시에 퇴근해 가족과 시간을 보냈다. +-> 그저 순응하는 것이 아닌 나 자신이 할 수 있는 정도를 파악하고 함께하는 팀원에게 이야기하는 것도 정말 중요하다는 생각이 들었습니다. + +114 +개발자들이 일정이 너무 짧다고 이야기를 해도 관리자들이 그냥 흘려 들을 때가 많다. 관리자와 개발자 간에 협상이 되어야 하지만 협상 기술이나 제대로 된 근거 자료가 부족해서 개발자들이 압ㄺ에 그냥 굴복하고 말 떄가 부지기수다 +개발자들은 논쟁하고 싶디 않아서 또는 긍정적인 태도를 보여주고 싶어서 "최선을 다해 노력하겠다"라고 대답해버린다. +-> 평소에 소통하는 능력을 어느정도 갖추고 있다고 생각하는데 취업시장에서 이러한 점들을 강점으로 어필하면 좋을거 같다는 생각이 들었습니다. + +116 +항상 '아니오'라고만 얘기하는 것은 프로다운 태도가 아니다. +모든 '아니오'에는 반드시 하나 이상의 대안들이 따라와야 한다. +-> 매우 중요하다고 생각합니다. + +118 +무언가 약속은 할 수 없더라도 문제 대응이 어떻게 되고 있는지 진척 상황을 계속 공유해야한다. + +122 +최대한 이른 시점에 붉은 깃발을 세워서 뭔사 잘못되고 있음을 지적하고 팀과 다른 사람들로 하여금 현실적인 다른 대안을 찾아 나설 수 있도록 해야 한다. +-> 현재 진행하고 있는 밋업 프로젝트에서 애자일 방식으로 프로젝트를 진행하고 있는데 불확실성이 큰 요구사항에 대해 살짝 어려울거 같다는 이야기는 했지만, 해보겠다고 했는데, 이런 상황에서 문제가 생긴다면 빠르게 전해야겠다고 생각이 들었습니다. +-> 혹시 이렇게 할 수 있을지 없을지 잘 판단이 안서는 요구사항에 대해서는 어떻게 대처하는 것이 좋은지 궁금하기도 합니다. From 7c925a7019daa16830412ff9e6efc15e27e192ab Mon Sep 17 00:00:00 2001 From: nebulaBdj Date: Thu, 31 Oct 2024 21:16:14 +0900 Subject: [PATCH 5/6] =?UTF-8?q?6=EC=9E=A5=20=ED=99=A9=EB=8F=99=EC=A4=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\355\231\251\353\217\231\354\244\200.md" | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 "6\354\236\245/\355\231\251\353\217\231\354\244\200.md" diff --git "a/6\354\236\245/\355\231\251\353\217\231\354\244\200.md" "b/6\354\236\245/\355\231\251\353\217\231\354\244\200.md" new file mode 100644 index 0000000..9ed8a2f --- /dev/null +++ "b/6\354\236\245/\355\231\251\353\217\231\354\244\200.md" @@ -0,0 +1,25 @@ +## 6장 동작하는 소프트웨어 + +### 중요하다고 생각한 내용과 나의 생각 + +126 +전통적인 관리자들과 비즈니스 컨설턴트들이 절차와 문서의 중요성을 아무리 강조하고 싶어하더라도 소프트웨어 프로젝트에는 소스 코드 그 자체만큼 중요한 것은 없다. 나머지는 모두 부차적이다. + +128 +코드는 기계장치라기보다는 유기물이다. 코드는 정원처럼 지속적인 유지보수가 필요하다. + +130 +나쁜 코드를 다루어야 하는 기업은 경쟁력이 떨어지게 된다. + +132 +기술적 부채를 줄이는 것은 기존의 더러운 것을 청소하는 것이다. 이미 깨끗한 상태를 더럽혀서는 안된다. 즉 어떤 상황이든 추가 코드로 인해 기술적 부채가 더해져서는 안 된다. 하지만 이 개발자는 그렇게 해도 된다고 생각하고 있었다. +-> 해당 개발자처럼 잘못된 이해와 지식에 확신을 가지는 것에 주의해야 겠다는 생각을 했습니다. + +133 +빨리 하는 것과 허술한 것은 다르다. 우리의 결정이 어떤 의미이고 어떤 결과를 가져오는지 우리는 잘 이해하지 못할 때가 많다. + +137 +테스트하지 않았다면 코드 작성을 완료했다고 할 수 없다. 단위 테스트는 코드가 제대로 구현되었는지 확인하는 가장 좋은 방법이다. +테스트 주도 개발을 접해보지 못한 보통의 개발자들은 주어진 요구사항에 맞춰 동작할 거라고 '기대만 하는' 상태로 코드를 작성하고는 바로 다음 요구사항의 구현에 들어간다. 즉 제대로 된 테스트 없이 코딩을 마무리한다. 기능 구현이 완료되었다고 할 수 있으려면 반드시 테스트까지 되어야 한다. +-> 현재 TDD 방식으로 개발을 진행하고 있는데 생각보다 쉽지 않고, 함께하는 팀원은 어려울거 같다고 해서 일단 저만 진행하고 있는데 이 글을 읽고, 다음 스프린트에서 요구사항 정의와 레드 단계의 테스트 코드를 작성하여 팀원도 같이 TDD를 할 수 있게 해야겠다는 확신이 생겼습니다. +-> 그리고 필자가 작성한 것처럼 테스트 코드를 작성하는 것까지 기능구현의 단계로 생각해여 개발해야 겠다는 생각 또한 들었습니다. From db8c81f0ce677f09eb543c8a93d33ca936c7bfc4 Mon Sep 17 00:00:00 2001 From: nebulaBdj Date: Thu, 31 Oct 2024 23:01:17 +0900 Subject: [PATCH 6/6] =?UTF-8?q?1,2=EC=9E=A5=20=EC=82=AD=EC=A0=9C?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\355\231\251\353\217\231\354\244\200.md" | 39 -------- .../\355\231\251\353\217\231\354\244\200.md" | 94 ------------------- 2 files changed, 133 deletions(-) delete mode 100644 "1\354\236\245/\355\231\251\353\217\231\354\244\200.md" delete mode 100644 "2\354\236\245/\355\231\251\353\217\231\354\244\200.md" diff --git "a/1\354\236\245/\355\231\251\353\217\231\354\244\200.md" "b/1\354\236\245/\355\231\251\353\217\231\354\244\200.md" deleted file mode 100644 index c3e9182..0000000 --- "a/1\354\236\245/\355\231\251\353\217\231\354\244\200.md" +++ /dev/null @@ -1,39 +0,0 @@ -## 1장 21세기의 소프트웨어 개발 - -### 중요하다고 생각한 내용과 나의 생각 - -31p - -매일 코드를 작성하는 일은 행복이었다. 그떄 이후로 아침에 눈을 뜰 때마다 오늘 할 일이 하고 싶어 기대되는 일만 하기로 스스로와 약속했다. - -→ 자신이 하고 싶어 하는 일을 하는 것은 정말 중요하다고 생각합니다. - -→ 여기서 생각난 질문이 있는데 여러분은 ‘자신이 잘하는데 재미가 없는 일’과 ‘자신이 잘하는 것 같지는 않지만 재밌는 일’이 있다면 어떤 것을 선택하실 건가요?? - -32p - -이제 개발자들은 개발뿐만 아니라 다음과 같은 여러가지를 할 수 있어야한다. - -- 고객과 대화하기 -- 테스트/배포 자동화하기 -- 전체 비즈니스에 영향을 미칠 기술 선정하기 -- 지리적으로 분산된 팀들과 협업하기 -- 고객을 도와 필요한 작업을 정의하기 -- 우선순위 선정하기 -- 진척 상황 보고하기 -- 변경사항과 기대일정 관리하기 -- 잠재 고객 및 파트너에세 제품 소개하기 -- 사전 영업 활동 지원하기 -- 개발 일정과 비용 산출하기 -- 채용 면접하기 -- 아키텍처 설계하기 -- 비기능적 요구사항과 계약 조건 검토하기 -- 사업 목쵸 이해하기 -- 주어진 여건에서 최적의 결정하기 -- 새로운 기술 주시하기 -- 더 나은 업무 방식 찾기 -- 고객에게 가치 있는 상품이 전달되고 있는지 고민하기 - -소프트웨어 개발자가 소프트웨어 개발 업무만 하면 되던 시정른 지나갔다. - -→ 다양한 역량을 갖춘 개발자가 되어야 계속 발전하는 산업 속에서 살아남을 수 있을거라고 생각합니다. diff --git "a/2\354\236\245/\355\231\251\353\217\231\354\244\200.md" "b/2\354\236\245/\355\231\251\353\217\231\354\244\200.md" deleted file mode 100644 index 2737e99..0000000 --- "a/2\354\236\245/\355\231\251\353\217\231\354\244\200.md" +++ /dev/null @@ -1,94 +0,0 @@ -## 2장 애자일 - -### 중요하다고 생각한 내용과 나의 생각 - -_38p_ - -애자일은 절자적인 부분과 기술적인 부분 두 종류로 나눌 수 있다. - -**절차적인 관점에서의 애자일** - -팀과 조직이 어떻게 구성되고 협업해야 하는지에 대한 것들 규정 - -- 회의 방식 -- 구성원 각각의 역할 -- 요구사랑 파악 방법 -- 작업 진척 속도 파악 방법 -- 점진적/반복적으로 일할 때 취하는 방식 -- 진행 상황을 개발팀 밖의 관계자에게 전달하는 방식 -- 비즈니스 피드백 방식 - -⇒ 팀에 정말로 중요한 것, 비즈니스에 가치가 있는 것에 집중 - -결론적으로 **팀이 올바른 목표를 향해 진행 중인지 확인** - -**기술적인 관점에서의 애자일** - -개발, 확장, 유지보수, 제품을 출시하면서 겪는 어려움들에 대해 특정한 기술적 관례나 기술 자체를 매우 구체적으로 가이드 - -ex) TDD, 페어 프로그래밍, 지속적인 통합, 단순한 디자인 원칙 등 - -결론적으로 **목표한 것을 올바르게 실행하고 있는지에 대해 안심할 수 있게** 함 - -**애자일의 의미** - -- 민첩하다고 해서 애자일을 실행하고 있는 것은 아니다. -- 빠르고 짧은 피드백 루프에 대한 것 - - 더 빨리, 더 짧게 피드백 루프를 만들수록 애자일해진다. -- 애자일은 문제 자체를 해결해주지 않는다 문제를 드러나게 한다. -- 특정 기능의 상용화 가능성을 일찍 알게 된다면 투자에 대한 위험도 줄일 수 있다. - -→ 애자일 방식을 채택한 이유에 대해 정확하게 이해하며 이번에 진행하는 밋업 프로젝트에 어떻게 적용하면 좋을지 생각할 수 있게 도움을 주는 내용이었습니다. 문제를 빠르게 찾아내는 것이 목표에 빠르게 다가가는 것에 큰 도움이 될것이라고 생각합니다. - -→ 하지만 잘못된 피드백 주기 선정으로 사소한 문제를 해결하는 과정에 시간을 뺏기면서 오히려 목표에 다가가는 길이 흐려지게 되면 안된다고 생각합니다. 적절한 애자일 주기를 선정하는 방법은 무엇이 있을지 궁금합니다. - -_40p_ - -그저 계획에 맞춰서 지시 받은 일만 하는 것이 아니아, 비즈니스와 고객 가치 창출에 개발자들이 직접 함여하는 것도 매우 중요하다고 주장한다. - -→ 비즈니스 임팩트를 지닌 코드를 작성하는 것이 정말 중요하다고 생각합니다. - -_41p_ - -기업들은 단순히 특정 분야만이 아닌 다방면에 걸친 저문가를 찾고 있다. 코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 요건이다. - -_42p_ - -**애자일의 12가지 법칙** - -1. 가치 있는 소프트웨어를 일찍, 지속적으로 전달하여 고객을 만족시키는 것을 최우선으로 한다. -2. 개발의 막바지 단계이더라도 고객의 요구사항 변경을 환영한다. 애자일 프로세스들은 변화를 활용하여 고객의 경쟁력을 높이는 데 기여한다. -3. 동작하는 소프트웨어를 몇 주에서 몇 개월 단위로 자주 전달한다. 가능한 한 전달주기를 짧게 한다. -4. 비즈니스 담당자들은 프로젝트 기간 내내 매일 개발자와 함께 일한다. -5. 프로젝트는 동기가 부여된 개인들로 구성한다. 그들이 필요로 하는 환경과 자원을 제공하고 프로젝트가 완료될 때까지 믿고 맡긴다. -6. 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 바업은 얼굴을 마주보고 대화하는 것이다. -7. 프로젝트 진척도를 가늠하는 가장 기본 요소는 동작하는 소프트웨어다. -8. 애자일 프로세스들은 지속 가능한 개발을 이끈다. 투자자, 개발자, 사용자들은 일정한 개발 속도를 계속 수용할 수 있어야 한다. -9. 기술적인 탁월함과 좋은 설게에 대한 지속적인 관심은 기민함을 높인다. -10. 단순함, 즉 하지 않아도 되는 일은 최대한 하지 않아야 한다. -11. 최선의 아키텍처, 요구사항, 설계는 스스로 조직화되는 팀에서 나온다. -12. 개발팀은 정기적으로 일을 어떻게 하는 것이 더 효과적인지 되돌아보고 그에 맞추어 일하는 방식을 조율하고 바로잡는다. - -_44p -_ 안타깝게도 ‘애자일’이 과거에 일하던 방식의 그저 새로운 이름이 된 듯 싶다. - -_45p -_ 이러한 변화에도 불구하고 좋은 소프트웨어를 빠르게 공급하지 못하고 있는 것이 현실이다. - -→ 이번 밋업 프로젝트에서 TDD 방식을 도입해 애자일 방식으로 개발 및 프로젝트를 진행할 예정인데, 위와 같이 기본 방식의 그러 새로운 이름이 되지 않게 노력해야 겠다는 생각이 들었습니다. - -_48p_ - -애자일의 모든 절차들에는 기술적 탁월함이 전제되어 있다. - -도요타가 성공할 수 있었던 중요한 요인은 절차를 개선하는 것뿐만 아니라 자동차의 품질에 이미 충분한 역량과 그를 뒷받침하는 노력이 있었기 때문이다. - -→ 기술적 탁월함을 갖추기 위해 노력해야겠다는 생각이 들었습니다. - -_53p_ - -절차와 결과물 둘 다 중요하다는 점을 강조하기 위함이다. - -_54p_ - -소프트웨어 장인정신은 여러 기술적 실행 관례를 활용하고 정교하고 솜씨 있게 짠 코드의 중요성을 강조함과 동시에 코딩을 넘어서 고객의 더 많은 부분을 도울 것을 강조한다. → 일을 올바르게 수행하도록 돕는다. - -→ 앞으로 이 책을 읽으면서 소프트웨어 장인정신을 품기위해 꾸준히 노력해야 겠다고 생각했습니다.