BackLinks of SpikeSolution

• ExtremeProgramming
       초기 Customer 요구분석시에는 UserStory를 작성한다. UserStory는 추후 Test Scenario를 생각하여 AcceptanceTest 부분을 작성하는데 이용한다. UserStory는 개발자들에 의해서 해당 기간 (Story-Point)을 예측(estimate) 하게 되는데, estimate가 명확하지 않을 경우에는 명확하지 않은 부분에 대해서 SpikeSolution 을 해본뒤 estimate을 하게 된다. UserStory는 다시 Wiki:EngineeringTask 로 나누어지고, Wiki:EngineeringTask 부분에 대한 estimate를 거친뒤 Task-Point를 할당한다. 해당 Point 의 기준은 deadline 의 기준이 아닌, programminer's ideal day (즉, 아무런 방해를 받지 않는 상태에서 프로그래머가 최적의 효율을 진행한다고 했을 경우의 기준) 으로 계산한다.
        * SpikeSolution: 주어진 문제에 대한 구현의 난이도를 예측하기 위한 작은 실험 프로그래밍.
• FreechalAlbumSpider
       각 모듈들이 서로 불러져야 할 순서들을 정하고 난뒤, 내가 만든 각 모듈들을 일종의 SpikeSolution 처럼 라이브러리 연습하듯이 이용해보았다. 그러면서 잠시 놓쳤던 흐름을 다시 잡았다. 이러한 일들을 의식적으로, 그리고 '무엇을 할까 - 이것을 하자' 라고 생각해낼 수 있었던 것이 기분을 참 좋게 했다.
• MineFinder
        * 지뢰찾기 프로그램의 윈도우 핸들을 얻고 해당 메세지를 보내어서 지뢰찾기 프로그램을 구동하는 루틴 관련 SpikeSolution. (아.. UnitTest 코드 넣기가 애매해서 안넣었다. 궁리해봐야 할 부분같다.)
        * 지뢰찾기 프로그램의 윈도우 핸들을 얻은뒤 DC를 얻은후 화면 캡쳐. 그리고 캡쳐한 비트맵을 근거로 하여 데이터로 변환하는 루틴 관련 SpikeSolution
        * 지금쯤 다시 짜라고 한다면 TFP를 좀 더 제대로 추구할 수 있을 것도 같다. (이 점에서 TFP를 할때 SpikeSolution 에 대한 어느정도의 충분한 시간을 두는 점이 좋을 것 같다는 생각이 들었다. 초기 SpikeSolution 으로 해당 부분을 간단하게 대강 해보고, Test를 할 수 있는 부분에 대한 구체화하기.)
• PairProgramming
        * 자존심문제? - Pair를 의식해서여서인지 상대적으로 Library Reference나 Tutorial Source 를 잘 안보려고 하는 경향이 있기도 하다. 해당 부분에 대해서 미리 개인적 또는 Pair로 SpikeSolution 단계를 먼저 잡고 가벼운 마음으로 시작해보는 것은 어떨까 한다.
       1002는 VNC와 넷미팅 (그때 넷미팅 화면공유시 XP가 뻗었던 관계로. -_-;) 을 이용, Python을 공유해서 다른 곳에 있는 사람과 SpikeSolution 을 VPP로 시도한 적이 있다. VNC가 화면 refresh가 느리다는 단점 빼고는 별다른 지장이 없었다. 모르는 라이브러리들을 Pair 하는 사람이 다운받아주고, 라이브러리를 설치하고. 모르는 것은 Pair 에게 물어보고, 어떻게 만들까 토론했던 경험이 좋았다.
• ProgrammingContest
       만약 팀을 짠다면 두사람은 PairProgramming으로 코딩을 하고(이 때 Interactive Shell이 지원되는 인터프리터식 언어라면 엄청난 플러스가 될 것임), 나머지 하나는 다른 문제를 읽고 이해하고, (가능하면 단순한) 알고리즘을 생각하고 SpikeSolution을 종이 위에서 실험한 뒤에 현재 커플이 완료를 하면 그 중 한 명과 Pair Switch를 하고 기존에 코딩을 하던 친구 중 하나는 혼자 다른 문제를 읽고 실험을 하는 역할을 맡으면 효율적일 겁니다. 즉, 두 명의 코더와 한 명의 실험자로 이루어지되 지속적으로 짝 바꾸기를 하는 것이죠.
• ProjectPrometheus/Iteration4
       || Data Base 접근 SpikeSolution || 1 || ○ ||
