Key Conception 을 응용 하여 민첩 한 소프트웨어 개발 을 진행 하 다

더 읽 기
며칠 전 회사 에서 외국인 강 의 를 들 었 는데 내용 과 제목 이 똑 같 습 니 다. Key Conception 을 활용 하여 민첩 한 소프트웨어 개발 을 했 는데 수확 이 있 는 것 같 습 니 다. 꺼 내 공유 하 세 요.프로젝트 를 시작 할 때 가장 먼저 해결 해 야 할 두 가지 문 제 는 '이 프로젝트 가 어떤 특성 을 실현 해 야 하 는가' 와 '어떤 특성 을 우선적으로 완성 해 야 하 는가, 어떤 것 을 나중에 완성 할 수 있 는가' 이다.우리 가 이 두 가지 문 제 를 해결 하지 않 으 면 전체 프로젝트 의 전개 가 매우 혼 란 스 러 워 지고 '다음 단계 에 무엇 을 해 야 할 지', '오 노, 지금 보 니 그 특성 을 먼저 해 야 할 것 같다' 는 것 에 시간 을 소모 할 것 이다.주관 의 억측 을 통 해 잘못된 결정 을 초래 할 수 있 기 때문에 우 리 는 이 두 가지 문 제 를 해결 하 는 데 더욱 효과 적 인 도구 가 필요 하 다.
만약 에 우리 가 Feature List 로 '실현 하고 자 하 는 특성' 을 표시 하고 이러한 특성 이 완 성 된 순 서 를 우선 순위 로 표시 한다 면 실제 적 으로 우 리 는 아래 의 표를 통 해 프로젝트 에 대해 더욱 잘 계획 할 수 있 도록 도와 줄 수 있다.
Feature\Key Conception
KC(1)
KC(2)
…...
KC(n)
SUM
Feature-1
Feature-2
….
Feature-n
Key Conception [앞으로 KC 로 약칭] 이 무엇 인지 소개 하 겠 습 니 다. 저 는 Key Target 이 라 고 부 르 는 것 이 더 적합 하 다 고 생각 합 니 다. 프로젝트 목 표를 달성 하 는 관건 적 인 요소 나 프로젝트 의 최종 품질 에 영향 을 주 는 관건 적 인 조건 을 의미 합 니 다.한 항목 에 당연히 여러 개의 KC 가 있 을 것 이다. 그들 은 프로젝트 가 실현 하고 자 하 는 특성 과 우선 순위 에 영향 을 주 는 관건 적 인 요소 이다.다음은 핸드폰 QZone 프로젝트 를 예 로 들 어 이 표를 어떻게 활용 하여 본 고가 해결 하고 자 하 는 두 가지 문 제 를 확정 하 는 데 도움 을 줄 수 있 는 지 설명 한다.
이것 은 인터넷 QZone 의 기능 을 핸드폰 으로 옮 기 는 프로젝트 입 니 다. 우 리 는 이 프로젝트 의 KC 가 이미지 품질, UI 체험 감, 다운로드 속도 가 있다 고 생각 합 니 다.실현 해 야 할 특성 이 너무 많 습 니 다. 여기 도 일부분 만 열거 되 어 있 습 니 다.
(1) 플래시 로 멋 진 효 과 를 완성 하기;
(2) 한 버튼 으로 모든 작업 을 완성 합 니 다.
(3) Context Sensitive 기능 [즉, 소프트웨어 현재 상태의 Context 를 통 해 사용자 의 현재 조작 의 도 를 판단 할 수 있 음]
(4) 필요 에 따라 테 마 를 다운로드 합 니 다. [즉, 일회 성 이 아니 라 필요 에 따라 해당 하 는 테마 데 이 터 를 다운로드 합 니 다.]
잠깐 만...
표를 작성 하 는 규칙 은 특정한 특성 이 특정한 KC 에 특히 유리 하 다 면 2 점, 보통 1 점, 괜 찮 습 니 다. 0 점, 반작용 - 1 점, 특히 이 KC 에 불리 하면 - 2 점 을 주 는 것 입 니 다.마지막 으로 각 줄 의 총 점 을 계산 하면 도대체 그런 일 을 해 야 하 는 지, 그리고 이런 일의 선후 순 서 를 명 확 히 할 수 있다.우리 의 예 를 다 쓴 후에 다음 과 같다.
Feature\Key Conception
영상 품질
UI 체험 감
다운로드 속도
SUM
플래시 로 쿨 링 효과 완성
2
0
-2
0
하나의 버튼 으로 모든 작업 을 완료 합 니 다.
0
1
0
1
Context Sensitive 기능
0
2
0
2
필요 에 따라 테마 다운로드
-1
0
2
1
조금 만 설명해 주세요. 첫 줄 에 플래시 를 사용 하면 당연히 효과 가 좋 습 니 다.하지만 휴대 전화 에 있어 서 는 큰 시련 이다. 현재 무선 다운로드 속 도 는 정말 칭찬 할 수 없 기 때문이다. 아직 다운로드 하지 않 은 사용자 의 절반 이 귀 찮 은 지 이런 점수 다.두 번 째 줄 에 대해 핸드폰 클 라 이언 트 가 매우 기괴 하기 때문에 한 소프트웨어 가 절대 다수의 핸드폰 을 받 아들 이 고 모 으 려 면 조작 을 간소화 하고 더 적은 버튼 으로 가능 한 한 많은 조작 을 완성 해 야 한다. 그래서 두 번 째 Feature 는 사용자 의 사용 이익 에 부합 되 지만 다른 두 개의 KC 와 아무런 관련 이 없다.OK. 이로써 우 리 는 최종 점수 에 따라 어떤 특성 이 제한 적 으로 실행 되 어야 하 는 지 결정 할 수 있 습 니 다. 특히 당신 의 특성 목록 이 수백 개 일 때.또 직관 적 감각 에 지나치게 의존 해 잘못된 결정 을 내 릴 확률 도 줄 일 수 있다.이러한 가치 가 대응 하 는 것 은 Key Conception 이기 때문에 결정 하 는 순 서 는 객관 적 이 고 주도면밀 하 며 프로젝트 의 전체적인 목표 와 이익 에 부합 하 는 것 이다.
여기 서 의 예 는 매우 간단 하지만 진정 으로 조작 하 는 것 도 이렇게 쉬 운 것 은 아니다. 세 계 는 다양 하고 문제 가 끊임없이 발생 하기 때문에 이런 간단 한 시계 로 는 목적 을 완전히 달성 하지 못 할 때 가 있다. 이 럴 때 는 반드시 조정 을 해서 우리 의 수요 에 적응 해 야 한다.예 를 들 어 우 리 는 프로젝트 의 모든 특성 이 실현 난이도 가 다르다 는 것 을 알 고 있 습 니 다. 난이도 도 특정한 특성 우선 순 위 를 결정 하 는 관건 적 인 요소 이기 때문에 우 리 는 목표 의 마지막 에 열 을 더 해서 모든 Feature 의 난이 도 를 기록 해 야 합 니 다.
Feature\Key Conception
KC(1)
KC(2)
......
KC(n)
SUN
Difficulty
Feature-1
Feature-2
….
Feature-n
최종 적 으로 순 서 를 정할 때 경험의 원칙 은 동등 점수의 피 처 스에 서 어떤 어 려 운 부분 을 우선 하 느 냐 에 달 려 있어 야 흐름 을 따라 내 려 오 거나 맹호 가 하산 하 는 기 세 를 가 질 수 있다.먼저 간단 한 후작 을 고 르 는 것 이 어 려 운 것 은 팀 의 사기 에 영향 을 미 칠 수 있 고 프로젝트 에서 끊임없이 정상에 오 르 는 것 은 현명 하지 못 하 다.그 밖 에 KC 마다 중요성 이 다 를 수 있 기 때문에 점 수 를 매 길 때 서로 다른 KC 에 대해 서로 다른 우선권 을 가지 고 그 중요 도 를 다시 나타 내 는 것 도 총 점 에 영향 을 미 칠 수 있다.그러나 '과 유 불 급' 이기 때문에 너무 복잡 하 게 하지 않도록 해 야 한다.
또 다른 예 는 하나의 큰 프로젝트 에 대해 우리 의 Feature List 는 수백 개가 있 을 수 있다 는 것 이다. 이런 것들 을 한 장의 표 에 넣 으 면 특성의 바다 에 묻 혀 헤 어 나 지 못 하고 지혜 롭 지 못 하 다 는 것 이다.이때 우 리 는 Outline Feature List 를 제시 하여 관건 적 이 고 추상 적 인 특성 을 배치 하고 이 강령 적 인 표를 이용 하여 먼저 대체적인 범 위 를 결정 할 수 있다.그 다음 에 모든 세분 화 된 작업 을 할 때 모든 추상 적 인 Feature 에 대해 Detail Feature List 를 표시 합 니 다. 이렇게 하면 간단 하면 서도 뚜렷 하기 때문에 너무 긴 특성 목록 에 대해 걱정 할 필요 가 없습니다.
Outline Feature List[OFL]
Feature\Key Conception
KC(1)
…...
KC(n)
SUM
Difficulty
Detailed Feature List
Feature-1
DFL [1] 이곳 의 모든 항목 은 OFL 과 같은 형식의 표 로 목적 과 내용 이 다 를 뿐이다.
….
DFL[2]
Feature-n
DFL[n]
그 밖 에 토론 할 만 한 문제 도 많 습 니 다. 실제 업무 에서 우 리 는 이 표를 유연 하 게 조정 하고 새로운 구조 와 새로운 의 미 를 부여 하여 실제 프로젝트 의 수요 에 적응 할 수 있 습 니 다. 그러나 중요 한 원칙 은 너무 복잡 하지 않 고 이 도 는 스스로 파악 해 야 합 니 다.
내용 은 여기까지 입 니 다. 하지만 CSDN 의 Blog 를 신고 하 세 요. Blog 와 미리 보 기 를 쓸 때 표 는 좋 았 지만 홈 페이지 에 올 라 온 결 과 는 자동 으로 단락 마다 들 여 쓰 기 를 해서 표 형식 이 엉망 이 되 었 습 니 다. 해결 하고 싶 습 니 다.