개발 중반에 개발 사양이 변경되는 것을 막는 방법은 무엇입니까?

문제점 : 개발을 시작하기 전에 계획하는 데 시간이 얼마나 걸리더라도 프로젝트의 중간 또는 끝 부분에 항상 많은 양의 변경이 필요합니다. 이들은 종종 많은 재개발이 필요한 큰 변화입니다.

나는 돈을 지불하는 고객을 위해 일하지 않습니다. 이것은 사내 개발 웹 사이트의 사내 개발 팀입니다. 따라서 비용을 청구 할 수있는 것은 아닙니다. 그리고 마지막 날에는 마감일을 맞추려고 노력해야합니다.

질문 : 사양 변경이 개발 도중 또는 개발 후에 최소화되는 것을 최소화하고 방지하는 가장 좋은 방법은 무엇입니까?

헬무트 폰 몰케 (Helmut von Moltke)는 "군대와의 접촉에서 살아남는 전투 계획은 없다"고 유명한 군대의 말이있다. 같은 맥락에서, 당신이 미래를 예측하고 이해 관계자의 마음을 읽을 수 없다면 (아직도 마음이 만들어지지 않았을지라도) 변경 될 필요가없는 사양을 만드는 것이 불가능하다고 생각합니다 그들은 주장했다). 대신 여러 가지 방법으로 접근하는 것이 좋습니다.

1. 변경할 수있는 것과 변경할 수없는 것을 명확하게 구분하십시오. 이해 관계자에게 명확하게 전달하고 가능한 빨리 변경 불가능한 사항에 대해 명시 적으로 사인 오프하도록하십시오.
2. 미리 변경을 준비하십시오. 변경 가능한 부품을보다 쉽게 ​​변경하고 구성 가능성에 투자하고 부품을 독립적으로 변경 및 교체 할 수있는 프로토콜을 정리하는 코드 방법을 사용하십시오.
3. 이해 관계자와 자주 대화하고 피드백 및 승인을 요청하십시오. 이렇게하면 동기화 상태를 유지하고 너무 늦었을 때 "오, 그것이 우리가 원하는 것이 아닙니다"라고 주장하는 것을 피할 수 있습니다. 다른 답변에서 언급했듯이 민첩한 방법론과 빈번한 미니 릴리스가 도움이 될 것입니다.
4. 불가피한 변화를 수용 할 시간을 일정에 기입하십시오. 당신이 원한다고 생각한다면 "우리는 더 많은 시간이 필요합니다"라고 말하는 것을 두려워하지 마십시오. 당신이 주어진 일정이 비현실적이라면 시작 시간보다 시작 시간보다 그것을 알고 (그리고 기록을 작성하도록)하는 것이 좋습니다 끝.
5. 변경 사항이 너무 광범위하고 마감 기한을 위협하는 경우 "이 변경은 가능하지만 마감 시간을 X 시간만큼 밀어 붙여서 선택하십시오"와 같이 말합니다.
6. 변경 요청, 변경 우선 순위 지정 및 버전 또는 릴리스에 변경 사항 할당을 공식적으로 처리하십시오. 사람들에게 "이 릴리스에서는 할 수 없지만 다음 스케줄에 기꺼이 맡길 수 있습니다"라고 말할 수 있다면 "너무 늦어서 변경 사항을 적용 할 수 없습니다"라고 말하는 것보다 훨씬 낫습니다. "안녕하세요"라고 말하면 친구가 될 것입니다. 적들을 풀어 놓을 수 있도록 기꺼이 시간을내어 행복하게 해줄 것입니다.

무엇인가를 빨리 전달하고 (나는 무엇이든 사용하는 것을 망설임) 자주 전달합니다. 즉, 일종의 반복 개발 방법론을 사용하십시오.

이것이 애자일 개발의 기초이지만, 거의 모든 방법론과 함께 사용될 수 있습니다.

프로젝트를 일련의 미니 프로젝트로 세분화하면 클라이언트 앞에 무언가를 넣을 수 있기 때문에 더 많은 제어권을 얻을 수 있습니다. 그들은 할 것이다).

