Showing posts with label Scrum. Show all posts
Showing posts with label Scrum. Show all posts

Wednesday, June 26, 2024

Project Terminology: Scrum GuideBook

 Project Guides for Developers using Scrum Guidebook by J. Sutherland & J. McKenna

A link to the actual documentation (brief reading time, approx. 25 minutes) is here

I stumbled upon this information going over Youtube videos with developer advice for project management and what makes a senior developer versus a junior developer in their work alone. As a software developer student, and 8-week courses, with other life hassles to pay on time - I am getting doubtful of a prosperous career in IT because I lack the confidence in my skills as a developer. The terminology without a community to converse daily becomes absent in my return to class structures and it is difficult to maintain interest when I feel over-stressed by it. I enjoyed the learning - so I focus on that part. And get back to it. 

So, in this video by subscribing to the "Thriving Technologist" - I am learning how experienced programmers are establishing programmer habits to enact for future project and career security. One thing I picked up - without direct intent - was the leadership role to be foundational and established within the developer role in any project and to remain in that seat at all times. Do not let anyone dictate the developer or its duties. This is a job role to secure the salary/wage for each project and the vital attitude we all must exhibit as a developer to create the unity in our work and the ability to follow each other and consistently work regardless of personal projects. Don't let the personal project style/patterns/work flow seep into the career projects!
I also found it interesting to use the scrum guide for projects that use inter-departmental feedback to maintain throughout its term in development. Which means, the developer does have an establish role to fulfill and to let the other departments handle theirs. The goal incrementing and completely done by standard finish lines create the micro-management for diverse work groups to collectively be assertive in deadlines by standard and to assist if needed much more available and readily than by reading from the top philosophy. 
I did not know Scrum Guidebook before this youtuber explained in his knowledge as a developer how project spaces that use it - should follow it to the tee. It does explain that in it as well. I enjoyed the documentation - which is also something that the youtube video explains. 
Here is a sample of who I am talking about: 


This is a separate video but he does a great job at explaining Developer Advice, Tips, and very straightforward on the subject he presents. I would definately enjoy working with him - even at my inexperienced stage - I would be more interested in how to improve and him being able to provide that to me (in the form of youtube is even better - saves me the embarrassment!)

Scrum Guidebook Review

The history of the Scrum Guidebook is a basic step for group projects of any kind, technically. This is pertaining to accountable dollar for time, resources, and micro-managing at its best. The idea of being provided a task and doing it - was an older programmer technique that was heavily reliant on integrating program code and modifying based on the time spent writing it. But nowadays, programmers don't want to waste time by redoing the entire architecture so it has been mutually agreed upon to write based on easy to read code, easily transferrable code, and code that operates with tools effectively. 
One of the habits he stresses was documentation in his videos. I am going to be taking a Documentation Writing course in the Fall of 2024 and as plainly as it sounds - excited about it. I think if I'm going to be good at anything, hopefully its writing! But also reading it. I want the user to imagine what they are reading and be effective throughout the documentation so we can post it without running into multiple variations of how they interpreted it, what their thoughts on it were, and what helped them use it in which part of code the best. These should be habits by the developer regardless - especially in new programs, projects, developments to pass to the company for the next programmer to easily read and adjust for other improvements or modifications to insert other tools or features. 

I'm glad to have encountered this. I guess its been in most active use since 2020 - so, I'm not too far behind. I've never been involved in a project and am happy to have found his advice most useful to an inexperienced programmer as myself. I have much to work on and create those good developer habits within my time of study!





Just do it.

The only way to know, is to do it! Going into my C# Part 2 course and IT Training this term, coming from A results in my first half with ASP...