조직 / 팀의 모습 / 어떤 팀의 모습 /
이 분류가 정확히 맞아들어가는 것은 아니지만, 조직의 모습을 고민하는데에 하나의 의견이 될 수 있을 듯 하다.
리더 / engineering leader / 팀 리더 / 팀장 / 관리자의 역할 / 방법 / 팁 / 관리 / 관리자
ref. 3 을 참고한다면, 적어도 서구권에서 리더는 좀 더 assertive(확신적인) 가 되어야 할 듯 하다.
Damian Hughes, a professor in organizational psychology, who told him, “You only have one role as a leader: to create an organisation where people flourish. The rest is pretty easy.”
글로 그림 / 차트 그리기 / chart / draw chart / 챠트 / diagram /
다이어그램 / visio 대안
markdown 같은 형식으로 flow chart 를 그릴 수 있다.
vscode 에서 plugin 을 지원한다.
github issue / github 사용법 / github 로 개발하는 방법 / github 로 collaborator 로 이슈 해결 / 협업 툴 / 그룹 웨어 / vscode 에서 github 를 사용하는 방법 /triaging / triage / 깃헙 / 깃허브 사용법 / 깃허브 이슈 사용법 / github 이슈 / 활용법
vscode Wiki를 읽으면 vscode team 이 어떻게 github 를 사용하는지 알 수 있다.
November 2019 처럼 날짜를 사용)investigation-wanted 는 재현을 할 수 없거나, 세팅등이 너무 오래걸려서 재현할 시간이 없거나 하면 이 label 을 사용한다.help-wanted 는 community 에 도움을 요청하기 위한 용도wont-fix label 을 붙이고 close 하는 경우
wont-fix 를 사용한다.upstream issue
plan-item 이라는 label 을 붙인다.plan-item 에는 자세한 checklist 를 넣게 된다.(예시)bug, plan-item, feature-request 에 milestone 을 할당한다.importatant 가 가장 먼저 해결된다.from: ref. 1, Robert Sweeney, Founder and CEO at Facet
I turned down Daniel Buchmueller for a job at Netflix. After a 60 minute interview I was on the fence, so I concluded that he "wasn't senior enough." He went to Amazon instead where he co-founded Amazon Prime Air (their drone delivery service) and was #2 on Fast Company's "Most Creative People" list. At some point, we programmers are going to have to admit that we really can't judge another programmers technical abilities in a 60 min interview. We end up hiring programmers that are good at interviewing, but not necessarily good at doing the job. And we miss out on engineers like Daniel.
나는 넷플릭스에 있을 때 Daniel Buchmueller 를 채용하지 않았다. 1시간의 인터뷰를 한 후에도 나는 확신이 들지 않았다. 그래서 나는 그가 senior 에 적합하지 않다고 결론 내렸다.
그는 대신에 Amazon 에 갔고, 그는 Amazon Prime Air (그들의 드론 배달 서비스)를 공동설립 했고 Fast Company 의 "가장 창조적인 사람" 리스트에서 2위를 차지했다.
어떤 점에서 우리 프로그래머들은 우리가 다른 프로그래머들의 기술적인 역량을 60분의 면접후에 판단할 수 없다는 것을 인정해야만 한다.
우리는 "면접에서 좋아 보이지만 일을 잘하지는 않는 프로그래머들"을 고용하는 것을 관뒀다. 그리고 우리는 (여전히?) Daniel 같은 엔지니어를 놓친다.
451 리서치(451 Research)의 수석 애널리스트 라울 카스타논 마르티네즈
마르티네즈는 "비즈니스 특성상 UC(Unified Communication, 통합 커뮤니케이션)보다 협업 솔루션이 더 잘 맞는 곳들도 있다. 스타트업이나 디지털 네이티브 기업들이 그 예다. 단순히 직원 가운데 IT 전문가 비율이 높아서만은 아니다. 지식 노동자의 비중이 높을수록, 그리고 엔지니어 및 개발자 직원 기반이 강세일수록 협업 솔루션이 더 적합하다. 이들의 커뮤니케이션 방식에 더 잘 맞기 때문이다. 이런 이유로 UC에서 협업 툴로 이전하는 기업들도 많을 것이라 생각한다"고 말했다.[ref. 1]
“There are some companies that because of the nature of their business, could be well suited for that,” Castañón Martínez said, such as startups or digital native companies. “Not just because they tend to be more tech-savvy or tech-oriented than other companies, but mainly because of the type of workers. If they have a higher percentage of knowledge workers, and they are in a stage where they might have a strong employee base of engineers and developers, it just makes sense because that is how they communicate. So, I think that we might see some shift in that sense.”
타임라인 방식, 그룹피드 등, 그룹을 만들고, 그안에서 task 등을 추가하는 방식으로 보임, flow, taskworld 와 같은 방식 같다.
서버설치형이 아니면, 용량의 제한이 있다.
https://tmup.com/main/function
github team/ github org
ref. 1 에서 github 를 통해 팀작업을 하면 2가지 방법으로 협업을 할 수 있다고 알려준다. 2개는 아래와 같다.
여기서는 Organization 을 이용해 보자.
새로운 organization 을 만들고, 그 안에 repository 를 한 개 만들어 보자. 조직(organization)을 한 개 만드는 것은 마치 계정하나를 새로 만드는 것과 같은 느낌이다. 그래서 이 계정(조직) 아래에 원하는 repository 를 만들고 관리 해 나가면 된다. 당연한 이야기지만 repository 는 repository 안에서 각각 설정을 할 수 있다.
그리고 ‘조직’ 아래에는 여러개의 team 을 둘 수 있다. team 아래 또 team 을 둘 수도 있다. 팀(team) 을 만드는 방법은 여기를 참고하자.
┌─────────────────────────────────────────────────────┐
│ │
│ organization │
│ │
│ ┌─────────────┐ ┌───────────┐ ┌────────────┐ │
│ │ team1 │ │ │ │ │ │
│ │ │ │ │ │ │ │
│ │ ┌────────┐ │ │ team2 │ │ team3 │ │
│ │ │ team10 │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ └────────┘ │ │ │ │ │ │
│ └─────────────┘ └───────────┘ └────────────┘ │
└─────────────────────────────────────────────────────┘만드는 방법은 아래 sreenshot 들을 따라서 하면 된다.
조직 생성 시작
가격 결졍
조직 설정(set up)
memeber 추가
설문 제출
생성 완료
