1. Call it Agile. Make it haphazard. 우연하게 결국 애자일은 “계획 없음”을 의미하지 않을까?
2. Ignore architecture. 애자일이 요구 사항이 지속적으로 진화한다는 것을 의미한다면 애플리케이션 아키텍처도 지속적으로 진화 해야 하지 않을까?
3. The answer is Scrum. What was the question? 애자일은 방법론이 아니다. 그것은 각각 다른 종류의 프로젝트에 적합한 방법론의 집합 이다. 스크럼은 “모범 사례”이기 때문이 아니라 가장 견고하게 구조화 된 민첩한 변형이기 때문에 가장 인기 있는 것이다. Scrum은 IT가 수행하는 대부분의 프로젝트를 구성하는 상용 소프트웨어 (COTS) 및 SaaS(Software as a Service) 구현에 적합하지 않다. 다른 Agile 변형, CRP(회의실 파일럿) 또는 ATTD(근접 수용 테스트 주도 개발)가 더 나은 대안일 수 있다.
4. Play leapfrog — from Waterfall to SAFe in a single bound. SAFe가 비즈니스에 필요한 것이라면 SAFe는 IT가 수행 할 일이며 단일 경계에서 Waterfall-to-SAFe 틈을 뛰어 넘어 위험을 염두에 두지 말아야 한다.
5. Insist your development partners use Agile. Also insist they agree to fixed price bids. 개발 파트너가 Agile을 사용하도록 해야 한다. 또한 고정 가격 입찰에 동의한다고 주장함.
6. Offshore agile. 개발 파트너와 협력 할 때 대부분의 팀 구성원의 시간대 및 언어 문제를 해결 해야 한다.
7. Make it all about process. Agile Manifesto가 “프로세스와 도구보다 개인과 상호 작용”을 중요시 한다
애자일로 전환을 방해하는 7가지 방법
– 출처:디지털엑스원 정우진 대표
