“기능 요청!!!”
소프트웨어 엔지니어들이 고객 문제의 긴급성을 경시하기 위해 사용하는 전투 외침이 종종 있습니다. 결국,우리는 우리를 직면 끝없는 버그 로그에 밖으로 시선 때 새로운 기능을 추가 할 시간이 없다.
미국 소프트웨어 엔지니어,버그 및 기능 요청의 차이는 분명하다. 버그는 코드가 실제로 작동하는 방식과 코드가 작동하는 방식 사이의 불일치입니다. 기능 요청에는 현재 코드베이스에서 처리할 수 없는 사례를 만족시키기 위해 새 코드가 필요합니다.
이런 종류의 사고 과정은 항상 우리가 도네돈과 같은 소프트웨어를 어떻게 사용해야 하는지에 대한 보다 일반적인 질문으로 이끈다. 조직에서 버그를 기록하기 위해 한 유형의 소프트웨어를 사용하고,향후 작업을 관리하기 위해 다른 유형의 소프트웨어를 사용하고,기능 요청을 추적하기 위해 또 다른 유형의 소프트웨어를 사용해야합니까?
우리는 클라이언트 또는 고객이 기록한 문제를 선별하여 문제를”버그”버킷 또는”기능 요청”버킷에 던지는지 여부를 확인하려고 많은 정신적 에너지를 소비합니다. 컨설팅 업무의 경우,소프트웨어가 어떻게 행동해야하는지에 대한 사전 정의 된 합의를 통해 작업 할 때 이는 의미가 있습니다. 기능 요청은 추가 요금이 필요할 수 있습니다.
그러나 좋은 소프트웨어를 만드는 순수한 관행에 관해서,특히 우리 자신의 제품을 작업하는 경우,이 방법으로 문제를 분류하는 데 얼마나 신경을 써야합니까?
우리는 교칙(및 기술)문제를 해결하는 방법으로 얻을 수 있습니다.
로버트 마틴(일명 삼촌 밥)소프트웨어에 대해 많은 이야기. 그는 웹을 단지 전달 메커니즘으로 간주하며 그 이상은 아닙니다. 이는 최종 사용자 경험이 아니며 소프트웨어의 목적이 아닙니다. 그것은 단순히 작은 작은 바보 같은 세부 사항입니다. 아직,우리 프로그래머 프로그램,우리의 응용 프로그램의 아키텍처는 너무 전적으로 웹 응용 프로그램 이라는 사실에 의해 영향을.
같은 방식으로,우리가”끝내야 할 일”에 사용하는 용어를 바보 같은 세부 사항으로 간주한다면 어떨까요?
그”물건”을 로깅하는 사람의 관점에서 볼 때,그녀가 새로운 기능을 요청하는 것과 버그를 발견하는 것이 정말로 중요합니까? 그녀는 단지 그녀의 문제가 다른 인간에 의해 해결되기를 원하며,가급적이면 그녀의 문제가 언제 해결 될지 알기를 원합니다.
우리가 소프트웨어 세계를 떠나면 전문성을 더 분명하게 볼 수 있습니다. 배관공이 새는 샤워를 고치기 위하여 들어올 때,나는 당신이 세부사항에 관하여 걱정하지 않는다는 것을 상상할 것입니다. 샤워 헤드가 잘못 설치된 경우(버그)또는 가스켓이 파손 된 경우(버그)또는 테프론 테이프가 저렴한 파이프(기능)에서 누락 된 경우,당신이 걱정하는 것은 해결하기 위해 얼마나 오래 걸릴 것입니다 얼마나 당신이 청구됩니다.
버그 또는 요청? 둘 다입니다. 그리고 그것은 중요하지 않습니다.
지난 주 우리는 맘모스 킨,중소 기업을위한 인사 소프트웨어 도구를 발표했다. 킨은 당신에게 요청을 각 직원의 시간을 추적 할 수있는 간단한 방법을 제공합니다. 친족이 지금하지 않는 한 가지는 주말과 휴일을 근무일과 구별하는 것입니다. 당신이 추수 감사절 동안 전체 주를 벗고 싶어한다면,당신은 수동으로 해제 요청하는 시간의 양을 입력해야합니다.
팀은 이미 친족이 자동으로 추적을 수행하도록 몇 가지 요청을 받았습니다. 사실,그것은 릴리스 큐에 있습니다. 그러나 로그인 할 때 로그인 한 장소에 관계없이 친척 팀이 버그,기능 요청,작업 또는 할 일로 간주해야합니까?
내 내면의 삼촌 밥을 호출,내 대답은 간단하다:당신이 요청을 분류하는 방법을 중요하지 않습니다. 그것은 단지 멍청한 세부 사항입니다.
그것은 우리가 그것을 전혀 분류해서는 안된다고 말하는 것이 아닙니다. 친족 팀은”기능 요청”에서 문제에 태그를 지정하고 더 중요한 문제를 먼저 해결할 수 있습니다(예:권한 부여 문제가있는 사용자). 그것은 훌륭하고 멋쟁이,그리고 유효한 접근법입니다.
그러나 모든 것을 우리가 호출하는 기능 요청이 모든 것을 호출하는 버그보다 덜 시급하다고 자동으로 가정하는 것은 실수입니다. 그것은 우리가 문제를 해결할 때 문제를 어떻게 분류하는지에 대한 다소 사소한 세부 사항을 만들고 있습니다. 그것은 그렇게해서는 안됩니다. 결국 이러한 모든 요청은 단순히 해결이 필요한 것들입니다.
전문성을 멍청한 세부 사항으로 삼으십시오
이를 위해 이러한 모든 요청에 제공하는 레이블은 크게 중요하지 않습니다. 더 중요한 것은 누군가가 그들에게 참석하고 이러한 요청이 해결 될 때의 일반적인 생각이 있다는 것입니다. 더 중요한 것은 33%더 많은 사용자가 항목 비 대 해결되는 항목 혜택을 누릴 것입니다. 그게 다야. 아무것도 더.
따라서 다음에 작업,버그,기능 요청 및 할 일을 분류하는 데 너무 많은 시간을 할애 할 때는 교칙을 잊어 버려야합니다. 그들은 단지 바보 같은 세부 사항입니다.
30 초 안에 완료 한 계정에 가입하십시오. 카 와이 청에 의해 더 읽고 싶으십니까? 현대 프로그래머에 카 와이의 새 책,개발자의 코드,전자 책 및 인쇄에서 사용할 수 있습니다. 트위터@개발자코드에서 그를 팔로우할 수 있습니다.