적어도 내 경험상 "민첩 해 지려고" 하는 매우 일반적인 팀의 패턴 을 설명합니다. 이것이 실제로 애자일 자체의 일부이거나 일반적인 잘못 구현 된 것인지, 민첩한 선언 / 원칙 또는 그 고유 한 결과에 어긋나는 지 여부에 대해서는 논쟁의 여지가 있습니다. 경험적 관점에서 볼 때 내 자신의 작은 샘플 경험 세트 (및 내가 이야기하는 사람들)를 기반으로 팀이 민첩한 경우이 패턴을 겪을 가능성이 평균보다 높습니다. 그것을 그대로두고 구체적인 예에 초점을 맞추자.
설명하는 내용 에는 두 가지 측면 이 있습니다.
- 공통된 이해 / 비전 누락으로 비효율적
- 성공 / 진행 및 총 비용을 측정하는 방법
잘못된 길을 가거나 서클에서 달리기
필자의 경험에 따르면, 이런 일이 발생하는 주된 이유 는 코드를 빠르게 생성하기 위해 팀이 이미 알고 있거나 쉽게 알아낼 수있는 사용 사례 나 요구 사항을 적극적으로 제쳐두고 있기 때문 입니다. 10-20 년 전에 사람들은 거대한 사양을 작성하려고 시도했고 모든 것을 미리 생각했지만 종종 실패했습니다. 그들은 너무 오래 걸렸거나 무언가를 간과했습니다. 과거에 배운 것 중 하나는 소프트웨어 개발에 알 수없는 것들이 많고 많은 것들이 바뀌기 때문에 빠르게 반복하고 합리적인 출력을 빠르게 생성한다는 아이디어입니다. 이것은 매우 좋은 원칙입니다. 그러나 오늘날 우리는 또 다른 극단적 인 상황에 처해 있습니다. "이것은 다음 스프린트의 일부이기 때문에 신경 쓰지 않습니다"또는 "그 버그를 제기하지 않습니다. 다시 발생할 때 처리합니다."
- 찾을 수있는 모든 고급 사용 사례 , 요구 사항, 종속성 및 제한 사항을 수집하십시오 . 모든 이해 관계자와 개발자가 볼 수 있도록 위키에 넣으십시오. 새로운 것이 나올 때 추가하십시오. 주주 및 사용자와 대화하십시오. 최종 제품에 기여하지 않거나 한 가지 문제를 해결하지만 세 가지 새로운 문제를 야기하는 해결 방법 / 해킹을 구현하지 않도록 개발 하는 동안 이 검사 목록을 검사 목록 으로 사용하십시오 .
- 높은 수준의 개념을 공식화하십시오 . 인터페이스 또는 클래스 디자인에 대해 이야기하는 것이 아니라 문제 영역을 대략적으로 스케치합니다. 최종 솔루션의 주요 요소, 메커니즘 및 상호 작용은 무엇입니까? 귀하의 경우 jquery 해결 방법을 중간 단계로 사용하고 추가 작업 만 발생시키는 경우를 분명히해야합니다.
- 수집 한 목록을 사용 하여 개념 을 검증하십시오 . 명백한 문제가 있습니까? 말이 되나요? 오랜 기술 부채를 유발하지 않으면 서 동일한 사용자 가치를 달성 할 수있는보다 효율적인 방법이 있습니까?
과용하지 마십시오. 개발자가 아닌 사람을 포함하여 팀의 모든 사람이 MVP로가는 최선의 경로가 무엇인지 공통적으로 이해하도록해야합니다. 모든 사람은 명백한 감독이 없으며 실제로 작동 할 수 있다는 데 동의해야합니다. 이것은 일반적으로 막 다른 골목으로 내려가거나 같은 것을 여러 번 다시 실행하는 것을 방지합니다. 애자일은 예상치 못한 상황을보다 잘 처리 할 수 있도록 도와줍니다. 알려진 것을 무시하는 것은 아닙니다.
의주의 침몰 선정-착오 : 한 아키텍처 또는 데이터베이스 유형으로 시작하는 경우, 대부분의 사람들은 중간 프로젝트 변경 주저한다. 따라서 물건을 구현하기 전에 "교육받은 최고의 추측"을하는 데 시간을 투자하는 것이 좋습니다. 개발자는 코드를 빠르게 작성하려는 경향이 있습니다. 그러나 종종 몇 가지 모형, 라이브 프로토 타입, 스크린 샷, 와이어 프레임 등이 있으면 코드 작성보다 더 빠른 반복이 가능합니다. 작성된 모든 코드 줄 또는 단위 테스트로 인해 전체 개념을 다시 변경하기가 더 어려워집니다.
성공 측정
완전히 별개의 측면은 진행 상황을 측정하는 방법입니다. 프로젝트의 목표는 주위에있는 물건을 사용하여 높이가 1m 인 타워를 만드는 것입니다. 예를 들어 시장 출시 시간이 안정성보다 중요한 경우 카드 하우스를 구축하는 것이 완전히 유효한 솔루션이 될 수 있습니다. 목표가 지속되는 것을 만드는 것이 레고를 사용하는 것이 더 좋을 것입니다. 요점은 해킹으로 간주되는 것과 우아한 솔루션이 프로젝트의 성공을 측정하는 방법에 전적으로 의존한다는 것 입니다.
"로드"에 대한 귀하의 예는 꽤 좋습니다. 나는 과거에 모든 사람들 (판매, PO, 사용자 포함)이 성가신 것에 동의 한 적이 있습니다. 그러나 그것은 제품의 성공에 영향을 미치지 않았으며 장기 부채를 유발하지 않았습니다. 개발자 리소스와 관련하여 더 가치있는 일이 있었기 때문에 삭제했습니다.
내 조언은 다음과 같습니다.
- 작은 버그라도 모든 것을 티켓 시스템의 티켓으로 유지하십시오 . 프로젝트 범위 내에있는 것과 그렇지 않은 것을 적극적으로 결정하십시오. 마일스톤을 생성하거나 백 로그를 필터링하여 항상 수행해야하는 모든 항목의 "완전한"목록을 갖도록하십시오.
- 프로젝트가 성공으로 간주 될 수 있는 엄격한 중요성과 명확한 차단 점 을 확보하십시오. 최종 제품에는 실제로 어느 정도의 안정성 / 코드 품질 / 문서가 필요합니까? 맨 위에서 선택하여 가능한 한 매일 최선을 다하십시오. 하나의 티켓으로 작업 할 때 새로운 티켓을 소개하지 않고 티켓을 완전히 해결하십시오 (우선 순위가 낮아서 사후에 게시하는 것이 합리적이지 않는 한). 모든 커밋은 당신을 옆으로 또는 뒤로가 아니라 최종 목표를 향해 앞으로 나아갑니다. 그러나 다시 강조하기 위해 : 나중에 추가 작업을 생성하는 해킹이 여전히 프로젝트에 순전히 긍정적일 수 있습니다!
- PO / 사용자를 사용하여 사용자 가치를 파악하고 개발자에게 기술 비용을 계산하도록 합니다. 비 개발자는 일반적으로 실제 장기 비용 (구현 비용뿐만 아니라)이 무엇인지 판단 할 수 없으므로 도움이됩니다. 비등 개구리 문제에주의하십시오 : 시간이 지남에 따라 많은 관련이없는 작은 문제들이 팀을 정지시킬 수 있습니다. 팀이 얼마나 효율적으로 작업 할 수 있는지 정량화하십시오.
- 전반적인 목표 / 비용을 주시하십시오. 스프린트에서 스프린트로 생각하는 대신 "팀이 프로젝트가 끝날 때까지 필요한 모든 것을 할 수 있을까"라는 사고 방식을 유지하십시오 . 스프린트는 단지 문제를 해결하고 체크 포인트를 갖는 방법입니다.
- 조기에 무언가를 보여주고 싶지는 않지만 사용자에게 제공 할 수 있는 최소한의 가능한 제품으로가는 가장 빠른 길에 코스를 구성하십시오 . 그럼에도 불구하고 전반적인 전략은 그 사이에 검증 가능한 결과를 허용해야합니다.
따라서 누군가가 최종 구현 목표에 맞지 않는 일을 할 때 이상적으로 이야기를 고려하지 마십시오. 스토리를 닫는 것이 유익한 경우 (예 : 고객의 의견을 수렴) 즉시 새로운 스토리 / 버그를 열어서 부족한 문제를 해결하십시오. 지름길을 가져가더라도 비용이 절감되지 않고 숨기거나 지연시킬 수 있습니다.
여기서의 비결은 프로젝트의 총 비용에 대해 논쟁하는 것입니다. 예를 들어 PO가 기한을 정하기 위해 지름길을 강요하는 경우 프로젝트 완료를 고려하기 위해 이후에 수행해야 할 작업량을 수량화하십시오!
또한 기준 기반 최적화에 주의 하십시오. 팀이 스프린트 검토에서 보여줄 수있는 스토리 수로 측정되는 경우 좋은 "점수"를 달성하는 가장 좋은 방법은 모든 스토리를 10 개의 작은 스토리로 자르는 것입니다. 작성된 단위 테스트 수에 의해 측정되는 경우, 불필요한 많은 테스트를 작성하는 경향이 있습니다. 이야기를 세지 말고, 필요한 사용자 기능이 얼마나 작동하는지, 프로젝트 범위 내에서 기술 부채로 해결해야 할 비용이 얼마나 큰지 등을 측정하십시오.
개요
요약하자면, 빠르고 최소한으로하는 것이 좋은 방법입니다. T 그는 문제는 "빠른"해석하고 "최소"입니다. 장기 비용을 고려해야합니다 (이 프로젝트와 관련이없는 프로젝트가 아닌 한). 배송일로부터 1 개월 만 걸리지 만 기술 부채가 발생하는 바로 가기를 사용하면 회사에 1 주일이 소요되는 솔루션보다 많은 비용이 듭니다. 즉시 테스트 작성을 시작하는 것이 빠른 것 같지만 개념에 결함이 있고 잘못된 접근법을 구체화하는 경우에는 그렇지 않습니다.
그리고 당신의 경우에 "장기"가 의미하는 바를 명심하십시오 : 나는 훌륭한 코드를 작성하여 파산하여 너무 늦게 배송 된 한 개 이상의 회사를 알고 있습니다. 회사의 관점에서 보면 좋은 아키텍처 또는 깨끗한 코드는이를 달성하는 데 드는 비용이 그렇지 않은 경우보다 적은 경우에만 유용합니다.
희망이 도움이됩니다!