애자일로 성공하려면 무엇이 필요합니까?

일부 조직에서는 민첩한 채택이 실패 할 수 있습니다. 폭포가 유일한 (진정한) 방법이지만 프로젝트에서 민첩을 시도했지만 실패한 회사에서 일하기도했습니다.

내가 (후배 였음을) 아직도 기억했던 사람들에게 물었을 때, 나는 그들에게 실제로 일어난 나쁜 악몽을 상기시키는 것처럼 열심히 폐쇄되었습니다.

프로젝트가 실패한 이유를 모르겠습니다. 웹에서 애자일이 실패한 이유는 일부 회사이지만, 그 이유는 대부분 경제적 인 자료가 있습니다. 그래서 나는 여기에 약간의 피드백을 요구한다고 생각했다.

일부 조직에서 애자일 채택이 실패하는 이유는 무엇입니까? 아니면, 또 다른 방법으로 .. 애자일과 함께 성공하려면 무엇이 필요합니까?

민첩한 사고 방식과 민첩한 방법을 이해하고 지원하려면 관리, 고객 및 개발자가 필요합니다. 더 자세하게:

• 경영진은 전통적으로 듣고 싶어하는 것과는 반대로 진실을 듣는 데 편안해야합니다 (예 : "예, 프로젝트가 제대로 진행되고 있음"(11 개월 동안)). ... 음, 몇 달 ... 음 ... " 또한 각 당사자가 자신의 직무를 수행하고 책임을지게하는 데 편안해야합니다. 가장 중요한 것은 개발자가 기술적 결정과 추정을해야한다는 것입니다. 따라서 철저한 제어 및 미세 관리가 필요하지 않습니다.
• 고객은 애자일이 "주문 만들기"뿐만 아니라 몇 개월 후에 배송을 받기 위해 개발 프로세스에 깊이 있고 지속적으로 참여해야한다는 것을 이해해야합니다. 또한 큰 고정 요구 사항 사양이없고 개발 팀이 처음 요청한 내용을 전달하겠다는 약속이 부족하여 편안해야합니다.
• 개발자는 책임감, 의사 결정, 공개 의사 소통 및 팀 작업에 익숙해야합니다. 즉, "코드 소유권", "외로운 카우보이"및 팀 자체로 해결할 수있는 문제에 대해 다른 사람들을 결실없이 비난하지 않습니다.

내 경험상, 그것은 가장 자주 실패한 애자일 프로젝트 뒤에 놓인 첫 번째 요점이지만, 다른 두 가지도 문제를 일으킬 수 있습니다.

최신 정보

"관리"란 직접 프로젝트 관리자뿐만 아니라 더 높은 수준을 의미합니다. @Michael이 매우 올바로 언급했듯이, 일부 외부 당사자 (예 : QA 또는 외부 작업 할당 자)도 Agile 프로젝트의 성공 / 실패에 영향을 줄 수 있지만 해당 리더가 허용하는 경우에만 가능하다고 가정합니다. 또는 조직 내에서 책임과 명령 줄이 명확하지 않은 경우.

당신이 필요합니다 :

• 매우 개방적이고 정직한 사람 . 가시성은 모든 종류의 계층 경계에서 신뢰가 필요하기 때문에 모든 것입니다.
• 고객과 관리자 정말 진실을 듣고 싶어.
• 현재 필요한 것에 맞게 기꺼이 자신의 역할을 재정의 할 수있는 사람들 .
• 현재 작동하지 않는 프로세스를 자유롭게 변경할 수 있습니다 .
• 실수를 기꺼이 인정 하고 반대하는 사람들 .
• 빌드 및 테스트 환경 을 마음대로 던질 수있는 기능 . (이것은 사람들이 신용을주는 것보다 더 중요하고 비싸다.)
• 벽을 채울 수있는만큼의 화이트 보드.

매우 간단 해 보이지만이 산업에서는 많은 것들이 요구됩니다.

애자일 프로젝트는 주요 플레이어가 애자일을 거부하거나 프로젝트의 성공에 대한 관심이 없거나 프로젝트를 완전히 방해하는 경우에 더 자주 실패합니다. 후자는 어떤 다른 프로젝트와 마찬가지로 프로젝트를 죽일 수 있지만 민첩한 프로세스는 사람들에게 더 많은 유연성을 제공하며 파괴적인 정치를 재생하는 유연성을 포함합니다.

예 :

• QA는 한 달 동안의 수동 테스트주기를 통과하지 않으면 고객이 소프트웨어를 볼 수 없다고 주장합니다.
• 관리는 비현실적인 마감일을 부과합니다
• 고객이 요구 사항의 우선 순위를 거부합니다 ( " 모두 우선 순위가 가장 높습니다!")
• 즉각적인 이해 관계자는 아니지만 정치적 영향력을 가진 사람은 키 팀원에게 길고 관련없는 작업을 계속 할당하므로 프로젝트 관리자는이를 막을 수 없습니다.

나는 내 개인적인 경험을 통해서만 조언을 줄 수 있습니다.

Agile에서 한 명의 고용주가 완전히 실패했습니다. 작업은 임시로 수행되었으며 테스트는 없었으며 요구 사항은 전자 메일 및 회의록에 문서화되었습니다. 사용 된 유일한 개발 방법은 무정부 상태 또는 '불을 잊어 버린 코딩'이었습니다. 개발자들이 너무 많은 이야기 추적 프로젝트 관리 소프트웨어를 설정하기에는 너무 많은 소프트웨어 엔지니어링 방법을 구현하는 것이 불가능했을 것입니다.

또 다른 고용주에서 우리 팀은 애자일 모범 사례를 수립하기 위해 필사적으로 노력한 영웅적인 멤버를 가졌습니다. 우리는 Kanban 보드, 이슈 트래킹, TDD 및 BDD를 사용했습니다 (Agile 자체는 아니지만 Agile 그룹에있는 경향이 있음) . 불행히도 우리는 스토리 포인트, 추정 세션, 용량 계획, 번 다운 차트, 속도 그래프 등 작업이 원활하게 진행될 수있는 유용한 민첩한 프로젝트 관리 도구와 같은 것들이 부족했습니다. 우리의 Kanban 보드가 너무 가득 차면 Agile이 잘못되는 전형적인 증상으로 더 큰 보드를 구입했습니다.

내가 현재있는 곳은 2 주 반복, TDD, 일일 스탠드 업, 반복 별 타임 박스 회고 및 대부분의 작업에 대한 쌍 프로그래밍으로 용량 계획을 세우는 방법으로 스토리 포인트를 사용합니다. 이는 전체 관리 바이 인 및 고객 교육의 결과입니다.

애자일이 회사에서 성공하기 위해서는 다음 사항이 필요하다고 생각합니다.

• Agile을 이해하고 도구를 적절하게 사용하는 프로젝트 관리자
• 애자일을 이해하고 개방적이고 정직하며 애자일을 이해하는 개발자
• 클라이언트에서 바이 인. 그들은 Agile의 이점을 인식하고 주어진 시간 내에 개발 될 수있는 것에 관해 개발자의 조언을 기꺼이 들어야합니다.

편집 : 또한 매일 스탠드 업 및 짧은 반복과 같은 것들이 유용한 이유에 대해 잘 이해하는 것이 중요합니다.

민첩한 실패에 대한 나의 경험은 경제와 관련이 없지만 기업 / 부서 / 개인 정치와 관련이 있습니다.

개인적인 차원에서, 성격이 충돌 할 사람들이 있습니다. 그것들을 애자일 팀이나 심지어 짝을 이룬 프로그래밍 팀으로 강제로 강요하면 서로 싫어하는 점이 끓는점으로 올라갑니다. 이것은 매우 불쾌하고 매우 빠르게 이루어지며 리얼리티 쇼에 합당한 방해 행위와 같은 일을 일으켜 스크럼 회의를 비난의 원형 발사 반으로 만들거나 심지어 더 나빠질 수 있습니다.

그 위에는 개발 관리가 있습니다. 나는 이것이 두 가지 다른 방식으로 잘못되는 것을 보았습니다.

첫 번째는 '카고 컬트 애자일 (Cargo cult Agile)'인데, 관리자는 왜, 언제, 언제 사용하는지, 즉흥 연주를하는 이유를 이해하지 않고 선언문과 클래스 / 도서 / 웹 사이트를 정확히 읽도록 요구합니다. 마치 애자일 관리자가 마법을 정확히 따르기 때문에 마법이 일어나기를 기다리는 것 같습니다. 이러한 민첩한 구현은 프로젝트 실패로 이어질 많은 문제를 야기 할 수 있습니다.

