먼저 다음과 같은 기본 원칙으로 인해 민첩한 프로세스가 작동 할 수 있다고 생각합니다.
둘째, 민첩한 프로세스가 성공하기 위해 필요한 초기 조건이 무엇인지 궁금합니다. 예를 들어 다음이 필요합니다.
성공하려면 무엇이 필요합니까? 이러한 초기 조건 중 일부를 갖지 않는 것이 더 잘 처리되는 다른 Agile 구현이 있습니까?
답변:
애자일 선언문 을 진정으로 그리고 완전히 믿는 비즈니스의 모든 수준의 사람들
우리는 소프트웨어를 수행하고 다른 사람들이 소프트웨어를 개발하도록함으로써 소프트웨어를 개발하는 더 좋은 방법을 발견하고 있습니다. 이 사업을 통해 우리는 가치를 얻게되었습니다.
- 프로세스 및 도구에 대한 개인 및 상호 작용
- 포괄적 인 문서에 대한 작업 소프트웨어
- 계약 협상을 통한 고객 협업
- 계획에 따라 변경에 응답
즉, 오른쪽에있는 항목에는 가치가 있지만 왼쪽에있는 항목은 더 중요하게 생각합니다.
그리고 Agile Manifesto를 믿는다는 것은 모든 Agile Manifesto를 의미 합니다 . 마지막 부분은 무시할 수 없습니다. 오른쪽 항목 에는 여전히 가치 가 있습니다.
프로그래머, 관리자, 고객 등의 직원이 있다면 민첩성 작업을 변형 할 수 있습니다. 당신이하지 않으면, 당신은 투쟁합니다.
최소한
무엇보다도, 당신은 교장을 이해하고 체인을 강요하기에 충분히 믿으며 애자일이 당신의 상황에 적용될 수 있다고 믿는 하향식 스폰서 십을 가져야합니다.
프로세스를 믿지 않는 고위 경영진이 있으면 직원들이 프로세스를 왜곡, 왜곡, 오염, 약화 시키거나 악화시킬 수 있기 때문에 궁극적으로 프로세스를 약화시킵니다.
고위 경영진이 교장을 이해하지 못하면 프로세스를 왜곡하는 지름길과 타협을 요구하기 시작합니다. 그런 다음 상황이 나빠질 때, naysayers는 "내가 그렇게 말했다, 민첩한 작동하지 않습니다!" 죽음의 행진으로 돌아 가기!
이것은 애자일을 채택하지 않는 것보다 나쁩니다. 일반적으로 "Agile But ..."이라고합니다. 경영진은 애자일 (Agile)이라는 용어를 사용하지만 "그러나 ..."는 실제 주체를 모두 버리고 이전에하고 있던 일을 계속 수행하지만 "하지만 ..."는 이제이를 애자일이라고합니다. 그것은 애자일에게 더 잘 모르는 사람들에게 나쁜 이름을줍니다.
좋은 부작용
버그 없음, 자동화 된 테스트, 명확하게 정의 된 개발, 헌신적 인 사람들 등 여러분이 나열한 것은 애자일의 긍정적 인 부작용입니다.
민첩성, 은색 총알 또는 만병 통치약은 아니지만 모든 수준 (고객 <-> 관리 <-> 개발자)에서 투명성 을 촉진 하고 생산성에 문제가있는 사람들을 빠르게 두드러지게합니다. 특히 스크럼과 같은 애자일의 특정 구현.
염두에 두어야 할 몇 가지 사항 :
전문 팀 응집력-개방적인 사람들이 다른 사람들과 잘 어울릴 수 있습니까? 그들은 일에 자율권을 부여 할 수있는 성숙하고 책임감있는 사람들입니까?
커뮤니케이션 문화 및 정책-사람들이 조직에서 우려, 생각 및 의견을 얼마나 잘 표현합니까?
애자일이 무엇인지 아닌지 이해-외부 이해 당사자들은 자신의 책임을 받아들이는 프로세스에 대해 충분히 알고 있습니까? 그렇지 않다면, 이것은 의사 민첩성을 만들 수 있습니다. 마찬가지로 일부 항목을 구성 할 수 있도록 명확하게 정의 된 제품 소유자 및 ScrumMaster가 있습니까?