[Pulp-dev] Roadmap Challenges

Tue Apr 10 19:40:59 UTC 2018

 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 <bbouters at redhat.com 
> <mailto:bbouters at 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 at redhat.com <mailto:Pulp-dev at redhat.com>
>     https://www.redhat.com/mailman/listinfo/pulp-dev
>     <https://www.redhat.com/mailman/listinfo/pulp-dev>
>
>
>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180410/3fd501bd/attachment.htm>