We need to generate requirements better and assign ownership. imo best way to do this is generating system-wide requirements that break down into subteam requirements.
* We need to define sources of truth for the aircraft, i.e what's going on the aircraft, what is the aircraft going to do etc. This ties into the above.
Support for requirements, departments can’t own requirements however so we should assign requirements down to the person level rather than departments. Keeping everything in the central architecture space.
What about bus factor? We need to have a contact person but if contact person leaves it can cause issues.
Solution is to answer the question of why we have a certain requirement.
Support for doing architecture and design document starting from requirements and bringing together all hardware and software interfaces.
Summer Program
Mechanical: Building a test drone for FW
Firmware: Getting Safety flying
EE: ZP3.0 board, PDB, Motor Controller
CV:
Business: Recruitment and general financials
High-Level Requirements:
Building and flying a simple test drone using safety
ZeroPilot 3.0
Integration Lead
Understands the requirements for each of the seperate subteams and where they crossover
Integration example: EE cares about things like pinout, cares about things like wiring, the physical characteristics. They get the signal to FW. FW cares about the signal and information about the signal. the conversations that integration lead had were choosing the protocol.
Therefore, an integration lead has to 1) Start conversations around requirements and design specs 2) Understand interfaces 3) Make decisions across interfaces
System:
Once requirements are being developed at the subteam level, the integration lead calls out dependencies between teams
Once dependencies are identified, the integration lead understands what each team needs and drives decision making.
Once decisions are made, oversee and resolve concerns around development of these interfaces.
* We need to shift teams to focus more on iteration, as well as integrating iteratively as early as possible. How should this look?
FW had an idea of what a perfect ZP, one or two pieces fall short and nothing works anymore. This time you’ll separate work into milestones that can always be flown.
EE will iterate faster by spending less time finding small flaws and just ordering boards with the full knowledge that they may not work. Flaws are significantly easier to find when you actually have the board. If you have a board and there’s other boards being worked on, just send the board.
Mech already operates iteratively, more aggressive timelines.
CV needs to integration test on iteration.
* How do we want to track progress and changes? We don't really use asana consistently now, not sure how consistent confluence use is. I want to know if we should shift systems or just use these more.
FW: When shit hit the fan we gave up on Asana we started pulling people in.