E D R , A S I H C RSS

BackLinks search for "ExtremeProgramming"

BackLinks of ExtremeProgramming


Search BackLinks only
Display context of search results
Case-sensitive searching
  • 1002/Journal
         MMM 에서의 제목에 해당하는, 그리고 참으로 자주 인용되는 브룩스 법칙이 나왔다. Communication 비용, 분업화 되기 힘든 일에 대한 비용 문제. ExtremeProgramming 의 관점으로 다시 바라보고 비판하고 싶지만, 아직은 고민하고 얻어내야 할것이 더 많기에.
  • AcceptanceTest
         원문 : http://extremeprogramming.org/rules/functionaltests.html
         ["ExtremeProgramming"]
  • CodingStandard
         ["ExtremeProgramming"]
  • CollectiveOwnership
         ["ExtremeProgramming"]
  • ContinuousIntegration
         [ExtremeProgramming]
  • ExtremeBear
         ["ExtremeProgramming"] 을 실전과 같이 경험해 보기 위한 스터디.
  • ExtremeProgramming
         ExtremeProgramming 은 경량개발방법론으로서, RUP 등의 방법론에 비해 그 프로세스가 간단하다. XP 에서의 몇몇 개념들은 일반적인 프로그래밍에서도 유용하게 쓰일 수 있다. 특히 TestDrivenDevelopment(TestFirstProgramming) 의 개념과 Refactoring, UnitTest는 초기 공부할때 혼자서도 실습을 해볼 수 있는 내용이다. 개인 또는 소그룹의 훈련으로도 이용할 수 있을 것이다.
         http://extremeprogramming.org/map/images/project.gif
          * http://extremeprogramming.org - 처음에 읽어볼만한 전체도.
          * [http://www.trireme.com/whitepapers/process/xp-uml/xp-uml-short_files/frame.htm eXtremeProgrammingMeetsUML] - 아직 읽어보지 않았음.
  • ExtremeProgrammingExplained
         ExtremeProgramming 의 철학을 소개한 서적. 저자 KentBeck. TheThreeExtremos 중 한명. 얼마전에 2판이 나왔다.
         [책분류] [ExtremeProgramming] [ExtremeProgrammingInstalled] [ExtremeProgrammingExplained2/E]
  • HowTo
         2013년 11월 중순, ZeroWiki는 어느새 수기집처럼 변해 버렸다. 위키를 뒤지다 보면 훨씬 잘 정리된 페이지들[* 예) [ExtremeProgramming], [LittleAOI], [디자인패턴]]을 발견할수 있지만 그런페이지들을 일부러 찾아 가지 않는 한 접근하기가 쉽지 않다. 그 이유중 하나는 그 페이지들을 찾아 볼 필요가 없기 때문이다. 제로 위키의 내용은 훌륭하긴 하지만 위키를 찾아 헤매는 대신 구글에서 검색하는것이 빠르다. 그렇다면 우리가 이 위키를 버려야 하는가 아니면 지금 이대로 수기집으로 놓아두어야 하는가. 수기집이 좋지 않다는 말은 아니다. 위키가 점점 수기집으로 변하면서 더이상 조직화된 정보가 쌓이지 않는다는 것이 문제이다. 더불어 수기집에서 이전의 좋은 정보로 가는 링크가 부족하다. 이는 위키에 단편적인 정보를 쌓기만 했지 정리하지 않았기 때문이다. 이런 파편화 된 위키를 정리하기 위해서는 구글검색과는 다르면서 이전 정보들로 갈수 있는 창구가 필요하다. 그래서 이 HowTo를 시작하기로 마음 먹었다. 단, 좀더 책임감 있고 좋은 정보 조직화를 위해 contribute를 도입하면 어떨까라는 생각이 든다. 지금의 오픈소스처럼 누구나 자유롭게 수정할수 있되 그 줄을 누가 수정했는지 이 문서에 기여한 사람은 누구인지 적어보자는 말이다. 그리하면 좀더 나은 위키가 될수 있으리라 믿는다. - [안혁준]
  • HowTo/StartProject
         [ExtremeProgramming]
  • HowToStudyXp
         ExtremeProgramming을 어떻게 공부할 것인가
          * http://groups.yahoo.com/group/extremeprogramming
          * http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
  • IeeeSoftware
         최근에 소개된 시만틱 웹(Sematic Web)이나 ExtremeProgramming도 비슷했다. 외국에서는 몇 년 전부터 한참을 떠들어서 이제는 시들해진 느낌까지 드는데, 마소가 소개하지 않으면 국내에는 없는 기술이다. 아무도 관심을 갖지 않는다. 나는 이걸 프로그래머들의 집단심리(Mob Psychology)라고 부른다.
  • IterationPlanning
         ["ExtremeProgramming"]
  • KentBeck
         ExtremeProgramming의 세 명의 익스트리모 중 하나. CrcCard 창안. 알렉산더의 패턴 개념(see also DesignPatterns)을 컴퓨터 프로그램에 최초 적용한 사람 중 하나로 평가받고 있다.
  • LearningToDrive
         ["ExtremeProgramming"]
  • MockObjects
         ["ExtremeProgramming"], ["UnitTest"]
  • NewTestsForOldBugs
         ["ExtremeProgramming"]
  • ObjectWorld
         첫번째 Session 에는 ["ExtremeProgramming"] 을 위한 Java 툴들에 대한 간단한 언급이였습니다. 제가 30분 가량 늦어서 내용을 다 듣진 못했지만, 주 내용은 EJB 등 웹 기반 아키텍쳐 이용시 어떻게 테스트를 할것인가에 대해서와, Non-Functional Test 관련 툴들 (Profiler, Stress Tool) 에 대한 언급들이 있었습니다. (JMeter, Http Unit, Cactus 등 설명)
         Http Unit 에 대해선 좀 회의적인 투로 설명을 하신것 같고, (이정도까지 테스트 할까..에 가까운) ["ExtremeProgramming"] 에서의 TDD 스타일은 따로 취급되었다라는 생각이 들었다는. (XP에서의 테스트를 먼저 작성하라는 이야기에 대해서 그냥 TP를 읽는 수준으로만 넘어간것 보면. 코딩 완료이후 테스트를 기본이라 생각하고 설명하셨다 생각됨.)
         [From a [http://groups.yahoo.com/group/extremeprogramming/message/52458 thread] in XP mailing list]
  • PairProgramming
          * ExtremeProgrammingPlanning 이라는 책을 보면 해결책을 구할 수 있을 것 같다. (Xp 책들의 장점이자 단점이라면 얇은 두께의 분책이려나.. --a)
         ["ExtremeProgramming"]
  • PairProgrammingForGroupStudy
         PairProgramming이란 ExtremeProgramming이라고 하는 새로운 소프트웨어 개발 방법론의 한가지 기법으로, 두명이 한 컴퓨터를 이용해서 같이 프로그래밍을 하는 것을 말합니다.
  • PairProgramming토론
         PairProgramming 자체에 대해 조금 설명을 드리자면, 우선 이건 Driver와 Observer로 역할 분담이 되는데 정해진 게 아니고, 계속 바뀝니다. 운전하는 사람이 있고, 옆에서 코치하는 사람이 있는 거죠. 실제로 타이핑을 하는 사람은 타이핑이란 작업에 몰두하느라 지력을 좀 빼앗깁니다. 대신 이걸 관찰하는 사람은 여유가 있으므로 이것 저것 객관적인 코치를 해줄 가능성이 높죠. 그런데, 예를 들어, Driver가 코딩을 하다가 Observer가 "그게 아냐 이렇게 하면 더 좋아"하면서 설명을 하는데 잘 이해를 못하겠다 싶으면 키보드를 밀어주며 "니가 해봐"라고 말합니다. 역할 바꾸기가 되는 거죠. 이게 아니더라도, 가능하면 두 사람이 지속적으로 역할 바꾸기를 하면 좋습니다. (ExtremeProgramming에선 타이머를 이용해서 정해진 시간이 되면 역할 바꾸기를 하는 예도 있습니다) 뭐 어찌되었건, 피곤하다 싶거나 지금 머리가 잘 안돌아간다 싶으면 옆 사람에게 키보드를 넘기면 되죠.
  • PersonalHistory
          * [XpWeek] - 2004년 겨울방학 ExtremeProgramming 체험하기
  • ProjectPrometheus/Journey
          * 예전에 일할때 잘못했었던 실수를 다시하고 있으니, 바로 기획자와의 대화이다. Iteration 이 끝날때마다 개발자가 먼저 기획자 또는 고객에게 진행상황을 이야기해야 한다. 특히 ExtremeProgramming 의 경우 Iteration 이 끝날때마다 Story 진행도에 대화를 해야 한다. Iteration 3 가 넘어가고 있지만 항상 먼저 전화를 한 사람이 누구인가라고 묻는다면 할말이 없어진다. 이번 Iteration 만큼은 먼저 전화하자;
  • PyUnit
         ["UnitTest"], ["ExtremeProgramming"]
  • PythonLanguage
          * '''ExtremeProgramming 과 잘 어울린다.'''
  • REFACTORING
         그리고 Refactoring 을 이해하는데 ExtremeProgramming 을 이해하면 도움이 될 것이다.
  • Refactoring/BuildingTestCode
         테스팅 코드는 ExtremeProgramming 의 중요한 부분이다. [Beck, XP]. 이 이름은 빠르고 게으른 해커같은 프로그래머들에겐 마술주문과 같을 것이다. 하지만, extreme programmer들은 테스트에 대해 매우 헌신적이다. 그들은 가능한 한 소프트웨어가 빠르게 발전하기 원하고, 그들은 테스트들이 당신을 아마 갈 수 있는 한 빠르게 갈 수 있도록 도와줄 것을 안다.
  • RegressionTesting
         RegressionTesting는 ExtremeProgramming 소프트웨어 개발 방법론의 필수적인 부분이다. 소프트웨어 개발 주기에서 매번 마다 모든 소프트웨어 패키지들에 대하여 광범위하고, 반복적이고, 자동화된 전체 소프트웨어에 테스트를 통하여 그러한 디자인 문서들이 교체된다.
  • RonJeffries
         ExtremeProgramming의 세 명의 익스트리모 중 하나
  • SimpleDesign
         ["ExtremeProgramming"]
  • SoftwareEngineeringClass
         시간이 나면 ExtremeProgramming에 대해서도 이야기를 하신다는데, 어떤 이야기가 나올지 궁금하네요. [SPICE] 레벨4는 되어야 사용할 수 있다는 말엔 조금 당황스러웠어요. --[Leonardong]
  • SpikeSolution
         ["ExtremeProgramming"]
  • StandUpMeeting
         ExtremeProgramming
  • TestFirstProgramming
         ExtremeProgramming에서는 UnitTest -> Coding -> ["Refactoring"] 이 맞물려 돌아간다. TestFirstProgramming 과 ["Refactoring"] 으로 단순한 디자인이 유도되어진다.
          * wiki:Wiki:ExtremeProgrammingUnitTestingApproach
         ["ExtremeProgramming"]
  • TheCowboyWay
         See Also: ExtremeProgramming
  • UnitTest
         ExtremeProgramming 에서는 TestFirstProgramming 을 한다. TestFirstProgramming 에서는 해당 기능에 대한 테스트 프로그램을 먼저 만들고, 실제 프로그래밍을 한다.
         TestFirstProgramming 을 하게 되면 해당 프로그램을 작성해 나가는 과정이 UnitTest 작성중 남게 된다. 이는 일종의 WhiteBoxTesting 이 된다. 또한, 해당 모듈이 제대로 돌아가는지에 대한 결과도 체크하므로 BlackBoxTesting 의 역할을 한다. 즉, ExtremeProgramming 에서의 UnitTest 는 두가지 테스트의 성격을 같이 포함하고 있다. (Gray Box Testing)
         ["ExtremeProgramming"]
  • UserStory
         ["ExtremeProgramming"]
  • WardCunningham
         ExtremeProgramming의 세 명의 익스트리모 중 하나. WikiWiki 창안자.
  • WikiProjectHistory
         || ["ExtremeProgramming"] || ["1002"] || 2002.1.9~1.31. ExtremeProgramming 에 대한 개념이해 & 정리 ||종료||
  • XPlanner
          ExtremeProgramming 팀을 위한 웹-기반 프로젝트 관리도구, 위키 스타일의 포매팅도 지원한다고 한다.
  • XpWeek
         한 주 동안 ExtremeProgramming을 '''최대한''' 체험해보기.
         See also [ExtremeBear],[ExtremeProgramming]
  • XpWeek/ToDo
         ExtremeProgramming 개발주기를 참조
  • XperDotOrg
         국내 ExtremeProgramming 사용자(?) 모임.
  • ZP도서관
         || ExtremeProgramming Installed || Ron Jeffries, Ann Anderson, Chet Hendrickson || Addison-Wesley || 도서관 소장 || 개발방법론 ||
  • comein2
          * ExtremeProgramming 관련 UnitTest , Refactoring
  • 가독성
         가독성은 개인취향이라고 생각합니다. 제 경우는 C, C++에서 { 를 내리지 않는 경우보단 내리는 경우가 더 보기 편하고, JavaLanguage 에서는 내리지 않는게 더 편하답니다. 애초에 CodingConventions 이라는 것이 존재하는 것도 통일된 코딩규칙을 따르지 않고 개인취향의 코드를 만들어내다 보면 전체적으로 코드의 융통성이 결여되고 가독성또한 전체적으로 떨어지는 문제를 미연에 방지하기 위함이라고 생각합니다. 특히나 ExtremeProgramming 의 경우처럼 CollectiveOwnership 을 중요한 프랙티스 중의 하나로 규정한 방법론에서는 CodingConventions 과 같은 공동소유의 산출물에 대한 규칙이 더윽 중요하다고 생각됩니다. 요는, { 를 내리느냐 내리지 않느냐가 가독성이 높냐 낮냐를 결정짓는 것이 아니고 가독성이라는 하나의 평가요소의 가치는 개인에 따라 달라질 수 있다는 것입니다. - 임인택
  • 데블스캠프2004/세미나주제
          * 개발 방법론( ExtremeProgramming )
  • 방울뱀스터디
          * [ExtremeProgramming]의 몇가지를 실천할 것입니다. [PairProgramming], [Refactoring]...
  • 분류패턴
          * 프로젝트로부터 분파된 페이지들은 분류링크에 해당 프로젝트를 적는다. 그렇게 함으로서 해당 프로젝트와 관련된 페이지들을 분류패턴을 이용, 묶을 수 있다. (ex - ExtremeProgramming 쪽) 분류는 여러개를 두어도 상관없다.
  • 새싹배움터05
          C, 발표잘하는법, PPT제작 기법, [Python], [PHP], [ExtremeProgramming], ToyProblems, Linux, Internetworking(TCP/IP), Ghost(demonstration), OS(abstraction), OS+Windows, Embedded System, 다양한 언어들(Scheme, Haskell, Ruby, ...), 보안(본안의 기본과 기초, 인터넷 뱅킹의 인증서에 대해..), C언어 포인터 특강(?), 정보검색(검색 엔진의 원리와 구현), 컴퓨터 구조(컴퓨터는 도대체 어떻게 일을 하는가), 자바 가상머신 소스 분석
          [PythonLanguage], [PHP] (WebProgramming), [ExtremeProgramming] (XP를 적용시켜 코드가 아닌 다른 무언가를 만들어 보자 -_-a ), Ghost 사용법, 발표잘하는법, PPT제작비법, OS개발
          음 어떤게 좋을까요?? 많아 보였는데 실제로 하려고 생각하면 몇가지 없기도 하네요. 가능한 주제를 먼저 골라보면... [Python], [ExtremeProgramming] 이 대표적인데... - [톱아보다]
  • 지도분류
         ||["ExtremeProgramming"]|| Agile Methodology 인 ExtremeProgramming 에 대한 전반적 설명||
  • 프로젝트
          * [XpWeek] - 2004년 겨울방학 ExtremeProgramming 체험하기
  • 프로젝트기록의필수요소토론
         [1002] 프로젝트 이름에 대해서 한마디 한다면, 'Java', 'ExtremeProgramming' 은 공부하려고 하는 지식의 종류이지 프로젝트의 이름으로 부적절하다고 봅니다. 만일 Java Study 팀이 두 개인 경우라면? 문제가 발생할 수 밖에 없습니다. 초창기에 해당 기술부분으로 페이지를 열 수는 있지만, 나중에 프로젝트가 끝나고 난다음에는 일반화시켜서 본래의 이름을 반환해주는 것이 좋다고 생각합니다. (즉, 'Java' 페이지는 Java 에 대한 소개나 기술 등을 넣어주고, 'Java' 페이지이름을 썼던 프로젝트팀은 프로젝트팀 이름의 새 페이지를 만들어서 경과보고를 하는식으로..)
Found 53 matching pages out of 7540 total pages

You can also click here to search title.

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2021-02-07 05:23:15
Processing time 0.0289 sec