[FE개발 스터디] 함께 자라기 - 애자일로 가는 길

이번에 회사에서 개발 스터디를 진행하였다.

프론트엔드 개발자끼리 진행했으며 읽은 책은 함께 자리기 - 애자일로 가는 길입니다.

 

각 챕터마다 생각나는 구절등을 남기고 서로의 의견을 남기는 식으로 진행하였다. 

그 중 내가 작성한 구절들은 기록하여 남겨보려고 한다.

 

• 당신은 몇 년차?
  
  • 의도적 수련 ⇒ 애자일
  • 그냥 단순 코딩은 포함되지않는다.
  • 10년차 꾸준히… 단순코딩은 실력이 늘지 않는다. @김순일
    • 다양한 방식, 피드백 수용, 충분한 공유
• 자기 계발은 복리로 돌아온다
  • 일년 후 회고
    • https://k-soonil.tistory.com/22 - 올해 1월에 작성한 23년 개발자로서의 회고
  • 자신의 갖고있는 것을 잘 활용하라
    • 그전에 자기계발을 진행할때 NESTJS, Flutter, Svelte 등 다양한 방법으로 공부하고 학습해봤는데 최근에 느끼는건 신규 지식( 아예 다른 방향의 지식 )도 중요하지만 지금 내가 하는 개발의 전문성을 키워야한다는 것을 느꼈다. 하이퍼링크로 연결했을때 너무 멀리가지않고 가까운 지식부터 채우는것이 더 중요한것을 생각했다.
  • 학습 프레임과 실행 프레임
    • 아직 1년차라 책과 코드를 보며 업무를 배우며 학습
    • 아직 1년차라 A선임, B책임 에게 많이 물어보며 학습 / 공부하고 싶은 주제로 스터디 운영
  • 가장 학습하기 힘든 직업이 살아남는다.
    • 개인적으로 개발자의 연차가 오를수록 능력치가 올라가는건 개발능력이 아닌 의사소통이라고 생각합니다.
    • 단순 코딩 과 개발은 GPT처럼 다양한 보조기술들이 나올거라고 생각합니다. 하지만 그러한 기술이 하지 못하는건 소통/협상/설득 입니다.
    • 어메스 다양한 회의에서 자신의 의견을 틀리더라고 표출하고 더 나아가 경력이 오를 수록 좀 더 정확한 의견을 표출할수 있다고 생각합니다.
  • 수십 년 동안 전문가가 안 되는 비결
    • 피드백을 받았을때 어떻게 대응할 것 인가
  • 당신이 제자리걸음인 이유
    • 자신의 업무에 지루함과 불안함을 느끼지 하려면 어떻게 해야하는가
      • 난이도 높이기
        • 안해도 되는 업무를 자신의 의지로 작업
          • 리팩토링
          • 자동화 테스트
      • 실력 높이기
        • 사회적 접근
        • 도구적 접근
    • 의도적 수련의 일상적 예시
      • 예시
    • 프로그래밍 언어 배우기의 달인
      • 하나의 뼈대 언어를 마스터 하면 다른 언어로 넘어 가는 건 크게 어렵지 않다고 느껴집니다.
        • 반복문, 조건문등 수식형식은 비슷한 경우가 있고 각각의 언어는 풍부한 라이브러리 또는 프레임워크를 가지고 있어, 개발 속도를 높이고 특정 문제를 쉽게 해결할 수 있게 해줍니다.
    • 실수는 예방하는 것이 아니라 관리하는 것이다.
      • 실수 관리 문화
      • 실수를 비난하고 처벌하면 실수가 나와도 덮어버린다.
      • 실수를 통해 건강한 피드백을 받고 관리하면 더욱더 성장할수 있다.
    • 뛰어난 선생에 대한 미신
      • 대부분 개발자들이 만든 강의등을 볼때 개발자들이기 때문에 말을 잘하거나 학습을 잘해주는 사람이 없다고 느꼈다.
      • 그들이 제공해주는 클론코딩을 따라해보고 특정 함수나 로직을 스스로 분석해보고 주석을 달면서 학습하는 방향이 좋았던거 같다.
    • 나홀로 전문가에 대한 미신
      • 개인이 아무리 뛰어난 개발실력이 있어도 개발은 기획 서버 클라이언트 디자인이 나와야하고 개인이 이 작업을 모두 하기 힘들기에 팀이 존재하며 서로 협력하여 내가 전문가가 되기 보다 내가 속한 팀이 ‘전문적인 팀’이 되어야한다.
    • 소프트웨어 관리자의 개선 우선순위
    • 데일리스크럼/ 플래닝 / 회고 / 스토리 포인트 다양한 관리 방법을 도입하고 변화하고 있다.
    • 다양한 관리 환경과 시스템이 변화하고 있다. 그 변화속에 지금 프로젝트 관리는 잘되고 있는가?
    • 협력을 통한 추상화
      • 남들이 봤을때 이해하기 쉬운 추상화 코드를 짜면 협력에 도움이 된다.
    • 신뢰를 깎는 공유인가, 신뢰를 쌓는 공유인가
      • 신뢰를 쌓는 공유를 하려면 복수공유 모든 작업을 공유를 해야한다.
        • 자신의 실패 즉 이슈와 버그도 모두 공유해야 신뢰가 쌓인다.
      • 객관성의 주관성
        • 소통에서 남들을 설득할때 객관적이고 논리적도 중요하지만 상대방 ( 결정권자 )를 고려해야한다.
      • 이것도 모르세요?
        • 커뮤니케이션 / 멘토링 / 코칭능력 도 하나의 기술이다.
        • 나의 말로 인해 다른 사람이 성장할수도 퇴화할수도 있는 것이다.
    • 하향식 접근의 함정
      • 탑다운과 바텀업을 섞어 사용 한 방법을 고집스럽하게 사용하지않게해야된다.
      • 삼투압적 의사소통 → 많은 회의를 통해 기획과 백엔드의 진행도를 알고 있어 이전보다는 늘어나고 있다고 생각합니다.
    • 전문가팀이 실패하는 이유
      • 전문가들이 모아서 팀을 만든다고 잘하는것이 아니고 정보를 공유하고 협력이 필요하며 그러기 위해서 다양한 분야를 경험한 제네럴리스트 있는 것이 도움이 된다.
        • 개인적으로는 한 사람이 여러 기술을 경험한 사람(저희로 치면 프론트 / 백엔드 / 기획 / 디자인)을 경험한 사람 보단 한 사람이 한 분야에 전문가가 되면서 각자 분야의 전문가들과 수많은 의사소통과 의사결정, 수많은 경험을 통해 해당 분야를 간접적으로 경험해하는 것이 좋을거 같다.
      • 구글이 밝힌 탁월한 팀의 비밀
        • 심리적 안정감
          • 저는 회의나 면담때 말 실수를 종종 하는 편이에요 그래서 상대방이 실수를 해도 웃어 넘기고 제가 실수 해도 웃어 넘기려는 편이에요( 큰 건이 아니라면)
          • 저희 회사는 의견을 말하기 좋은 회사인편인거 같아요. 그래서 데일리때 한마디씩 하자라는 생각을 갖고 하고 있어요 ( CA에서는 못했네요) 특정 이슈가 없어도 금일 작업사항을 확인차원에서 한마디씩 하는 건 좋은거 같아요.
      • 쾌속 학습팀
        • 저는 예전에 언어를 바꿔라 라는 말을 회사에서 경험한 적이 있습니다.
          • 자바와 JSP로만 구성된 환경에서 api 개발과 프론트 환경을 구축해 분리 해라라는 말과 ( 당시 회사는 자바개발자 뿐이였습니다.)
          • react로 된 언어를 vue로 변경해라( vue가 쉽고 접근성이 좋다고 해서)
          • 이러한 변화는 보통 개발자들의 의견을 수렴해서 정하기 보단 급작스럽게 변화했고 그 변화속에서 자신의 커리어와 맞을 않다고 판단하는 개발자들은 퇴사를 하기도 했고 (자바개발자가 프론트 개발자가 되거나 등) 변화환경을 잘 아는 사람이 와서 하기보다 그냥 진행했던 부분이 많아서 좋지않은 기억이 꽤 있습니다.
        • 사용하는 언어가 도태되지 않을 경우(중요) 버전 업 마이그레이션을 진행하는 게 더 좋다고 생각합니다.
      • 프로젝트 확률론
        • 에자일 회의로 확률을 ‘그리고’가 아닌 ‘또는’으로 변경할수 있다고 하는 데 아직 체감은 되지않는 거 같습니다.
    • 애자일 도입 성공 요인 분석
      • 성공도 회귀 분석 → 짧은 반복 개발 주기 / 고객 참여 / 코드 공유
        • 일주일 단위 스프린트를 잡아 개발단위를 짧게 잡고
        • pr / 다양한 회의로 코드를 공유를 하며
        • 페이스북/인스타 댓글등으로 고객의 소리를 듣고 있는 거 같다.
      • 당신의 조직에 새 방법론이 먹히지 않는 이유
        • 방법론이 중요한것이 아니다. 누가 참여했는가가 중요하다.
          • 우리회사는 다양한 방법론의 제시하고 그에 대부분 따라서 진행하는 거 같습니다.
      • 애자일을 애자일스럽게 도입하기
        • 애자일 방법론을 도입할때 뭘 해야 할지 명확하게 알려달라고 한다. 근데 그 모습은 전혀 애자일적이지 않다.
          
          

마무리

• 과거 스터디를 할때 같이 코딩하는 식의 독서 모임이였다
• 책에 있는 예제를 코딩하고 새로 써보는 함수나 기능들을 얘기해보는 모임을 해본 경험이 있는데 이번 스터디는 색다른거 같아 달랐다.
• 뭔가 자신의 의견/생각이 더 중요한 스터디였던거 같다.

 

약 6주간 진행하였으며 한 챕터당 한가지이상의 의견을 적고 서로 그 의견에 대한 의견을 나누며 진행했습니다.

처음 하는 진행방식과 토론적인 스터디가 재밌게 느껴졌습니다. 에자일 방식의 개발과 회의를 진행하면서 스터디를 해서 좀더 도움이 되는 스터디였던거 같습니다.