민첩한 방법론이란 무엇입니까? [닫은]

27

민첩한 방법론에 대해 간단한 문장으로 설명 할 수 있습니까?

development-process agile

— key 키 파사 크
소스

3

대학의 CompSci 교사에 따르면 "폭포 방법, 더 빠름"

— Malfist

11

@Malfist는 뇌에 손상이 제한되는 학계에 머물기를 희망합니다 ;-)

— Steven A. Lowe

@Steven A. Lowe, 슬프게도, 우리 교과서의 세 번째 장은 "Agile Software Development"이고 여전히 그것이 무엇인지 전혀 모릅니다.

— Malfist

2

@Malfist 저는 1990 년대 중반 주요 도시의 큰 대학 캠퍼스에 있었고 CS 학장과 이야기하기 위해 방황했습니다. 그는 기분이 좋지 않고 기분이 좋았 기 때문에 우리는 예술의 상태와 그것이 대학 교과 과정에 어떻게 반영되는지에 대해 조금 이야기했습니다. 그는 "객체 지향 프로그래밍은 유행 일 뿐이며 여기서 가르치지 않는다"고 말했습니다. 너무 슬퍼.

— Steven A. Lowe

1

민첩한 방법론은 중국어와 같습니다. 배우기 전까지는 얻을 수 없습니다.)

— Job

22

애자일은 많은 것들과 관행이지만, 그 핵심은 단지 반복적 인 개발이라고 생각합니다.

반복 : 매우 작은 폭포를 생각해보십시오. 즉, 폭포 방법 (요구 사항-> 사양-> 코드-> 테스트)이지만 1 년 동안 수행하는 대신 몇 주 동안 수행하여 전체적으로 관리 가능한 덩어리를 만듭니다. 계획. '반복 / 스프린트 / 증가'가 끝나면 작지만 완벽하고 테스트 된 추가 기능 세트가 있습니다.

이를 통해 고객이 원하는 것이거나 비즈니스의 변화가 필요한 것이 아니라는 것이 밝혀지면 프로젝트 과정을 신속하게 변경할 수 있습니다. 따라서 "민첩한"이라는 용어가 사용됩니다.

— 어부
소스

이것은 실제로 정답이 아닙니다. 애자일은 방법론이 아니라 철학입니다.

— RibaldEddie

32

애자일 선언문보다 더 나은 것은 없다고 생각합니다.

우리는
소프트웨어를 수행하고 다른 사람들이 소프트웨어 를 개발하도록함으로써 소프트웨어 를 개발하는 더 좋은 방법을 발견 하고 있습니다.
이 사업을 통해 우리는 가치를 얻게되었습니다.

프로세스 및 도구를 통한 개인 및 상호 작용 포괄적 인 문서를 통한
소프트웨어 작업 계약 협상을 통한
고객 협업 계획에 따라
변경 에 응답

즉,
오른쪽 에있는 항목 에는 가치가 있지만 왼쪽에있는 항목은 더 중요하게 생각합니다.

에서 http://agilemanifesto.org/

— 앤디 로리
소스

1

유일한 단점은 나쁜 프로세스를 보지 않으면 선언문 자체가 정의를 수행하지 않는다는 것입니다. 실제로 선언문이 얼마나 많은지를 얻으려면 나쁜 것과 비교해야합니다. 요즘에는 너무 많은 사람들이 애자일과 스크럼을 혼동하기 때문에 +1입니다. 그럼에도 불구하고 그들은 스크럼과 스크럼 + XP를 혼동하고 있습니다.

— MIA

2

하지만 애자일은 때때로 모순 될 수 있습니다. 기본적으로 "우리는 유연성을 중시하지만 그 유연성을 얻는 데 필요한 도구와 프로세스를 평가 절하합니다". 변화에 대응하기 위해서는 훌륭하고 유연한 도구가 필수적입니다. 예를 들어 Ruby-on-Rails 마이그레이션과 데이터 모델을 간단히 변경하기 위해 일주일이 소요될 수있는 누군가의 수제 반 베이크 ORM 시스템.

— user8865

2

"개인 및 상호 작용"이 "프로세스 및 도구"를 어떻게 대체 할 수 있는지, 또는 "작업 소프트웨어가 포괄적 인 문서를 위반할 수있는"방법이 궁금하십니까? 이것들은 모두 다른 것들입니다 ... 걱정하지 마라. 나는 애자일과 사랑에 빠지지 않았다.

— NoChance

13

나에게 가장 중요한 아이디어는 다음과 같습니다.

우리는 필요한 것 (프로젝트의 시작)에 대한 지식이 부족한 상황에서 소프트웨어를 설계해야하기 때문에 요구 사항이 변경 될 것입니다.

전통적인 (Waterfall) 접근 방식 은 프로젝트 시작시 모든 사람이 포괄적 인 사양에 서명함으로써 계약에 모든 사람을 고정시켜 이러한 변화를 완화하려고합니다. 이것은 CYA로 작동 할 수 있지만 사용자의 요구에 맞지 않는 것을 "행복하게 사인온!"

