프리젠 테이션을 준비 중입니다. 내 주제는 혁신적인 소프트웨어 엔지니어링 방법론입니다. Agile은 현대적이고 혁신적인 방법론이지만 Agile에 대한 해답은 무엇입니까? 다른 혁신적이고 현대적인 방법론은 무엇입니까? 테스트 주도 개발 및 행동 주도 개발도 혁신적인 방법론입니까? 그리고 eXtreme Programming은 폭포와 같은 전통적인 방법론입니까?혁신적인 소프트웨어 엔지니어링 방법론
Google은 이러한 방법론이나 프레임 워크를 혁신적이고 전통적이며 다른 것으로 분류 할 수 있는지 확신 할 수 없습니다.
방법론이나 프레임 워크를 선택하는 것은 제품과 고객 요구에 완전히 달려 있습니다. 제품 요구 사항을 충족하고 팀에 효율성을 제공하는 제품은 그 범위에서 혁신적인 제품 일 수 있습니다.
대부분의 소프트웨어 개발 프로세스는 오늘날의 개발 환경에서이라는 복잡한 환경의 복잡한 제품을 개발 중입니다. 애자 일 방법론, 익스트림 프로그래밍, TDD 및 BDD은 복잡한 환경에서 복잡한 제품을 개발하기위한 이전 정의와 매우 잘 일치합니다. 따라서 민첩한 방법론의 대부분은 복잡한 제품을 개발하는 검사입니다.
애자일 방법론
용어 민첩한 소프트웨어 개발 전문가에 의해 사용되는 정말 인기있는 용어입니다. 민첩한 방법론, 스크럼, 칸반 (kanban) 또는 XP와 같은 프레임 워크가 많이 있습니다. 그들은 우리를 민첩하게 만드는 방법을 제안합니다. Agile이라는 용어는 모두이 방법을 다룹니다. 대부분은 예측, 적응, 투명성, 검사 및 경험적 프로세스를 해결합니다. 모든 민첩한 방법론은 소프트웨어 개발 중에 이러한 문제를 해결하려고합니다.
익스트림 프로그래밍
익스트림 프로그래밍은 자격을 갖춘 소프트웨어 제품을 개발하고 변화하는 요구 사항 및 환경에 채택에 초점을 맞추고 있습니다. 솔직히, 나는 XP를 정말로 좋아한다. 개발 방법론 만 제안하는 것은 아닙니다. 그것은 또한 고객 관리, 비용 관리 등에 관한 몇 가지 제안을합니다. 그것은 정말로 기본이지만 구현하기 어렵습니다. 나는 Extent Programming Explained by Kent Beck 책을 읽을 것을 강력하게 제안한다.
참조 : 투명성, 검사, 적응 :
Extreme Programming Explained, by Kent Beck
스크럼
스크럼은 경험적 프로세스 제어를 기반으로 소프트웨어 개발을위한 또 다른 프레임 워크입니다. 정말 간단하며 소프트웨어 개발 중 일부 역할과 이벤트를 정의합니다. 역할은 스크럼 마스터, 제품 소유자 및 개발 팀입니다. 이벤트는 스프린트 플래닝, 데일리 스크럼, 스프린트 리뷰 및 스프린트 회고전이다. 자세한 정보는 스크럼 가이드를 읽으십시오.
는
테스트 주도 개발
테스트 주도 개발은 소프트웨어 개발 과정을 참조하십시오. 나는 이것이 애자일 방법론 그 자체라고 말할 수 없다. 소프트웨어 개발이 민첩하게 진행될 수 있도록 도와줍니다. 테스트 주도 개발은 첫 번째 단계에서 테스트 할 개발자를 지원합니다. 테스트 주도 개발은 또한 모든 개발에 앞서 테스트를 생각할 수있는 마음이 필요합니다. 단위 테스트 만 쓰는 것이 아닙니다.
도 Test-driven development by Martin Fowler
참조
Test Driven Development: By Example, Kent Beck
행동 중심의 개발
그것은 다른 소프트웨어 개발 과정과 테스트 주도 개발에서 나타났다. 개발, 관리 및 고객과 같은 크로스 팀에 초점을 맞추어 요구 사항을 동일하게 이해할 수있는 도구 및 공유 프로세스를 공유합니다. BDD는 비즈니스 사람, 고객 및 기술 팀이 제품에 대해 동일한 이해를 가져야한다고 제안합니다. 고객 요구 사항은 사용자가 작성한 문장을 도구로 자동 테스트 할 수 있습니다.
도 참조
10 Tips for Writing Good User Stories
요약
애자 자체가 XP, 스크럼, 간판 (Kanban) 또는 기타 방법 또는 프레임 워크없이 누락 된 용어 . 모든 민첩한 방법론 또는 프레임 워크는 TDD, BDD 또는 연속 통합 없이도 누락됩니다. 이 모든 항목은 회사 문화, 고객 또는 사업자가 지원해야합니다. 프로젝트의 모든 이해 관계자는 프로젝트 이상의 제품에 대한 사고 방식을 가져야합니다. 그렇지 않으면 민첩한 방법론이 도움이되지 않을 수 있습니다.
마지막으로 나는 지속적인 통합에 대해 잘 이해하고 있음을 강력히 제안합니다.
난 당신이 사례, 방법론과 철학을 혼합하는 생각도
The Clean Coder: A Code of Conduct for Professional Programmers
참조하십시오.
새로운 혁신적인 소프트웨어 개발 방법을 찾으려면 큰 기술 회사와 그들이 어떻게하고 있는지 살펴볼 수 있습니다.
페이스 북을 생각해 봅시다. 그들은 Erik Meijer's GOTO 2015 video에서 설명한대로 "The hacker way"을 연습합니다. Erik에 따르면 Agile은 그렇지 않습니다. 대부분의 민첩한 프레임 워크에서와 마찬가지로 코드 작성에 중점을두고 있으며 코드에 대해 많은 이야기를하지 않습니다.
Spotify를 살펴보면 자체 조정 스케일링 "민첩한"구현이 있습니다. 외모는 정말 재미있어. the Spotify engineering culture video's.
하지만 정말 혁신적입니까? 아니면 그냥 사이클의 진화입니까?
이름이 더 이상 혁신적이지 않습니다. 대부분 10 세 이상입니다. 그들은 시도되고 테스트 된 개념이며, 일부는 그들을 사랑하고, 일부는 그것을 싫어하지만, 혁신적인 지옥은 아닙니다.
결국 소프트웨어 개발은 모든 솔루션에 맞는 하나의 크기가없는 프로세스입니다. 이는 코딩이 독창적 인 과정이기 때문에 표준화하기가 어렵습니다. 각 회사와 제품은 고유 한 경로를 찾아야합니다.
"애자일 (Agile)"은 다른 프로젝트가 실패한 (때로는 비용이 많이 드는) 곳에서 프로젝트가 성공 (또는 실패)하는 경향이있는 이유를 찾기 위해 함께 모인 사람들의 무리가 2001 년에 만든 용어입니다.
Agile Manifesto이 회의에서 나왔습니다. 밑에있는 사람들의 목록을 볼 수 있습니다. 스크럼, 크리스탈, XP, TDD 등과 같이 모두 "민첩"하다고 여겨지는 원칙, 방법 및 관행과 관련된 사람들이 많이 있습니다.
그래서 "민첩한"은 여러 가지 물건에 대한 포괄적 인 용어입니다 주요 값 다음에 오는 값은 principles입니다.
"방법론"이라는 단어는 많은 막연한 의미가 있으므로 그 근원으로 되돌릴 것입니다. 그것은 "방법"과 "ology"에서옵니다.
etymonline.com에서 어원이 포함되어 있습니다 : 교육이나 가고 ... 과학적 탐구 ... 조사 ... 추구하는 후 다음의
의 취급 하나의 행실Method: 정기적, 체계적인 치료 ... 방법. .. 여행, 길 .. 무엇이라도하는 길. 지식의
-ology: 지점, 과학
-logy: 말하기, 담론, 논문, 이론, 이론, 과학 ... 문자 나 말 또는 (특정 주제)
"Agile Methodology"는 소프트웨어 개발을 더 잘 수행하는 방법에 대한 여러 가지 가치, 원칙, 관행 및 아이디어를 포괄하는 용어입니다. 그 아이디어의 가르침; 그 아이디어의 다음과; 그 공동체를 둘러싼 사람들.
당신은 그들이 애자의 모든 부분이야 어떻게 볼 수 있도록 내가 빨리 당신이 언급 한 것들을 통해 갈 것이다:
이테스트 주도 개발 : 켄트 벡 (Kent Beck)과 함께 발생하는 XP의 일부, 대중화
행동 주도 개발 : Dan North에서 시작된, 기본적으로 "test"라는 단어가없는 TDD, 그것이 소리보다 심오한 것을 제외하고는. 확실히 민첩한 방법의 파생.
eXtreme 프로그래밍 : 또한 Kent Beck, TDD 소개, 확실히 애자 일.
폭포수 : 모든 것을 앞다투어 얻으려는 것으로 분명히 말하면서, 가 아니라 Agile.
그러나 다른 분야에서 나오는 것들이 많이 있습니다. 도요타의 린 제조 (Lean Manufacturing)에서 비롯된, 특히 데밍 (Deming)의 작업과 관련한 많은 린 (Lean) 지식 체계가이 공간에서 놀기 시작했습니다. 그래서 당신은 같은 것들을 얻을 :
아마도 당신이 찾고있는 것의 범위를 벗어나는 엄청난 다른 지식과 아이디어가 있습니다. 그래서 나는 인식을 높이기위한 용어를 버릴 것입니다.
제품 개발 : 영향 매핑, 스토리 매핑, 예 매핑, A/B 테스트
기술 흐름 : 개발 운영, 지속적인 통합, 연속 배포
사람과 심리학 : 댄 핑크의 "드라이브", Cynefin, 신경 다양성, 사회 자본
스케일 민첩한 방법 : 대규모 스크럼 (이하), 애자일 프레임 워크 (SAFE) 스케일, 징계 애자 납품 (DAD)
전략 : 린 캔버스, 엔터프라이즈 서비스 계획 (ESP), 사이먼 워 들리의 전략 지도.
여기의 용어 중 일부는 실제로 출현하며 아마도 변경 될 것입니다. 이 목록은 확실히 완전하지 않습니다. 주로 애질런트가 시작한 범위, 커뮤니티의 규모 및 진행 방향에 대한 아이디어를 제공하기 위해 이들을 포함 시켰습니다.
미래에는 더 이상 애자일이라고 부르지 않을 것이며, IM뿐 아니라 전체 비즈니스를 포함하여 끝날 것입니다. IMO는 환상적입니다. 기업의 경계를 넘어서 전 세계에 걸쳐 협력을 증진하기 시작했으며 다음 단계입니다.
프레젠테이션이 메모로 끝나면 나는 그것을 좋아할 것입니다.
_ "Agile Methodology"는 소프트웨어 개발 방법에 대한 가치, 원칙, 관행 및 아이디어를 모으는 포괄적 인 용어입니다. ** better ** _ - 나는 "better"라는 용어에 동의하지 않습니다. "민첩한 방법론"- 소프트웨어 개발 ** 민첩 **을 만드는 데 도움이되는 방법론입니다. "기민한"단어는 형용사입니다. 따라서 방법론을 통해 개발을 "신속하고 간편하게 진행할 수 있으며 향후 변경 사항에 신속하게 대응할 수 있습니다." – Fabio
"우리는 소프트웨어를 개발하고 다른 사람들을 돕는 방법으로 소프트웨어를 개발하는 방법을 발견했습니다." - http://agilemanifesto.org. "민첩"이라는 용어는 자신이하고있는 일을 후퇴 적으로 해결하려고 시도한 것입니다. 그것은 설명이 아니고 목표였습니다. – Lunivore
_ "애자일"은 다른 프로젝트가 실패한 곳에서 프로젝트가 성공한 이유를 연구하기 위해 함께 모인 사람들의 무리에 의해 2001 년에 만들어지는 용어입니다. 당시 C3가 나온 C3는 크라이슬러 관리자에 의해 실패한 것으로 간주되었습니다. 그 후에 방법론이 금지되었습니다. 이 프로젝트에는 애자일 서명자 몇 명이있었습니다. –
안녕하세요 @ Yusuf 저는 애플리케이션을 개발하는 동안 민첩하고 프로토 타이핑하는 방법을 주로 연구했습니다. 제 견해로 프로토 타이핑은 클라이언트와 다른 스택 홀더가 임의의 모델을 자유롭게 제안 할 수 있고 그 모델이 프로토 타입을 개발하는 데 사용될 수 있기 때문에 소프트웨어 엔지니어링 관행을 적용하는 가장 혁신적인 방법입니다. 그리고 스택 홀더가 원하는 소프트웨어를 얻을 때까지 계속됩니다. 게다가 나는 @erencan의 대답을 좋아하고 배웁니다.
그런 광범위한 목록은 위대한 목록 인 – sheidaei
을 볼 수있어서 좋았습니다. 고맙습니다. Scrum.org는 스크럼이 방법론이 아니라 프레임 워크라고 말하지만 "스크럼은 또 다른 방법론"이라는 응답으로 사용하고 있습니다. 이 [post] (https://www.scrum.org/About/All-Articles/articleType/ArticleView/articleId/658/Scrum-Framework-not-methodology) – hkulekci
당신은 rigth @hkulekci를 확인할 수 있습니다. 그에 따라 게시물을 업데이트했습니다. 당신의 도움을 주셔서 감사합니다. – erencan