Show Menu
Cheatography

A sheet describing how we use Rally to manage our development pipeline

Rally Schedule states

Idea
(I) Provis­ional User Story or Defect, requires design work
Defined
(D) User Story or Defect has either been designed or is a simple story
In Progress
(P) Once work has been started by a developer
Complete
(C) Work has been completed by a developer including code reviews and updated docume­ntation
Accepted
(A) Work has been signed off by the testing team.

How to Complete a User Story

Review User Story and Acceptance Criteria
Document design in the ADD document
Take the Task within Rally, and check that you agree with the time estimate
Write Unit & component tests to confirm the behaviour of the first part of the first task
Write code to pass the tests you have already written
Review tests and make sure they are correct
Update todo estimate if sensible
Iterate previous 3 steps till task is complete
Refactor code to ensure it high enough quality.
Update actual time spent on task
Iterate previous steps for tasks until User story is complete
Do a final refactor step to ensure code is well designed etc.
Review ADD & update if required
Review SMG & update if required - mark the checkbox stating that docume­ntation is uptodate.
Ask someone to code review work.
Action all MoSCoW items as required and give back to reviewer to do the merge
Mark task as complete
Testing team will test and Review and reopen if required or mark as Accepted
 

Checklist for a Code Review

Check code runs
Does design match documented design
Can you break by changing test values etc
High level review to ensure methods aren't too long
High level review to ensure classes are named properly
High level review to check its clear what the code does
Check test coverage
Check tests are in the correct area of code and seem sensible
Check naming of methods and variables
Check no libraries are in use unless agreed
Check abstra­ction is required
Check naming conven­tions
The code should be branched and all comments committed in the relevant part of code, and then committed back to Github. Each change should be classified by:
(M) Must Change
(S) Should Change
(C) Could Change
(W) Won't address

Raising a defect

Enter a descri­ption of how to reproduce it
Enter the Git Commit Hash it was found in
Set the severity and priority (ask Marryat if unsure)
Check if it should be scheduled for this iteration.
Ideally link it to a Test Case
Ideally link it to a User Story

Fixing a defect

Git commit messages should include the DE### so it links in Rally
Enter the Git Hash that fixes the defect in the Fixed in Field
Enter any notes that are relevant
Set the Defect State to Fixed
Set the Scheduled State to Complete
Set the Resolution

Verifying a Defect

Enter the Git commit hash that you are verifying the fix in
Change the Defect Status to Closed
Change the Scheduled State to Accepted
Add in any notes that are relevant
Re-run the test case and record the result if presen­t/r­elevant
 

Metadata

  • Languages:
  • Published: 16th May, 2014
  • Last Updated: 12th May, 2016

Comments

No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          Relaymed Developer Guidelines Cheat Sheet

          More Cheat Sheets by Marryat

          Relaymed Developer Guidelines Cheat Sheet