Hello, all -
I have been working on and started organizing into a Work Package workflow
that I think will work for Snowdrift.coop. I'd like to get your thoughts
and feedback on the layout as well as the proposed process.
Please note that, even if we decide to move forward with this proposal, I'm
most focused on what works best for the project and its members, so if we
find something that doesn't work for us, we'll tweak it. I'm not expecting
this first pass to be deemed perfect for our usage, but I had to start with
something to get the conversation started.
Here are my proposoals.
- Work will be tracked in Releases
- Release is a new Work Package type that I created. OpenProject was
using it in their instance, and it made sense. It's a high level package
to track all the cumulative work going on to get us to a certain
point (in
our current case, the alpha prototype)
- We currently have more of a rolling release style, so either we can
consider revising when we release updated code, or we can just
consider the
release done when the last piece is rolled out. I'm guessing the latter,
but I just watned to point out the two options.
- Each release would be laid out to have 5 different phases:
- *Phase I: Requirements Gathering*: This will be when we determine
all of the different components we want to work on for this release. Each
component will yield its own Epic (which will be chlidren work packages
under Phase I), tracked under Phase I.
- *Phase II: Implementation Specifications*: (Note: Thinking of changing
this to just Specifications or Solutioning): This is where the Epics are
reviewed and broken down into User Stories (which will be children work
packages under Phase II). From those User Stories, tasks will be created
(as children under Phase III, even though they're created during Phase
II). Note that the tasks will need to be assigned to the appropriate
Circle/Group).
- *Phase III: Implementation*: This will be where the tasks that were
created in Phase II are actually worked on by the respective teams. Any
code bugs during this step can be created and made children under Phase III
to be worked before moving to testing.
- *Phase IV: Testing: *This will be where the code is ran through
automated tests, as well (potentially) as manual review, to ensure that
there are no foreseable bugs. Any bugs found during this phase would be
created as children under Phase IV.
- *Phase V: Deployment: *This would be assigned to the Sys Admin team
to actually deploy the changes.
- If we stick with Rolling Release, I still believe the above five
phases could work, though each Epic could be in different phases at
different points. Then, I believe we'd be probably be looking more at a
kanban style workflow than what I have listed above. I know there is the
backlogs section that we have that could be reviewed as well.
- I still need to figure out where we would want to store our Feature
Requests/WishList items. There are some proposals I'd have on that:
1. We could create work packages with a type of Feature Requests, which
(at first) would not be linked to anything. When we decide we
want to use
it, we could convert it to an Epic and add it to the Release
we're putting
it in.
2. If we're not going to use the Backlogs section for anything else,
this could be a place to have them, which would at least allow us more
sorting capabilities than #1 (Though I would have ideas for
prioritization
in #1 as well, just probably not as quick and easy as a kanban board).
3. Wiki page on OP. Then, every member has access, organization is a
simple cut/paste, etc.
I appreciate and welcome all comments, questions, brainstorming, etc.
Anything to help us move forward. Thanks!!
- Jason (JazzyEagle)
_______________________________________________
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss
