Table of Contents
Software Development Life Cycle (SDLC) 3
Project Management using Scrum 6
All SDLCs must address how they will deal with the following phases of software development: Requirements gathering and management, analysis of the requirements, design of the code that will be written, coding, testing the code, and delivery of the system into production. Once a system is in production, then the team must integrate how the production system will be maintained into its process. Lunatic Labs will use an Agile methodology known as Scrum for its SDLC.
Scrum uses a backlog to manage requirements. A User Story represents a requirement in a simple, customer-focused narrative. User Stories are added to the backlog as new requirements are identified by the customer or the development team. As User Stories are added to the backlog, they are prioritized by business value or the value they will bring to the development team in learning or building foundational pieces of a system.
Analysis is somewhat informal in Scrum. During a Sprint Planning meeting, the backlog is prioritized and user stories are selected to be a part of the sprint. Once the stories are selected, the team breaks the stories down into smaller tasks needed to complete the User Story. This analysis step transforms the user story from the user's perspective to a software engineering perspective.
Scrum advocates “design by discovery” or “emergent design,” but Scrum also assumes a level of experience that most students do not yet possess. Therefore, Lunatic Labs will rely on more formal design approaches to make the design step more explicit. Many developers like to use the Unified Modeling Language (UML) to produce diagrams that help to communicate design decisions.
UML 2.0 defines thirteen types of diagrams, divided into three categories: Six diagram types represent static application structure; three represent general types of behavior; and four represent different aspects of interactions:
- Structure Diagrams include the Class Diagram, Object Diagram, Component Diagram, Composite Structure Diagram, Package Diagram, and Deployment Diagram.
- Behavior Diagrams include the Use Case Diagram (used by some methodologies during requirements gathering); Activity Diagram, and State Machine Diagram.
- Interaction Diagrams, all derived from the more general Behavior Diagram, include the Sequence Diagram, Communication Diagram, Timing Diagram, and Interaction Overview Diagram. (Milutinovich and Bondareva)
The following design activities should be incorporated into your process as appropriate:
- developing a user interface design using mock-ups or tools specifically created for designing UI’s, like Figma
- using a modeling tool like UML to
- produce an architecture design that helps communicate the structure of the system to the entire team
- model classes and their interactions in the system
- Illustrate how your system interacts with other systems using an Interaction Overview Diagram
Automated Unit tests should be written at the same time as the production code, whether you choose to write the tests before or after the production code.
Code should be written in short increments. If you add small amounts of production and test code and your system breaks, then you know exactly where the problem was created. If you write several pages worth of code and your system breaks, your debugging becomes much more complicated as you try to figure out where the bug was introduced into the code.
For integration and system testing, code should be deployed into an environment specifically used for testing.
For Lunatic Labs, our standard will be to have at least 80% Code Coverage. The ideal would be to always have 100% code coverage, but this is practically impossible to achieve.
TBD.
Per the Scrum Guide, Sprint Planning addresses the following topics (Schwaber and Sutherland):
- Why is this Sprint valuable?
- Agile emphasizes delivering business value with each sprint. The team should understand what business value they will deliver with this sprint.
- What can be Done in this Sprint?
- The user stories in the product backlog should already have story points assigned to them and should already be prioritized. Existing teams will know what their Velocity is. User stories are added to the sprint based on their priority and how many of them can be accomplished based on the team’s velocity. For instance, if a team has a velocity of 15, and the highest prioritized user stories have story points of 2, 3, 5, 1, 3, and 5, the team can commit to the first five stories adding up to 14 points.
- How will the chosen work get done?
- In this step, the team will decompose each User Story into smaller tasks and estimate them by hours. They will also assess whether they need further input from the Customer or a technical expert to successfully deliver the user story.
In addition to these 3 items, the team should set goals for the sprint and address any known obstacles for the sprint.
The daily stand-up should last no more than 15 minutes. Each team member answers 3 questions:
- What did you do yesterday?
- What will you do today?
- Is anything blocking your progress?
These meetings should focus on the requirements and the progress made on the task assigned. The team should not engage in trying to problem solve during the meeting, especially if it is a technical roadblock. If someone is experiencing a blockage, a subsequent meeting should be scheduled with the people who can help remove the blockage, whether it be a question about how the functionality should work or if they need technical assistance.
Typically, a sprint review entails a presentation of the work accomplished during the sprint, but in addition, the team assesses the Product Backlog (see Github Project Organization) to see if user stories have been added, and if so, to assign story points and prioritize each new story. The Customer may wish to change the priorities of existing stories so they will be developed sooner. When this occurs, the user stories should be reordered in the Github Project kanban board to reflect the new prioritization.
The Sprint Retrospective meeting should occur after the Sprint Review is completed and before the next sprint begins. While the Sprint Review focuses on the user stories planned and delivered, the Sprint Retrospective focuses on “how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. “ (Schwaber and Sutherland) Typically, the team answers three questions:
- What work has been done well in this sprint?
- What work hasn’t been done well?
- What should we start doing to improve?
Definition of Done is related to how teams manage their project boards. Refer to Github Project Organization for more information.
Team members should remember that the purpose of the sprint retrospective is not to assign blame or penalize anyone. It is focused on improving performance in the future.
Velocity is a measure of a team’s rate of progress. It is calculated by summing the number of story points assigned to each user story that the team completed during the iteration. (Cohn 38)
TODO
Teams should use the Github Project feature to communicate the team’s progress. At a minimum, it should have the following columns: User Stories, Todo, In Progress, In Review, Done. Here is an example of the columns:
The first column should contain all of the User Stories that have been identified, and the stories should be in prioritized order. When a new User Story is identified, it should be added to the bottom of the column. User Stories are reprioritized at the beginning of each Sprint Planning Meeting.
When stories are selected to be part of a Sprint during the Sprint Planning Meeting, they should be broken down into smaller tasks or issues and added to the Todo column. Each smaller task should have an abbreviation in its description that links it back to a User Story. Once a task is assigned to an individual, it should be moved into the In Progress column.
Once an individual has completed their task, a Pull Request should be created and the item should be moved to In Review. Code should then go through a Code Review. The project lead and/or technical lead should review the code to ensure that it meets coding standards and has adequate code coverage. If the code is approved, the Pull Request should be merged and the issue should be moved to Closed. If the code does not pass the code review, the item should be moved back to In Progress until it passes the code review.
The project is split up between the prod, test, dev, and various feature branches.
- The prod branch is the LIVE production site that anyone can access and will hold the major version releases of the product.
- The test branch contains the code pushed to our testing environment, where we will test our completed tickets for stability before we push to production.
- Feature branches are merged to dev for inclusion in other developers’ local development environments.
- There will be a feature branch for every issue/ticket and in these branches, we will develop different features and elements that we want to add to the product.
A user is able to create a feature branch right from an issue posted as a ticket in the GitHub issues tab.
- Go to the page of the repository you're working on.
- Click on the Issues tab to open up a page listing all the issues in your repository.
- Here you can select your issue. You can filter by Assignee for convenience.
- You can also reach the specific issue page by clicking on the Projects tab on the main repository page and then the specific project. Here all the issue tickets are sorted by Backlog, Todo, In Progress, In Review, and Done. You can then click on your specific issue ticket there.
- On the specific issue page, you can click on Create a branch under Development on the right-hand margin.
- From there you can pick a branch name and the repository destination.
Developers should commit their code early and often. Any time a piece of code is completed (i.e., a new function or new variables are added, a new call to another piece of code is added, etc.), that should trigger the developer to commit their code.
Before creating a Pull Request, the developer needs to pull any changes in the dev branch to their local git repository and resolve any merge conflicts. Once a feature is completed we will create a pull request to review the code before we merge it into the dev branch.
- Go to the page of the repository you're working on.
- Click on the Pull Requests tab to see all pull requests for the project.
- Click on the button towards the right that says New pull request.
- Use the compare dropdown menu to select the feature branch you'd like to merge and the base dropdown to select the branch you'd like to merge into.
- Add a title and description for your pull request before clicking Create pull request. Note: It is good practice to move the position of your ticket in the Projects page when its status changes. For example, when you are currently working on it, move it to In Progress, or when you've submitted a pull request for it, move it to In Review.
- git init - initialize an existing directory as a Git repository.
- git clone [url] - retrieve an entire repository from a hosted location via URL.
- git status - show modified files in working directory, staged for your next commit.
- git add [file] - add a file as it looks now to your next commit(stage).
- git reset [file] - unstage a file while retaining the changes in working directory.
- git diff - diff of what is changed but not staged.
- git diff --staged - diff of what is staged but not yet committed.
- git commit -m "[descriptive message]" - commit your staged content as a new commit snapshot.
- git branch - list your branches, a * will appear next to the currently active branch.
- git branch [branch-name] - create a new branch at the current commit.
- git checkout - switch to another branch and check it out in your working directory.
- git merge [branch] - merge the specified branch's history into the current one.
- git log - show all commits in the current branch's history.
Code reviews can service a number of goals but all of them can be grouped into two broad categories. The technical category is to improve the code base. While Linus’ Law (given enough eyeballs, all bugs are shallow) may not be technically true, evidence definitely indicates that reviewing code is much better than the alternative. The second category is about improving the team or the project as a whole. These goals may even be considered incidental benefits. In any case, these benefits accrue because knowledge is distributed among the team, which reduces risk and improves cohesion.
Each code review should have a well-defined scope. A mature development process typically requires all code changes to be reviewed and approved before they are committed to the main branch of the project source repository. In this circumstance, commits should be kept small enough to allow all changes to be reviewed in one sitting. This may necessitate breaking changes into several steps, which is a symptom of successful development. However, if your development process is not yet mature it is not unreasonable to choose a single module or source file to be reviewed.
- Select the changes or modules to be reviewed.
- Cleanup your code, compile, run tests, etc. before the review.
- Choose 1-3 appropriate goals to concentrate on.
- Choose 1-5 other developers to participate.
- Schedule a block of uninterrupted time available for everyone.
Choose one of the participants to be the official scribe. This provides an artifact to capture the work product and ensures all suggestions are recorded. Remember one of the goals is to improve the development process. It is common during code reviews to recognize a deficiency in a team's process. The scribe should make a note of these so they can be addressed at the next team-wide meeting or by the project lead. If there are many other developers, the scribe may not be an active participant since their time will be filled with making notes.
The author of the code will “host” the meeting and begin by describing the code under consideration and formally asking the participants to provide constructive feedback. This is also a good time to emphasize any specific goal(s) this review should concentrate on. The scribe should make a note of any specific goals.
Before reviewing individual lines or functions, the group should determine where the code stands with regard to the following attributes, and the scribe should record the results.
- Conformance to the project coding standard
- Complexity
- History (for example: new, legacy, active development, refactored, etc.)
The author should describe each section of the code in some appropriate order (bottom-up, or top-down, or order of processing, or some other logical sequence) so the other participants understand both the desired outcome and the implementation. Stop after each section so participants can ask questions or raise concerns. All of the following dimensions of the code should be considered if they apply. Some may be more appropriate to discuss once all the code has been described by the author.
- Correctness (Is the code correct? Is the code complete?)
- Clarity/maintainability (Is the code as simple as possible? Does it repeat itself?)
- Architecture
- Security
- Test coverage (Are all edges tests? Are all code paths executed?)
- Optimization/performance
Time should be tracked against an issue in Jira.
Works Cited
Milutinovich, Jovana, and Kate Bondareva. “What is UML | Unified Modeling Language.” UML.org, https://www.uml.org/what-is-uml.htm. Accessed 3 January 2023.
Schwaber, Ken, and Jeff Sutherland. “The Scrum Guide.” The Scrum Guide, https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf\#zoom=100. Accessed 3 January 2023.