CS-348, CS@Worcester, Week-4

Source Article: https://www.atlassian.com/agile/project-management/definition-of-done

Recently, in doing a project in class, I had to write a Definition of Done (DoD) file for my portion of the project. I had a basic understanding of what needed to be conveyed, but not exactly how to convey it. I wanted to know more. I looked further into what the industry standard is, and that’s how I came across this post, which I used to help me figure out the one for my project.

I recall from the previous class activity that we looked at the Scrum Guide by Ken Schwaber and Jeff Sutherland, and the guide did give information on what the Definition of Done was and what it is meant to convey, but I wanted something more in-depth.

According to the article, the Definition of Done is a shared set of criteria that tells a Scrum team when a product increment is truly complete. The specifications contained are not created by one person but agreed upon by the entire team because there needs to be a shared understanding of what’s expected at the end of each sprint and for the project overall. This is needed to avoid miscommunication and make sure the team adheres to the pillars of Scrum: transparency, inspection, and adaptation. The developers of the team have the responsibility of parsing out what the DoD will be continuously as it will evolve and change as increments pass.

I knew that whatever was agreed upon needed to be something that is measurable and testable, otherwise there would never be a satisfying way to declare being done. But the article mentioned something about the DoD needing to also be “ready to ship”. This means that there can be no hidden work left after the spring, and there can’t be extra polishing stages.

The most helpful portions of the article were the examples that were provided of what can be included in a DoD. Here are some of them./

• Increment Passes SonarCube checks with no Critical errors
• Increment’s Code Coverage stays the same or gets higher
• Increment meets agreed engineering standards
• Acceptance Criteria for Increment pass
• Acceptance Tests for Increment are Automated

Most of the examples include the project passing specific tests or meeting certain standards that would be either required by the client or the organization the team is working for, which is par for the course. The DoD is an important part of Scrum, and I need to understand how to think of a project in order to write one in future cases.

From the blog CS@Worcester – A Beginner's Journey Through Computer Science by Christiana Serwaah and used with permission of the author. All other rights reserved by the author.

Source: https://www.perforce.com/blog/qac/what-is-linting

Recently, in class, we did an activity on creating a lint script. The activity honestly confused me a little bit out of the many questions I had about it. One of the questions I wanted to explore is more about what linters do and why we use them. The activity gives a brief description of what linters are and their purpose.

According to the activity, Linters are tools that check the formatting and style of code and files in projects. Some extensions, like the one used earlier in the activity, markdownlint, can perform some of this checking, but not all tools are available as extensions. I would like to understand them a bit more, so I chose a source that went into extensive detail about what linting is and linters.

It scans the code for things that don’t necessarily prevent the code from running but can cause bigger issues later on, such as small bugs, conflicting formatting, and bad style choices. It can also look for common errors like indexing beyond arrays, dereferencing null pointers, unreachable code, and non-portable constructs.

It’s better suited for programming languages like Python and JavaScript because they are interpreted languages that don’t have a compiling phase, so linting helps with keeping up consistency. Linting is more effective in code that follows standard rules and is in projects that need to adhere to shared style guidelines.

Linters are a basic form of static analysis tool, which are any tools that can analyze code without running it. More advanced tools are able to detect:

• Deeper data-flow problems
• Runtime risks
• Security vulnerabilities
• Complex rule violations
• Defects across multiple files or modules

Linters are a very helpful tool but they do have some limitation that needed to be accounted for when wanting to use it on a project.

Overall, I learned that Linters are one of many analysis tools that can be used in a program, and I also learned one of the ways methodologies like Scrum are able to keep transparency and deal with continuity and consistency issues when dealing with a larger team.

I would like to become more familiar with creating lint scripts, so I can integrate them more into my programs, especially since consistency is something I have issues with, the more I learn about how to code better.

From the blog CS@Worcester – A Beginner's Journey Through Computer Science by Christiana Serwaah and used with permission of the author. All other rights reserved by the author.

Summary of the Blog Post

The blog highlights several clean-code principles specifically focusing on Java. It talks about using meaningful names, keeping methods small, breaking down complex logic, and making classes more focused on single responsibilities. It also covers organizing projects so that packages and modules make sense. Other topics include avoiding unnecessary comments, choosing good formatting, and using tools like linters and static analysis to keep code quality consistent across a team. The blog also mentions the importance of avoiding side effects and making code more predictable so that debugging becomes easier.

