코딩하기 전에 기능을 아는 것이 얼마나 중요합니까?

개발 작업이 진행된 소프트웨어 개발 회사에서 일하고 있습니다. 온 쇼어 팀은 지원을 처리하고 고객과 직접 대화합니다. 우리는 고객과 직접 대화하지 않습니다. 우리는 온 쇼어 팀의 사람들과 직접 대화합니다.

요구 사항이 올 때, 온 쇼어 팀은 고객과 대화하고 요구 사항 문서를 작성하여 알려줍니다. 우리는 요구 사항을 연구 한 후 디자인 문서를 만듭니다 (전통적인 폭포 모델을 따릅니다).

그러나 전체 프로세스에는 한 가지 문제가 있습니다. 해외 또는 육상 팀의 어느 누구도 애플리케이션의 기능을 완전히 이해하지 못합니다. 복잡한 주문 처리, 카탈로그 관리, 캠페인 관리 및 기타 활동을 처리하는 매우 복잡한 웹 앱을 알고 있습니다. 요구 사항이 명확하지 않기 때문에 디자인 문서로 어려움을 겪습니다. 그런 다음 온 쇼어 팀, 오프 쇼어 팀 및 고객간에 일련의 질문 / 답변을 진행합니다. 우리는 종종 코드의 기능을 이해하라는 지시를받습니다. 그러나 코드베이스가 거대하고 간단한 메뉴 항목을 이해하는 데는 몇 주가 아니라도 며칠이 걸리기 때문에 일반적으로는 불가능합니다. 우리는 고객들에게 우리에게 지식 이전 을 제공하라고 말했습니다.응용 프로그램에 대해 아무 소용이 없습니다. 관리자는 디자인 문서가 완전하지 않거나 요구 사항이 명확하지 않은 경우에도 코딩을 시작하라고 말합니다. 우리는 분명해 보이는 요구 사항의 일부를 코딩하고 나머지를 기다릴 것입니다.

일반적으로 배포는 한 달 정도 지연됩니다. 극단적 인 경우 우리는 개발 및 생산 과정에서 오류가 매우 적지 만 고객이 요구 한 것은 아니라고 말할 것입니다. 그것은 비난 게임과 일련의 변경 요청을 시작하고 우리는 매우 다른 것을 개발하게 될 것입니다.

제 질문은 앱의 기능을 완전히 모른다면 어떻게 개발 작업을 하시겠습니까?

최신 정보

개발 방법론 그것은 실제로 내 선택이 아니며 나는 팀의 리더가 아닙니다. 그것이 시작된 방법입니다. 나는 사람들에게 민첩성의 장점에 대해 이야기하려고 노력했지만 아무 소용이 없습니다. 게다가 우리 팀은 민첩한 환경에서 일하는 데 필요한 사고 방식을 가지고 있다고 생각하지 않습니다.

짧은 버전 :

해야 할 일 알기 ≠ 고객 알기

이것을 상상해보십시오. 당신은 부동산 개발과 관련된 회사입니다. 파트너에게 대규모 단지를 건설하도록 요청하십시오. 파트너는 당신이 그에게 준 모든 서류에도 불구하고이 단지에서 아파트를 구매할 사람들과 직접 대화해야한다고 말합니다. 진심이야?

긴 버전 :

배우는 것은 재미 있기 때문에 특정 응용 프로그램이 어떻게 사용 될지 항상 아는 것이 좋지만, 대규모 프로젝트에서는 항상 가능하지는 않습니다.

일부 도메인은 너무 복잡합니다. 당신이 경우 단지 개발자 및 여러 도메인에서 여러 응용 프로그램에서 작업, 당신은 그냥 항상 최종 사용자가 무엇을하고 있는지 이해할 수 없다 는 회계 학습 오년 지출을 필요로하기 때문에, 의과 대학 10 년, 로스쿨 등 6 년

다른 한편으로, 특정 도메인을 이해하지 못하도록 만들어진 소프트웨어 제품은 기껏해야 사용할 수 없을 것입니다 .

이것이 기능 및 비 기능 요구 사항을 도메인을 완전히 이해하는 사람들이 작성해야하는 이유입니다. 일반적으로 요구 사항 수집에는 동시에 다음이 포함됩니다.

1. 기술자 (예를 들어 특정 기능이 불가능하다고 말하고이 방법으로 수행하면이 기능이 훨씬 우수 할 수 있으며 훨씬 저렴한 대안이 있지만 수천 달러가 소요될 것이라고 말하는 개발자),

