@@ -0,0 +1,113 @@
+[함께 자라기 애자일로 가는 길]
+
+2. 함께
+
+2-6) 하향식 접근의 함정
+
+"비전문가일수록 자신이 만든 애초에 세운 계획에 집착했습니다. 오히려 전문가일수록 자신의 계획을 수정한 횟수가 많았습니다."
+
+저도 기능을 개발할 때, 시작 전부터 최대한 세세하게 계획을 짜고 계획한대로 진행하려고 하는 스타일이었는데
+
+뭔가 항상 아무리 꼼꼼하게 짜려고 해도 막상 실제로 구현에 들어가면 수정할 부분이 계속해서 보이더군요
+
+처음 짰던 계획에서 조금씩 수정될수록 '내가 좀 더 신중히 생각했어야했나? 아직 부족하구나' 하고 아쉽다고만 생각 했는데
+
+수정한 방법이 이전 계획보다 나은 방법이라면 과감하게 수정하는 것도 좋을 수 있겠다고 생각이 들었습니다.
+
+
+
+Q1) 여러분들은 새로운 기능에 대한 기획서를 받았을 때, 어떤 식으로 기능 구현에 대한 설계를 시작하고 진행하시는지 궁금합니다 좋은 방법 있으면 공유 부탁드려요!
+
+
+
+2-7) 전문가팀이 실패하는 이유
+
+'함께' 라는 소제목에 어울리는 파트인 것 같습니다. 
+
+이번 파트에서 화자는 협력 없이 뛰어난 개인의 능력으로만 만들어진 결과물 보다 부진한 능력에도 정보의 공유, 협력을 통하여 만들어진 결과물의 퀄리티가 더 나을 수 있다고 말하고 있습니다.
+
+사실 업무적 능력도 좋고 협업 능력도 뛰어난 사람이라면.. 무슨 일을 해도 성과를 잘낼 것이라는 것은 다들 알고 있는 얘기이지만.. 그 만큼 어려운 길이라고 생각되네요
+
+협업 능력의 차이로 전문가들이 비전문가들에게도 밀릴 수 있다는 결과는 적잖이 놀라웠습니다.
+
+
+
+2-8) 구글이 밝힌 탁월한 팀의 비밀
+
+"내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음"
+
+이 파트를 읽으면서 뭔가 중간중간 고민했던 '좋은 팀'의 기준이 어느정도 잡혀가고 있다고 느꼈습니다.
+
+책의 앞부분부터 얘기하고 있는 '좋은 팀' 이란 건 각자 개인이 지닌 실력 외에 서로의 협업을 통하여 더 나은 결과물을 만들어내는 팀 이었고,
+
+그런 팀이 되려면 서로가 가진 것들을 최대한 가감 없이 공유를 해야한다고 했습니다.
+
+화자가 여기까지 말해오던 것들을 가능하게 하는 것이 '심리적 안전감' 이라고 생각합니다.
+
+반대로 생각해보면 팀 내에 '심리적 안전감'이 있어야 개인의 능력이나 실수에 대해 가감없이 밝힐 수 있고 이로 인해 좋은 협업, 능력 공유가 되어 좋은 팀이 될 수 있는 것 같습니다.
+
+
+
+Q2) 팀원이 나로 인해 속한 팀에 심리적 안전감을 얻도록 도와줄 수 있는 방법에는 어떤 것이 있을까요..?
+
+
+
+2-9) 쾌속 학습팀
+
+"패러다임 전환, 죽느냐 사느냐"
+
+웃프게도.. 지금 현재 제 상황이 이렇게 될 수도 있었겠네요.. 최근 사내 회의에서 다른 스택을 공부하는 것에 대해 얘기가 나왔었습니다..
+
+실제로 그런 참사가 발생한다면.. 제 경우에는 마지막 부분인 '현실에서 실천하기'에 나와있는 것 처럼 우선 스스로 학습 환경을 준비하면서
+
+든든한 학습 동료를 찾아봐야겠네요.. 잘부탁드립니다.. :)
+
+
+
+2-10) 프로젝트 확률론
+
+그냥 정말 직관적으로 '에이 7번이면 한 번은 나오겠지' 싶어서 1-1과 2-2를 골랐는데 기분 좋게도 확률 상 둘 다 유리한 곳을 골랐네요
+
+사실 항상 이런 내기같은 걸 할 때 "어차피 당첨 아니면 낙첨 반반이다" 라고 말하며 확률을 잘 안믿는 편이긴 합니다..ㅎㅎㅎ
+
+
+
+3. 애자일
+
+3-1) 애자일의 씨앗
+
+"신뢰가 있을 경우 협력의 비용이 낮아지고 원활해진다는 연구가 많습니다."
+
+으음.. 여기서 말하는 신뢰가 앞서 말한 '심리적 안전감'과 비슷한 느낌인 것 같고 신뢰(심리적 안전감)를 통하여 고객(상대방)에게 수월하게 협력을 얻어낸다는 말이라고 느꼈습니다.
+
+
+
+3-2) 애자일 도입 성공 요인 분석
+
+"두려워도 중요하다면 시도해봐야 하지 않겠는가."
+
+화자가 전달하려는 내용과는 좀 벗어난 내용일 수도 있지만 이번 파트에서 가장 인상 깊고 제게도 필요한 문장이었습니다.
+
+실제로 협력이나 도움이 필요한 상황에서도 무지, 실수에 대한 부끄러움이나 일개 팀원이라는 생각 때문에 제대로 의사표출을 못했던 상황이 잦았던 것 같습니다.
+
+지금 당장에 가장 먼저 시도해보고 싶은 건 스스로 '실수를 인정하고 다른 사람과 공유하는 것'이고, 이를 통해서 매일매일 아주 조금이라도 성장을 경험하고 싶습니다.
+
+
+
+3-3) 당신의 조직에 새 방법론이 먹히지 않는 이유
+
+"우리는 말할 수 있는 것보다 더 많이 알고 있다"
+
+화자가 이전에 얘기했던 주제 중 '뛰어난 선생님'에 대한 것들이 떠올랐습니다. 실제로 지식은 많이 가지고 있지만 그것을 제대로 전달할 수 없는 사람,
+
+지식은 전자에 비해 조금 부족하지만 이를 잘 알려줄 수 있는 사람 중에 책에 나온대로 정신과 의사로 비유하자면 의학 지식만 많은 사람 보다 실제로 좋은 처방을 해줄 수 있는 사람이
+
+좋은 의사(뛰어난 선생님) 인 것 같고, 이런 능력도 일종의 소프트스킬이지 않을까 생각이 듭니다.
+
+
+
+3-4) 애자일을 애자일스럽게 도입하기
+
+무작정 애자일을 권하고 도입하려 하는 행동은 책 아주 도입부에 나왔던 몇 가지의 기준을 들이밀며 "이런 기업이 우수한 기업이다!" 라고 주장하는 것과 마찬가지인 것 같네요
+
+애자일이라고 할 수 없을 정도로 다른 방향이라도 본인이 속해있는 팀에서 최고의 효율을 낼 수 있는 방법이 있다면 그 방법이야말로 해당 팀에서의 '애자일'이라고 할 수 있을 것 같습니다. 
\ No newline at end of file

리뷰: 제 개인적인 철직인데요, 무작정 코딩부터 하지 않으려고 합니다.
빈 종이를 한장 가지고 와서 먼저 요구사항이 무엇인지를 스스로 재정의 해봅니다.
기획에 따라서 단순 나열이 가능할 때가 있고 또는 프로세스로 요구사항을 정리할 때가 있는 것 같아요.

그렇게 요구사항에 대한 정리가 끝나면 필요한 클래스를 정의하기 시작합니다.

이때 모든 걸 다 완벽하게 하기는 당연 불가능에 가깝기 때문에 최대한 꼭 필요할 것 같은 클래스 속성과 메서드에 대해서만 정의를 하고 넘어갑니다.

요렇게 요구사항 분석과 간단한 설계 과정을 끝낸 다음에 본격적으로 구현을 하려고 넘어가요.
그러다보면 당근 당초 설계와는 틀어지는 부분이 발생하게 되는데 이럴 때는 과감하게 기존 설계를 버리고 구현부에 집중을 합니다.

다만 구현부에서 수정된 내용을 설계문서에도 반영될 수 있도록 되도록 수정하고 있어요!