시스템이 발전하는 것을 볼 때 일부 요구 사항이 변경되고 일부 요구 사항이 중복되고 다른 요구 사항이 우선 ​​순위가 높아집니다. 그러나 프로젝트 수명주기가 짧으면 이러한 변경에 대처할 수 있습니다.

상당한 규모의 소프트웨어 프로젝트를 완전히 지정할 수 있다는 이론은 완벽한 환상입니다. 이 이론은 소프트웨어 개발의 거의 모든 역사를 위해 대기업에서 소규모 조직으로 작동하지 않는 것으로 밝혀졌습니다.

갈 때 변화를 수용 할 수있는 방법을 찾아야합니다! 대부분의 이해 당사자들은 '그렇다, 그것이 내가 원하는 것'이라고 말하더라도 실제로는 그들이 앞에 올 때까지 그들이 원하는 것을 알지 못하기 때문에 일어날 것입니다. 그래서 우리는 많은 사람들이 반복적 인 방법을 채택하고 있습니다.

제품을 반복하든 다른 방법을 사용하든 이러한 변경 사항을 수용 할 수있는 방법을 찾아야합니다. 변경 사항이없는 방법을 찾는 것은 몇 분 동안 중력을 해제하여 비행을 계속할 수 없기 때문입니다.

변화를 막으려 고하지 말고 받아들이 십시오. 계획이 많을수록 계획이 변경 될 가능성이 높습니다. 따라서 더 적게 계획 하지 마십시오. 적은 양의 작업 코드를 자주 제공하는 민첩한 개발 방법론을 채택하여 고객에게 2 주마다 사양을 변경할 수있는 기회를 제공하십시오.

당신은 잘못된 질문을하고 있습니다. 사양 변경은 항상 모든 규모의 소프트웨어 개발 프로젝트에서 발생합니다.

종종 비즈니스 요구 사항이 변경되기 때문이지만 고객 (내부 또는 외부)이 반복 할 대상을 보지 않고도 가능한 것을 시각화하기가 어려워서 솔루션 개발.

당신이 묻는 질문은 "사양을 어떻게 고정시킬 수 있는가"가 아니라 "내가 작성한 모든 것을 버리지 않고 변화하는 환경에 대응하도록 코드와 프로세스를 어떻게 구성 할 수 있는가"입니다.

그러면 민첩한 방법론, 반복 개발 및 컴포넌트 기반 / 모듈 식 코딩, 지속적인 통합 등의 기술 솔루션과 같은 전문 용어 빙고 분야로 연결됩니다.

나는 이것이 당신의 모든 문제에 대한 은색 총알이라고 말하지는 않지만 적어도 당신이 묘사 한 상황을 관리하려는 욕구 때문에 적어도 그들이 조사 할 가치가 있습니다.

구체적인 솔루션을 제공하지는 않지만 죄송하지만 변경을 수락하고 관리하는 사고 방식이 변경을 피하려고 시도하는 것보다 더 큰 배당금을 지불한다고 생각하는 경향이 있습니다.

놀랍다면 변화는 놀라움 일뿐입니다!

나는 다음에 대해 생각할 것을 제안한다.

• 어쨌든 이러한 변화는 어디에서 발생합니까?
• 왜 일찍 알지 못합니까?
• 왜 이러한 변화에 기여하지 않고 잠재적으로 더 많은 변화를 일으키지 않습니까?

변화는 우리가하는 일의 본질입니다. 당신이 알고리즘을 코딩 않았다 언제부터 정확히 1 일에 상상으로?

그러나 변경에 의해 좌절 된 개발자가 "놀랐다"는 것을 계속 피하고 싶다면 결정이 내려지는 행동에 더 가까이 다가 가야한다고 생각합니다. 결국, 나는 당신이 어떻게 더 나은 제품을 만들 수 있는지에 대한 많은 아이디어를 가지고 있다고 확신합니다. 탁자에 앉거나 "놀라운 변화"를 처리해야한다는 점을 영원히 받아들이십시오.

글쎄요.하지만 전화는 항상 더 많이 원하지만 여기에 고려해야 할 몇 가지 사항이 있습니다.