2. 프로젝트 관리 전문가

3. 이 영역과 고객의 정확한 요구를 완전히 이해 한 고객 영역의 전문가 . 물론 이것은 고객 자체 일 수 있습니다.

하나의 기능적 및 비 기능적 요구 사항이 작성되고 충분히 정확하므로 해당 요구 사항을 코드로 변환하는 작업을 수행하는 사람 으로서는 아무것도 필요하지 않습니다.

구체적인 경우에 대해서는 문제의 원인을 직접 설명하십시오.

요구 사항이 명확하지 않기 때문에 디자인 문서로 어려움을 겪습니다.

모든 문제를 일으키는 고객에 대한 지식이 부족하지 않으며 요구 사항의 품질이 낮습니다. 올바르게 관리되는 프로젝트에서 기능적 및 비 기능적 요구 사항은 완벽하고 명확해야합니다. 요구 사항 문서가 명확하지 않거나 "제품의 시각적 디자인이 매력적이어야 함"또는 이와 같은 다른 어리 석음이 있다고 말하면, 제품 작성 방법을 모르는 사람들이 작성한 것이기 때문입니다.

그것을 알고, 당신은 다르게 행동해야합니다 :

• 요구 사항을 수집하는 팀이 필사적이고 자신의 팀이 요구 사항 수집에 숙련 된 인력을 보유하고 있다는 사실을 알고 있다면 상황을 상사에게 설명하고 다른 팀은 예를 들어 귀하의 직원과 같이 유능한 사람으로 교체해야한다고 말합니다.

• 그렇지 않은 경우 (즉, 절박하지 않은 경우), 낮은 요구 사항의 내부 원인을 파악 하고 작업을 올바르게 수행하면 프로젝트의 전체 비용 만 줄 이도록 설득하십시오 . 서면으로 작성된 요구 사항이 비용을 증가시켜 프로젝트에 미치는 영향 (얼마나 많은가)과 마감일을 준비하지 않을 위험에 대한 통계를 보여주는 것이 좋습니다.

아마도 요구 사항 문서가 불완전 할 것입니다. 나는 항상 이것을 본다 : 경험이없는 프로젝트 관리자들은 단지 한 페이지짜리 문서가 충분하다는 것을 확신하고, 왜 그들이 한 페이지 대신에 3-4 백 페이지를 쓸 것인지 이해하지 못한다. 회사의 경우 요구 사항에 더 많은 시간을 할애하면 비용이 줄어든다는 것을 보여주십시오.

직면 한 문제에 대해 잘못된 개발 방법을 사용하고 있습니다.

Waterfall을 사용하여 다음을 수행합니다.

1. 올바른 요구 사항을 미리 파악하십시오-분명히 작동하지 않습니다
2. 고객과 떨어져 요구 사항을 코딩-요구 사항을 개발하기로 약속 한 고객과 관련된 문제를 효과적으로 확인할 수 없습니다.
3. 고객이 기능을 볼 수있는 첫 번째 기회는 테스트하는 중입니다. 현재 발생한 문제로 인해 너무 늦었습니다.

가능하면 프로젝트를 관리하는 다른 방법을 사용하십시오. 애자일 소프트웨어 개발 에는 직면 한 문제를 해결하기 위해 설계된 여러 기능이 있습니다.

Waterfall과 Agile 의 적절한 비교는 잠시 전에 작성되었으며 문제를 강조하는 몇 가지 인용문을 가져옵니다.

마크가 없습니다 :

Waterfall 방식으로 단계가 완료되면 Waterfall 방식으로 설계 및 구현 된 대부분의 소프트웨어는 시간과 사용자 요구에 따라 변경하기 어렵 기 때문에 되돌아 갈 필요가 없습니다. 이 문제는 비용이 많이 들고 비효율적 인 방법으로 완전히 새로운 시스템을 설계하고 설계해야만 해결할 수 있습니다.

묶여 ...

민첩한 방법을 사용하면 최종 사용자의 요구 사항에 따라 사양을 변경하여 고객 만족도를 높일 수 있습니다. 이미 언급했듯이, 워터 폴 방법을 사용하면 변경이 불가능하므로 프로젝트를 다시 시작해야하기 때문에 불가능합니다.

... 이동할 수 없다

