Hello Chen,

it is really a big problem when we have tasks that depends on other tasks.
To avoid this, our PO try to select tasks that don't depend on each other
per iteration. In the next iteration, if the task is done (it includes
code-review, test...), the PO selects a task that depends on already done

However, sometimes it's not possible to do. In these cases, I think that
the best solution is to define the api of the tasks and create a branch for
each one. You don't need to know how the task will be done
(implementation), but you know what the task will do (api) and use it in
other tasks. This way, we can start a task B that depends on a task A even
if A is not done yet. After A is completed, we can merge the branch A into
branch B and finish the task B.

William Seiti Mizuta
Desenvolvedor da Caelum

On Mon, Dec 17, 2012 at 1:34 AM, Cahyadi Hendrawan <chen.hendra...@gmail.com
> wrote:

> Hi William,
>>> Would you simply revert master back to known working state and merge the
>>> feature branch back in at a later date when its fixed and working?
>>> (Wondering if doing something like that messes with the history and causes
>>> problems down the line when merging feature branches into master?)
>> If the changes made in a branch are not big, the merge will probably be
>> simple. However, it can be a mess if the feature branch took a long time to
>> be done. So, I think that the best way is to divide the feature in small
>> tasks that don't take a long time to be completed and merged in the main
>> branch.
> We are also trying to implement branch per task workflow in our company.
> To do a feature X, we divide the feature into several small task that can
> be done by several people. It is often that the task are depends on other
> task, so we often have a situation where certain people need to wait for a
> task to be merged into master before they can start their work. The task
> that the other tasks depend on is probably has been (functionally)
> finished, but still pending for approval due to code-review, sanity check,
> etc.
> This become a major problem for us. How do you handle such scenario?
> Regards,
> Chen
> --


Reply via email to