#+PROPERTY: Effort_ALL 2d 5d 10d 20d 30d 35d 50d
#+PROPERTY: allocate_ALL dev doc test
#+PROPERTY: ORDERED_ALL true false
#+COLUMNS: %70ITEM(Task) %3Effort %8allocate %BLOCKER %ORDERED

* Resources                                            :taskjuggler_resource:
** Developers
:PROPERTIES:
:resource_id: dev
:END:
*** Paul Smith
:PROPERTIES:
:resource_id: paul
:END:
*** Sébastien Bono
:PROPERTIES:
:resource_id: seb
:END:
*** Klaus Müller
** Others
*** Peter Murphy
:PROPERTIES:
:resource_id: doc
:limits:   { dailymax 7h }
:END:
*** Dim Sung
:PROPERTIES:
:resource_id: test
:END:


* Accounting Software                                   :taskjuggler_project:
  SCHEDULED: <2013-04-15 Mo>
** STARTED Specification
   - State "STARTED"    from "TODO"       [2013-05-02 Do 16:50]
   CLOCK: [2013-04-30 Do 16:50]--[2013-05-03 Do 16:50] => 72:00
   :PROPERTIES:
   :Effort:   20d
   :allocate: dev
   :task_id:  task_spec
   :END:
** Software Development
   :PROPERTIES:
   :allocate: dev   
   :ORDERED:  true
   :BLOCKER:  previous-sibling
   :task_id:  task_dev
   :END:
*** TODO Database coupling
    CLOCK: [2013-05-03 Do 15:21]--[2013-05-11 Do 22:21] => 199:00
    :PROPERTIES:
    :Effort:   20d
    :END:

    *This task uses the smart progress inference*: This task's
    completeness is guessed using the clocked times, since it has no
    explicit `complete' property. However the clock durations add up
    to more than the effort and TJ3 does only allow values
    [0,100]. Therefore semantically the task is not regarded as
    complete until the TODO state equals "done", no matter how much we
    clock on it.  According to TJ3 doc, the complete information has
    no impact on the TJ3 scheduler, it's pure documentation.

    *Alternatives*: 
    1) Instead of setting `complete', we could set the property
       `booking' for a resource or task, when we export to TJ3. Then
       TJ3 would have additional information, since the bookings
       reflect how much work was actually put into a task vs. how much
       we originally planned. Note that unlike `complete' this has an
       impact on the scheduling. TJ3 then can schedule a new plan
       based on the amount of work that actually happened.  Downside
       is, that the org-syntax does not capture who/which resource
       clocks on a task. And that the clock times will cause
       scheduling errors when they do not comply with the scheduled
       time windows for the tasks (e.g., when the bookings are earlier
       than the task could have started, which can be constrained by
       dependencies). When the bookings exceed the effort, TJ3 overwrites the effort with the booking value.
  
       No completeness is calculated automatically though.
    2) We continue to set `complete', but when the progress rendered
       by the clocksum exceeds 100%, we adjust the effort s.t. it
       yields 99% again. However, this might be surprising since the
       export shows different efforts than the org-file.


*** Back-End Functions
    :PROPERTIES:
    :Effort:   5d
    :task_id:  task_backend
    :END:

*** Graphical User Interface
    :PROPERTIES:
    :Effort:   35d
    :END:
** Software testing
   :PROPERTIES:
   :allocate: test, paul
   :ORDERED:  true
   :BLOCKER:  task_dev
   :END:
*** Alpha Test
    :PROPERTIES:
    :Effort:   5d
    :task_id:  task_alpha
    :END:
*** Beta Test
    :PROPERTIES:
    :Effort:   20d
    :allocate: test
    :task_id:  task_beta
    :END:
** Manual
    CLOCK: [2013-05-03 Fr 12:48]--[2013-05-08 Fr 17:48] => 125:00
   :PROPERTIES:
   :Effort:   50d
   :allocate: doc
   :BLOCKER:  task_spec
   :complete: 75
   :task_id:  task_manual
   :END:
    This task's completeness is explicitly set. Even if there are
    clock in this task, it is being ignored.

** Milestones
*** Project start
*** Technology Preview
    :PROPERTIES:
    :BLOCKER:  task_backend
    :END:
*** Beta version
    :PROPERTIES:
    :BLOCKER:  task_alpha
    :END:
*** Ship Product to Customer
    :PROPERTIES:
    :BLOCKER:  task_beta task_manual
    :END: