lab05 : Second Retrospective, Product Improvement, Additional Testing

num	ready?	description	assigned	due
lab05	true	Second Retrospective, Product Improvement, Additional Testing	Fri 10/29 11:00AM	Fri 11/05 11:59PM

Grading for Second Retro

Today: Second Retrospective

You already know the goal and procedure for Retrospectives from your RETRO_01. This Retrospective allows you to discuss things that emerged from the MVP effort and feedback you received.

• You’ll do a quick standup and then the retro in team groups
• When you are finished and still have time, discuss your team’s strategy towards the testing requirement in this lab.
• Staff will be dropping in to observe.

Retro Deliverable

• In your team’s repo, under team directory Add file RETRO_02.md to team/retrospectives

• Add a section:

  # Retro #2 10/29/21 
  
  * Led by: name-goes-here
  * Present: name1, name2, ... , nameN
  * Absent: name1, name2, ...
  
  ## Action item
  
  * a goal: identify something the team wants to get better at
  * a change: identify one thing that the team will change about how it works together
  * a measurement: identify at least one way to measure whether the change helped the team acheive the goal, or move closer to it.
  
  ## Optional
  
  * Record anything else you think the team might want to remember from this retro
  
  

• After the Retro

  Retro leader: add

  ## Retro Assessment
  
  * A brief description of what retro outline or process you used.
  * A brief assessment of how it went.
  * What advice would you give to the next person leading a retro
    based on what you learned today?
  

Grading for new Development / Testing

Over the next week, please focus predominantly on new/improved functionality/robustness/user experience for your product, using your momentum and ideas from the MVP effort and discussion.

Again, every team member should be assigned new issues towards this goal. Minimum requirement is that each team member be assigned and complete at least one new issue during this week, but a higher issue frequency is encouraged. Make sure that your issues have clear acceptance criteria in Github Projects and that you have a process for completing and assigning issues (e.g. feature branches or your own “Continuous Delivery” rules). It should be possible at any point in time to deploy your product with new improvements over time!

So, while focus should be on your product growing/improving, we want you to experiment more with Test-Driven-Development (TDD). This could be a great week to fully embrace TDD, and we think you would get many benefits from it in the long term. It is, however, an investment in the short term, so if you don’t think that you are ready to completely switch over to TDD, then at the very least you’ll have to select a tool for component testing (a type of integration or end-to-end testing) and implement at least one component test or other integration or end-to-end test in your source code. Use of a Behavior-Driven Development (BDD) framework would also check this box.

Teams working with React could use the React Testing Library or Enzyme or Storybook. Python backends could for example be tested with TestProject or the BDD frameworks Behave or Lettuce.