버그 추적 / 문제 추적 소프트웨어를 사용하여 설계 질문, 새로운 도구 등 논의

버그질라, 사마귀 또는 JIRA와 같은 버그 추적 / 문제 추적 소프트웨어를 버그 나 작업에 사용할뿐만 아니라 결국 결정으로 이어지는 토론을 시작하고 유지하는 경험이 있습니까?

예를 들어, 개발자는 모든 보호 된 필드를 폐지하고 액세스하는 보호 된 메소드를 사용하여 개인 필드로 변경해야한다고 생각합니다. 그것은 그의 부름이 아니며, 그것을 논의하고 싶습니다. 일반적으로 그는 결정이 내려 질 때 다음 개발자 회의에서 요점을 제시합니다. 대신 내 생각은 특정 유형의 "결정"문제를 열고 버그 나 작업을 설명하는 것처럼 그의 의도를 설명하는 것이었다.

다른 개발자들은 자신의 의견이 있다면 의견을 제시 할 수 있으며, 결국이 문제는 "허용됨"또는 "거부 됨"으로 종결됩니다.

내가 볼 수있는 장점 :

• 비동기식 의사 소통 : 아직 의사 결정에 대한 모든 파급 효과를 감독 할 시간이 없을 때 회의에서 자신의 의견을 표명 할 사람은 없습니다.
• 결정으로 이어지는 고려 사항 기록. 나중에 그 질문을 다시 제기하면 질문을 할 수 있습니다.
• 다른 문제들과의 관계가 이루어질 수 있습니다.
• 커밋과 같은 버전 제어 소프트웨어와의 통합은 결정으로 추적 될 수 있습니다.

단점 :

• 황금 망치의 심한 냄새 : 문제 추적 소프트웨어는 일반적으로 실행 가능한 항목을 추적하는 데 사용됩니다
• 조직적인 오버 헤드는 불균형 할 수 있습니다. 작은 비공식 대화 대신 아이디어를 서면 형식으로 전달해야합니다.

우리가 일하는 방식, 이슈 트래킹은 모든 이슈를 추적해야합니다. 우리는 어떤 문제가 분석 될 때까지 실행 가능한지 알 수 없습니다. 추적 시스템에 실행 가능한 문제 만있는 경우 너무 빨리 분류되어 토론 및 결정이 손실 될 수 있습니다. 우리는 모든 작업을 수행해야합니다 (어쨌든 워크 플로에서).

"위험"에 대한 Jira 구현 범주가 있으므로 Jira를 사용하여 실행할 수 없지만 소프트웨어를 위태롭게하는 항목을 추적하고 있습니다. 항목에 대한 토론이 추적되고 일단 위험이 사라지거나 완화되면 문제가 종결됩니다. 귀하가 제공 한 예는 위험 범주로 쉽게 이동할 수 있습니다.

이와 같은 것들에 대해 논의하고 추적하고 결정을 기록하는 것이 중요합니다. 개발자가 몇 달 안에 문제를 다시 제기하면 "질문과 대답"응답에 대한 정당성이 있습니다.

내가 틀렸다면 나를 바로 잡으십시오. 하지만 당신이 말하는 것은 "버그 추적 / 발행 추적 시스템을 사용하여 '의사 추적'을 수행 할 수 있습니까?

처음에 나는 이것이 정말로 좋은 생각이라고 말할 것입니다. 정확한 방식으로 사용하지는 않지만 추적 목적으로 사용하는 것이 좋습니다. 우리의 경우, 긴 이메일 스레드-더 많은 포럼 / 메일 링리스트가 뒤 따릅니다.

그러나 더 넓은 의미에서 귀하의 질문은 의사 결정을 효과적으로 수행하고 관리하는 방법에 관한 것이며, 작업의 의미를 더 나은 통찰력을 가져 오는 결정에 다시 연결하는 것입니다.

내가 말했듯이, 그것이 사람들을 돕는다면 좋은 아이디어가 될 수 있습니다. 그것에 대해 잘못이 없습니다. 그러나 의사 결정을 효과적으로 내리고 관리하려면 구체적인 사항이 거의 필요하지 않습니다.

1. 대부분의 의사 결정은 포괄적이고 포괄적 인 노력으로 이루어져 결정이 내려지기 전에 모든 중요한 측면이 적절히 다루어지고 평가되어야합니다. 따라서 어떤 도구를 사용하든 관계된 모든 사람들이 정보에 투명하게 액세스 할 수 있어야합니다. 사람들이 정보를 전달하고 수집하는 비동기 모드가 도움이된다는 것은 옳습니다. 사람들은 제안을하기 전에 시간을 투자 할 수 있기 때문입니다. 일반적으로 회의에서 사전 답변을 요청하는 경우 충분한 숙제를 가진 동일한 사람에 비해 판단이 똑같이 들리지 않을 수 있습니다.

2. 그러나 이것이 반드시 모든 투표가 동일한 "순수한 민주주의"를 의미하는 것은 아닙니다. 일반적으로 의사 결정자는 한 명 또는 몇 명이어야합니다. 모든 의견을 수렴하는 동안 의견을 제공 한 모든 사람이 아니라 결정에 대해 개별적으로 책임을 져야합니다.

3. 대부분의 결정은 실행 가능해야합니다. 이것은 모순을 피하기 어려울 수 있습니다. 그러나 결정이 실행 가능하지 않고 주관적이라는 사실은 미래의 (미스) 해석에 대한 가능성이 있음을 의미합니다.

4. 결정의 수준과 범위를 분류하는 것이 중요합니다. 가장 중요한 것은 특정 설계 문제 또는 코드의 특정 측면, 프로세스 측면을 논의하고 있는지 또는 프로젝트 계획 및 추적 관련 문제인지 여부를 식별해야합니다. 이슈가 프로덕션 코드에서 발생하는 경우가 많지만 이러한 모든 사항이 적용 가능하지만 이러한 모든 의사 결정을 효과적으로 관리하려면 독립적으로 모든 다른 측면을 구별 할 수 있어야합니다.

5. 때때로 결정은 개인에 대한 특정 시스템 또는 역할과 책임을 사용할 지에 대한 것일 수 있습니다. 공지 사항 보드 유형 포럼에서 특정 결정을 코딩하는 것과 함께 이러한 결정을 내리는 것이 어려울 수 있습니다.

6. 추가 일화; 모든 팀은 코드 검토 및 디자인 검토를 자체적으로 프로세스로 작성해야합니다. 여기에는 인용 한 예와 같은 많은 문제가 철저하게 포함됩니다. 의사 결정은 다른 것들과의 거래를 추적하는지의 여부입니다.

올바른 의사 결정 관행에는 정보를 모으는 방법과 올바른 정신으로 구현을 통해 결정을 내리는 방법에 대한 많은 훈련이 필요합니다.

도구는 정보를 넘어서서보다 잘 표현할 수 있도록 도와 줄뿐입니다. 그러나 그것이 당신에게 효과가 있다면 그것은 좋은 도움이 될 것입니다.

FogBugz는 갈 길입니다. 무료가 아닙니다. 최신 기능으로 민첩한 방법론을 훨씬 쉽게 구현할 수 있습니다.

더 간단하고 자유로운 방법은 Asana입니다.

어떤 도구를 사용하든 성공적인 프로젝트를 위해서는 팀 커뮤니케이션이 가장 중요합니다.