Why I Picked This Resource

I picked this blog mainly because I sometimes struggle with writing code that is easy for other people to read. In group projects, especially in CS-343 and other classes, I’ve noticed that even when my code works, people ask me to rewrite parts to make it more understandable. Since the course emphasizes professional development and communication skills, I wanted to learn more about how to write code that doesn’t confuse future developers—including a future version of myself. Also, I’m working with Java in my Android and backend mini projects, so the resource felt immediately relevant.

What I Learned and My Reflections

One thing that really affected me was the section on method size and single responsibility. I realized I often cram too much logic into one method because it feels “efficient” while writing it. But the blog explains that smaller, focused methods improve readability and make testing easier. Another important point was naming. I always knew naming mattered, but the blog explained it in a more practical way—names should communicate intent, not just function.

I also learned about using automated tools to maintain code quality. Honestly, I never used static analyzers or formatters seriously, but now I see how they support good software processes, which we discuss a lot in this class. Clean code isn’t just a personal style; it’s part of a team’s workflow and long-term sustainability.

How I Will Apply This Going Forward

Going forward, I plan to be more disciplined about breaking up my functions, using stronger naming, and removing unnecessary comments. I also want to integrate automated formatting and code-quality tools in my personal projects, so I get used to writing cleaner code consistently.

From the blog CS@Worcester – Vish's Journey in Computer Science by Vishisht Seku and used with permission of the author. All other rights reserved by the author.

The recent learnings related to Scrum and Agile process under the aegis of Professor Al-Faris has been very enlightening. I have also been trying to look up for new learnings online.  While reading through several Agile blogs, I came across an article by Mike Cohn titled “How to Coach Your Team to Run a Daily Scrum Meeting When You Cannot Attend” on Mountain Goat Software. It immediately caught my attention because it deals with a real-world challenge that I have actually seen in group projects — what happens when the person who usually runs the meeting cannot make it. The post discusses how a Scrum Master or team lead can help their team stay organized and independent enough to run daily Scrum meetings even without them being there.

Cohn’s main point is that the Scrum Master’s goal should not be to control every meeting, but to coach the team until they can manage those sessions on their own. He explains that when a team always relies on one person to start and run the daily Scrum, they become dependent. The healthier approach is to let the team take turns facilitating, learn to keep time, and handle updates themselves. He suggests that leaders should model good habits at first — like staying on topic, focusing on progress, and keeping it short — but gradually step back so that team members feel responsible for running the meeting.

I chose this article because I can relate to it from my experience in software engineering classes where teamwork can be uneven. Sometimes one or two people end up organizing everything, while others stay quiet. This article showed me that real professional teams face the same issues, and that strong teams are the ones where everyone learns to self-organize. I also liked how Cohn keeps his advice practical — he doesn’t overcomplicate the process, but focuses on people learning through consistent, small improvements.

Reading this blog reminded me why learning about Scrum in class is not just about memorizing roles or ceremonies. It’s about building habits of communication and accountability. As a computer science student, I used to think Agile was mainly for project managers, but this article helped me see how every developer plays a part in maintaining the team’s rhythm. Even if I’m just a developer, I can help keep meetings focused or volunteer to run one. That kind of initiative builds confidence and makes the team stronger.

Resource: Mike Cohn, How to Coach Your Team to Run a Daily Scrum Meeting When You Cannot Attend

From the blog CS@Worcester – Vish's Journey in Computer Science by Vishisht Seku and used with permission of the author. All other rights reserved by the author.

Why I Chose This Podcast

The episode I listened to is called “How GitHub Operationalizes AI for Teamwide Collaboration and Productivity” from the SuperDataScience podcast, hosted on superdatascience.com. In this episode, the guest, Kyle Daigle, who is GitHub’s Chief Operating Officer, talks about how GitHub uses tools like GitHub Copilot to improve how teams work together. I picked this episode because I use GitHub for class projects and wanted to learn how professionals collaborate on a much larger scale. It also connects to our course topics on teamwork, version control, and communication.

What the Podcast Is About

The discussion focuses on how artificial intelligence can support developers instead of replacing them. Kyle explains that Copilot helps write code faster and gives smart suggestions during coding. But the main idea is about collaboration, not just automation.

