- ProjectPrometheus/Journey . . . . 21 matches
* Task 를 작성할때 Refactoring 을 명시적으로 써 놔야 하겠다. Acceptance Test 처럼. 써놓지 않으니까 잊어먹고 자주 안해준 것 같다. 그리고 생각보다 시간이 걸리는 만큼. (이건 Refactoring 을 플밍 중에 자주 해주지 않아서인것 같다. 2시간정도 걸렸으니)
* 리듬이 깨졌다라는 느낌이 들때. Task 단위를 To Do List 단위로 다시 쪼개는 지혜 필요할 것 같다. 현재 Task 사이즈가 Pair 기준 1시간이긴 한데, 막상 작업할때에는 시간을 헤프게 쓴다란 생각이 듬.
* UserStory 정리 & Engineering Task 재정의
* ["ProjectPrometheus/EngineeringTask"]
* 'Iteration 3 에서 무엇은 되었고 무엇은 안되었는가?' 지금 Iteration 3 쪽 Task 가 아직도 정리 안되었다. Task 정리를 하지 않고 Iteration 3 를 진행한 점은 문제이긴 하다. (비록 구두로 개발자들끼리 이야기가 되었다 하더라도. 제대로 정리를 한다는 의미에서.) Iteration 3 Task 정리 필요. 그리고 나머지 Iteration 에 대한 Task 들에 대해서 예측할 수 있는것들 (슬슬 눈에 보이니)에 대해 추가 필요.
Iteration 1 에서 밀린 일들이 3 task 쯤 되는데, 계속 그정도의 일들이 밀린다. 하긴, 3 task 가 밀렸음에도 불구하고, Iteration 1 에서의 처음 Task 를 맡은 만큼 Iteration 2 에서 Task 로 실었으니까.
* Iteration 1 에서 못한 일들을 Iteration 2 로 넘길때는 Iteration 1 에의 Task 를 Iteration 2로 넘겨줘야 한다. Iteration Planning 은 일종의 Time-Box 이다.
* Iteration 1 에서 9 Task points 를 완료했다면, Iteration 2 에서도 9 Task points 를 맡는다.
* Book Search Iteration 에 대한 구체적인 Task 설정.
* Python, webdebug 를 이용, ["ProjectPrometheus/LibraryCgiAnalysis"] Task
* HttpURLConnection 을 이용, HTML 문서 가져오기 Task
* Engineering Task 가 아직 명확치 않다. Engineering Task 를 지금 일단 간단하게 생각하는게 나을까 아니면 Architecture Design 뒤에 더 구체화해서 쓰는게 나을까 궁리중. 일단은 전자를 먼저 간단하게나마 궁리.
* Requirement 를 받았다. Requirement 를 받기전에 너무 준비를 소홀히 했다라고 생각한다. Requirement 를 받는대에도 미리 계획을 세웠어야 했는데. 차라리 전에 이용하던 UserStory 작성 -> 대강의 EngineeringTask 궁리 -> EngineeringTask 에서 공통으로 겹치는 부분 / 큰 부분 나누기 -> Estimate 결과 작성 이라도 시도해볼걸 이란 생각이 든다. Requirement Process 에 대해서 꼭 비격식적이더라도 구조적인 방법을 생각해볼 필요가 있단 생각이 들었다. (너무 허둥지둥했던 것을 생각하면.)
- Chapter II - Real-Time Systems Concepts . . . . 16 matches
Soft / Hard 가 그 두가지 예라고 할 수 있다. Soft Real Time 이란 말은 Task 의 수행이 가능하면 보다 빠르게 진행 될 수 있게 만들어진시스템을 말한다.
예를 들어 High Priority를 가진 Task가 선점형 수행을 하며 다른 Task 보다 많은 자원을 사용할 수 있을 때를 말한는것 같다.
반에 Hard System이란 특정 시간내에 Task의 작업이 완수 되어야 하는 작업들을 말한다. 대부분의 Real-Time 시스템에서는 두가지
공유 자원이란 하나 이상의 Task가 같은 자원을 쓸 경우를 말한다. 두 Task는 배타적으로 같은 Resouce에 접근을 하며 Data의 파손을 방지한다. 이러한 방식을 mutual exclusion (상호 배타성) 이라고 한다.
=== Multitasking ===
멀티태스킹이란 프로세스의 스케줄과 CPU의 스위칭에 의해 복수의 Task가 실행되는 것을 말한다. 또한 멀티태스킹이란 Back/Fore Ground 처럼 복수의 Task가 운영되는 것을
=== Task ===
=== Context Switch ( or Task Switch) ===
게 된다면 다른 Task들에 의해 그 값이 바뀌어져 있을 수도 있습니다. 그러므로 Task에서 쓰일 변수/메모리는
Task Stack 에 값을 저장하여 해당 Task로 다시 진입했을 때 스택에서 꺼내 그 값을 복원하는 방법이 있겠습니다.
=== Task Priority ===
=== Assigning Task Priorities ===
* 얼마나 자주 TASK가 수행되어 지느냐에 따라 할당되는 우선순위
* 간단히 자주 실행되는 TASK가 높은 우선 순위를 갖는다는 말....
* 모든 TASK는 정기적으로 수행 된다.
* TASK들은 동기적이지 않다...-> 이 말은 다른 TASK들과 대화하며 공유하므로 동기적으로 실행 되지 않는다는 것.
* CPU는 가장 높은 우선순위를 갖는 TASK를 수행한다는 점.
=== Intertask Communication ===
- Ant . . . . 13 matches
Ant 의 몇몇 특정 Task 들의 경우 (JUnit, FTP, Telnet 등) 해당 라이브러리가 필요하다. 이는 http://jakarta.apache.org/ant/manual/install.html#librarydependencies 항목을 읽기 바란다.
==== Optional Tasks ====
Ant 는 다양한 Optional Tasks를 제공합니다. 일단 Task 라는 말이 앞으로 많이 나올텐데 Glossary 를 참고하세요. 예를들면 CVS 에 소스를 업데이트 해주는 Optional Task 가 있을 수 있고, 또 .NET 컴파일을 한다던지.. 기타 등등 다양한 Task 가 있습니다. (이에 대한 예제로는 ["AntTask"]를 참조)
위의 예에 하나가 추가됐죠? -D 옵션은 Build 파일의 Property task 와 같은 역할을 합니다. 즉 Build File 내부에서 사용되는 일종의 변수를 선언한다고 볼 수 있겠죠? ^^
Ant 를 다룰줄 안다는 말은 즉, Build File 을 만들줄 안다는 의미와 같다. Build File 은 파일이름에서도 알 수 있듯이 xml 을 기반으로 하고 있다. 예제로 참조해볼만한 화일로 ["Ant/TaskOne"], ["Ant/BuildTemplateExample"] 이 있다. 해당 화일을 보면서 설명을 읽으면 편할것이다.
''project'' 태그 다음에 올수 있는 태그로 아래 나오는 Task 들의 묶음이라고 생각하면 된다.
* Task 관련 태그들
* '''Task''' : Ant 에서의 작업단위(빌드, CVS, FTP, JUnit 실행 등등)를 말하는 것입니다. 예를 들어 설명하면 property task 는 Ant에서 쓰는 변수(쉘에서의 환경변수와 비슷한)의 값을 설정합니다. ["Ant/TaskOne"]
* '''Target''' : '''Task'''들의 집합으로 서로간의 의존관계와 주어진 조건에 따라 수행된다.
- LIB_1 . . . . 12 matches
// Task 0 is Highest Task :: priority 63
void mn_task()
char *sen2 = "Check Running Task \n";
char *sen3 = "Task Name Priority StackSize Running \n";
// Show the task delay , usage and
LIB_TASK_DISPLAY(10);
// Task 1 :: priority 60
void task1()
// TASK STATE DISPLAY
LIB_TASK_DISPLAY(5);
LIB_create_task (char* string,int,&task_point,task_size) 함수는
// create The Sample Task 1,2
LIB_create_task("Management\n",63,mn_task,&TaskStack0[256]); // 매니져 함수를 만들어준다.
LIB_create_task("task1\n",60,task1,&TaskStack1[256]); // 사용자 태스크 1을 만들어준다.
LIB_create_task("task2\n",59,task2,&TaskStack2[256]); // 사용자 태스크 2를 만들어준다.
LIB_create_task("StatTask\n",LIB_IDLE_PRIORITY + 1,LIB_TASK_CPU_STAT,&OSStack[256]); // 상태를 알아보는 태스크를 만든다.
LIB_create_task("IdleTask\n",LIB_IDLE_PRIORITY,idle_task,&TaskStack3[256]); // 유휴상태일때 돌아가는 idle태스크를 만든다.
- LIB_2 . . . . 11 matches
if ( High_Task->priority < pSuspend_heap[i]->priority && pSuspend_heap[i]->delay < 0 ) {
LIB_resume_task(pSuspend_heap[i]->priority);
High_Task->StackSeg = S_SEG;
High_Task->StackOff = S_OFF;
S_SEG = High_Task->StackSeg;
S_OFF = High_Task->StackOff;
High_Task = &START_TCB;
High_Task 로 지정된 태스크일 것이다. 그 태스크의 스택 위치를 찾아 스택 포인트를 바꿔준다.
High_Task->StackSeg = S_SEG;
High_Task->StackOff = S_OFF;
S_SEG = High_Task->StackSeg;
S_OFF = High_Task->StackOff;
- ExtremeProgramming . . . . 10 matches
초기 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 (즉, 아무런 방해를 받지 않는 상태에서 프로그래머가 최적의 효율을 진행한다고 했을 경우의 기준) 으로 계산한다.
그 다음, 최종적으로 Customer 에게 해당 UserStory 의 우선순위를 매기게 함으로서 구현할 UserStory의 순서를 정하게 한다. 그러면 UserStory에 대한 해당 Wiki:EnginneringTask 를 분담하여 개발자들은 작업을 하게 된다. 해당 Task-Point는 Iteration 마다 다시 계산을 하여 다음 Iteration 의 estimate 에 적용된다. (해당 개발자가 해당 기간내에 처리 할 수 있는 Task-Point 와 Story-Point 에 대한 estimate) (Load Factor = 실제 수행한 날 / developer's estimated 'ideal' day. 2.5 ~ 3 이 평균) Iteration 중 매번 estimate 하며 작업속도를 체크한뒤, Customer 와 해당 UserStory 에 대한 협상을 하게 된다. 다음 Iteration 에서는 이전 Iteration 에서 수행한 Task Point 만큼의 일을 할당한다.
Iteration 중에는 매일 StandUpMeeting 을 통해 해당 프로그램의 전반적인 디자인과 Pair, Task 수행정도에 대한 회의를 하게 된다. 디자인에는 CRCCard 과 UML 등을 이용한다. 초기 디자인에서는 세부적인 부분까지 디자인하지 않는다. XP에서의 디자인은 유연한 부분이며, 초반의 과도한 Upfront Design 을 지양한다. 디자인은 해당 프로그래밍 과정에서 그 결론을 짓는다. XP의 Design 은 CRCCard, TestFirstProgramming 과 ["Refactoring"], 그리고 StandUpMeeting 나 PairProgramming 중 개발자들간의 대화를 통해 지속적으로 유도되어지며 디자인되어진다.
개발시에는 PairProgramming 을 한다. 프로그래밍은 TestFirstProgramming(TestDrivenDevelopment) 으로서, UnitTest Code를 먼저 작성한 뒤 메인 코드를 작성하는 방식을 취한다. UnitTest Code -> Coding -> ["Refactoring"] 을 반복적으로 한다. 이때 Customer 는 스스로 또는 개발자와 같이 AcceptanceTest 를 작성한다. UnitTest 와 AcceptanceTest 로서 해당 모듈의 테스트를 하며, 해당 Task를 완료되고, UnitTest들을 모두 통과하면 Integration (ContinuousIntegration) 을, AcceptanceTest 를 통과하면 Release를 하게 된다. ["Refactoring"] 과 UnitTest, CodingStandard 는 CollectiveOwnership 을 가능하게 한다.
그리하여 각 Wiki:EngineeringTask 들이 구현되고, 궁극적으로 UserStory 의 Story들이 모두 진행되면 Mission Complete. (아.. 어제 Avalon 의 영향인가. --;)
- ProjectZephyrus/Client . . . . 8 matches
노동의 양으로 생각해야 하는건 Engineering Task 가 아닌가요? 암튼 이번의 경우는 필수 기능 기준으로 잡아보긴 했습니다. (엄격하게 나눈건 아니긴 하지만요.~) --석천
''Engineering Task나 User Story 모두 노동의 양으로 estimation을 해서, 포인트를 준다. 이렇게 "비용"이 적힌 카드들을 놓고, 어느 것을 하고, 미루고, 먼저하는 지 등의 순위 결정은 "중요도 중심", "위험도 중심"이 있는데, 작년 이후 익스트리모들(KRW)은 복잡하게 이런 걸 따지지 말고 그냥 비지니스 가치로 순서를 정하라고 한다. --JuNe''
Task Point - 영서 & 석천이 Main Frame 연습용 코드 작성했을때 기준을 1 Task Point 로 잡음. (대강 120 라인정도/1시간 정도의 난이도 & 속도)
Total 6.5 TP. 실제로 6.5 * 1.5 = 9.75 TP 걸릴것으로 예상. 하지만 Task 는 계속 작업하면서 추가되기에, 실제로는 더 걸리겠지. 하지만 현재 생각할 수 있는 한도내에서의 예측이라는 점에서 의미. (미지인 부분에 대해 미리 걱정하기엔 현재 일도 빠듯하기에) 계속 Update 시켜야 하겠지.
|| '''내용''' || '''Task Point''' || '''완료여부(○)''' ||
|| 내용 || Task Point || . ||
|| 내용 || Task Point || . ||
- LIB_3 . . . . 7 matches
High_Task = &START_TCB;
/* Create The Task
void LIB_create_task (char *task_name,int priority,void (*task)(void),INT16U * Stack)
LIB_STACK_INIT(task,Stack); <-------- 스택을 초기화 해준다.....
pReady_heap[ready_tcb_ptr]->Task_Name = task_name;
SUSPEND 된 TASK 들을 다시 살려주는 고마운 펑션
/* Resume task
void LIB_resume_task(INT16U priority ){
/* Wait task
void LIB_suspend_task(INT16U priority){
/* Delete the Task
int LIB_del_task(LIB_TCB *task){
if ( pReady_heap[i] == task ) {
if ( pSuspend_heap[i] == task) {
/* Resume task
/* Find Ready Task & Run the Task
High_Task = pReady_heap[0];
- LIB_4 . . . . 6 matches
void LIB_STACK_INIT (void (*task)(void),INT16U * Stack)
*Stack-- = (INT16U)FP_SEG(task);
*Stack-- = (INT16U)FP_OFF(task);
*Stack-- = (INT16U)FP_SEG(task);
*Stack-- = (INT16U)FP_OFF(task);
TCB는 TASK CONTROL BLOCK의 약자.. 한마디로 태스크에 대한 정보를 담고 있는 구조체
// Task Priority
INT8U *Task_Name;
// Task Stack
// Task Delay
// Task Status
INT8U Task_Status;
- NSISIde . . . . 6 matches
== Engineering Task ==
한 Iteration 을 2시간으로 잡음. 1 Task Point는 Ideal Hour(?)로 1시간에 할 수 있는 양 정도로 계산. (아.. 여전히 이거 계산법이 모호하다. 좀 더 제대로 공부해야겠다.)
0.4 + 0.4 + 0.5 + 0.5 + 0.5 + 0.5 + 0.7 = 3.5 (전체 3.5 Task Point) [[BR]]
추가 Task : Load / Save MDI Framework 와의 연결
현재 완료된 Task
* velocity : 1.3 task point
* velocity : 1.7 task point
* average : 1.5 task point
* velocity : 0.7 task point.
* average : 2.2 / 3 = 0.73 task point / Iteration (2 hours)
* UserStory 의 작성과 EngineeringTask 부분 작성시에 애매모호하게 쓴 부분과 잊어먹고 고려하지 않은 부분이 있었다. (이는 훗날 뒤통수를 친다. -_-;) 너무 복잡해서도 안되겠지만, 중요한 사항들에 대해 잊어서도 안될것이다.
- Chapter I - Sample Code . . . . 5 matches
수행시간 측정은 한 task 의 수행시간을 측정하기 위해서 한다. (당연한거 아냐?). 이 측정은 PC의 82C52 타이머 2번을 통해 수행된다. 수행시간 측정을 위한 함수로는 PC_ElapsedStart()와 PC_ElapsedStop()이 있다. 하지만 이 두 함수를 사용하기 전에 PC_ElapsedInit()를 호출해야한다. 이 함수는 두 함수와 관련된 오버헤드를 측정하는데 사용된다. 이렇게 하면 PC_ElapsedStop 함수에 의해 수행시간이 리턴된다(마이크로세컨드). 이 두 함수는 모두 리엔터런트(주 : 몇 개의 프로그램이 동시에 하나의 task나 subroutine을 공유하여 쓰는 것에 대해 말함, from 한컴사전) 하지 않아야한다. 다음은 PC_DispChar()함수의 측정시간을 구하는 예이다.
uCOS-II는 여타의 DOS Application 과 비슷하다. 다른말로는 uCOS-II의 코드는 main 함수에서부터 시작한다. uCOS-II는 멀티태스킹과 각 task 마다 고유의 스택을 할당하기 때문에, uCOS-II를 구동시키려면 이전 DOS의 상태를 저장시켜야하고, uCOS-II의 구동이 종료되면서 저장된 상태를 불러와 DOS수행을 계속하여야 한다. 도스의 상태를 저장하는 함수는 PC_DosSaveReturn()이고 저장된 DOS의 상태를 불러오는것은 PC_DOSReturn() 함수이다. PC.C 파일에는 ANSI C 함수인 setjmp()함수와 longjmp()함수를 서로 연관시켜서 도스의 상태를 저장시키고, 불러온다. 이 함수는 Borland C++ 컴파일러 라이브러리를 비롯한 여타의 컴파일러 라이브러리에서 제공한다.[[BR]]
==== TaskStart() ====
==== TaskN() ====
==== TaskStart() ====
==== TaskN() ====
==== Tasks ====
- ProjectPrometheus/Iteration5 . . . . 5 matches
Team Velocity : 5 Task Point.;
|| Task || Point || 진행여부 ||
|| Task || Point || 진행여부 ||
|| Task || Point || 진행여부 ||
|| Task || Point || 진행여부 ||
- STLErrorDecryptor . . . . 5 matches
* STLTask.EXE : 해독기의 필터링 기능을 토글하는 컨트롤러로, 윈도우 작업표시줄(TaskBar)에 위치하게 됩니다.
다) 이젠 프록시 CL의 동작에 필요한 환경 옵션을 제공하는 Proxy-CL.INI 파일을 여러분의 개발환경에 맞게 고쳐야 합니다. 텍스트 편집기로 Proxy-CL.INI를 열면 아래의 [common], [proxy.cl], [stltask.exe] 부분이 모두 비어 있는데, 윗부분의 주석문을 참고하면서 환경 변수를 고쳐줍니다. 반드시 설정해야 하는 옵션은 다음과 같습니다.
프록시 CL의 에러 필터링을 활성화하거나 비활성화하는 역할을 맡은 프로그램인 STLtask.exe를 실행시켜 태스크바에 띄우는 과정입니다.
가) STLfilt.zip의 압축을 푼 디렉토리에서 STLtask.exe를 실행합니다. 별 문제가 없으면 아래와 같은 대화 상자가 뜹니다.
Upload:STLTaskFirstRun.gif
나) 위의 대화 상자에서 [Back to taskbar] 버튼을 누르면 윈도우의 작업 표시줄(태스크바)에 아이콘이 하나 뜹니다. 이 아이콘을 오른쪽 클릭하면 메뉴가 뜹니다.
Upload:STLTaskMenu.gif
여기서 "Enable Filtering"을 선택하면 그때부터 STL 에러 필터링이 가능해집니다. 그리고, 앞으로 STL 에러 필터링을 활성화하거나 비활성화할 때에는 이 태스크바의 아이콘을 사용하면 됩니다(Enable filtering/Disable filtering을 선택하면 되겠죠). 필터링이 활성화 되어 있느냐 그렇지 않으냐의 여부는 작업 표시줄의 아이콘 색깔( Upload:STLTaskActIcon.gif 은 활성화되었다는 뜻)로 확인할 수 있습니다.
- UserStory . . . . 5 matches
* Task Point 의 계산
Wiki:EngineeringTask 란 해당 Story를 구현하기 위해 실질적으로 해야 할 일들에 대한 서술이다. UserStory 의 각 항목이 비교적 사용자 관점에서의 서술이라 한다면, Wiki:EngineeringTask는 구현해야 하는 Developer들 관점에서의 서술이다.
UserStory 들을 작성한 뒤에는 Wiki:EngineeringTask 를 결정하고, estimate (해당 작업에 대해 얼마나 걸릴 것인가에 대한 예측)한 Story Point 와 Task Point 를 기준으로 적절히 계산해 나간다.
- 1002/Journal . . . . 4 matches
특정 팀원과의 토론이 필요한 Task 외엔 별다른 어려움 없이 잘 진행되었다. Virtual Pair Programming 에서도 VIM 단축키들을 배웠다.; ctrl + v, shift + v 몰라서 매번 할때 Help 뒤졌다 까먹고 그랬던것 같은데, 제대로 익힐듯 하다.
어제 다이어리 셋팅한 것을 이용하고, XP 에서의 Story 정리방법을 약간 적용하였다. 아직 각 Story 에 대해서 Task 를 안나눴기 때문에, 일단 좀 더 할일들에 대해 구체적인 서술이 필요하다.
* To Do List 에 대해서 Layering 이 필요하다 - 전체지도 : 부분지도 랄까. XP 라면 UserStory : EngineeringTask 를 이야기할 수도 있겠지. EngineeringTask 수준의 경우 Index Card 가 더 편하긴 한데, 보관해야 할일이 생길때 문제다. (특히 2-3일로 나누어서 하는 작업의 경우) 이건 다이어리 중간중간에 껴놓는 방법으로 해결예정. (구멍 3개짜리 다이어리용 인덱스카드는 없을까. -_a 평소엔 보관하다 필요하면 뜯어서 쓰고; 포스트잇이 더 나을까.)
- ProjectPrometheus/Iteration6 . . . . 4 matches
Team Velocity : 5 Task Point.;
|| Task || Point || 진행여부 ||
|| Task || Point || 진행여부 ||
|| Task || Point || 진행여부 ||
- XpWeek/ToDo . . . . 4 matches
[[HTML(<strike>)]] 개발자 - EngineeringTask 작업 [[HTML(<strike>)]]
EngineeringTask 예상
TaskPoint 할당
==== 개발자 - EngineeringTask 작업 ====
- 데블스캠프2011/다섯째날/HowToWriteCodeWell/강소현,구자경 . . . . 4 matches
import java.util.TimerTask;
timer.scheduleAtFixedRate(new TimerTask(){
import java.util.TimerTask;
timer.scheduleAtFixedRate(new TimerTask(){
- 조영준/다대다채팅 . . . . 4 matches
using System.Threading.Tasks;
using System.Threading.Tasks;
using System.Threading.Tasks;
using System.Threading.Tasks;
- 황현/Objective-P . . . . 4 matches
- (void) doSomeTaskWithSomething:(int)$localIntegerVar {
[$myClass doSomeTaskWithSomething:42];
public function doSomeTaskWithSomething($localIntegerVar, $_objp_type_check=false) { // (void)
$myClass->doSomeTaskWithSomething(42, true); // Compiler automatically adds last argument!
- Ant/TaskOne . . . . 3 matches
Task 의 예로 다음 build.xml 파일을 보며서 설명해보자.
위의 예에서 Task 는 무엇일까.? task 라 함은 단어 뜻 그대로 작업이라는 말을 뜻한다. 위의 예에서 볼 수 있는 작업을 javac,mkdir,jar,delete 등이 그 Task 라고 할 수 있다.
- ProjectPrometheus/Iteration2 . . . . 3 matches
=== 2nd Iteration - 8 Task Point Load. 7 Task Point 완료 ===
|| Task || Point (Pair 기준 1시간 : 1 point ) || 진행상황 ||
- ProjectPrometheus/Iteration7 . . . . 3 matches
|| Task || Point || 진행여부 ||
|| Task || Point || 진행여부 ||
|| Task || Point || 진행여부 ||
- BarMacro . . . . 2 matches
||Task||Due Date||
||Test Task||[[DueDate(20311121)]]||
- Gof/Command . . . . 2 matches
THINK 클래스 라이브러리 [Sym93b] 또한 undo 가능한 명령을 지원하기 위해 CommandPattern을 사용한다. THINK 에서의 Command들은 "Tasks" 로 불린다. Task 객체들은 ChainOfResponsibilityPattern에 입각하여 넘겨지고 소비되어진다.
- MineFinder . . . . 2 matches
== User Story & Engineering Task ==
여기서는 Task Estmiate 를 생략했다. (그냥 막 나간지라. ^^;)
- OpenCamp . . . . 2 matches
* 진행: OpenCamp Task Force 팀
* 진행: OpenCamp Task Force 팀
- PairProgramming . . . . 2 matches
* Pair 의 진행을 이끌어가는 것 - 프로그래밍의 흐름이라고 해야 할까. 디자인을 어느정도 선정도로 맞추고 어떠한 문제를 풀 것인가에 대한 약간의 선이 필요할 것 같다. 이 경우에는 초반 디자인이 허술했었다는 약점이 있었다. '전체적인 관점에서 무엇무엇을 하면 프로그램이 완성될 것이다' 라는 것. UserStory 만 생각하고 EnginneringTask 를 간과한 것이 큰 문제였다. (그때 EnginneringTask 에 대한 개념이 없었었다는. 어디서 함부로 주워만 지식. --; 사고를 하자 사고를. -_-)
- ProjectPrometheus/Iteration1 . . . . 2 matches
=== 1st Iteration - 10 Task Point 완료 ===
|| Task || Point (Pair 기준 1시간 : 1 point) || 진행상황 ||
- ProjectPrometheus/Iteration3 . . . . 2 matches
=== 3rd Iteration (7.5 Task Point Loaded. 5.5 Task Point Completed) ===
- XpQuestion . . . . 2 matches
=== UserStory, Engineering Task 의 의존성 문제 ===
- 어차피 실제 고객에게 가치를 주는 중요한 일만을 하자가 목적이기에. Documentation 자체가 중요한 비즈니스 가치를 준다던가, 팀 내에서 중요한 가치를 준다고 한다면 (예를 들어서, 팀원중 몇명이 항시 같이 작업을 할 수 없다던지 등등) Documentation 을 EngineeringTask 에 추가하고 역시 자원(시간)을 분배하라. (Documentation 자체가 원래 비용이 드는 일이다.)
- XpWeek/20041221 . . . . 2 matches
EngineeringTask 예상 5m
TaskPoint 할당 10m
- zennith/w2kDefaultProcess . . . . 2 matches
Mstask.exe - 작업관리자에서 종료 불가
사용자가 미리 지정한 시간에 작업을 실행시키는 Task Scheduler Service
Taskmgr.exe - 작업관리자에서 종료 가능
- ExtremeBear/Plan . . . . 1 match
* IndexCard (CRC Card, Task Card, Story Card 등으로 이용)
- ProjectPrometheus/Iteration4 . . . . 1 match
|| Task || Point || 진행여부 ||
- ProjectPrometheus/Iteration8 . . . . 1 match
|| Task || Point || 진행여부 ||
- ProjectZephyrus/Afterwords . . . . 1 match
- 초기 모임시에 Spec 을 최소화했고, 중간에 Task 관리가 잘 이루어졌다. 그리고 Time Estimate 가 이루어졌다. (["ProjectZephyrus/Client"]) 주어진 자원 (인력, 시간)에 대해 Scope 의 조절이 비교적 잘 되었다.
- Task . . . . 1 match
Rename : AntTask
- ZIM/EssentialUseCase . . . . 1 match
''XP 는 User Story에서의 사용자 무게중심 & 실제 구현시의 걸릴 Task point 으로 잡고, UP 는 기반이 될 아키텍처 순위로 잡고. 둘을 비교해서 생각하는 것도 좋겠군요. 조언 감사해요.~ ^^ --석천''
- 데블스캠프2013/셋째날/머신러닝 . . . . 1 match
using System.Threading.Tasks;
Found 40 matching pages out of 7555 total pages (5000 pages are searched)
You can also click here to search title.
