요구 사항이없는 상태에서 소프트웨어를 작성하는 것은 소유해야 할 기술이거나 피해야하는 상황입니까?

나는 일부 소프트웨어 개발자들이 이것에 매우 능숙하다는 것을 알고 있으며 종종 추상적 인 요구 사항으로 작동하는 개념을 제공 할 수있는 능력에 대해 찬사를 보냅니다. 솔직히, 이것은 나를 미치게 만들고, 내가 갈 때 "만들기"를 좋아하지 않습니다. 나는 이것이 문제가되었다고 생각했지만, 변화를 느끼기 시작했고, 아주 작은 방향으로 생각과 프로그래밍 과정을 조정할 필요가 있는지 궁금합니다. 이 능력을 기술로 습득하기 시작하거나 요구 사항 수집 및 비즈니스 규칙이 최우선이라는 아이디어를 고수해야합니까?

기술은 요구 사항없이 소프트웨어를 작성하는 것이 아닙니다. 공식적인 요구 사항 문서의 유무에 관계없이 프로젝트 소유자로부터 요구 사항을 도출하는 것입니다.

요구 사항 수집은 반드시 최우선 순위이지만 반드시 고객의 모든 요구 사항을 미리 파악할 필요는 없습니다. 물론 고객과의 올바른 대화를 관리하지 않으면 시스템 아키텍처를 쓸모 없게하는 중요한 정보가 누락 될 수 있지만, 제품을 정의하고 얻는 것도 드문 일이 아닙니다. 마지막 개발 시점까지 주요 시스템 아키텍처 결정을 연기하는 동시에 많은 개발이 중단되었습니다. 이는보다 견고한 정보를 얻을 때까지 제품 개발 초기에 잠재적으로 호환되지 않는 아키텍처를 커밋하지 않도록하는 린 개발 방식입니다. OP가 그의 질문에 묘사 한 상황에서

예, 때로는 고객이 실제로 요구하는 것의 핵심에 도달하기 위해 약간의 수정 구슬 응시가 필요합니다.이 시점에서 프로토 타입 스파이크와 느리고 때로는 고통 스럽습니다. 훌륭한 고객 관계 기술을 개발하고 복잡한 소프트웨어 아이디어로 고객이 처음에 소프트웨어가 실제로 무엇을해야하는지에 대해 더 많이 알지 못한다는 것을 인식하는 인내심을 갖습니다. 고객이 소프트웨어 개발 프로세스에 필요한 전문 지식이나 지식을 항상 보유하고 있지는 않기 때문에 고객이 요구 사항을 정의하기 위해 전문 지식에 의존하기 위해 초기에 전화를하는 경우가 많습니다.

이것은 매우 모호합니다 ...

내가 말할 수있는 두 가지 :

1. 완벽한 요구 사항을 기다리기 때문에 경력이 중단되는 매우 재능있는 기술 인력이 많이 있습니다. 또는 그들은 "죄송합니다. 할 수 없습니다. 요구 사항에 없었습니다." 현실은 요구 사항 작성이 매우 어렵다는 것입니다. 좋은 요구 사항에 필요한 정밀도는 대부분의 비즈니스 사람들이 만든 것과는 다릅니다. 기술과 비즈니스 사이에는 다리가 있으며, 다른 사람들이 기술을 만나기 위해 100 % 길을 잃게하는 사람들은 대개 잃습니다.

2. 고객보다 좋은 도메인을 배우는 소프트웨어 사용자가 있습니다. 이 사람들은 최고의 개발자가 100 %가 아니더라도 금으로 가치가 있습니다. 나는 소프트웨어 사람들이 국내 최고의 브랜드 관리자의 양적인 마케팅 요구를 기대하는 것을 보았습니다. 그들은 모든 솔루션을 코딩하는 데 최고는 아니지만 다리를 건너 갈 수 있기 때문에 영웅이었습니다.

인생은 흑백에 관한 것이 아닙니다. 자신 주위에 좁은 상자를 그리면 자신이 제한됩니다. 반대로 기술을 만드는 데 필요한 것을 무시하는 조직도 제한적입니다. 당신은 당신이 선호하는 회색의 위치를 ​​볼 수 있습니다.

요구 사항은 여행의 단계이며 비전은 방향입니다

많은 응용 분야에서 매우 상세한 기술 사양은 너무 앞서서 설명 할 수 있습니다. 빠른 토론을 통해 신중하게 조판 된 문서를 쓸모 없게 만들 수 있기 때문입니다. 대신 비전으로 시작하십시오. 모든 사람이 전반적인 그림을 이해하면 토론을 통해 요구 사항을 충족시킬 수 있습니다.

