Software Development Lifecycle
How do I interpret user needs and implement them into a program? How does creating “user stories” help with this?
Interpreting user needs is sometimes quite black and white. "I would like the program to do this, this, and this". Unfortunately, black and white requirements are a rarity when it comes to CS. Requirements can be vague, contradictory, and seemingly nonsensical. I believe the creation of user stories helps disambiguate certain requirements while also highlighting missing information to be requested from the client. The base organization user stories provide is a great tool for highlighting requirements.
How do I approach developing programs? What agile processes do I hope to incorporate into my future development work?
I typically approach program development in the standard phases of the software development lifecycle as they were initially taught to me.
Planning: I gather information to ensure I understand the requirements. I organize requirements into categories based on assumed requirement complexity. I also take time in planning to ensure "sub-requirements" are factored in.
Design: I write out the structure and methods I will use for the entire program, trying my best to look at things from many angles in order to highlight any problems that may arise.
Implementation: I begin to write the program, referencing my overall plan to ensure I stay on track. As problems arise I adjust the design as minimally as possible to maintain the original vision while also overcoming obsticles. It is very important to note that I wander between phases as necessary to properly complete the project.
Testing: I usually write test cases throughout the implementation phase to ensure things are working properly along the way, but it is better to write test cases before implementation in some cases. After implemenation is (seemingly) complete. I write more test cases, straining the program and searching for breaks and bugs. If any are found, I return to implementation to see if the problem is a simple fix. If not, I return to the design to ensure the design is not the problem.
Maintenence: I have no experience with maintaining a program at this time, but it would likely be another branch of the entire SDLC.
Overall, my method uses many agile principles. I am always ready for changing requirements. I am also constantly floating between SDLC phases. I never consider one phase of the SDLC "completed". Each new problem comes with its own plan, design, implementation, and testing. I do not limit myself to one phase.
In working with teams, I would love to implement Scrum. I believe it to be an excellent alternative to Waterfall in most cases.
The most fundamental individual trait in being a good team member is communication. It is communication, along with programming competency of course, that leads to an excellent team member.
Respect for others is another very important trat that a good team member should have.
I believe these two interconnected traits will always lead to a good team member and contribute to the overall goals of the team by providing transparency at all levels.