Embedded Files
WEEK 3/4 - Sprinting Through the Sprint
Week 3: 12 September - 18 September
Week 3: 12 September - 18 September
At the end of Week 2 during our Daily Standup, Emily and I were assigned two stories to work on for Sprint 6.1. We decided that we would began pair programming for the sprints until we both felt more familiar with the process of the UW Team. Pair Programming is an Agile Software Development technique, where two developers team together on one computer. Pair programming can be beneficial as it allows one person to 'drive' while the other 'navigates.' More simply put, one developer Is physically writing the code, while the other Is observing and reviewing the code being written. Although the development time is greater, the defect counts are lowered and this Increases the overall cost of development in most cases. A defect count Is the number of errors that have been discovered.
Since Emily and I are not located within the same region, we decided on using Discord to share our screen to display the code. This allowed us to pair program without being In the same place at once. Pair programming can also be useful to us since pushing or merging via GitHub can be a complicated task In some Instances. This technique allows us to avoid the mess of merge conflicts.
Image 1 - Daily Scrum Meeting Rules
Daily Standup Meeting
Daily Standup Meeting
Last week within my meeting highlight, I talked about a Daily Standup Meeting also referred as a Daily Scrum Meeting(DSM). This meeting consists of the core team, In our case the UW Workflow Team, getting together to discuss everyones Individual progress on their task(s) for the sprint. These DSMs have some criteria Including:
15 minute meetings - short & effective
Everyday at the same time - consistent
Run by the Scrum Master(Fredrick)
They also have a specific agenda, where the Scrum Master will call on each team member to answer three Important questions:
What did you complete yesterday?
What will you complete today?
Anything slowing you down or blocking you?
A DSMs Is suppose to help the team stay on task and Identify any blockers that could Impact the completion of stories within the sprint. Since last weeks post, the org chart of the UW Team has changed a little as we've added an additional developer to the team.
UW - 205
UW - 205
After reviewing both UW-205 & UW-206, Emily and I decided to tackle UW-205 first. There was no specific order to these tasks - we could've chose either one first - the order number did not matter and there were no dependencies between the two tasks. I'll touch back on why we chose to go with UW-205 to began with In a bit.
What Is the task? And the description of the task
Task: As an external UW Stakeholder, I need Toolbox MVP to be available on GitHub Wiki
Description: Create a GitHub Wiki for the Toolbox MVP document. It should likely live under a top level "Planning documents" section
What does this mean?
From a quick read of the description I had several follow-up questions to dig Into:
What Is a GitHub Wiki?
Are we simply transferring the existing page on Confluence/Jira to the UW's GitHub Page?
I was able to find some answers after looking up more about GitHub Wiki and discussing with the team. It seems that a GitHub Wiki Is used to 'share detailed, long-form information about a project.' Once confirming with the team, our assignment was to take the existing Toolbox MVP Document and move It Into a GitHub Wiki to allow external stakeholders to view the document who do not have access to Confluence/Jira. This job could be better described as a 'copy and paste' of a document from one tool to another. I was able to compare the current wiki on the workflow-tools repository to other repository wikis within the ufs-community.
Accomplishing the Task
The two Images below show the short-range weather application wiki, which I modeled our workflow-tools wiki after. Within the wiki you can see 'Pages' tabs are minimized, allowing only our Planning Documents sidebar to be displayed. Each page within our Planning Documents section Is linked to an Individual page within the Pages menu. Previously there was only a single page displayed In the Pages tabs called, 'Project Charter.' We took about a couple hours spread over two days to implement story UW-205. I've added a references list below for the resources used to complete the project.
Image 2 - UFS Short-Range Weather Application Wiki
Image 3 - workflow-tools Wiki
UW-205 vs. UW-206
UW-205 vs. UW-206
Deciding between UW-205 vs. UW-206, we chose UW-205 based on the description of the task. It was clear that both of these tasks would be the same process with different documents. We decided to Implement UW-205 first because It consisted of a single page and would be a great starting point. UW-206 consisted of transferring over 5 pages of documents In total and would be a bigger task.
Week 4: 19 September - 25 September
Week 4: 19 September - 25 September
UW - 206
UW - 206
What Is the task? And the description of the task
Task: As an external UW Stakeholder, I need the planning and design docs for configuration management available on GitHub Wiki
Description: Create a GitHub Wiki for the Component Configuration Management - UFS Weather Model document and several others docs Included underneath It. It should likely live under a top level "Planning documents" section
What does this mean?
After accomplishing UW-205, we knew exactly what this job would look like and were confident In our abilities to accomplish UW-206 as well.
Accomplishing the Task
We Implemented story UW-206 within two hours over a single day and were able to finish our tasks assigned to us within Sprint 6.1 four days early. We used the same resources from UW-205 to complete UW-206. Within our Active Sprints chart, we were able to move each task through the major phases, To Do --> In Progress --> Peer Review --> Done (Image 4). UW-205 Is currently In the Done phase, and UW-206 Is in Peer Review.
Image 4 - Active Sprint 6.1 Story Board
What's Next?
What's Next?
Since we finished our tasks In Sprint 6.1 early, we will be able to pull a task from the product backlog. The product backlog is a list of all things that need to be done within the project. In our case we will be able to take a look at the tasks In Sprint 6.2 and decide which one looks the best for us to be work on within the new sprint. After talking to Christina, Emily and I were able to decide on taking UW-191 for Sprint 6.2. We were given Insight Into the task and given resources to accomplish It successfully. The team also was able to move UW-206 Into the Done phase to close out Sprint 6.1.
Closing Out
Closing Out
To end Sprint 6.1, we close out with a Sprint Planning and Retrospective meeting. In this meeting we cover what went well, what could've been better and discuss more on the sprint ahead. Image 5 Includes an overview of the meeting.
Image 5 - Sprint 6.1 Retrospective
A Look Ahead
A Look Ahead
At the end of Sprint 6.1 we also welcomed a new team member Keven, who would be on the team and contribute 25% of the time as a developer. Sprint 6.2 will begin Monday, September 26th, with limited capacity for Emily and I. Next week, I will touch on what limited capacity means for the team, begin to discuss more on what UW-191's task consist of, and more.
Page updated
Report abuse