Scrum is a framework that teams use to organize themselves in a project to reach a common goal. The values that members of a scrum team value are commitment, courage, focus, openness, respect. Scrum team is open to new ideas and opportunities, respecting each other, and have patience for the scrum process, and focusing on time-consumed tasks, and finding space for improvement. 

Scrum deliver a product for customer in a time period called a sprint. Product Backlog is the to-do list for a team which contains the requirements for a project. Product owner, which is one of the scrum roles, is responsible for maintaining and adding updates for the list, removing and adding new requests from customers. Sprint backlog is lists of items from the product backlog that is worked on during the current sprint. Increment is the end product of a sprint. 

The product owner guides the team on the next steps in the scrum process and ensures that the team understands the requirements that a business or client wants. The Scrum leader is responsible for making sure the scrum team works effectively. When working in a scrum team, there are different types of events that the scrum team is involved in.  Sprint planning is when teams estimate how much work needs to be done in a sprint. Daily Scrum is a short meeting where team members plan for the day, and provide updates on challenges experienced, and what work has been done. Sprint Review is the period at the end of the sprint, where the team reviews the work that has been completed, and presents it to stakeholders. Sprint Retrospective is when a team comes together to discuss the sprint result and make adjustments for future scrums. 

This semester in  CS 348, I had learned about scrum. With learning scrum, I was able to see how software team deliver products for clients. 

What is Scrum? – Scrum Methodology Explained – AWS

From the blog CS@Worcester – jonathan's computer journey by Jonathan Mujjumbi and used with permission of the author. All other rights reserved by the author.

This article is a beginning-to-end write up of the Agile methodology by Miriam Posner, an Assistant Professor at UCLA. She starts with a pov of someone watching an agile team in action, complete with all the user stories, story points, stand ups, a whiteboard, post-it notes, and sprints. For those who have not been introduced to this software development process, ‘stories’ are descriptions of features with ‘points’ showing the difficulty of implementing said features. ‘Stand ups’ are start-of-the-day meetings done standing up for quickness, the whiteboard is to organize each story point, represented by post-it notes, into the stages of ‘in-progress’, ‘done’, ‘backlog’, etc. ‘Sprints are just quick two week long work periods that help to break down the project into digestible chunks.

While this might seem rather much from to some people, others might have an opinion closer to Miriam, who found it to be efficient and intriguing. As such she researched the origins of Agile and learned the complicated history of managers and software developers. I will try to keep this summary brief while hitting all the major points.

Miriam starts with the buildup to Agile. It started in the 50’s and 60’s, most ‘experts’ said building the computer was the hard part and programming it would be trivial. The sheer enormity of their incorrectness led to a push in the field to adopt the name (and stricter processes) of engineering, leading to the coining of the term ‘software engineering’. The idea was that by following engineering techniques the experts would “transform the arcane and error-prone craft of computer programming to meet the highest standards of the engineering profession.” The next people to step in were the businesses who looked to hire these new ‘software engineers’. They created a framework of control where one person defines the project and breaks it up into steps, which are in turn handed to engineers to build and test before moving on to the next step. This was derogatorily called the “waterfall” method, so of course upper management took the name and method and ran with it. This method started to fail due again to people who were not programmers believing they knew what programming entailed. The main problem was that whenever any issue came up in the code, every step needed to be redone which meant the timeline would be increasingly muddled.

Next came Agile, created by “17 middle-aged white guys dressed in khakis and dad jeans” in the Agile Manifesto. In their words:
“We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.“

I would like to continue this dive but I am out of words.

Have a good day.

Link:
https://logicmag.io/clouds/agile-and-the-long-crisis-of-software/

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

Hello Debug Ducker here, and this one is going to be a lot less focus. As I near the end of my college fall semester, I come to realize that I am nearing completion of college, and will hopefully come out with a bachelors degree in Computer Science. With this in mind I did some reflecting about my choice in the field and how have my classes helped me.