He describes something called inner sourcing, which means using the same open-source principles inside a company. Teams share their work, review each other’s code, and reuse components just like developers do in public GitHub projects. This approach helps people across departments communicate better and learn from one another. The podcast also highlights the importance of keeping a healthy culture where AI assists but humans make the final decisions.

What I Learned and How I’ll Use It

This episode changed the way I think about tools like GitHub Copilot. Before listening, I thought of it only as a shortcut for writing code. Now I understand it can help a whole team by keeping code consistent and by making collaboration smoother. I also liked the idea that collaboration depends as much on people and process as it does on software.

In future group projects or internships, I plan to encourage my team to:

• Use version control tools like GitHub for all projects, even small ones.

• Review each other’s work openly instead of working in isolation.

• Try using AI tools like Copilot responsibly to help maintain consistency.

This podcast helped me see that good collaboration is both a technical skill and a communication skill. Learning from professionals at GitHub reminded me that teamwork is what keeps software projects successful and developers constantly growing.

Podcast link: SuperDataScience – SDS 730: How GitHub Operationalizes AI for Teamwide Collaboration and Productivity (https://www.superdatascience.com/podcast/sds-730-how-github-operationalizes-ai-for-teamwide-collaboration-and-productivity-with-github-coo-kyle-daigle)

From the blog CS@Worcester – Vish's Journey in Computer Science by Vishisht Seku and used with permission of the author. All other rights reserved by the author.

In computing, professional growth relies on continuous learning well beyond the classroom. With technologies evolving rapidly, it is necessary to explore resources that strengthen both technical and communication skills. This course emphasizes those goals by focusing on two outcomes: mastering emerging methods and expressing ideas clearly in writing and speech. In this post, I share how a podcast on software process management supported these outcomes and expanded my understanding of collaboration in development work.

Resource Summary and Selection

The resource I selected is a podcast episode discussing effective practices for managing software teams and improving project flow. You can find it here: https://softwareengineeringdaily.com/2025/08/19/empowering-cross-functional-product-teams-with-tobias-dunn-krahn-and-doug-peete/

I chose this episode because podcasts often present material in a conversational and practical way. Unlike written posts, the dialogue between speakers adds context and tone, which made the discussion of process management easier to connect with.

Reflections and Key Takeaways

The episode highlighted how adaptability is essential in project management. Agile and DevOps were described as tools to handle change, reduce delays, and ensure quality. What struck me most was the emphasis on communication. The speakers described how gaps between developers and stakeholders often caused setbacks, and how simple practices like frequent check-ins or retrospectives helped overcome them. This encouraged me to think about how I might use these approaches in my own work to foster teamwork and reduce friction.

Podcasts vs. Blogs in Process Management

Blogs and podcasts each bring unique strengths to learning. Blogs are useful for detailed explanations, visual aids, and structured references—making them ideal for revisiting frameworks or technical steps. Podcasts, on the other hand, offer a dynamic experience. Hearing professionals speak candidly about challenges and decisions provides insight into the human side of project work that text may not fully capture. For process management, where collaboration and decision-making matter as much as tools, podcasts often relay those nuances more effectively.

I believe the two formats complement one another: blogs provide permanence and technical clarity, while podcasts make abstract practices more relatable. Together, they offer a balanced approach to professional development.

Conclusion

Reflecting on this podcast reminded me of the value of lifelong learning in computing. Adopting new models and improving communication are essential for success, and both blogs and podcasts serve as valuable resources for that growth. Moving forward, I plan to engage with both formats to build a deeper understanding of software practices and strengthen my professional toolkit.

From the blog CS@Worcester – Vish's Journey in Computer Science by Vishisht Seku and used with permission of the author. All other rights reserved by the author.

Hello Everyone!!

I came into computer science as a beginner, and honestly, I still feel like one. I’ve made it this far, but I don’t consider myself fluent in any programming language. Coding is not my strong suit, and truthfully, my first pull toward computer science was about learning and understanding the hardware.

I’ve come very far and software is obviously the largest component of computer science so i have to learn and clear my confusions. That’s what this blog is for: a place to track my progress as I learn more about software process management.

I don’t have it all figured out yet, but I’m here to keep learning If you feel lost you’re welcome to follow along with me in my new arc of learning software process management.

From the blog CS@Worcester – A Beginner's Journey Through Computer Science by Christiana Serwaah and used with permission of the author. All other rights reserved by the author.

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

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

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