코딩을 시작하기 전에 소프트웨어 제품을 얼마나 잘 정의해야합니까?

실제로 코딩을 시작하기 전에 사람들이 일반적으로 소프트웨어 제품을 얼마나 잘 정의하고 있으며 얼마나 잘 작동하는지 알고 싶습니까? 유스 케이스 정의, 위험 분석, 클래스 다이어그램 그리기 등을 언급하고 있습니다.

미래의 위험을 피할 수있는 최종 제품이 무엇인지 충분히 이해하는 것이 좋습니다. 변화.

다른 구체적인 질문은 다음과 같습니다.

1. 개발 이전의 계획 단계에서 일반적으로 프로젝트 시간의 몇 퍼센트를 소비합니까?

2. 코딩을 시작하기 전에 충족시키려는 측정 가능한 기준이 있습니까?

3. 코딩을 시작하기 전에 모든 클래스를 다이어그램으로 작성합니까, 아니면 처음부터 상황이 바뀔 것으로 예상되는 동적 디자인을 작성하려고합니까?

당신이 공유하고자하는 모든 경험은 굉장합니다!

"얼마나 잘 정의되어 있습니까?"에 대한 문자 답변 이다

시작할 수있을만큼 충분히 정의되었습니다.

초기 작업 범위 (초기 개념)를 식별 할 수있을 정도로 충분히 정의되었습니다. 이것은 필연적으로 발생할 변경을 식별하는 데 도움이됩니다.

스프린트의 우선 순위를 정할 수있을 정도로 충분히 정의되었습니다.

유스 케이스 정의를 언급하고 있습니다.

항상 도움이됩니다. 그러나 전부는 아닙니다 . 중요한 사용 사례를 우선적으로 다루고 다루어야합니다. 다른 사용 사례는 이후 릴리스에서 다룰 것입니다. 일부 유스 케이스는 우선 순위가 너무 낮아서 절대 완료되지 않습니다.

위험 분석,

일반적으로 시간 낭비.

클래스 다이어그램 그리기 등

도움이된다면.

개발 이전의 계획 단계에서 일반적으로 프로젝트 시간의 몇 퍼센트를 소비합니까?

많이 다릅니다. "공식적인"숫자를 얻으려면 Software Engineering Economics와 같은 좋은 책을 구입하십시오.

코딩을 시작하기 전에 충족시키려는 측정 가능한 기준이 있습니까?

"측정 가능". 정의하기는 거의 불가능합니다.

"배짱". 정책이 잘못되었습니다.

문제는 "무엇을하고 있는지 이해하고 있습니까?"입니다.

직감이 아닙니다. 예 / 아니오 질문입니다.

그것은 단지 예 / 아니오 질문이므로 "측정 가능"하지 않습니다.

또한 우선 순위를 정해야합니다. 당신은 모든 것을하지 않습니다. 처음 몇 개의 스프린트를 처리하기에 충분합니다.

코딩을 시작하기 전에 모든 클래스를 다이어그램으로 작성합니까, 아니면 처음부터 상황이 바뀔 것으로 예상되는 동적 디자인을 작성하려고합니까?

모든 것을 미리 알 수는 없습니다.

시도하지 마십시오.

클라이언트가 프로젝트 팀의 구성원으로 프로젝트에 적극적으로 참여하는 경우 개발자가 질문을하고 기능에 대한 빠른 결정을 내릴 수 있습니다. 그런 다음 사양이 자세하지 않을 수 있습니다.

고객이 멀리 떨어져 있고 장기간 피드백을받을 수없는 경우 사양이 매우 상세해야합니다.

우리 회사에서 우리는 사용자 스토리를 만들고 프로젝트의 개발자와 함께 계획 포커 를합니다. 이를 통해 사용자 스토리에 소요되는 시간을 알 수 있습니다.

프로젝트가 얼마나 잘 정의되어 있어야 하는가는 시작하기 시작하고 앞으로 2 주 동안 어디로 갈지 알기에 충분합니다.

Scrum Master는 단순히 Excel 시트 또는 다른 곳에서 제품의 총 기능을 정의하여 기능을 추적해야한다고 말합니다. 사용자 스토리를 작성하면 다음에 필요한 기능에 대해 많은 생각을 할 수 있습니다. 그런 다음 우선 순위를 정하십시오. 가장 중요하거나 필수적인 기능은 맨 위, 맨 아래는 맨 아래입니다.

가장 중요한 기능 중 일부를 나열한 후, 개발할 수 있다고 생각되는 기능을 2 주 후에 완료 상태로 가져 오거나 원하는 경우 한 달 동안 가져옵니다. 그런 다음 선택한 기능을 분해하여 몇 가지 코딩을 시작할 수 있습니다.

코딩하는 동안 선택한 기능을 완료 상태로 만들기 위해 개발해야 할 다른 요소를 확실히 생각하게됩니다. 완료는 더 이상 할 일이 없음을 의미합니다. 즉, 테스트, 코딩, 조립, 문서화가 완료되었습니다!

목표를 달성하는 한 언제든지 선택한 기능 목록이 확장 될 수 있습니다. 즉, 주어진 기간 동안 말했던 모든 것을 개발할 수 있습니다.

