<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://mediawiki.zeropage.org/index.php?action=history&amp;feed=atom&amp;title=UserStory</id>
	<title>UserStory - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://mediawiki.zeropage.org/index.php?action=history&amp;feed=atom&amp;title=UserStory"/>
	<link rel="alternate" type="text/html" href="https://mediawiki.zeropage.org/index.php?title=UserStory&amp;action=history"/>
	<updated>2026-05-14T10:47:52Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.39.8</generator>
	<entry>
		<id>https://mediawiki.zeropage.org/index.php?title=UserStory&amp;diff=39991&amp;oldid=prev</id>
		<title>imported&gt;qa22ahj at 02:15, 3 January 2014</title>
		<link rel="alternate" type="text/html" href="https://mediawiki.zeropage.org/index.php?title=UserStory&amp;diff=39991&amp;oldid=prev"/>
		<updated>2014-01-03T02:15:33Z</updated>

		<summary type="html">&lt;p&gt;&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;=== User Story 란? ===&lt;br /&gt;
&lt;br /&gt;
사용자의 요구사항에 대한 간략한 기술. XP의 다른 과정들이 그렇듯이 (이건 아마도 XP 방식으로 진행하는 팀들의 특징인듯. -_-a Case Tool 보다는 간단한 카드와 펜을 선호함.~) 보통 인덱스 카드에 기술을 한다.&lt;br /&gt;
&lt;br /&gt;
=== Story Estimation ===&lt;br /&gt;
* man-hour 의 계산&lt;br /&gt;
* Story Point 의 계산&lt;br /&gt;
* Task Point 의 계산 &lt;br /&gt;
&lt;br /&gt;
Wiki:EngineeringTask 란 해당 Story를 구현하기 위해 실질적으로 해야 할 일들에 대한 서술이다. UserStory 의 각 항목이 비교적 사용자 관점에서의 서술이라 한다면, Wiki:EngineeringTask는 구현해야 하는 Developer들 관점에서의 서술이다. &lt;br /&gt;
UserStory 들을 작성한 뒤에는 Wiki:EngineeringTask 를 결정하고, estimate (해당 작업에 대해 얼마나 걸릴 것인가에 대한 예측)한 Story Point 와 Task Point 를 기준으로 적절히 계산해 나간다.&lt;br /&gt;
&lt;br /&gt;
매 Iteration (개발주기)를 진행할 때마다 실제로 진행한 Story들을 계산, 다음 estimation에 이용하게 된다.&lt;br /&gt;
&lt;br /&gt;
=== Estimation 이 어려운 경우 ===&lt;br /&gt;
estimate 를 하기 힘든 경우는 두가지가 있다. 하나는 해당 Story 가 애매한 경우이고 하나는 해당 Story의 구현이 전혀 생소한 부분인 경우이다. 해당 Story 가 애매한 경우에는, 주로 Story에서 해야 할일이 많은 경우이다. 해당 Story를 작은 Story들로 나누어서 생각해본다. 구현이 전혀 생소한 부분에 대해서는 SpikeSolution을 해본뒤 estimation 하는 방법이 있다.&lt;br /&gt;
&lt;br /&gt;
=== Thread ===&lt;br /&gt;
3학년 2학기때 배운 UP(Unified Process)의 [[UseCase|&amp;quot;Use Case&amp;quot;]] 를 보는 듯하다.&lt;br /&gt;
Use Case 에 대해서 문서를 작성하고..그 다음으로 System Sequence Diagram을 만드는데.&lt;br /&gt;
시스템과 사용자간의 어떤 행위들을 하는가른 간단히 순서적으로 적는것이지. &lt;br /&gt;
개발 방법론이란 것이 어떻게 보면 다 그렇고 그런거 같아. ^^ - 구근&lt;br /&gt;
&lt;br /&gt;
물은 물이고 산은 산이다에서 물은 물이 아니고 산은 산이 아니다로 가고 난 후에야 비로소 다시 물은 물이고 산은 산이다로 올 수가 있죠. 항상 초월적으로 모두 다 같다 혹은 모두 다 다르다는 식으로 말하는 태도는 공부를 하고있는 학생으로서는 상당히 위험하지 않을까 하는 우려를 해봅니다. Wiki:UserStoryAndUseCaseComparison 에 양자의 유사점, 차이점에 대한 논의가 있습니다. 참고로 Use Case의 대가라고 불리우는 코번은 다음과 같은 말을 합니다.&lt;br /&gt;
&lt;br /&gt;
  &amp;#039;&amp;#039;After several years of debating this question and seeing both in use, I now think they have nothing in common other than their first three letters.&amp;#039;&amp;#039;&lt;br /&gt;
&lt;br /&gt;
--김창준&lt;br /&gt;
&lt;br /&gt;
SeeAlso [[User Stories]]&lt;br /&gt;
----&lt;br /&gt;
[[ExtremeProgramming]]&lt;br /&gt;
&lt;/div&gt;</summary>
		<author><name>imported&gt;qa22ahj</name></author>
	</entry>
</feed>