Kath's Journey | Going one step at a time: development

Study Session: The Scrum Methodology

September 02, 2023

Our team at work has started to adapt to the scrum method for planning and implementing our deliverables. When it was first announced, I felt some level of shock on how things will be done differently. Coincidentally, I was in this headspace of being a student of life by studying something every night instead of doom scrolling on my phone 😓. And so, I decided that this topic will be my first subject to study on.

📚Reference

Scrum: Novice to Ninja

M. David Green

This book worked well as a headstart on the details of the Scrum process. Reading this greatly helped me in following the discussions and understanding the motivations for certain decisions by the team.

📝 Notes & Takeaways

Scrum Roles consist of the following:

Scrum Master - officiates the scrum rituals; makes sure everyone is able to follow the scrum process; It is not advisable to make the Dev manager the Scrum Master as this will cause unnecessary tension during Daily Standups

Product Owner - defines the user stories and the acceptance criteria in coordination with the customer, ; monitors the backlogs

Dev - picks up the dev tasks

QA - does the testing

Scrum Rituals are:

Sprint Planning - this is when prioritization and organization of the sprint logs are done; this is also when story points are assigned; Story points should be agreed by all the members of the team during the discussion. Stories are organized in order of priority in the backlog and devs/qas pick up tasks on top of the sprint log. Because of this setup, there would be a scenario that a member would pick up a task that is outside of their specialization. Based on scrum principles, this is intentional so that all members will be well-rounded in their projects and will have a wider perspective on the overall architecture where the team's projects reside.

Quoting from the book:

"While it's valuable to have the most skilled talent working on the stories that are most appropriate for their specialties, it's also valuable for a team to share knowledge, so that everyone has a clear sense of what's involved in developing and maintaining the whole product. This helps the team become more versatile, provides learning and growth opportunities, improves everyone's ability to estimate new stories, and prevents mission-critical information from being the exclusive responsibility of one person. Finding the proper balance of efficient development and knowledge sharing is up to each team."

Daily Standup - should span 15-30 minutes only; it is the Scrum Master's responsibility that this ritual is timeboxed correctly; no side-discussions should be done;

Sprint Demo - quick demo of the stories deployed for the sprint; optional to invite customers during this ritual

Sprint Retrospective - What went well? What can be improved?

Scrum Artifacts:

Product Backlog
Sprint (usually has a 2-week long duration)
Stories
Burndown Chart
Story Points
Velocity Chart

The Scrum process can be made flexible to adapt with what works with the team. Our team is just warming up with incorporating Scrum with how we work. I'm also learning a lot, especially in the area of hitting my deadlines. 😓 This is a work-in-progress and I am thinking of new strategies to manage my work (especially due to upcoming commitments 💪🔥) so I really have to amp up my time management skills. This is exciting times. I'm ready for the challenge! 🧠🍄✨

0 Comments

development

HOW-TO: Unzipping GZ Files in Linux

April 15, 2022

0 Comments

development

Into the World of Frameworks & Libraries

February 25, 2021

It's really exciting when we get to learn something new in life. For me, this process gives me helpful doses of endorphins, although sometimes I have to experience some shots of cortisol first 😂. But I guess those hardships make the victory even sweeter, right?

I'm walking along this kind of road now at my work. I have been recently given a project wherein it was up to me to explore the right technology to execute the needed functionality for the implementation. Hours of research and lots of googling led me to the vast world of JavaScript libraries (and more!). It was my first time to have a closer look at all the current technologies we have now, and it was fascinating to learn more about some terms that I usually just encounter in passing.

💡 Take away #1: there's a difference between a library and a framework. I tend to use these two terms interchangeably when describing a group of reusable code, but apparently there's a distinction between them. This article sums it up adequately. The variation really just comes down to the level of control that the developer has in implementing those reusable codes.

My research introduced me to the following:

What is Material Design, you ask?

💡 Take away #2: There's a difference between Bootstrap and MD Bootstrap, mainly that one is open-source and the other one is paid. Here's a good article that differentiates them.

💡 Take away #3: jQuery is different from jQuery UI.

Just like with Bootstrap and MD Boostrap, I got confused again with these two because of how similar the names are. Although essentially jQuery UI is made out of jQuery, using each of them in a project would be entirely different implementation-wise.

💡 Take away #4: There are a ton of CSS frameworks out there, and the most commonly used are Preact, React, Angular and Vue.

I have heard about React and Angular, but actually I was just familiar with the names because the team has used in other projects in the past. This is the first time that I was actually diving deep into these technologies. Again as part of my research, I had to know more about these technologies and how they differ from each other.

Click here from some Preact introduction.

💡 Take away #5: Having similar names doesn't mean they are the same, and having different names also doesn't mean they are different. Gets? 😆

React and React JS are one and the same.
React JS and React Native are not the same.
Angular and AngularJS are not the same.

With these takeaways, I learned to really do the work of researching and exploring more about every technology available. Imagine, I had to present this to the senior director! Actually regardless of the audience, I have to know what I'm talking about. Especially in this case wherein everything is new to me, I really had to do the work and study everything.

All in all, the proof-of-concept presentation went well. I proposed the usage of an open-source jQuery plugin for the project. I am very much looking forward on how things will progress with this project.

I hope I can handle a similar task again in the future! I really enjoyed it. 🤓

~o~

Other References:
Wikipedia

0 Comments

development

Impact Analysis in Software Development

July 23, 2019

If you've been working in the software development field for years (like me), for sure you have done some kind of impact analysis at least once among the projects that you have worked on. Maybe you were not just aware but actually what you were doing is a form of impact analysis.

How do you define Impact Analysis?

Impact Analysis is the technique of analyzing how a new / or a modification of a functionality would affect the current business process as a whole.

I'm trying to define it here using my own words, on how I understood the concept. If you are trying to research the "technically correct" definition, then I guess my blog is not 100% reliable on that. :)

This is commonly done during a start of a project wherein the team is in the stage of analyzing the complexity of a project implementation.

I have recently done impact analysis on a project I am working on and here are some of the key points that I watched out in constructing my investigation.

Since I am (as of this writing) a NetSuite developer, mostly my concern of the impact analysis is on the records/scripts level. I should be able to pinpoint --

How the changes would affect the new records and the flow on how users interact with them (CRUD operations)

How it will affect existing records (CRUD also)

How it will indirectly affect other records (i.e. parent/child records, sourced fields, saved searches via the delete/inactivate dependencies list)
How it will affect other scripts; compare if there would be conflicting logic flows compared to the other existing scripts

Then I evaluate these points based on how critical the effect would be on the overrall process -- high, medium, or low. Take note that when presenting this to the team (BA, QA, and the management), you have to make sure that you are using the same terminologies (i.e. how impact is being measured -- S1-5 or U1-7).

Doing impact analysis is an extremely important step before starting the projects. Aside from seeing the changes in a high-level point of view, this approach also allows the team to do checking to ensure all existing functionalities would work as expected after a new feature implementation has been released to production.