전통적인 프로젝트 시작 후 애자일 개발 소개

약 1 년 반 전에 저는 애자일 개발을 주장하는 직장에 들어갔습니다. 내가 배운 것은이 장소가 몇 가지 민첩한 관행 (예 : 일일 스탠드 업, 스프린트 계획 및 스프린트 검토)을 채택했지만 원칙 (시간 / 충분한 정신, 실패, 조기 의사 소통, 풍부한 의사 소통)이 없다는 것입니다.

나는 이제 팀을보다 민첩하게 만드는 임무를 맡았으며 개발자와 비즈니스 팀으로부터의 완벽한 바이 인을 보장 받았다. 시험 프로그램으로, 그들은 15 개월의 요구 사항 수집을 완료하고 110 페이지 분량의 분석 및 디자인 문서 ( "돌로 작성"으로 간주 됨)를 가지고 있으며 끝까지 접근 할 수없는 프로젝트를 내게주었습니다. 사용자 (실제로 제품을 사용하지 않는 사용자 관리자로 구성된위원회에만 해당).

소규모로 시작하여 첫 5 개의 스프린트에 대한 예상 결과물 (미래의 스프린트는 정의되지 않은 상태로 남겨두고), 첫 스프린트의 목표 목록을 제공하고 A & D 문서를 해부하여 첫 스프린트의 목표를 달성 할 수있는 충분한 사용자 스토리를 얻었습니다. .

그 이후로 그들은 우리가 모든 스프린트에 대한 모든 요구 사항을 가지고 있지 않은 이유, 왜 세 번째 스프린트에 대한 작업을 시작하지 않은지 물었습니다 (더 중요하다고 생각하지만 첫 번째 결과물을 기반으로합니다) 스프린트 2 개), 전체 IT 팀이 바쁘거나 업무와 관련이 없다고 생각하는 문서 (예 : 사용자 매뉴얼을 미리 작성하거나 모든 스프린트에서 모든 데이터 필드를 문서화하는 등)를 더 많이 요구하고 있습니다. "선불"작업).

이것은 새로운 프로젝트 관리자로서 매우 거칠었지만 스토리 관리, 페어 프로그래밍 및 비즈니스에 대한 스크럼 반과 같이 효과적으로 구현하여 요구 사항 문서의 일부로 고객 수락 테스트를 앞당겨서 개선했습니다. .

그래서 내 질문은 :

1. 내성 사업에 변화를보다 효과적으로 도입하려면 어떻게해야합니까?
2. 비즈니스에 민첩성의 이점을 보여주기 위해 IT 측에 도입 할 수있는 다른 방법이 있습니까?
3. 문서화의 부담으로 인해 우리는 어려움을 겪고 있습니다. 비즈니스는 여전히 문서를 위험 대신 위험 관리 전략으로보고 있습니다. 문서의 우려와 요구를 완화하기 위해 무엇을 할 수 있습니까 (특히 문서의 수량과 모든 문서에 대한 필요성)?
4. 우리는 약 3 블럭 떨어져있는 사업과는 별개의 건물에 있으며, 사람들이 우리 프로젝트에있는 동안 다른 프로젝트를 수행 할 수없는 프로젝트 공동 거주지에있는 사람들을 거부합니다. 건물." 그들은 우리가 항상 거기에 가서 질문을 묶어 한 번에 모두 물어볼 수 있고 "일정한 중단"으로 그 사람의 시간을 낭비하지 않기를 기대합니다. 우리는 그들로부터 더 풍부한 의사 소통을 얻기 위해 무엇을 할 수 있습니까?

추가 조언도 주시면 감사하겠습니다.

감사!

나는 개발자들과 비즈니스 팀으로부터의 완전한 바이 인을 확신했다. [...] 나는 최종 사용자에게 접근 할 수 없다 ...]

한 가지 분명한 점은 당신이 "인"을 가지고 있다는 것을 구두로 확신하는 것과 다른 한편으로 당신의 일을 후원하고있는 사람 의 실제적인 헌신 과의 차이입니다.

가장 좋은 조언은 "Agile"이라는 레이블을 모두 따로 보관하는 것입니다. 가능한 한 대화에서 단어를 금지하십시오. 대신 다음 사항에 집중하십시오.

• 어떤 결과 를 제공해야하는지 (특히 팀이 아닌)
• 당신의 임무에 대한 성공 기준 은 무엇입니까 (다시 말하지만 팀보다는 당신의 것)
• 어떤 수단 (무엇이든, 사람, 사람들에게 접근, 시간, 정보, 교육 예산 포함)의 처분에 당신이

"팀을보다 민첩하게 만드는 것"은 실행 가능한 목표가 아닙니다. 충분히 구체적이지 않고, 측정 할 수 없으며, 최종 조건이 없습니다. 필요한 것은 특정한 것입니다. 결함이 X % 적거나 기능 제공 날짜의 Y %가 Z 날짜로 표시됩니다.

이러한 목표를 달성하려면 변경을 도입해야 할 수도 있습니다. 이제 몇 가지 규칙이 적용됩니다. 모든 개선 사항은 변경 사항이지만 모든 변경 사항이 개선 된 것은 아닙니다. 사람들은 종종 변화에 저항한다고 말하지만 실제로 사람들 은 변화에 저항 하고 변화가 개선 될지 모릅니다.

