From a tooling perspective:
we have had good success in the past with fully defining and designing a
feature in a Redmine Story. The story (description) provides a good way
to capture (and edit) the overall design and (comments) support a
discussion history. Then, the implementation can be broken down and
tracked by related sub-tasks which are aligned to sprints and cross
core/plugin boundaries. The feature is complete when all the
implementation tasks are complete.
On 04/06/2018 02:00 PM, Robin Chan wrote:
Brian,
To bring this back to your original question, here are some comments
in line.
Agree w/#1 - I have observed a few different ways that this problems
has been solved by developers. The requirement here is "I need a way
to understand all the work and deliverables associated with a
feature." This question comes down to how do we track of deliverables.
This is I think secondary and not as much of a problem as the next
question.
#2 - This is essentially a question of planning deliverables. Your
descriptions is "how will someone know if a feature is committed to"?
I think full planning is not necessary for commitment. I believe that
"full planning" part could go in #1 in terms of tracking status. I
think the question is actually "how will someone know if a feature is
committed to and when it is committed by" - addition of a time or time
frame.
In my experience, feature work generally went like this:
1. Define feature/problem to be solved.
2. Investigate:
- refine requirements/problem definition
- do enough design or planning of tasks to come up with estimate
of work
3. Commit to work or not
4. execute along list of tasks, refine list as you learn.
Steps 1-3 is part of roadmap planning (higher level planning) and #3-4
is sprint planning.
I think the problem with using the sprint field as we have used it, is
that if you add something to a sprint, the Scrum definition would lead
people to assume that the team is committing to it at the end of a
defined sprint period. We do not. This major departure from industry
standard does not serve us well in my opinion. We have kept items on
sprints for many months and then removed it. Even if we were able to
convince folks that our definition of sprint was "our next few
sprints" of work, we don't have any accountability that we are
actually keeping our commitment here and the folks wanting something
on the sprint don't have any idea if something added to a sprint will
be there in 3 weeks or 12 weeks. I think others in software are
reasonable in understanding that software deliveries aren't going to
be there until they are, but I think our immediate focus on what is in
process (impending delivery/next build) and on some of the larger
deliveries.
Robin
On Thu, Mar 29, 2018 at 3:13 PM, Brian Bouterse <bbout...@redhat.com
<mailto:bbout...@redhat.com>> wrote:
I want to start a discussion around how Pulp does roadmap planning
and some of our current challenges. This is the pre-discussion
part of a future PUP. I want to collaborate on characterizing the
problems first before we discuss solutions.
# The surface problem statement
It very difficult for external stakeholders to answer some simple
questions about any given feature:
* How would a user use this feature exactly?
* Is it completed? If not, how much is left to do?
* Which release is this going in?
* Has this feature been fully planned and accepted as a committed
to piece of work?
# deeper problems
I believe there are two deeper problems contributing to the
problem above.
1. Any given feature is typically spread across multiple Redmine
tickets. There may be the first implementation, followup changes,
adjustments, bugfixes, reworks, docs followups, etc. This makes it
practically hard to have the information necessary to answer the
first 3 questions ^.
2. Devs of core or a plugin have no clear way to clearly signal
that a feature has been fully planned and is committed to. The
'sprint' field has been used heretofore, but the recent feedback
suggests that mechanism may not be the best way to indicate that
work has been fully planned and accepted. We need a clear way to
answer the last question ^.
Do you agree or disagree with these problem statements? Do you
have anything to add about the problem statements?
Thanks!
Brian
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com <mailto:Pulp-dev@redhat.com>
https://www.redhat.com/mailman/listinfo/pulp-dev
<https://www.redhat.com/mailman/listinfo/pulp-dev>
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