HTML 모형 : 항상 HTML 모형을 만들어 응용 프로그램의 UI 부분을 정의하고, 어떻게 생겼는지 보여주고 의견을 묻습니다. 변경할만한 것이 있으면 HTML 프로토 타입에서 변경하십시오. 이를 사용하면 UI 문제, 기본 흐름 및 일부 추가 기능 (정렬, 페이지 매김, 표시 할 레코드 수 등)과 같은 많은 것들을 정렬합니다.

다른 쪽 끝에서 적극적인 참여 : 비즈니스 조직을 위해 개발하는 경우, 비즈니스에 참여하여 의심을 명확하게하고, 흐름에 어떤 변화가 필요한지 (필요한 경우) 물어보십시오.

모듈 식 릴리스 : 모듈 방식으로 코드를 해제하고 릴리스, 테스트하고 피드백을받은 후 다시 릴리스하십시오.

그렇기 때문에 사전에 계획을 세우는 것이 거의 불가능하지만 계획을 세우지 않아도된다는 변명이 아닙니다. 당신의 계획에 너무 깊이 빠져들지 마십시오. 당신의 계획이 마음을 아프게하는 것에 대해 걱정할 필요가 없습니다.

회사 내부에서는 누구나 IT 리소스를 인정하거나 추적하거나 예산을 책정해야하는지 여부에 관계없이 IT 리소스를 사용하는 비용이 있습니다. 실제로 팀은 특정 시간에 많은 양의 코드 만 만들 수 있습니다. 모든 부서와 프로젝트가이 예산을 공유하고 있습니다.

요구 사항을 변경하려는 사람을 막을 수는 없지만 결과를 피할 수는 없습니다. 변화는 개발 시간을 크게 증가시킬 수 있습니다. 그것이 그들이 다루거나 변경하지 않기로 결정한 사실입니다. 한 부서의 요청이 다른 부서에 영향을 줍니까? 변경 요청이 다른 그룹의 시간표를 위반하기 때문에 프로젝트를 다른 부서로 완전히 옮겨야 할 수도 있습니다.

개발주기 전반에 걸쳐 활발한 사용자 참여와 가능한 한 많은 민첩한 방법론을 사용하면 실제로 제품에 도움이됩니다.

사양 변경은 불가피하지만, 사용자와 투명성을 유지하면서 자주 문의하면 대부분의 변경이 가능한 빨리 캡처됩니다.

나를 위해 그것은 매우 쉽습니다.
하나는에게 "제품 소유자" 이 OK 인 기능을 주문한,하지만 그는이 마감일없이 될 수 계획 기능의 몇 가지를 선택해야합니다.
스프린트가 0으로 타지 않을 것이라고 말하는 PO와의 반 스프린트 회의라고 생각하십시오.

추신. 이라면 은 "PO"아니 내가 나에게 이야기하지 않는 것은 "PO"를 통해 이동 말할 것

사양 변경이 개발 도중 또는 이후에 발생하는 것을 최소화하고 방지하는 데 가장 좋은 방법은 무엇입니까?

최선의 방법은 없습니다. 개발의 특정 단계에서 사양 변경 사항을 제한하는 것은 경영진의 책임입니다.

그러나 변경 사항을 예상 할 수있는 방식으로 소프트웨어를 설계해야합니다. 그러면 변경의 영향이 훨씬 줄어 듭니다. 반복적이고 점진적인 개발 이 좋은 출발입니다.

직간접 적으로 고객이 대부분의 변경 (및 가장 중요한 버그, BTW)의 원인이라는 것을 알았습니다. 따라서 확실한 해결책은 고객을 제거하는 것입니다. (어쨌든 그들은 좋은가요?)

변화를 막을 수 없기 때문에 변화를 수용해야합니다. 가장 중요한 것은 코드가 거의 없을 때 변경하는 것이 비용이 적게 들기 때문에 가능한 빨리 고객으로부터 변경 요청을 가져와야한다는 것입니다. 따라서 프로토 타입 (아마도 종이 프로토 타입)을 사용하여 민첩한 방법 등을 사용하여 가능한 빨리 설계를 고객에게 제시해야합니다.

SCRUM과 같은 방법론을 사용하여 개발 프로세스에 몇 가지 원칙을 도입하는 것을 고려할 수 있습니다. SCRUM에서 팀은 기능 구현을 스토리 로 분할하고 각 스토리에 노력 추정치 (스토리를 구현하는 데 필요한 작업 시간 또는 일 수)를 지정 하여 초기 계획을 세웁니다 .

지연이 요청 된 경우 (이미 구현 된 스토리에 대해) 새 스토리 를 작성 하고 구현 노력을 추정해야합니다. 그런 다음 관리자 ( 제품 소유자 )에게 가서 새 기능이 추가 시간을 소비한다고 설명 할 수 있습니다. 프로젝트 관리자는 추가 노력을 수용하고 일정을 조정해야 할 책임이 있습니다 (아직 구현되지 않은 다른 스토리를 취소 할 수 있음).

팀이 SCRUM 또는 다른 개발 프로세스를 완전히 구현하지 않더라도 최소한 스토리를 기반으로 계획을 소개하고 각 스토리의 개발 노력을 추정하며 새로운 스토리가 요청 될 때 일정을 조정할 수 있습니다.

http://teddziuba.com/2010/05/why-engineers-hop-jobs.html

나는 또 다른 챕터가 소프트웨어 비즈니스가 어떻게 작동하는지 이해하지 못하기 때문에 퇴근 후 저녁에 너무 많은 스트레스와 불행을 보냈습니다. 나는 누구보다 높은 사람과 대면하는 데 아무런 문제가 없지만, 동료 얼간이의 후원은 없습니다. 아이들을 갖는 건 나쁜 일입니까? 곧 종료 될 것입니다.

솔직히 프로그래머들은 일반적으로 더 많은 공을 가지고 있었으면 좋겠다. 이것을 보자 :

"" "돈을내는 고객에게는 효과가 없습니다. 이는 사내 개발 웹 사이트의 사내 개발 팀입니다. 따라서 비용이나 기타 비용을 청구 할 수있는 것은 아닙니다. 마감일을 맞추려고 노력해야합니다. "" "

$ -paying 고객을 상대하고 계약을 맺어 엉덩이를 가렸다면 (http://vimeo.com/22053820?utm_source=swissmiss) 사양 변경으로 인해이 고객에게 더 많은 시간과 돈이 더 들게됩니다 ( 또는 잠재적으로 동일하거나 적은 시간이지만 기하 급수적으로 더 많은 돈). 귀사는 더 많은 시간과 비용을 들이지 않고 사양을 바꾸려고 노력하고 있습니다.

그 동안 마감일을 맞추려고하면 귀하와 동료 직원에게 불필요한 스트레스가 발생합니다. 주말에는 친구 / 가족과 좋은 주말을 보낼 수 없습니다. 당신에게 일을 던지는 사람은 아마 그것을 알지 못하기 때문에 정말 불필요합니다.

내가 제안한 해결책 : 공을 가지고 공을 가지고 공짜로 점심을 먹지 않고 모든 비용이 든다는 것을 설명하십시오. 작업 중 사양이 변경되면 자동차 정비공이 더 오래 걸리고 더 많은 비용이 청구되며 계약 기관은 더 오래 걸릴 것입니다 작업 도중에 사양이 변경된 경우 더 많은 비용을 청구 할 수 있으며 이에 대한 충분한 이유가 있습니다. 그들이 합리적인 방식으로 당신과 함께 일하고 싶지 않다면, 당신은 그룹으로서 일어나서 떠날 것이며, 프로젝트를 중단하고 정시에 제공 할 수있는 개발자를 고용해야합니다.

또한 민첩한 개발에 대한 약속도 있으며, 이는 마감 기한이 없음을 의미합니다.

나는 아직 프로그래머들이 파업을하는 것을 보지 못했지만 이것은 뭔가 일 것이다. 무능한 관리자는 소프트웨어 회사에 너무 풍부합니다. 너무 많은 사람들이 Craigslist 또는 실제 회사 내에서 아무것도 얻기를 원하지 않습니다. http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

프로그래머에게는 더 많은 공이 있어야합니다.

내가 확인한 접근 방식은 (모든 관리자에게 분명히 해당되는 것은 아님) "나는 그렇게 할 수 있다고 생각합니다.이 프로젝트에 얼마나 많은 시간을 할애하고 있습니까? 그것은 상당히 큰 변화입니다. 요청 중입니다. "