외로움 속에서

개인 개발이라면 팀 개발 때와 달리 운용 규칙을 결정하지 않아도 마음대로 개발할 수 있다.차라리 그 개인 개발을 좋아하는 사람도 있겠지만, 개인도 순조롭게 개발을 하고 싶고, 임무를 더욱 스마트하게 관리하고 싶은데, 그게 어떻게 이루어진 거예요?뭐 그런 거 늘었어.개인지

개인 개발도 리듬 있게 개발하고 싶어요

설치 내용의 압축 파일

하고 싶은 것들의 일정, 임무 관리

하고 싶어서 개인 개발에서 어떻게 활용해야 할지 생각해 봤어요.

고독한 폭풍의 목적

외로운 쓰레기와 팀 개발 중인 쓰레기는 다른 목적이다.팀 공유나 재평가, 로그의 회고성이 아니라 여러 저장소에 걸쳐 쌓이는 것을 중시한다.그런 의미에서 엄밀히 말하면 쓰레기는 아니지만 외로운 쓰레기라는 단어를 사용하고 싶어서 이곳을 쓰레기라고 부른다.참고로 아래의 쓰레기를 추출했습니다.

판넬 보는 방식

쌓이다

스크램의 간인 팀의 운용 재평가(sprint의 재평가) 등 상대방이 없으니까 당연히 없지!슬프다
외로운 쓰레기에서 다음과 같은 목적을 활용하다

하고 싶은 일을 정리한다

여러 항목을 판넬로 내려다본다

이후 설치 내용을 쉽게 돌아볼 수 있습니다

그리고 어떻게 설치했는지 보실 수 있어요.

"앞으로 설치 내용을 되돌아보기 쉽다"는 것이 가장 중요하다. 개인 개발에서 번거로운 것은 이전에 쓴 코드가 어떻게 움직였는지 생각나지 않는다는 것이다.번거롭다진짜?취미로 여러 개의 코드를 썼는데, 정말 기억이 나지 않는다.이것은 누가 쓴 것입니까?이렇게 되기 때문에 가장 찾고 싶은 것은 동기다.

여러 저장소 가로지르기

다음은 한 사람이 여러 항목을 쓰기 때문에 여러 저장소의 issue를 가로로 보고 싶습니다.회사라면 차라리 한 보고서만 보고 분업당하는 사람이 많지만 개인의 활동은 여러 사람을 뛰어넘는 사람이 많을 것이다.나는 이것을 통일적으로 관리하고 싶다.

실제 조작 방법

구현 방법 보존을 위한 작업

issue에서 어느 정도 통일된 기능 단위로 쓰고commit 자체는 매우 세밀하게 잘랐다.issue에서commit의 id를 복사합니다. 이commit에서 참조한 문서와 보도도 issue에 기록됩니다.그렇다면 그 기능은 어떻게 설치되었을까?뒤돌아봐도 돼.

commit만 보내면 이렇게 쉬운 거예요.

가로로 실행되는 zenhub 실행

원래 젠허브라는 사람은 이 페이지를 보세요.

zenhub를 도입하면 한 보드에서 여러 개의 저장소를 관리할 수 있습니다.

(검사된 저장소의 issue만 볼 수 있음)
코드를 많이 쓰고 싶은데 issue 관리가 힘들어졌어요. 그런데 일부러 저장소를 열기가 귀찮아요. github 프로젝트는 저장소 안의 issue만 관리할 수 있어요.그래서 이런 형식을 취하기로 했다.

조언을 구하세요!

많이 써 봤어요.솔직히 말해서 개인 개발의 운용이 이러면 안 될까 고민이에요.하지만 그걸 생각하기 위해 쓰레기 같은 걸 다시 배우고 좋은 걸 배웠어요.만약 이렇게 하거나 이렇게 하는 것이 비교적 좋다면, 반드시 나에게 알려주세요!