둘 사이의 차이점을 요약하기 위해 고전적인 폭포 방법은 예측 가능성을 나타내며 민첩한 방법론은 적응성을 철자한다고 말할 수 있습니다. 민첩한 방법은 이론적 근거, 정당성, 문서 및 회의와 같은 오버 헤드를 줄이고 가능한 한 낮게 유지하는 데 효과적입니다. 따라서 애자일 방식은 규모가 큰 프로젝트보다는 끊임없이 변화하는 요구 사항을 가진 소규모 팀에게 혜택을주는 이유입니다.

당신이 지금 어디에있는가는 나쁘다. 고객의 요구 사항을 충족시키지 못하고 소프트웨어 개발의 책임이 있다면 생산성이 저하되고 불신이 증가하며 상황이 나빠질 수 있습니다.

고객과의 관계는 매우 중요합니다 . 여기서 문제를 효과적으로 수집하고 현재 작업중인 방식으로 변화하는 요구 사항에 적응할 수없는 것처럼 들립니다. 따라서이를 변경하는 방법을 살펴 봐야합니다.

그것이 작동하는 방식이 아닙니다. 현재 교육의 주제 중 하나는 분석 및 고객과의 관계입니다. 프로젝트를 명확하게 정의하는 데 중점을 두었습니다. 이것을 상상해보십시오 :

• 당신은 집을 짓기 위해 건축 회사를 주문하지만 어떻게 당신이 그것을 원하는지 모릅니다. 1 층을 사용자 정의하면 팀이 1 층까지 집을 지을 수 있습니다. 그런 다음 1 층을 다르게 배치하려고합니다. 죄송합니다 ...

당신이 (부분적으로) 응용 프로그램에 대한 올바른 기초를 만들 수 있다고 확신하지 않는 한, 명확하게 정의 된 목표와 기능보다 다른 방법은 클라이언트에게 말하지 않을 것입니다. 그것이 무엇인지 찌르면 많은 돈과 시간을 낭비 할 수 있기 때문입니다.

다음은 문제를 극복하는 데 도움이되는 몇 가지 사항입니다.

1. 두 팀 간의 커뮤니케이션 을 향상시킵니다 . 다른 팀에 요구 사항을 3 단어로 압축하도록 요청하면 프로그래머가 해당 단어를 정확하게 구현합니다. 단어는 정확해야합니다. 그 말 없이는 아무것도 구현되지 않을 것입니다. 모든 단어는 2000 줄의 코드를 제공합니다. 새로운 단어가 알려지면 구현이 시작됩니다.
2. 프로그래머에게 단어가 즉시 명확하지 않은 경우 단일 질문을 할 수 있습니다. 질문은 다시 맞아야합니다. 즉각적인 답변이 필요합니다-답변은 세계의 다른 곳에서 왕복을 기다릴 수 없지만 미리 알아야합니다. 답변을받은 직후 구현이 시작되고 답변은 서신으로 이어집니다.
3. 구현하는 동안 명확하지 않거나 퍼지 요구 사항이있는 경우이를 해결하는 방법은 먼저 (기존) 3 단어를 보는 것입니다. 여전히 명확하지 않은 경우 프로그래머는 최선의 추측을 가능하게합니다 . 이 과정의 지연은 절대적으로 금지되어 있습니다. 다른 팀의 도움을 요청하는 것이 올바른 해결 방법이 아닙니다. 이미 올바른 3 단어를 결정하여 요구 사항을 변경할 가능성이있었습니다.
4. 이 모든 요구 사항이 여전히 명확하지 않거나 구현 하기 어려운 경우 올바른 처리 방법 은 문제를 일으킨 세 단어 를 거부 하고 다음 단어로 이동하는 것입니다. 거부 된 단어는 모두 수집되어 다른 팀으로 전달되며 시스템에 다시 들어가기 전에 해당 단어를 수정해야합니다. 단어를 거부하면 마감일이 항상 이동하며 구현을 다시 계획해야합니다.
5. 거부 된 단어 수에 따라 팀을 평가해야합니다. 요구 사항이 구현 된 후에는 영구적으로 수정되어 더 이상 변경할 수 없습니다 . 이미 구현 된 기능을 변경하려는 시도는 거부됩니다.
6. 문제의 실제 문제는 더 많은 정보가 구현을 더 쉽게 만든다고 가정한다는 것입니다. 사실이 아닙니다. 더 많은 자유 프로그래머 가지고는 쉽게 구현 . 요구 사항을 압축하면 프로그래머가 할 수있는 일을 너무 많이 제한하지 않고도 대량의 정보를 전달할 수 있습니다.