On Fri, Feb 05, 2016 at 01:23:57PM -0600, Jason Harrer wrote: > > 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)
Hi Jason, thanks for taking the initiative on this. It's nice to have a starting point. For such a small team, a process that's too structured will just end up getting abandoned. Let's make sure the process is meeting our needs, and *only* meeting our needs. I already feel like we're caught up in fitting into some predefined framework instead of finding tools to fill our needs. So what are our needs? I will only speak of the WEBSITE project (not legal, not financial, not outreach). For that project, I posit that we only need milestones and user stories right now (for the next couple weeks). MILESTONES ---------- One need we have right now is keeping the ship pointed in the right direction. Getting to full functionality is crossing a big ocean and we need some stars to guide by. We've *already done this*, by breaking it down into milestones. I think we should keep that terminology. I know OpenProject makes the word "milestone" special and kinda useless by default, but that's a checkbox that can be unchecked: https://i.imgur.com/xCkexfp.jpg http://shovel.snowdrift.coop/projects/snowdrift/settings/types So, if we can, we should uncheck that box and use 'milestone' as our biggest-scope work package. Side note: we need milestones *right now*, as we move towards full functionality, but I suspect we won't always need them at all times in the future. That is, we should *not* mandate that work always fall under a milestone. Sometimes that scope will be too big to be useful. Side note 2: One thing we *don't* need is releases. Those exist for software that is bundled up and distributed. We only do that in the most degenerate sense, and that won't change. USER STORIES ------------ Like I said, we already have milestones. The first milestone, Alpha, has the following definition: "A complete website that has a functional pledging prototype using artificial money" Here's the thing. That's just a collection of user stories. 1. "As a registered patron, I can pledge artificial money to projects to see how the mechanism works" 2. "As a new, interested visitor, I am presented with visuals and explanations that help me understand what Snowdrift.coop is trying to accomplish." 3. "As a visitor, I can quickly sign up and become a registered patron" [but the visitor must be made sufficiently aware of the responsibility they are undertaking] 4. "As a viewer, I can always quickly get information about the organization running the website, and about policies pertaining to how I use the site" Do we need any more process and structure at this point? As long as we have structure for milestones and user stories, we have all the structure we need to make a lot of real progress. Let's add more structure retroactively, reflectively, once we see the clear and present need for it. In the meanwhile, I'm pretty sure we can write a lot more than four user stories! Let's write a bunch and see what we need next.
signature.asc
Description: Digital signature
_______________________________________________ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