요컨대, 완벽한 것은 없습니다. 몇 가지 아이디어를 내고 동료와 공유하고 요구 된 제품 요구 사항을 충족하는 것이 적합한 지 확인하십시오. 그렇다면, 당신은에 있습니다! 명확하게하기 위해 간단한 고객 관리 제품을 사용하겠습니다. 무엇이 필요합니까?

As a user, I may manage the Customers;
As a system, I persist changes to the underlying data store;
As a user, I need to enter my credentials to be able to manage customers;
As a system, I have to authenticate the user against the Active Directory;

첫 초안은 그렇게 간단 할 수 있습니다! 그렇다면 우리 시스템에서 보안이 중요한 부분이라는 것을 알 수 있습니다. 궁극적 인 우선 순위 (Y / N)를 만들기에 충분한가? 요구 사항에 따라 달라집니다. 여기서 고객 관리가 가장 중요하다고 가정 해 봅시다. 따라서 다음 스프린트에서는 기본이지만 수용 가능한 방식으로 고객을 관리 할 수 ​​있어야합니다. 고객 관리 란 무엇입니까?

As a user, I may manage Customers;
    -> As a user, I add a customer to the system;
    -> As a user, I change a customer details;
    -> As a user, I delete a customer;
    -> As a system, I flag a deleted customer as being inactive instead of deleting it;
    -> As a user, I need to list the customers;
    -> As a user, I search the customers data bank for a given customer;
    -> ...

이것은 이미 애플리케이션 개발을 시작할 수있는 충분한 기능을 보여줍니다. 프로그래머에게 추가 지침이 필요한 경우 클래스 다이어그램에 익숙한 개발자가 고객 클래스와 해당 속성 및 메서드를 디자인 할 수 있습니다. 그러나 내가 염려하는 한, 내가 쓴 몇 가지로 시작하기에 충분할 것입니다. 도중에 일부 기능이 추가되거나 변경 될 수 있습니다. 중요한 것은 당신이 말한 것에 집중하는 것입니다. 이 예에서는 고객 관리입니다. 우리는 현재 사용자 인증에 신경 쓸 필요가 없습니다. 이것은 다음 스프린트에서 나중에 나올 것입니다.

이게 도움이 되길 바란다! =)

글쎄, 나에게 잘 작동하는 것은 "공평하게"기능이 지정되고 소프트웨어 아키텍처가 매우 느슨하게 지정되어 있다는 것입니다.

내가 일을 시작하려면 내가 뭘하는지 알아야합니다. 단순히 고객의 요구를 이해하면 효과가 없습니다. 내가 사용하는 도구를 작성하더라도 화면을 그리고 기능을 설명하고 각 버튼의 기능을 설명합니다. 그렇지 않으면 시작할 수 없습니다.

다른 한편으로, 나는 코드를 어떻게 개발할 것인지를 정확히 제시하지 않았습니다. 어쩌면 이것은 최악의 연습 일 수도 있지만 나에게 효과적입니다. 작성할 데이터베이스 테이블 세트를 정의 할 수 있지만 각 테이블에있는 컬럼은 정의하지 않을 수 있습니다. 필요한 객체와 클래스에 대해 생각할 수도 있지만 다이어그램을 그리지는 않습니다.

때때로, 나는 내가 잘못했을 때까지 어떻게해야할지조차 모릅니다. 나는 그것을 한 번 구축하고, 분해하고, 다시 한 번 해보자. 이 시점에서 나는 매우 상세한 로드맵을 그리고 다시 시작할 수 있습니다.

어떤 언어와 방법을 사용하고 있습니까?

Java 및 C ++와 같은 일부 언어는 Common Lisp 또는 Python과 같은 언어보다 초기 구조가 더 필요합니다 (Java에서 리팩토링이 더 쉬우므로 Java보다 C ++). Leo Brodie ( "Thinking Forth"에서 생각)는 코딩을 시작할시기에 대한 두 가지 조언을 제공했습니다. Forth에서 편안하게 느끼는 것보다 빨리 다른 언어로 원하는 것입니다.

워터 폴 방법론 (특히 초기 설계가 제공 가능한 경우)은 민첩성보다 선행 작업이 더 필요합니다 (민첩한 방법으로 초기 계획을 무시하고 싶지는 않지만). 우수한 자동 테스트 세트를 사용하면 더 큰 것을 변경하는 것이 더 안전 해 지므로보다 적은 선행 작업을 수행 할 수 있습니다.

또한 개인 및 생성 할 소프트웨어 유형에 대한 친숙도에 따라 다릅니다. 어느 시점에서 CRUD 앱을 주로 할 때 몇 가지 사양과 3 "x5"빈 메모지로 시작하는 전체 프로그램을 작성할 수 있습니다. 나는 지금 그렇게 쓰는 것을 쓸 수 없습니다.

여기서 유용한 용어는 MVP (최소 실행 가능 제품) 및 MMF (최소 시장 가능 기능)입니다. MMF는 비즈니스 가치를 제공하는 가장 작은 기능 버전입니다. MVP는 제품으로 실행 가능한 가장 적은 MMF입니다. 프로젝트를 시작할 때 MMF와 MVP를 식별하고 거기서 시작하는 것이 가장 좋습니다.

가능한 빨리 제품을 릴리스 한 다음 점진적으로 개선하십시오.