민첩한 방법 은 개발 팀을 막지 않고 피할 수없는 변화를 수용하도록 설계되었습니다. 여러 가지 방법으로이 작업을 수행하며, 그 중 가장 중요한 것은 프로세스의 이해 관계자가 반복적으로 개발하고 지속적으로 참여하는 것입니다. 내 경험상 하드 코어 플래너 인 일부 관리 유형에는 더 불편할 수 있지만 결국에는 모든 사람이 더 행복해집니다.

— JohnFx
소스

6

한 문장에서 이것은 다음과 같습니다.

애자일 소프트웨어 개발은 반복 적이고 점진적인 개발 에 기반한 소프트웨어 개발 방법론 그룹으로 , 요구 사항과 솔루션 은 자체 구성, 부서 간 팀 간의 협업 을 통해 발전 합니다 .

이것은 wikipedia 정의에서 나 왔으며 매우 좋아합니다. 핵심 원칙을 강조했습니다.

3

Agile이 아닌 것을 추가하고 싶습니다. 애자일이라고 주장하는 많은 상점이 있지만 단지 프로젝트 계획에 관심이 없으며 부당하게 짧은 시간 안에 일을 기대한다는 의미입니다.

Agile! = 프로젝트 계획이 없습니다. 성명서가 허위라고 생각하는 사람들은 관리 유형 인 경향이 있고 항상 모순되기 쉬운 것은 아니기 때문에 다루기가 어렵습니다.

— q303
소스

지금까지 질문을 한 이후로 나는 그러한 회사 중 일부에 속해 있으며 귀하에게 동의합니다.

— Chankey Pathak

동의했다. 민첩한 많은 사람들이 일을하는 가장 저렴한 방법입니다.

— SmallChess

2

Andy는 이미 Agile Manifesto와 연결되어 있습니다.

애자일 선언문의 출처를 살펴 보는 것이 도움이된다고 생각합니다. XP (Extreme Programming), Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming ( Alistair Cockburn의 목록)과 같은 몇 가지 공통된 요소와 많은 동기가있는 방법론이 많이 있었습니다. 그 방법론을 제안하는 사람들은 그들이 말하고있는 것의 힘이 향상되도록 공통된 것들을 다루기 위해 마케팅 용어를 생각해 내기로 결정했습니다.

흥미롭게도 (누군가의 말에 따르면) "애자일"대신에 선정 될 수있는 후보 명단에 여러 이름이있었습니다. 그 중 하나는 "적응"이었습니다. 저는 개인적으로 민첩성이 실제로 "민첩한"것보다 더 나은 것을 요약하는 단어로 생각합니다!

— 핀 앤크
소스

2

민첩한 방법론을 사용하면 제품 개발의 다른 측면보다 우수한 품질의 제품을 제공하는 데 중점을두고 사용자 커뮤니티의 피드백이 양질의 제품을 만드는 데 매우 중요하다는 것을 깨닫게됩니다.

구현을 강조하지 않고 제품을 개발에서 릴리스로 전환하면서 선행 설계, 문서 및 인터페이스 정의를 강조하는 전통적인 / 폭포 개발 접근 방식과 대조하십시오.

제 생각에는 팀이 제품에 구축 할 수있는 본질적인 품질이 있다고 생각합니다. 이는 제품이 개발 팀의 의도에 따라 기능하고 예측 가능한 향상을 합리적으로 수용 할 수 있는지 확인하는 형식을 취하는 것으로 보입니다. 제품이 사용자의 요구를 얼마나 잘 충족시키는지를 측정하는 인식에 전적으로 근거한 품질 요소도 있습니다.

애자일 방식은 제품을 제공하는 경향이 반복적으로 각 반복에 사용자의 피드백 및 개발자의 피드백을 통합하고, 촉진 제공 이 실현 경우 기능이 각각 증가를 최소한의 생존을 유도하기 위해 강제 함수로 자주 사용자의 피드백을 하고 동안 계속하기 위해 개발 활동의 경향을 방해 사용자의 피드백없이 장기간 내 생각에, 민첩한 접근 방식의 다른 측면은 이러한 핵심 교리를지지하는 경향이 있습니다.

빈번한 고객 협업을 강조하면 사용자 피드백을 생성하는 동시에 요구 사항의 변화에 유연하게 대응하여 제품 개발에서 해당 피드백을 정기적으로 통합 할 수 있습니다.
관련 배포 구성 및 환경에 빈번히 통합하면 제품이 가치 있고 피드백을 제공하는 사용자와 관련이 있는지 확인하기 위해 어떤 구성 및 환경이 관련성이 있는지 지속적으로 식별 할 수 있습니다.
자체 조직화 및 부서 간 팀 홍보는 팀 내에서 개인 책임을 작성하고 팀 내에서 사전 할당 된 역할 및 관리 계층에 의해 유지되지 않고 효율적으로로드 블록을 제거하는 방법을 결정할 수있는 권한을 부여합니다.

— 떡
소스