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.

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.