Category Archives: Scrum

CS448 Sprint 1 – Retrospective

This past Tuesday 2/27/2024 marked the conclusion of Sprint 1 for CS448 – Capstone. My team worked generally well together and we managed to complete all of our assigned tasks as well as some extra we added during the Sprint.

During this Sprint, I was involved in addressing a few different tasks and issues:

Issue spent most time on – “Create General and Pipeline” https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/10. This issue was in the “General” (#gitlab-profile) repository and consisted of three separate parts: 

  1. Moving settings from configuration files set up for integration with Dev Containers to .gitpod.yml extensions for GitPod integration.
  2. Refactoring the ‘commands’ folder to ‘bin’ to keep up with industry standard file naming. This includes updating script paths and .gitlab-ci.yaml environment variables to refer to bin.
  3. Adding the AlexJS linter to pipelines as well as the bin/lint.sh test script file.

Also, as a part of this issue I also implemented some minor typo and similar fixes so that all linters pass for a successful integration pipeline. Originally, these were three separate issues that were combined during the Sprint.

Issue #2 – “Familiarize ourselves with GuestInfoFrontend to Understand What Goes into CheckoutGuestFrontend”

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/37. This issue included all team members and was intended to prepare each of us for Sprint 2, during which we intend on tackling some front-end Epics/issues in CheckoutGuestFrontend. So, I reviewed the GuestInfoFrontend repository structure and began to strategize a possible plan of action for building out CheckoutGuestFrontend.

As mentioned, my Team added additional tasks to our Sprint Backlog during the sprint as we found we would have extra time leftover after completing our original tasks. We chose to take on “Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages” for the Documentation and General repositories as we had already set up the settings and thereby familiarity with these repos. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/issues/10

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/12

I created our new issues; we were able to complete the task for the Documentation repo as it was relatively simple in terms of not needing to make many changes/add linters, and make some progress in the General repo but pushed the issue into Sprint 2.

Reflecting back on the sprint, there were a few things that come to mind which worked really well – as a team we scheduled out our tasks well between standups and managed to have full attendance at each. Also, when we needed to add tasks we elected to stay within the repositories we had already been working in and were somewhat familiar with, which was a good choice as switching would have likely wasted time getting familiar with the new repo, as well as wasted time for another team who would have needed to become familiar with ours. 

However, we struggled somewhat with getting used to navigating the GitLab issue board, merges, child issues etc. and sometimes it felt like some team members were in different places where a solution may not have been fully communicated to all teammates. As a team, I feel we can improve on some of our internal communication and do a better job planning out our sprints and creating something of a road map, especially as we prepare for Sprint 2 which is considerably longer than the first. Personally, I think I can improve my time management and also be a bit more involved in the process of planning out our next Sprint and creating issues with relevant descriptions and linking to organize our tasks and get a better feel of how to use GitLab to its maximum potential.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Capstone: Sprint Reflection 6

Sprint 6 was the final sprint of the semester. We rounded up this sprint with an unfinished solution to issue APTS-254. Over the course of this sprint, we were feeling really good on our understanding of this issue. We required quite a bit of clarification from the Ampath team. After getting some really good clarification we found that the code we needed to work on was in an entire different directory from the one we had been previously working in. Once we finally found where we should be working, we began digging in deep into the issue. The first thing we noticed is that this issue was associated with their ETL server implementation. None of us on the team had previous understanding of what an ETL server was so we I did some digging. I found a few resources online (Here’s a good brief description) that I summarized for the group. The idea was fairly simple, except the way the Ampath team was using ETL was basically by skipping the Load portion and just passing the transformed data to the end user as a notification.

I had a really good understanding of the issue at this point and even began writing some code that I thought might work for this specific issue. Part of the major issue that stopped us from being able to test this solution was the fact that we were unable to test that our solutions actually worked before committing changes. In order to test our solutions we were going to need a running ETL server. In the end I was kind of bummed we weren’t able to resolve another issue before semester’s end. But I felt good in the things I learned from trying to resolve this issue.

I would love to continue working on these issues in the future but with all my personal projects and the fact that I will be starting a new job (as a Software Developer) on the 22nd, I don’t plan on having a lot of extra time. All in all I really enjoyed working on Angular 2 and seeing how a large scale project like Ampath was built.

From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.

Sprint 5 Learning Reflection Blog (4/12/17)

I can’t believe this is our last sprint! It went by so fast; it feels as though we are just starting. Overall it was definitely a good learning experience being able to collaborate with a real organization. Our group had a good conversation with our professor about this whole sprint experience with the AMPATH group and it kind of prepares us for what it would be like working for a company in the real world as a full-time job. Over the duration of 2 months we only were able to resolve one issue. By face-value it might sound bad, but we spent the majority of the time trying to understand the language of Angular2 and the framework of how everything operated. If you think about it, my experience with this is pretty similar to what it will be like when working for your first company; most of the time will be getting used to the coding language and the framework. Prepare to be doing that most of the time before you even begin coding anything!

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

Capstone Project: Sprint 2 Reflections

Another sprint down! This sprint was much more exciting then previous sprints. This sprint we were finally able to get OpenMRS and Ampath running locally on our machines so we could fiddle with it! I have a tendency to probe things I don’t understand until I either 1, understand them or 2 break them. Luckily this time was the former over the latter. Part of our previous sprint was to re-write an Ampath module, specifically the authentication. This was to help us learn how the REST API works and to generally learn how Angular works. We broke our sprint down into a few steps.

  1. Remove all traces of an authentication module from the Ampath directory tree.
  2. Attempt to rebuild a basic html/css of the original Ampath login page.
  3. Creating the Authentication routing so when we visit localhost it will successfully show us the html page we had just created.
  4. Make sure the login button successfully authenticates the user.

These four basic steps were what we felt as a scrum team, each individual could finish in the time we had for the given sprint. Unfortunately for me, because I enjoying coding and learning new things so much, I finished this by day 3 of our approximately 8 day sprint cycle. This left me with nothing to do, but plenty of time on my hands. I took that time to start researching TDD inside of Angular and how to write Karma tests. I really like the Karma framework and the way you simply declare what a test should be doing. I feel that it makes your testing output extremely easy to read, which is especially nice when you are showing it off to your wife who is by no means a software developer. But in the case of the real world, it gives someone A LOT of insight into what your code is supposed to do by them simply running test.

Tomorrow we start Sprint 3. From my understanding we are going to become familiar with JIRA and Ampaths issue tracking, so we can start (hopefully) resolving some issues for them! I am very exciting to be finally diving deep into this project and I hope to make some significant changes!

From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.

The Clean Coder: Chapters 9 & 10

The Management. Such an interesting topic for a book dedicated to becoming a professional. What Uncle Bob is talking about here is two distinct forms of management; personal management and business management. Interestingly enough, these two topics become intertwined quite often. The first instance in which this appears in the book is when he talks about meetings. When the section starts on meetings Uncle Bob stated something I’ve been saying for years now.

There are two truths about meeting.
1. Meetings are necessary.
2. Meetings are huge time wasters.

My current position requires me to attend an occasional meeting, typically conference call style. The one thing I have found is that these meetings are very important to keep people up to date on whatever the contents of the meeting are and it helps get every one on the same page. However, every meeting I have been apart of was by no means short. I believe the shortest meeting I was ever apart of still lasted 45 minutes and by the end I walked out with no more knowledge then I had gone in with. Having had these experiences, when I saw Uncle Bob’s statement about the two truths of meetings I felt relieved that I wasn’t the only one that felt this way. Uncle Bob went on to talk about the different meetings that are had in a Scrum methodology of software development. Reading his thoughts on how these scrum meetings should go is very interesting. Currently with the Capstone class at WSU we are using Scrum and I can see how some of these meetings could go very long. I believe my team and I have done a good job and avoiding wasted time during these meetings, though.

The rest of chapter 9 covers ways to stay focused. Fortunately for me, most of these methodologies or theories appear to be common sense to me and I didn’t take away that much new information from these paragraphs.

Chapter 10 talks about estimates. Interestingly enough, I’ve had to create a few estimates in my line of work. Granted these were extremely small scale and usually completed in under an hour. The thing I learned from creating those estimates was, it’s incredibly hard to estimate time for when things go wrong.

As I mentioned in a previous blog post I listened to a podcast (You can find it here ) on software estimation a few months back. This chapter from Uncle Bob felt like a refresher on the things talked about in the podcast. What I find most fascinating about this subject, is that in my field an estimate is occasionally taken as “set-in-stone” and “done-deal” type of artifacts. However, that’s what business has turned it into and that was never what estimates were intended to be used for.

I don’t have too much more to say about estimates for software, seeing as I haven’t had to ever create one yet. However, I know when my time comes to finally use this information, I will be referring back to Uncle Bob!

From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.

Capstone Project: Week 3 Reflections

Yet another week here and gone. This weeks reflections will be fairly brief due to it being the end of our sprint and having a weekend with nothing to work on. However, we did have a sprint retrospective this week due to our sprint completion! The retrospective went well. Our team has really great communication and that has helped us, so these retrospectives are just re-caps of things we found during the week.

One of the major issues we discussed was with our daily stand-ups. Due to us having to all do them remotely there leaves a lot open for loosely worded statements. We were using a lot of “I’ll try” or “I might get it done” and we wanted to clear up this language and be more precise. We found that two things happened when we became more precise.

  1. Others trusted what we said and knew we were going to get done what we said.
  2. We held ourselves personally accountable to truly get the things done that we said we were going to.

These two things I feel are very important for any scrum team!

We did our first real sprint planning today and I am very excited to start working with the AMPATH code and seeing what true professional software looks like!

From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.

Yay, Scrum!

For this semester, we will be collaborating with OpenMRS and AMPATH for the entire duration of the course to possibly help develop some type of new software that the association can use in their medical systems. That alone in itself is extremely exciting and I can’t wait to really begin diving into the hands-on programming of whatever software it is we will be developing because this will be the first time I am doing something that is career-based related in the real world.

What’s even more exciting is the new framework of Scrum that I have recently been introduced to. The idea of Scrum is to divide up the development cycle up into 1 to 2 week intervals known as sprints where there are goals and objectives set for each sprint that the team focuses on completing before moving onto the next sprint into the rest of whatever needs to be developed. I don’t really want to dive a lot into how Scrum actually works because I’m sure you can look it up online for a better understanding of it if you want but I am really looking forward to incorporating this framework into our collaboration with OpenMRS and AMPATH and gain further exposure to experiences I will most likely be using once I get a job as a software developer.

While I was job hunting, there were definitely a handful of companies and corporations who are looking for employees with experience in Scrum so hopefully I can add that to my resume after this course!

CS 448 Week 1 Blog (January 17 – January 23)

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.