FN SDK Final Retrospective
Overview
Reflect on past work and identify opportunities for improvement by following the instructions for the Retrospective Play.
Date | Jul 14, 2022 |
|---|---|
Team | FN SDK |
Participants | Stash Noga stash.noga@unity3d.com, Joel Wilson joel.wilson@unity3d.com Terrence Donnelly terrence.donnelly@unity3d.com Erick Makris erick.makris@unity3d.com Didier Lessage didier.lessage@unity3d.com |
Retrospective
Add your Start doing, Stop doing, and Keep doing items to the table below. We'll use these to talk about how we can improve our process going forward.
There is no way we support retrofitting SDK into the existing controller code base.
Start doing |
|---|
Find a way to hold the customer’s vendors accountable to schedule and milestones. |
Be sure that the SOW has well defined, attainable, testable requirements. |
Make a contractual obligation to provide access to vendor’s engineers. (ie access to Jabil engineer) |
Issue change orders early and often. Issue stop work orders when necessary. |
Include verbiage in the SOW that states that change orders will be signed/executed in set amount of time or all work will stop. |
Hold customer accountable for the number of usable devices. Needs to be 4. |
Customer must provide all materials needed for development (ex batteries/targets/etc) |
Have engineering support spun up so people can take time off and really be gone. Avoid single point of failure. |
Be sure that documentation and README’s are up to date so work can be picked up by other engineers with limited delays cause by bad documentation. |
Log additional support (ad hoc support) as an issue in Jira and adjust the schedule to reflect the additional support provided by Unity engineering. |
Pad our delivery timeline. Delivery on the last day of the contract is not supportable. Leave a week for final button up and documentation and delivery. (Hyper Care Sprint) |
Record every meeting. |
Do acceptance testing for every milestone delivery. Acceptance Test checklist. |
When taking over an existing code base add a TAC (technical architecture consultation) sprint for “discovery”. Should be a prerequisite for writing the SOW (when possible) |
|
Stop doing |
|---|
Don’t do work without an executed change order in place. |
Spending time trouble shooting the customer’s issues before they do their own due diligence to confirm the problem is with the code and not with the device/firmware. |
|
Keep doing |
|---|
Remain flexible |
Update documentation as the project is underway to avoid late scramble. |
|