개발자는 이러한 토론을 통해 요구 사항 을 해결하는 방법을 배워야합니다 . 이는 오늘날 고객의 의사 결정이 전체 비전에 어떻게 적용되는지에 대해 고객에게 질문하는 것을 의미합니다. 이러한보다 자세한 논의가 빠를수록 전체 비전이 일관된 설계로 더 빨리 강화됩니다.

어떤 종류의 이슈 트래커에서 이러한 토론의 결과를 추적하여 다른 사람들이 원래 토론을 놓친 경우 의견을 남길 수 있도록해야합니다. 그리고 귀하 또는 다른 팀원이 설명이 필요할 경우 다시 참조 할 수있는 기록을 보유 할 수 있습니다.

따라서 비전에 대비하여 코딩하는 법을 배우십시오. 그러나 때가되었을 때 이러한 요구 사항을 충족시킬 준비를하십시오.

Steve Jobs는 고객이 미래의 제품 모양을 정확히 설명 할 수 없으므로 제품을 제공하는 것이 귀하의 일이라고 생각했습니다. 따라서 사용자 정의 소프트웨어를 항상 제공하지 않는 한 공식적인 사양을 잊고 프로토 타입을 만들고 고객이 그 제품을 가지고 놀게하면서 생각하는 것을 알려주십시오. 올바른 사람이 프로토 타이핑을하도록해야하는데 도움이 필요합니다. 나는 경험에서 이것을 말합니다-저는 직관적 인 인터페이스를 만드는 것을 좋아하는 프로토 타입 원숭이이며 고객이 원하는 것을 이해하고 종이에 적거나 Excel을 사용하여 설명 할 수있는 제품을 가진 사람과 팀을 이룹니다.

우리 둘 다 천재는 아니지만 우리는 똑같이 생각합니다. 화학을 얻었고 어떤 것들이 어떻게 만들어지고 있는지에 대해 큰 영향을 미쳤다고 말할 수 있습니다. 이제는 중대 규모의 팀만이 독점적으로 제품을 개발하는 프로토 타입과 비코 더를 가질 수 있지만 그만한 가치가 있습니다. 프로토 타이핑은 소프트웨어 개발에서 가장 저렴한 단계이므로 UI와 명백한 동작을 올바르게 수행하는 것이 좋습니다. Code Complete를 읽지 못했지만 그 책에 쓰여진 것과 비슷한 것이 있다고 생각합니다.

사양은 훌륭하지만 완벽하지는 않습니다. 그것에 관한 정리가 있습니다. 사양이 완료되었다는 것을 증명할 수 없으며 도구에 버그가 없거나 정지한다는 것을 증명할 수 없습니다. :)

그러나 소프트웨어 회사는 프로세스의 이러한 결함에도 불구하고 항상 소프트웨어를 배송합니다. 사양은 절대 완벽하지 않습니다. 스펙은 또한 비 자연적이며 구식입니다. 프로토 타입에 대한 스펙은 로그 테이블과 비슷합니다. 스펙은 기본적으로 지루한 브로슈어입니다. 대신 툴 / 그래프와 상호 작용할 수 있습니다. 영감을 얻으려면 http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html 을 확인하십시오 .

이제 엉덩이를 덮기 위해 계약을 맺어야한다면 사양이 좋습니다. 그러나 스펙은 이전이 아닌 프로토 타입을 따라야합니다. 프로토 타입을 싸게 만드는 방법을 알아내는 것이 당신의 임무입니다.

나는 종종 상황에 내가 사업은 현재 사람들이 어떻게 작동 정확히 어떻게 발견, 비즈니스 분석가의 역할을해야하는 것으로 나타났습니다 생각 은 (종종 매우 다른 것) 작동하고, 그들이 얼마나 좋아하는 일에.

소프트웨어 구축을 위해 내려야하는 결정에 대해 항상 명확하게함으로써 성공을 거두었습니다. 나는 나의 추론을 설명하고, 내가 찾은 것에 대한 문서를 작성하고, 그래프를 만들어 모든 사람에게 배포하는 등의 일을합니다.

완전한 요구 사항이 전달 될 때까지 어떤 작업도 거부함으로써 인상을주지 않을 것입니다. 그러나 품질 요구 사항을 직접 수집하면 (실제로주의를 기울이지 않아도) 동일한 품질 소프트웨어 목표에 도달 할 수 있습니다.

