민첩한 방법론에 대해 간단한 문장으로 설명 할 수 있습니까?
답변
애자일은 많은 것들과 관행이지만, 그 핵심은 단지 반복적 인 개발이라고 생각합니다.
반복 :
매우 작은 폭포를 생각해보십시오. 즉, 폭포 방법 (요구 사항-> 사양-> 코드-> 테스트)이지만 1 년 동안 수행하는 대신 몇 주 동안 수행하여 전체적으로 관리 가능한 덩어리를 만듭니다. 계획. ‘반복 / 스프린트 / 증가’가 끝나면 작지만 완벽하고 테스트 된 추가 기능 세트가 있습니다.
이를 통해 고객이 원하는 것이거나 비즈니스의 변화가 필요한 것이 아니라는 것이 밝혀지면 프로젝트 과정을 신속하게 변경할 수 있습니다. 따라서 “민첩한”이라는 용어가 사용됩니다.
답변
애자일 선언문보다 더 나은 것은 없다고 생각합니다.
우리는
소프트웨어를 수행하고 다른 사람들이 소프트웨어 를 개발하도록함으로써 소프트웨어 를 개발하는 더 좋은 방법을 발견 하고 있습니다.
이 사업을 통해 우리는 가치를 얻게되었습니다.
프로세스 및 도구를 통한 개인 및 상호 작용 포괄적 인 문서를 통한
소프트웨어 작업 계약 협상을 통한
고객 협업 계획에 따라
변경 에 응답
즉,
오른쪽 에있는 항목 에는 가치가 있지만 왼쪽에있는 항목은 더 중요하게 생각합니다.
답변
나에게 가장 중요한 아이디어는 다음과 같습니다.
우리는 필요한 것 (프로젝트의 시작)에 대한 지식이 부족한 상황에서 소프트웨어를 설계해야하기 때문에 요구 사항이 변경 될 것입니다.
전통적인 (Waterfall) 접근 방식 은 프로젝트 시작시 모든 사람이 포괄적 인 사양에 서명함으로써 계약에 모든 사람을 고정시켜 이러한 변화를 완화하려고합니다. 이것은 CYA로 작동 할 수 있지만 사용자의 요구에 맞지 않는 것을 “행복하게 사인온!”
민첩한 방법 은 개발 팀을 막지 않고 피할 수없는 변화를 수용하도록 설계되었습니다. 여러 가지 방법으로이 작업을 수행하며, 그 중 가장 중요한 것은 프로세스의 이해 관계자가 반복적으로 개발하고 지속적으로 참여하는 것입니다. 내 경험상 하드 코어 플래너 인 일부 관리 유형에는 더 불편할 수 있지만 결국에는 모든 사람이 더 행복해집니다.
답변
한 문장에서 이것은 다음과 같습니다.
애자일 소프트웨어 개발은 반복 적이고 점진적인 개발 에 기반한 소프트웨어 개발 방법론 그룹으로 , 요구 사항과 솔루션 은 자체 구성, 부서 간 팀 간의 협업 을 통해 발전 합니다 .
이것은 wikipedia 정의에서 나 왔으며 매우 좋아합니다. 핵심 원칙을 강조했습니다.
답변
Agile이 아닌 것을 추가하고 싶습니다. 애자일이라고 주장하는 많은 상점이 있지만 단지 프로젝트 계획에 관심이 없으며 부당하게 짧은 시간 안에 일을 기대한다는 의미입니다.
Agile! = 프로젝트 계획이 없습니다. 성명서가 허위라고 생각하는 사람들은 관리 유형 인 경향이 있고 항상 모순되기 쉬운 것은 아니기 때문에 다루기가 어렵습니다.
답변
Andy는 이미 Agile Manifesto와 연결되어 있습니다.
애자일 선언문의 출처를 살펴 보는 것이 도움이된다고 생각합니다. XP (Extreme Programming), Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming ( Alistair Cockburn의 목록)과 같은 몇 가지 공통된 요소와 많은 동기가있는 방법론이 많이 있었습니다. 그 방법론을 제안하는 사람들은 그들이 말하고있는 것의 힘이 향상되도록 공통된 것들을 다루기 위해 마케팅 용어를 생각해 내기로 결정했습니다.
흥미롭게도 (누군가의 말에 따르면) “애자일”대신에 선정 될 수있는 후보 명단에 여러 이름이있었습니다. 그 중 하나는 “적응”이었습니다. 저는 개인적으로 민첩성이 실제로 “민첩한”것보다 더 나은 것을 요약하는 단어로 생각합니다!
답변
민첩한 방법론을 사용하면 제품 개발의 다른 측면보다 우수한 품질의 제품을 제공하는 데 중점을두고 사용자 커뮤니티의 피드백이 양질의 제품을 만드는 데 매우 중요하다는 것을 깨닫게됩니다.
구현을 강조하지 않고 제품을 개발에서 릴리스로 전환하면서 선행 설계, 문서 및 인터페이스 정의를 강조하는 전통적인 / 폭포 개발 접근 방식과 대조하십시오.
제 생각에는 팀이 제품에 구축 할 수있는 본질적인 품질이 있다고 생각합니다. 이는 제품이 개발 팀의 의도에 따라 기능하고 예측 가능한 향상을 합리적으로 수용 할 수 있는지 확인하는 형식을 취하는 것으로 보입니다. 제품이 사용자의 요구를 얼마나 잘 충족시키는지를 측정하는 인식에 전적으로 근거한 품질 요소도 있습니다.
애자일 방식은 제품을 제공하는 경향이 반복적으로 각 반복에 사용자의 피드백 및 개발자의 피드백을 통합하고, 촉진 제공 이 실현 경우 기능이 각각 증가를 최소한의 생존을 유도하기 위해 강제 함수로 자주 사용자의 피드백을 하고 동안 계속하기 위해 개발 활동의 경향을 방해 사용자의 피드백없이 장기간 내 생각에, 민첩한 접근 방식의 다른 측면은 이러한 핵심 교리를지지하는 경향이 있습니다.
- 빈번한 고객 협업을 강조하면 사용자 피드백을 생성하는 동시에 요구 사항의 변화에 유연하게 대응하여 제품 개발에서 해당 피드백을 정기적으로 통합 할 수 있습니다.
- 관련 배포 구성 및 환경에 빈번히 통합하면 제품이 가치 있고 피드백을 제공하는 사용자와 관련이 있는지 확인하기 위해 어떤 구성 및 환경이 관련성이 있는지 지속적으로 식별 할 수 있습니다.
- 자체 조직화 및 부서 간 팀 홍보는 팀 내에서 개인 책임을 작성하고 팀 내에서 사전 할당 된 역할 및 관리 계층에 의해 유지되지 않고 효율적으로로드 블록을 제거하는 방법을 결정할 수있는 권한을 부여합니다.