For this semester, I did a CS course called Software Construction, Design and Architecture. To best describe it, its like applying the fundamentals of computer science, while understanding new techniques to build better software . I remember at the beginning we review some CS concepts such as Polymorphism, Abstraction Inheritance, and Encapsulation, and when studying it I was surprise to see I was still familiar with the subjects. Even funny that I recently applied for an internship with a company that had me do a test involving those subjects It made me feel more confident with my abilities. Also with the way the class was setup I was a lot more engage with the subjects.

I also learn some new things that involve CS such as UML class diagrams that basically meant to outline the program class structure. Here is an example that I did for class assignment

This was meant for some appointment application, I just did a diagram of it. I can see this being helpful in the field to help people understand what exactly going on with classes if they are new to a project.

I also learn about API work and I am not exactly clear on how it all works but I say I understood a little. I relearn the HTTP methods during that time, which I needed cause it has been a while since I had experience with them. Funny, that one of the HTTP method names is just GET, which just gets you information from a database. Anyway I hope to return trying API so I can get a better grasp on it.

That is a review on the class work but about my efforts. I say I did quite well despite some difficulties. Some unexpected hurdles came but I was able to jump over them to the other side and learn some new skill as a result. Though time waits for nobody and I may have missed some things but hopefully that could be mended.

Now that I am typing these I would like to use to blog for other purposes in the future but we’ll see. Have a nice a holiday and thank you for your time.

From the blog Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Hello everyone

For my last blog for the semester, the topic would be about Software Licenses and their importance in the computer science field. This was one of the most underrated things I learnt during the semester, so that’s why I wanna talk about it. Even though now it seems obvious, it never crossed my mind that I should always put a license on my project. This blog makes an amazing explanation on why you should always put a license on your work and also which one to choose from.

The blog begins by explaining the different types of software licenses, starting with:        Permissive Licenses – which impose minimal restrictions on what you can do like modification and distribution of it. Some of the most popular permissive licenses are the MIT and the Apache license. They are highly popular because they typically only require attribution, which is that you have to give credit to the original author.                                            Then the blog talks about:                                                                           Copyleft Licenses – anyone could modify and distribute the code, but they had to share their changes with the community under the same license. Some of the most popular Copyleft Licenses are the GNU Lesser General Public License (LGPL), which allow linking to open-source libraries with limited obligations but impose stricter requirements if the library is modified. There is also the GNU General Public License (GPL). They are a bit more restrictive, requiring that any derivative works be distributed under the same license and with access to the source code.                                                               

At the end of the blog, it addresses unlicensed code. Emphasizing that code without a clear license is not automatically free to use and may lead to copyright infringement. If the code does not have a license then it is considered to be under the default  copyright laws. This means that only the original author has the right to use, distribute or modify it. If someone was to happen to use it even if it is publicly available, it raises legal issues.          This blog to me was incredibly helpful and useful as it not only explained the various types of software licenses but also gave examples of them. It showed and highlighted the types of works and where would you wanna use these licenses and what works the best for you. One thing that I learnt while reading this blog was understanding what is an SBOM which stands for Software Bill of Materials. It is a detailed list of all the components in the code and their respective licenses. It is important to understand what licenses works the best for you so you can get the most out of it. The computer science field is an amazing work space that everyone can work together to build each other up and licenses help us do just that!

https://www.blackduck.com/blog/5-types-of-software-licenses-you-need-to-understand.html

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

I recently read the article “Gathering Requirements for a Development Project in 2025” on Developer-Tech.com. The article talks about how collecting and understanding software requirements is changing, focusing on new technologies and ways of working to make the process better.

I picked this article because I want to improve how I manage software projects. Gathering requirements is such an important part of any project, and understanding future trends can help me stay ahead. The article gave clear examples of how requirement gathering is improving and what to expect in the coming years.

The article covered three key points:

