Shepard Test Stand

Good point re: using the gantt chart. I went ahead and turned on issue tracking and gantt chart features. I also created an issue type called "Milestone" to use with these issues. I am a little nervous about two elements in the timeline. The first is how close we will be cutting it (mostly be cause I agree with the basic premise of the estimates for the time). Not sure what we can do about that one, but I wanted to put it out there.

The second is harder to express. One of the things we have talked about doing in general at Mach 30 in early stage kite projects like Shepard is to emulate the agile software model of write a little, test a little (or test early, test often). In hindsight, I'm pretty sure we have not discussed this idea in the Shepard meetings, so I am not surprised that the timeline is very front heavy on design and in some ways assumes we will have a solid design that just needs building. I am trying to figure out how to express a timeline that would work this way, but it has been a while since I read the formal material on agile (iirc we would need to break the project down into small sub-versions each building toward more and more complete function and then do sprints around those sub-versions; I'm getting some of these details wrong, but hopefully some of the idea is getting across). My thought is that we can hopefully tackle unexpected problems as soon as they pop up and iterate the design right then instead of catching a problem during the build phase.

Thoughts/comments?

Thanks for adding those features, I think that will help out. I agree that the schedule is tight. I would like to think that we could make the September deadline, but there's not much wiggle room.

As for the Agile process, my personal feeling is that if we follow it we'll miss the deadline. With that said, if Agile is a goal of Mach 30's, I would stay on target and do the best we can to have it ready. If Shepard wasn't finished for the Open Hardware Summit would a presentation still be practical?

So, I was prepared to write a post about in order to investigate the pros and cons of Agile vs a more traditional process, and then I remembered that there is a facilitation ground rule we use in our meetings that is in play here: "when in doubt about process, the facilitator decides." I think at this point it is more important to pick a method of working and go with it, and include some time to reflect on the method we choose in the debrief at the end of the project.

That being said, I have to admit, I feel less qualified in this case to make that decision. So I will outline my thoughts on why I was leaning toward Agile and if there are still any concerns, we will use the traditional approach.

• An Agile method will likely apply to more projects in the future because it will encourage to us to build prototypes of sub-systems and test them when we have questions about what design we should use instead of getting stuck in analysis paralysis (this is a lesson we are trying to learn from some of the New Space companies, how to balance analysis with testing)
• if we schedule the sprints correctly, I could see us still having something significant to show before project completion (maybe the structure of the stand which we could still use to fire the motor even if we could not collect data?)
• we might be able to setup parallel sprints in different project areas (data collection vs structure development, since the data collection is more about the selection of the correct A2D solution and the structure is more about the mounts for motors and sensors), so we could get everyone working on a piece of the puzzle at the same time

Obviously, we will have to take care at the interfaces between sub-systems, but I think we could handle that with some planning for the order of the sprints.

I agree that there could be at least 2 parallel efforts in this project.
- The test stand structure
- The data collection system.

I actually foresee very little interaction between these two subsystems after the interfaces are worked out during the design and build phases.

I created issues for each part of the timeline, and they now show up on the Gantt chart. We may need to add supplemental items to the timeline though depending on how the Agile process is implemented.

I left the assignee field blank on each of the issues intentionally.