쉬운 승리, 낮은 행잉 과일이라고 생각하는 관행에 중점을 둡니다. 변화를 구현하기 위한 것이 아니라 변화 의 영향 을 평가 하고 사람들이 회귀보다는 개선의 결과를 가져올 수 있도록 프레임 워크를 확립하는 관행에 중점을 둡니다 . "정보 라디에이터"는 회고와 마찬가지로 좋습니다.

이러한 변경 중 일부는 핵심 정보를 보유한 사람들에게 더 많은 액세스 권한을 부여하는 것과 같이 필요하고 위협으로 인식 될 수 있습니다. 타협하지 마십시오. "구매"란 양이 정치적 학살을 당하지 않도록 요청받은 것을 실제로 전달할 수있는 협상 과정을 의미합니다.

일이 올바르게 진행되지 않으면 (그리고 아마도 잘못 될 것입니다) 당신에게 책임을 전가하기 어려운 것을 설정하십시오. 이러한 상황이 발생할 수 있다는 점에 유의하고이 상황이 발생하면 준비하십시오 : 이탈 전략을 알아 두십시오.

새로운 것을 매끄럽게 도입하기 위해서는 사람들이 그것을 위협 과 영구적 인 것으로 보지 않도록해야합니다 .

우리 중 많은 사람들이 새로운 것을 피하기 위해 자연스럽게 연결되어 있습니다. 생물학적입니다. 일반적으로 참신을 찾는 사람들은 당신에게 아무런 문제를 일으키지 않을 것입니다. 더 불안한 사람들이 당신의 제안을 현재의 위로에 대한 위협으로 보지 않도록해야합니다.

팀이 실천이나 아이디어를 채택하는 이상적인 방법은 아이디어가 경영진과 같은 외부인이 아니거나 임의의 컨설턴트와 다른 외부인이 아닌 아이디어에서 나왔는지 확인하는 것입니다. 이를 위해 하나의 주제만으로 전체 팀과 브레인 스토밍 회의를 만듭니다. 주제가 문제가되어야합니다. 회의에서 아이디어를 신중하게 제시하고 논쟁과 사실을 제시해야합니다.

우리는 영원한 것들에 대한 결정을 좋아하지 않습니다. 우리는 잠재적 인 변화의 영향으로 이미 불안합니다. 그 행동은 애완 동물 상점에 의해 잘 알려져 있습니다. 개를 사는 것은 매우 큰 결정이며 인생을 근본적으로 바꿀 것입니다. 당신이 가게에있을 때, 세일즈맨은 종종 당신이 그것을 집으로 가져 가고 마음이 바뀌면 그것을 반환하도록 제안합니다. 예상 한대로 반품이 거의 없습니다. 이 제안에는 한 가지 목표 만 있습니다. 사람들이 의사 결정을하지 못하게하는 불안을 줄입니다. 팀 연습에 영향을 평가 한 후 일정 시간 동안 시도해 보라고 제안하십시오.

두 번째 질문에 대해서는 한 번에 한 가지만 가져 오십시오.

귀하의 문서 문제는 P.SE의 자체 게시물이어야하며 둘 다 정기적으로 만나기를 원한다면 두 개의 다른 건물에 있다는 사실에 아무런 문제가 없습니다. 측면 중 하나가 전혀 만나기를 원하지 않는 상황이 있습니다.)

애자일은 모든 사람을위한 것이 아니며, 비즈니스에서 가장 인기있는 유행어이기 때문에 민첩한 말을 좋아하는 것처럼 들립니다. 우선 새로운 프로젝트 나 소규모 유지 보수 프로젝트를 추진하여 프로세스를보다 민첩한 방법론처럼 만들기 시작하는 것이 좋을 것입니다. 이미 진행중인 프로젝트를 사용하여 방법론을 재 설계하는 것은 8 차선 고속도로 중간에 타이어를 교체하는 것과 같습니다. 비즈니스 애자일이 효과를 발휘할 수있는 방법이 필요하지만, 비즈니스 애자일이 작동 할 수있는 환경이 필요하지만, 애자일은 기존 문화와 잘 맞지 않을 것이라고 말한 것에 근거합니다.

문서화를 원하는 대상에 따라, 사용중인 도구에서 자동으로 생성되거나 중복되고 문서 B에 정보 A가 표시하도록 요청한 정보가 있음을 표시 할 수 있습니다. 또한 문서 계획을 조정하고 예상치가 변경되는 이유를 알려주고 요청 된 문서의 양을 줄이거 나 비즈니스 분석가와 같은 리소스를 사용하여 문서를 작성하도록 요청해야합니다.

Since then, they've asked why we don't have all the requirements for all the sprints, why I haven't started working on stuff for the third sprint (which they consider more important but is based off of the deliverables of the first 2 sprints) and are pressing for even more documentation that my entire IT team considers busy-work or un-related to us (such as writing the user manual up-front, documenting all the data fields from all the sprints up front, and more "up-front" work).

그게 네 문제 야 그들은 그것을 얻지 못합니다. 누군가가 당신에게 더 민첩 해 지길 바라지 않고 기꺼이 타려고하지 않습니다. 그들은 잘못된 기대를 가지고 있습니다. 시작하기도 전에 문제가 발생합니다. 기대치를 수정하면 실패합니다. 150 MPH를 운전하라고 요구하는 것과 같습니다.

원하는 문서의 시간 / 자원 / 비용을 바탕으로 일정이 얼마나 멀리 진행되는지 확인하십시오.

이를 통해 프로젝트 팀에게 얼마나 많은 작업을 추진하고 있는지, 그렇지 않은 경우이를 줄일 수있는 방법을 알 수 있습니다.