현재 우리는 Jira를 적절히 활용하고 있는 것인가에 대한 의문 #43
Replies: 2 comments 3 replies
-
1. Github프로젝트 배포단계인 현 상태에서는 Jira보다는 Github을 사용한 프로젝트 관리가 더 적합해 보이는것 같습니다. 단, 데이터베이스 초기 구축과 같은 프로젝트에 필요한 기능이 완전히 구현되지 않은 지금으로서는 기존의 상태(Jira)를 유지하고, 현재의 스프린트 요구사항이 마무리되고 더 이상의 굵직한 요구사항이 없다 판단되면 Github를 이용한 프로젝트관리로 옮겨갔으면 좋겠다는 것이 제 생각입니다. 2. Contributer
|
Beta Was this translation helpful? Give feedback.
-
저도 해당 의견에 동의합니다!! 적어도 프로젝트가 정상적으로 돌아가기 위해 필요한 기능들이 마무리 된 시점에서 스프린트 방식을 종료하는게 좋을 것 같네요.
네 정확합니다. 물론, 사용자가 코드에 직접 기여하는 것에 신중을 가할 필요가 있다고 생각합니다. 다만, 이건 깃허브 Issue를 도입했을 때 얻을 수 있는 장점 중 하나인 것으로 추후 사용자가 많아졌을 때 고민해도 될 것 같아요. 아직까지는 크게 신경쓰지 않아도 될 것 같습니다. |
Beta Was this translation helpful? Give feedback.
-
|
넵 좋은 의견인것 같습니다👍👍 |
Beta Was this translation helpful? Give feedback.
-
|
저도 결국 같은 얘기지만 추가로 덧붙이자면 기능 구현, 배포가 완료된 단계에서부터는 github로 이슈를 공개하고 쌓아놓으며 |
Beta Was this translation helpful? Give feedback.
-
|
정리 및 피드백 감사합니다 😄 |
Beta Was this translation helpful? Give feedback.
-
이 글의 목적은 저의 생각을 전달함과 동시에 제가 생각한 문제점과 해결방안이 적절한지에 대한 팀원들의 의견을 묻기 위함입니다.
저의 생각이 절대 정답이 될 수 없기에 팀원분들께서 편하게 의견 내주셨으면 좋겠습니다!
결론부터 말하자면, 프로젝트 이슈를 관리하는 방법을 기존 Jira에서 Github로 변경하자입니다.
프로젝트가 배포되어 localhost에서 벗어난 현 시점에서
gonghak98어플리케이션은 더 이상 저희끼리만 쓰는게 아닌 모두가 접근할 수 있으며, 모교 학생들이 이용할 수 있는 공간이 되었습니다. 따라서 이제는 사용자의 관점에서 봤을 때, 필요한 이슈들을 자유롭게 작성할 수 있는 시스템이 필요하다고 판단했습니다. 그리고 최근 경험을 통해, Github의 이슈 탭을 활용하는 것이 더 적합하다고 생각했습니다.1. 사용자에게 필요한 기능들을 누구나 작성할 수 있다.
현재 Jira는 권한이 있는 팀원들만 접근할 수 있습니다. 그렇기에 각 팀원들이 본인 파트에서 필요하다고 생각하는 이슈들을 자유롭게 작성하고 본인에게 할당하는 방식입니다. 하지만 Github의 이슈 탭을 활용하면 누구나 이 프로젝트에 필요한 점 혹은 개선할 점들을 이슈로 등록할 수 있습니다.
이렇게 되면, 이슈를 해결할 수 있는 사람은 누구나 가능해집니다. 기존의 방식에서는 다음과 같은 문제가 있었습니다.
JPA 관련 기능을 개선하고 싶은 사람은 JPA 관련 이슈를 해결하면 됩니다. 도커 관련 기능을 개선하며 공부하고 싶은 사람은 도커 관련 이슈를 해결하면 됩니다. 이제는 각자의 역할의 경계가 허물어졌으면 하는 바입니다.
2. 이슈 템플릿을 활용하여 이슈에 대해 팀원들이 더욱 자세히 알 수 있다.
현재 Jira에서 사용하는 이슈들의 내용을 확인할 수 있는 방법은 제목 뿐입니다. 간혹, 본문에 자세한 내용을 작성하는 분들도 있지만 대부분 제목으로만 이슈 내용을 작성하는 것에 그칩니다. 이렇게 될 수밖에 없는 이유는 현재 이슈를 작성하는 목적이 본인이 해야 할 업무 리스트를 작성하는 것이기 때문입니다. 따라서 내가 작성한 이슈에 대해 다른 팀원에게 알려야 할 필요성도 중요성도 크게 인식하지 못하고 있습니다. 이러한 방식은 지금 당장은 문제가 없을 지라도 추후 프로젝트가 고도화되고, 장기적으로 운영될 때 큰 문제를 야기할 수 있다고 생각합니다. Github의 이슈 템플릿을 활용한다면 이슈를 작성할 때마다, 필수적으로 들어가야 하는 내용들을 템플릿으로 만들어 적용할 수 있습니다.
2024-LikeLionHackerton-MoodinG/MoodinG-BE#17
간단하게라도
왜 이 이슈가 이 프로젝트에 필요한가에 대해 작성하여 팀원들에게 공유하는 것이 팀 프로젝트가 올바른 방향으로 발전할 수 있는 방법이라고 생각했습니다.3. 배포 로그를 작성할 때, 어떠한 기능이 추가되고 개선되었는지를 이슈 단위로 작성할 수 있다.
이제, 프로젝트를 main 브랜치에 머지하여 소스코드가 자동으로 배포될 경우, Github의 release 탭을 활용하여 배포 로그를 작성할 예정입니다. 이 때, 해당 릴리즈 버전에서 어떠한 기능들이 추가되었는지를 이슈 번호를 링크로 달아 작성할 수 있습니다.
https://github.com/hanjo8813/PleaseGraduate/releases
4. PR을 올릴 때, 관련된 이슈와 연결시킬 수 있다.
PR을 작성할 때,
closed+#+이슈 번호를 작성하면 해당 PR이 Merge 되었을 때, 연결된 이슈가 자동으로 닫히게 됩니다.이를 활용하면, 나의 활동들을 PR 단위로 관리할 수 있으며 이 PR이 어떠한 이슈를 해결하였는지를 편하게 볼 수 있습니다.
2024-LikeLionHackerton-MoodinG/MoodinG-BE#23
5. 프로젝트의 방향성을 변경할 수 있다.
1번의 내용과 연결되는 부분인 것 같습니다. 기존에는 일정한 주기로 스프린트를 생성한 다음, 각자 본인이 맡은 파트에서 해야할 일들을 알아서 작성하였습니다. 그런데 저는 이게 뭔가 숙제하는 느낌...? 때로는 할 게 없음에도 억지로 작성해야 하는 경우도 있었습니다. (저의 경험) 하지만 Github의 이슈를 활용하면 프로젝트에서 개선되거나 추가되어야 할 부분이 생각나면 언제든지 이슈로 등록할 수 있으며, 본인 파트가 아니더라도 개선이 필요한 내용이라면 누구나 등록할 수 있습니다. 그리고 이슈 내용을 보고 본인이 해결할 수 있을 것 같거나 해당 내용을 공부하며 해결해보고 싶으면 자유롭게 이슈를 가져가서 해결합니다. (ex. 해당 이슈에 댓글로 “제가 해결하겠습니다!” 라고 남기면 해당 이슈를 담당자로 지정, 이슈를 해결하기 위한 아이디어 혹은 출처 자료에 대해 공유하며 팀원들과 충분한 논의)
Beta Was this translation helpful? Give feedback.
All reactions