그리고 다른 논평자들이 말했듯이 항상 소프트웨어가 변경 될 것이라는 가정하에 빌드하십시오. 변화는 당신이 의지 할 수있는 하나의 상수입니다. 새로운 요구 사항이 갑자기 나타날 때 소프트웨어를 업데이트하는 데 어려움을 겪지 않도록 항상 유연하고 모듈 식으로 소프트웨어를 구축하십시오.

스타트 업에서 소프트웨어 개발자로 일하고 싶다면 소유해야 할 기술입니다.

컨설팅 회사에서 일하고 싶다면 모든 비용을 피하는 것이 좋습니다. 이는 고객이 문제를 얼마나 잘 해결했는지가 아니라 사양 / 요구 사항을 얼마나 잘 구현했는지에 따라 회사가 보수를 받기 때문입니다.

여가 시간에 재미를 위해 코딩하고 있다면 그것은 전화입니다. 여가 시간에 전화를 걸 자격이 없다고 생각되면 몇 가지 방법으로 시도해보고 어떤 것이 효과가 있는지보십시오. 또한 하나의 크기에 맞는 것은 아니며 일부 프로젝트는 하나 또는 다른 유형의 접근 방식을 요구합니다. 일반적으로 이러한 프로젝트 중 하나에서 잘못된 것을 선택하면 매우 빨리 알아낼 수 있습니다.

둘 다. 고객을 만족시켜야합니다. 즉, 고객이 원하는 것을 알아야합니다. 반면에 고객은 자신이 원하는 것을 전달하는 데 악명이 높습니다.

따라서 고객이 원하는 것이 무엇인지 모르는 시나리오는 피하고 싶지만, 요구 사항이 최상으로 '불완전'하고 최악의 경우에는기만적인 시나리오가 불가피합니다. 좋은 실제 프로그래머는 적응성이 필요합니다.

요구 사항없이 프로그램을 작성할 수 없습니다. 'Hello World'조차도 출력을 생성해야합니다. 따라서 UML과 같은 큰 스택 형태의 공식 요구 사항에 대해 문의하고 있다고 생각합니다. 그리고 그에 관해 나는 두 종류의 사람들을 만났습니다.

1) 공식적인 요구 사항이 필요한 사람들. 해야 할 일과 최선을 다하는 방법을 정확하게 알려야합니다. 그들은 논쟁 B를 취하는 절차 A 와 같은 문장을 좋아 하고 그것을 싫어할 것입니다 . 프로그램은 우리 부서의 작업을보다 효과적으로 만들어야합니다 . 그들은 보통 회사 동물입니다.

2) 반대의 사람들 1. 그들은 무엇을해야하는지, 어떻게해야하는지에 대해 배우기를 싫어하고, 성취해야 할 것을 들려주는 것을 좋아합니다. 그들은 고객과 대화하고 그들이하는 말을 분석 한 다음 자신의 솔루션을 개발하는 것을 좋아합니다. 그들은 일반적으로 프리랜서이며 회사에 적합하지 않습니다.

나는 그들 중 어느 것이 더 낫다고 말하지 않을 것입니다. 둘 다 장단점이 있습니다. 다른 조건에 적합합니다.

요구 사항을 모르면 운영 소프트웨어를 개발할 수 없습니다 . 그러나, 당신은 당신의 경험이 당신에게 요구 사항이 가능성을 알려주는 것을 개발하는데 유쾌한 찌르기를 할 수 있습니다되려고. 민첩한 개발은 80:20 규칙 및 프로토 타입 제작을 통한 요구 사항의 '발견'을 포함한 '직관적 인'기술의 조합을 사용합니다. 다시 말해, 숙련 된 개발 팀이 필요한 것을 가장 잘 추측하고 소프트웨어 프로토 타입을 제작합니다. 80:20 규칙에 따르면 80 % 정확하다고합니다. 그런 다음 프로젝트 이해 관계자는 유형의 프로토 타입을 검토합니다. 그들의 피드백은 요구 사항을 이해함에있어 20 %의 격차를 메우기 시작합니다. 따라서 애자일은 요구 사항없이 소프트웨어를 작성하는 것이 아니라 이전 경험을 사용하여 "이와 같은 것을 원하십니까?"라는 의미입니다. 80 %의 사례에서 기존 요구 사항 프로세스를 통해 플로팅하는 것보다 실제로 필요한 것을 빠르게 도약하고 확인할 수 있습니다.

애자일이 요구 사항없이 코드를 작성한다고 누가 말했습니까? 나는 선언문이 누군가에 의해 이런 식으로 해석되었다는 것을 알고 있지만 ... 그렇지 않습니다.