• Using Artificial Intelligence (AI): It explains how AI tools can make collecting and understanding requirements faster and more accurate. AI can analyze a lot of data quickly and help figure out what stakeholders (the people involved in the project) need.
• Better Team Collaboration: The article emphasizes how important teamwork is. New communication tools are helping teams work together more easily, making sure everyone understands the project’s goals.
• Agile Development Methods: It talks about Agile, a way of working that breaks projects into smaller steps. Agile lets teams adjust requirements as they go, so the final product meets user needs better.

This article made me think differently about how I collect and organize project requirements. The idea of using AI tools stood out to me because it would make the process quicker and catch mistakes I might miss. In the past, I’ve done everything manually, and it can take a lot of time.

The part about teamwork also hit home for me. I’ve worked on projects where poor communication caused delays and confusion. Using tools that help everyone stay connected and clear about the goals can make a big difference.

I also liked what the article said about Agile. I’ve worked on projects where requirements changed halfway through, and it was stressful. Agile makes it easier to handle those changes, which is something I plan to learn more about and use in future projects.

Overall, this article was a great introduction to how requirement gathering is improving. By using AI, working more closely with teams, and adopting Agile methods, I can do a better job on projects. If you’re interested, I recommend reading the full article: Gathering Requirements for a Development Project in 2025.

From the blog CS@Worcester – Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

I’m writing this blogpost about Scrum, specifically about the Sprint Retrospective(although the author refers to it as a Scrum Retrospective) that takes place after a Sprint Review. This blogpost(possibly article?) caught my eye while I was browsing through some blogs, as it directly references something we’ve learned about in class, but from a different point of view. Does ‘fun’ and ‘silliness’ have a place in a professional setting like a Sprint Retrospective? My initial thought after reading this introductory question is that yes, a little playfulness is fine as a means to relieve tension and stress, so long as it doesn’t hinder productivity, and so long as everyone is comfortable with it. But while it’s fine in moderation, it’s by no means a necessity. If someone wants to maintain professionalism, then that’s completely fine too. But as someone who’s never actually worked on a development team, I was interested to hear an experienced person’s take on the subject.

In the referenced article, Sjoerd Nijland first addresses the common critiques of playfulness, where people call it unserious and unprofessional, and assume that it gets in the way of productivity. He counters by mentioning the benefits of playfulness based on neuroscience. Some of these include: Improving brain function, energy, and happiness, relieving stress, deepens connections and trust, and encourages creativity needed for problem-solving, amongst many other benefits. It’s something that everyone, even introverts, can benefit from. It’s a mindset. It provides psychological safety. It puts people in a comfort zone, leaving them open to new ideas and discussion. It keeps people trusting of one another, instead of checking and inspecting each other. And so he counters the common by saying that not only can it be beneficial in a professional environment, but that “Discouraging playfulness at work is profoundly UNprofessional”. When applied intentionally, it can be a great mechanism for helping your team deal with what would otherwise be a stressful environment.

I like the way he views playfulness, because he thinks of it in a different way than most people would. Playfulness isn’t slacking, it’s a tool, one that benefits team dynamic and productivity in the long run. Too much of it can be detrimental, and people shouldn’t be neglecting work for play, but ideally it should exist in some capacity. He references existing scrum environments and scrum professionals, and addresses how it’s helped in certain cases, and how some of the scrum critics aren’t viewing it the way they should. Playfulness and seriousness complement each other, and when used correctly, is a great tool for improving your team’s relations, stress levels, and ultimately, productivity. I’ve changed my mind playfulness being unnecessary. A little levity is important for the mind and body, and I’ll definitely keep that in mind when I’m in a professional environment.

Link: https://medium.com/serious-scrum/a-serious-look-at-playful-formats-in-retrospectives-73aed21aa083

From the blog CS@Worcester – Justin Lam’s Portfolio by CS@Worcester – Justin Lam’s Portfolio and used with permission of the author. All other rights reserved by the author.