Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 59 Next »

About This Project

The goal of this project is to develop the Intelligent Transportation Systems (ITS) Joint Program Office (JPO) Operational Data Environment (ODE) Collaboratively using Agile Development Methodologies with the CV Pilot Teams.

The Operational Data Environment is a real-time data acquisition and distribution software system that processes and routes data from Connected-X devices –including connected vehicles (CV), personal mobile devices, and infrastructure components and sensors –to subscribing applications to support the operation, maintenance, and use of the transportation system, as well as related research and development efforts.


Leveraging The ODE

leveraging-the-ode-cv-pilot-systems-engineering-briefing.pdf
 


ODE Architecture Diagram

Helpful Documents

usdot-rsu-specification-4-1_final_r1.pdf

ode_user_consumer_producer_activity.xlsx

semi-ode-task-4-conops-final.pdf

wyo-phase-2-v2.zip

scms-poc-ee-requirements-20160407_1648.pdftask-4-system-design-description-v3-1-20160526.pdf

Definition of Done

  1. User acceptance criteria in the user story has been met    
  2. Testing has been  completed

  3. The code has been pushed out to GitHub

  4. This process has been documented in Jira & release notes

  5. Demonstrated to Product Owner


Process for Closing a Story

  1. Developers burn down their hours and change the status of their completed tasks to Done.  
  2. Developers mark whether the Acceptance Criteria has been met and Mark (X) that all the Definition of Done criteria has been met.

  3. The Product Owner verifies that the Acceptance Criteria has been met  and that the Definition of Done is satisfied after the Sprint Review (Demo).

  4. This Product Owner gives the OK to close the story.

  5. The Scrum Master close out the Sprint.


Bugs

A bug is a defect in a feature that has already been accepted. Bugs should not used to detail new features and functionality  . Bugs are directly related to features that have already been delivered and provide no new user value, which is why they do not have points. The other reason they do not have points is that bugs can be impossible to estimate and could take 30 seconds or 30 days to resolve.

Bugs should include this information:

  1. Title:  Short and descriptive 
  2. Description: Reference the story that produced the bug. Describe what should be happening and what is currently happening.

  3. Instructions: Outline the steps to reproduce it.

  4. Resources: Include screenshots and other assets to help show the bug.

  5. Make a comment in the story that produced the bug.
  6. Scrum Master/Team can close out bugs after they have been fixed.




Tip Of The Day

 

 A man can be as great as he wants to be. If you believe in yourself and have the courage, the determination, the dedication, the competitive drive and if you are willing to sacrifice the little things in life and pay the price for the things that are worthwhile, it can be done.

Vince Lombardi




 







 


  • No labels