다른 하나는 스프린트 및 스크럼과 같은 용어가 사용되는 'Agile In Name Only'이지만 실제로는 소액 관리, 부정직 한 명령 체계 위아래로 이동하는 부정직, 오래 쓸모없는 상태 회의 및 기타 물건과 같은 오래된 관행에 대한 레이블입니다. . 프로젝트는 예전처럼 실패하지만 이제는 애자일은 관리가 열악하지 않고 비난받을 수 있습니다.

그 이상은 프로젝트의 고객 / 고객에 의한 바이 인 부족입니다. 이 사람들은 부서별 우선 순위를 가지고 있으며 경영진이 업무의 필수 부분이라는 것이 명확하지 않은 경우 개발 팀과의 협력에 저항 할 수 있습니다. 이는 부서의 정치 나 기업 정책에 의해 악화 될 수 있습니다. 예를 들어, 운영과 마케팅 모두 프로젝트에 투입되어 양측이 아무것도 동의 할 수 없기 때문에 팀이 바퀴를 돌리게됩니다. 또 다른 예는 시간 관리 및 청구에 대한 회사 정책으로 인해 충돌이 발생하는 경우입니다. 실제로 외부 고객이 내부 고객보다 다루기가 더 쉽다는 것을 알았습니다. 그들은 그 과정에서 얻은 관심을 좋아했고 그들이 돈의 가치를 얻고 있다는 것을 알고있었습니다.

관행을 도매로 매입하지 않으면 IMO "Agile"이 실패합니다. 내 말은 애자일은 다음을 이해하는 "고객"(일반적으로 다른 부서 또는 관리자)에 의존한다는 것입니다.

1. 그들은 생각한다고해도 소프트웨어가 원하는 것을 100 % 모른다
2. 그들은 생각하는 경우에도 완료하는 데 시간이 얼마나 걸릴지 모른다
3. 그들은됩니다 말 은 걸릴 것과 이용 약관을 읽고 동의를해야하며 시간을 줄일 기한을 충족하는 기능을
4. 반복 할 때마다 기능을 선택 해야하며 한 번에 전체 100 % 완전한 응용 프로그램을 얻을 수 없습니다 .

이 모든 것은 대부분의 관리자가 삼키기가 매우 어려운 일이며, IMO가 애자일을 수행하기 어려운 첫 번째 이유입니다. 관리자는 "x 날짜로 완료됩니다"라고 말하고 해당 날짜까지 "마 법적으로"처리하는 데 익숙합니다. (개발자가 80 시간을 투자 한 후) 개발팀 이이 프로젝트가 3 개월 안에 완료 될 것임을 알리 겠다는 사실을 깨달은 것은 180도이며, 프로젝트를 수락하거나 요구 사항을 줄이는 것이 유일한 선택입니다. 더 빨리 끝났다.

둘째, 개발팀을 신뢰해야합니다. 위의 # 1과 손을 잡으면 관리자로 고용 된 사람들의 의견을 신뢰하는 관리자는 거의 없습니다. 개발자가 프로젝트에 x 시간이 걸리고 x가 경영진이 생각하는 것보다 더 많다고 말하면 "소프트웨어를 작성하는 방법을 모르므로 개발자가 옳을 것입니다"라는 사례는 결코 아닙니다. 아무것도없는 개발자들은 직장에서 쉬고 싶어서 3 개월이 걸릴 것이라고 말했다.

셋째, 개발 팀은 애자일을 지원해야합니다. 그것은 구석을 자르지 않고 "이것이 맞습니까? x가 일어날 때 Y는 어떻게해야합니까?"라는 끊임없는 피드백과 질문을 무시하지 않는 것을 의미합니다. TDD 또는 페어 프로그래밍을 따르지 않더라도 개발 팀은 민첩한 프로세스 (예 : 스프린트, 반복)를 수행 할 수있는 능력이 있어야합니다. 여기에는 작업을 올바르게 평가할 수있는 리드 / 관리자가 있어야하며 모든 기능을 우선 순위로 둘 필요가 없으며 작업에 대한 백 로그를 작성하는 것이 좋습니다.