• ProjectPrometheus/Journey
        * Iteration 2 에 대한 SpikeSolution 계속 진행
        * Iteration 2. Recommendation System 에 대한 SpikeSolution
       알고리즘에 대한 SpikeSolution 에 대해서는, 일단 연습장에 명확하게 알고리즘을 세운뒤 프로그래밍에 들어가는 것이 좋겠다고 생각함. 그리고 알고리즘 디자인시에 Matrix 와 Graph 등의 모델을 그려서 생각해보는 것이 효율적이겠다는 생각이 들었다.
       오늘 무엇을 할 것인가 하며 ["ProjectPrometheus/Iteration"] 를 보고선 HTML Parsing 을 진행하기로 했다. 그 전에 ["1002"] 는 '아, 작업하기 전에 Book Search 에 대한 전반적인 그림을 그려 놓는게 좋겠군. 그리고 난 뒤 HTML Parsing 부분에 대해 구현해야지' 라고 생각을 했다. 한편 ["neocoin"] 은 수요일때와 마찬가지로 'HTML Parsing 부분에 대해 일단은 SpikeSolution 으로 만든뒤 모듈화 시켜나가야지' 라는 생각을 했다. 프로그래밍 스타일이 다른 두 사람이 진행 방법에 대한 언급없이 진행을 하려고 했다. ["1002"] 는 '아 전체 그림' 하며 CRC 세션을 하려고 하는 중간. 한편 ["neocoin"] 은 같이 진행하고 있는 CRC 세션에 중간에 대해서 '지금 서로 무엇을 하고 있는거지?' 하며 혼란에 빠졌다. 똑같은 디자인 단계에 대해서 ["1002"] 는 전반적 Book Search 에 대해 생각을 하고 있었고, ["neocoin"] 은 모듈과 모듈간 연결고리에 대해 생각을 하였다.
• ProjectSemiPhotoshop/Journey
        * 한일 : 3시간 정도의 상민과 현민의 Alcanoid SpikeSolution 작성 - 자료실 스크린샷
• ProjectSemiPhotoshop/SpikeSolution
       내 생각엔 SpikeSolution 과정에서 중복된 코드가 나올것 같고 나중에 이것들을 묶어서 단순한 설계를 구현시킬 수 있을 것 같다.
• ProjectSemiPhotoshop/계획서
        * 10/29 pm1:00~pm5:00 상민과 현민의 알카노이드 SpikeSolution
• ProjectSemiPhotoshop/기록
        * 10/29 pm1:00~pm5:00 상민과 현민의 알카노이드 SpikeSolution
• ProjectZephyrus/ClientJourney
       영서에게 JTree 관련 프로그래밍에 대해서 설명을 했다. JTree와 관련하여 미리 공부하라고 하긴 했는데, 아직은 힘든가 보다. 오늘 작업시간이 5시 30분부터 9시 (저녁 30분가량), 약 3시간 가량이 걸렸던것으로 기억된다. 팀으로 모일 수 있는 시간이 흔하지 않으므로, 각 필요한 부분에 대한 학습과 예제 코드등의 JDK에 대한 SpikeSolution 에 대해서는 집에서 해 봐야 할 것이다. 작업 시간에 학습시간을 같이 할애 하기엔 시간이 그리 넉넉치 않다. [[BR]]
        * PairProgramming를 하면서 SpikeSolution 으로 한번 구성했던 소스를 다시 만들어보고, 여러번 말로 설명해보고, 더 쉬운 방법으로 설명해보려고 하는 동안 알고있는것에 대해 생각이 빨리 정리된다.
       1002는 CVS 사용방법에 대한 예를 보이고 설명을 했다. wincvs 윈도우 버전에 익숙하지 않았던 관계로 command 입력방법을 가르쳐줬다. 그리고 영서와는 주로 Swing쪽을, 창섭과는 Java Socket Class 에 익숙해지기 위해 Socket 관련 SpikeSolution 을 했다.
       후배들과의 PairProgramming 이다. 여태껏의 경험에 의하면 언제나 애매한 것이 Junior : Expert 문제이다. 이번에는 어차피 SpikeSolution 이므로, 내가 아는 한도에서 약간의 예를 보이고, 후배들로 하여금 해보도록 하는 식으로 했는데, 그 덕에 둘이 Pair 를 해보는 기회가 없었던 것 같다. 중간에 내가 화장실 갔다올때 잠시 둘이서 Pair 를 하는 모습을 봤었는데, 이 선은 내가 적절하게 지켜나가야겠다. 너무 멀리도, 너무 가까이도 아니도록. --1002
• UserStory
       estimate 를 하기 힘든 경우는 두가지가 있다. 하나는 해당 Story 가 애매한 경우이고 하나는 해당 Story의 구현이 전혀 생소한 부분인 경우이다. 해당 Story 가 애매한 경우에는, 주로 Story에서 해야 할일이 많은 경우이다. 해당 Story를 작은 Story들로 나누어서 생각해본다. 구현이 전혀 생소한 부분에 대해서는 SpikeSolution을 해본뒤 estimation 하는 방법이 있다.
• 비행기게임
        암튼. 초반의 열정이 후반의 끈기로 이어지려면, 해당 일에 대한 좋은 방법들을 중간에 계속 궁리하고, 적용해봐야겠지. 개인적인 조언이라면, 초반에 너무 그래픽 등에 많이 신경쓰지 않는것이 낫다고 생각함. 일단은 전반적인 틀과 게임 엔진을 만든다는 기분으로 하고, 그 엔진이 자신이 원하는 아이디어를 수용할 수 있는가에 더 촛점을 맞추는게 낫지 않을까 함. 단, 생각은 전반적인 부분을 보되, 구현을 쉽게 하기 위해서는 구체적 예제 데이터를 가지고 작업하는것이 효율적이겠지. 그리고 그 예제 데이터를 기반으로 일종의 SpikeSolution식으로 구현을 한뒤, 그 구현된 프로그램을 보고 다시 코드를 작성하던지 또는 ["Refactoring"] 해서 일반화시키던지.(새로 짜도 얼마 시간 안걸림. 예상컨대, 아마 중반에 소스 한번 뒤집어주고 싶은 욕구가 날껄? 흐흐) --["1002"]

You can also click here to search title.