Dev huddle은 개발자 간의 일관성을 실현하는 도구입니다.

당신은 어떻게 팀의 개발자가 기술 방향에서 일치함을 유지하도록 확보합니까?이것은 어려운 문제다!각 팀은 모두 자신의 특질을 가지고 있다.tech lead의 사람으로서 나는 많은 생각을 했고 마지막으로 권한 수여나 공동 목표 등 모호한 생각을 얻었다.안 돼!
하지만 제가 속한 팀에서 효과가 있는 의식이 있습니다.나는 데프의 비밀을 이야기하고 싶다.

Dev huddle?



개발자 조정 기대
여러 가지 이름이 있습니다: Dev Huddle, Tech Huddle, Dev Meeting.명칭이 어떻든지 간에 그것은 팀의 개발자를 대상으로 하는 정기 회의이다.이것은 기술 주제를 토론하고 구조, 약정 또는 그 어떠한 다른 기술 창고에 대해 결정을 내리는 논단이다.
와, 너무 창의적이야!너는 아마 냉소할 것이다.네, 이것은 돌파할 만한 것이 없습니다.그러나 문제는 세부적인 부분에서 나온다.하나를 효과적으로 운행하는 것은 매우 까다롭다.또 다른 쓸모없는 회의를 하는 것만큼 개발자들을 낙담하게 하는 것은 없다.만약 네가 그들의 시간을 쓰고 있다면, 너는 그것을 가치 있게 하는 것이 가장 좋다.

내가 왜 이러지?


'어떻게'에 주목하기 전에'왜'에 대해 이야기합시다.우리는 무엇을 실현하기를 기대합니까?

  • 창설 일치성: 개발자는 긴밀하게 협력할 수 있지만 소프트웨어를 구축할 때 마치 그들이 본 적이 없는 것 같다.그들은 인코딩 약정에 동의합니까?JSON 을 분석하기 위한 기본 라이브러리는 무엇입니까?작은 결정들이 많아요.시간의 추이에 따라 이러한 것들은 소프트웨어 구축에 대한 일치된 이해를 형성했고 이것은 어떤 고성능 팀에게도 매우 중요하다.

  • 혁신 촉진: 가장 유행하는 기술로 6개월에 한 번씩 응용 프로그램을 다시 쓸 수는 없지만 실험을 격려하고 싶습니다.Continuous improvements 화합물은 시간에 따라 변화한다.나는 처음에는 희망이 없어 보였던 팀의 일원이었다.1년의 많은 작은 개선을 거쳐 우리는 지금 하고 있다continuous deployment.그러나 이런 상황은 한 차례의 큰 추진 아래 발생하는 경우는 드물다.

  • 변론 격려: 일부 팀은 내가 말한 종신제 토론을 실천하고 팀에서 가장 경험이 많은 사람들은 이곳에서 기술 결정을 내리며 나머지 사람들은 응, 그들을 따른다.만약 그들이 다행히도 이 결정들을 알게 된다면당신의 노인들은 경험과 직감이 있지만, 다른 사람들도 공헌할 수 있다.
  • 준비


    나는 쌓인 생각을 한데 묶는 것을 좋아한다.벽에 있는 종이 한 장과 접착물 같은 간단한 것들또는 Github의 질문 목록입니다.하나하나가 간단한 제목일 수 있다.그들은 그곳에서 대화를 시작했다.몇 가지 예:
  • , 새로운 단언 라이브러리strikt를 만들어 봅시다
  • API 호출 재구성React hooks
  • 최신 Micro Services 문서 누락

  • 누가 새로운 주제를 추가했습니까?개개인페어링할 때 재구성 대상을 찾았습니다.너는 그 새 도서관에 관한 그 문장을 읽었다.벽에 추가하기만 하면 된다.
    처음에는 유일하게 아이디어를 발표한 사람이었다.시간의 흐름에 따라 팀의 다른 멤버들은 더욱 편안함을 느끼고 참여할 것이다.잠시 후에 우리는 어떻게 이야기할 내용을 선택하는지 알게 될 것이다.

    시간을 찾다


    필요할 때 모이라고 할 수도 있다.우리는 민첩하다!나의 경험에 따르면, 이것은 실천에서 통하지 않는다.항상 급한 일이 있어요.누군가는 지금 시간이 없다.
    내 건의?일정한 시간대를 선택하십시오: 매주 같은 날 같은 시간.이상적인 상황에서 네가 가장 적게 끊기만 하면 된다.매일 점심을 먹고 나면사실 중요하지 않아요.사람들은 그것에 익숙해져서 일정 중에 고려할 것이다.
    30분이면 충분히 의미 있는 대화를 할 수 있을 것이다.회로판의 유량은 매우 좋은 지시기다.만약 네가 영원히 이야기하지 않을 화제를 점점 더 모았다면, 아마도 좀 더 있을 때가 되었을 것이다.만약 네 물건을 다 썼다면, 아마도 너는 좀 일찍 완성할 수 있을 것이다. 심지어는 2주에 한 번으로 바꿀 수 있을 것이다.

    개발자 집합을 어떻게 운영합니까


    운영 개발팀은 주제 목록을 조회하고 주제를 토론하며 결론을 얻어 기록하는 것을 포함한다.아주 간단하게 들리죠?

    적당히 발생하다
    그리 빠르지 않다.우선 촉진자가 있어야 한다.전체 시간을 단일 주제가 차지하지 않도록 총 시간을 유지합니다.모든 사람에게 발언할 기회를 주다.이 역할이 없으면 술집에서 토론할 수도 있고, 맥주가 없을 수도 있다.
    나는 과거에 전 팀에서 모든 훈련을 맡았다.오랜 시간이 지나서야 나는 이것이 얼마나 큰 잘못인지 깨달았다.회의가 전체 단체에 속해야 할 때, 그것은 결국 너의 것이 될 것이다.이 밖에 동시에 추진하고 적극적으로 참여하기는 어렵다.회전 안내로 변경합니다.모든 사람은 적당한 연습을 할 수 있고, 너도 약간의 즐거움을 누릴 수 있다.
    만약 네가 너무 많은 화제를 가지고 있다면, 너는 반드시 해결해야 할 화제를 선택해야 한다.창설 순서대로 가져오거나 시작하기 전에 얻을 수 있습니다 dot vote.어떤 사람들은 다른 사람들보다 더 많은 점수를 가져올 것이다.최대한 균형을 잡다.큰 구조 변경은 몇 분 이상 걸리기 때문에 후속 회의가 필요할 수도 있다.
    그리고... 토론이 잇따랐다.한데 뭉치면 부서진 문화를 복원할 수 없지만 좋은 시금석 테스트다.당신은 관점을 진술하고 있습니까 아니면 사실을 진술하고 있습니까?너는 발언을 쟁취하고 있니?만약 그렇다면, 한데 모이는 것이 너의 가장 작은 문제다.다음은 경험이 부족한 진행자를 돕는 예시 목록입니다.
    - Are there open points from last time?
    - Choose the topics for today
    * For every topic
    
        The owner presents the issue so that everybody is on the same page
        Talk about it (Keep a timebox!)
        Resolution
            What did we decide?
            Assign an owner to take care of the follow-up
    
    - Have we made decisions that need to be reflected in ADRs?
    - Finish on time, unless there is something that absolutely can't wait
    

    결과


    팀을 서로 교류시키는 것은 이미 매우 중요하다.그러나 결과가 없다면 사실상 회의가 아니라 사교 모임이다.우리의 발견을 적어 봅시다.보통, 그것은 당신이 하고 싶은 일이나 지금부터 해야 할 일에 관한 것이다.

    기술 이야기


    pointy-haired micromanagers이 취한 모든 행동을 기록하고 싶은 사람들의 말을 듣지 마라. 아무리 중요하지 않더라도.사소한 일에 대해서는 장부를 최소한으로 통제하고 의존한다slack time.
    더 큰 일에 대해 기술 이야기를 쓰고 일반적인 쌓인 일에 통합할 수 있도록 하세요.할 수 있는 말이 많다about this.TLDR: 기술 이야기를 사용자 이야기와 같은 표준으로 유지합니다.

    추적 결정



    아카이빙 결정
    모두들 한 덩어리로 붐벼서 흥분했다.그것은 매우 격렬해졌지만, 너는 이미 분호를 사용할지 여부에 대해 일치했다.대변이 곧 끝난다.아무도 그것을 쓰지 않을 때까지, 다음 주에 너는 어쩔 수 없이 처음부터 시작해야 한다.사람을 분노하게 하다.
    lightweight Architecture Decision Records 좀 사다 주시겠어요?이것은 듣기에 매우 공식적이고 융통성이 없을 수도 있지만, 사실은 그렇지 않다.너는 단지 한 곳에서 네가 한 결정을 기록하기만 하면 된다.제목, 사용자가 결정한 내용과 상하문 해석이 있는 가격 인하 서류.나는 어떤 사람들이 소설을 써서 카프카의 미덕을 시적으로 묘사하는 것을 본 적이 있으며, 간단한 일도 효과를 볼 수 있다.
    Title: Use Kotlin instead of Java for new services
    
    Date: 2018/10
    
    Decision: We'll be using Kotlin whenever we start a new service but leave the existing ones
    
    Context: We think Kotlin will help us create more lightweight services while improving quality thanks to null safety
    
    사용할 수 있습니다many templates.중요한 것은 규율이 있어야 하며, 네가 동의한 내용을 반영해야 한다.

    한 덩어리로 붐벼라!


    돌이켜보면 내가 있는 모든 팀은 개발자에게 조율된 위치를 제공하는 데 적지 않은 이익을 얻었다.이것은 노력과 시간에 대한 작은 투자다.계속 시도해 보세요. 가장 적합한 설정을 찾으세요.

    좋은 웹페이지 즐겨찾기