Additionally, the test cases, and what determines success or failure, must be identified and created using a testing framework. Finally, the work is divided amongst the team. In the Agile methodology the design process will take place during the Sprint planning session. The length of the Sprint planning session will be determined by the amount of backlog items, although this meeting is likely to require several hours for discussing architecture and design decisions.

Requirements review
The requirements come from the stakeholders and it is the responsibility of the Scrum Master to make sure all the Sprint backlog items are sufficiently groomed and are ready for the team to review. The Scrum Master will work with the Product Owner to groom the Product Backlog items and create Sprint tasks. In this phase, the Product Owner and the Scrum Master will prioritize the tasks so that applications can be delivered iteratively. The Sprint tasks must be created prior to holding the Sprint planning session and the team needs to review them so they can be prepared with their questions. The development team or the quality assurance team may have questions that need clarification, however these questions will not delay the start of work.

Architecture and design
This is an area where many organizations fail to properly implement a successful strategy. A successful strategy is one that will promote code reuse, scalability and maintainability. In many cases, teams are not provided with an overall architecture that defines the relationships between modules or services that are delivered. When this information is neglected, then it leads to disorganized solutions that require more maintenance than they should. This step is different than the design patterns used by the development team, however it will, very likely, incorporate those patterns into the solutions. In this step, the team will identify services or modules that can be reused. Also, reusing services might require changes to the functions to meet the new requirements. Architecture and design are factors that will lead to the successful delivery of applications and databases. A robust application infrastructure depends on the organizations ability to coordinate the various levels of services and modules. Additionally, a data platform that is designed well is easier to maintain and add new features.


Quality
Ensuring the highest quality starts early in the development process. Identifying requirements is the greatest factor for success because it enables the team and the stakeholders to have a shared understanding of the goals for a successful delivery. Once the team begins the Sprint planning session, the quality assurance engineers will bring the test cases and include them in the Sprint backlog items. This allows the development team to understand the outcomes that will be considered successful. There are many methods for testing software, however a good test plan will include functional, regression and end-to-end tests.


Assigning work
In the Agile methodology, a task will be assigned an estimated scope. There are various methods for this, including a point system or using playing cards. Personally, I prefer to estimate using man hours. Estimates in man hours identify modules that are unnecessarily complex because the team will frequently require more hours than expected. Additionally, using man hours allows for greater accuracy when planning releases. When assigning work to each developer, it's important to consider skill and experience. A senior engineer will be able to complete tasks that are more complex. A junior/mid level engineer needs to have a realistic amount of work they can complete while delivering a quality solution.


Conclusion
Agile is a flexible process that allows for changing requirements while enabling development teams to continually deliver iterations of new application features. In the Agile process, not every Sprint will produce a version of an application that is scheduled for a release. Often, projects will require multiple Sprints to implement a feature set, then subsequent releases will enhance the application. This process allows the organization to get feedback from customers and develop the necessary changes quickly. The solution design needs to plan for the releases and identify which features and capabilities will be included in each release.

Share

Before diving into that discussion, let's take a very simplistic look at AI in general. There are two main parts to AI, and they are “machine learning” and “decision making”. The machine learning part is where the models are created and developed. The decision mak…

Read more

In the first article of this series, I wrote about the Agile Story Types, which are the tools used by the various members of an organization to complete work. In the article Embracing Agile: an organizational adoption, I wrote about the steps necessary to get requirements from stakeholders to the development team.  In that article, I wrote about the process that an organization uses to successfully achieve a completed product.  In this article, I’m going to identify the key components of the SDLC. This article is intended to combine tools, process and automation, to achieve an overall strategy that will lead to the successful release of a Product.

DISCLAIMER: I have intentionally avoided the topics of design and quality assurance. I believe that those topics are so significant, that they require their own articles. Secondly, they might vary significantly in each organization.  Readers will need to consider what is appropriate by evaluating their own resources and capabilities.

Before creating a release plan for a specific product, it is important to have a DevOps process in place. What exactly is DevOps? DevOps is the repeatable procedures used for delivering new products, features or capabilities, while managing post deployment support that integrates with development. There are a few key points in my definition that need more clarification. First, the procedures for delivering work should be repeatable, which implies that automation tools must be setup and configured properly for the specific product. Second, the setup and/or creation of automation tools are tasks within one of the sprints and they will receive testing in the same manner as any code that is written. Finally, any changes made by the operations team must be incorporated into work being performed by the development team.

Components

The following components are the foundation of a DevOps program. These components should be reviewed, audited and updated regularly to ensure proper compliance and function. These components and their implementation will vary based on the organizational resources and strategy, however here are some of the core components:

Source Control

A system with a proper plan for versioning development is critical when you need to identify the features and capabilities that are included in a particular set of changes. Versioning allows an organization to track the integration between services that are known to be stable, which allows for greater modularity.

Continuous Integration

Regular integration of work products helps to identify problems sooner rather than later. This process will allow integration test cases to be performed and it exists to prevent code that works in the development environment being deployed to production only to find out that it fails when integrated with other services.

Continuous Deployment

This practice allows for work products to get installed into various environments regularly and often enough to complete performance, security, and validation testing. Also, it enables developers to have the latest code base to work with during their Sprint.

Testing Integrations

The types of tests that must be executed will vary by the methodology used for coordinating development and testing. Test driven development is a useful strategy because it incorporates test planning design into the Sprint planning phase, however it's only one of many approaches that can be used in an SDLC.

Testing frameworks

There are numerous testing frameworks available, and they have a tendency to correlate with the development tools that have been chosen. For example, .NET has a test framework and it can be configured to perform specific test cases based on certain actions performed.

Security testing

These test cases should be performed prior to any release to production since they are a critical step in any Cyber-security program. It seems that there are many organizations without a comprehensive security testing strategy, and we have seen many breaches as a result. The latest practice in most cyber security programs is a zero-trust architecture. Regardless of the architecture, these test cases will attempt to simulate a malicious person that is intent on breaking the application, database or network.

Static/Dynamic Analysis testing

A search of static analysis testing will tell you that code isn't executed, instead it is reviewed for compliance with coding standards and the design plan. In the past, these actions were performed by one to several others, however recent innovations have led to the implementation of tools that perform this step. Code reviews were a useful tool in which developers received feedback regarding the coding standards and the team was able to discuss performance issues related to coding techniques that were implemented.

In dynamic testing the code is executed to ensure that it works as expected. These test cases differ from the validation test cases because they are performed on the module where the work was completed. Often times, this type of testing is done in coordination with some type of Software Composition Analysis(SCA) tool. An SCA tool helps analyze the Open source libraries used in an application, and they will evaluate the remote libraries for performance and licensing requirements. An SCA testing process might be a standalone process due to the importance of ensuring compliance of licensing regulations.

Validation testing

These test cases will depend on the environment that code is deployed into. For example, when deploying to a development environment, these test cases ensure that new features or capabilities are reachable even if they don’t perform many functions in the backend yet. When deploying to a Test, UAT or production system, then this process will expect specific results. This type of testing ensures that changes are working as expected, so the various use cases must pass successfully after any deployment.

Summary

 These topics are just some of the ones that make up a well designed DevOps strategy, and each organization will customize their program to fit their particular SDLC needs. When combined into a repeatable process, then stakeholders and developers are able to agree to delivery dates for work products. Additionally, a Scaled Agile SDLC allows organizations to perform work on different systems simultaneously, and each product has its own release plan.

Share

Subscribe now

Previous Next

Mr. Nicolari is an Information Technology executive that has been in the industry for nearly 30 years. He began his career working in a support role while attending college after his discharge from the U. S. Navy. Providing Information Technology support services fueled his desire to enhance his skills in the digital world and he went on…

Read more

Epics

The highest level stakeholders will be creating Epics, then grooming them into features and Product Backlog Items. Ideally, this is the job of the Product Owner, who would then coordinate with the Scrum Master to produce User Stories. Epics are normally used to describe a business need. Something new in this post is the concept of a Product Backlog Item. A PBI (Product Backlog Item) can be a feature or high level user story that contains the requirement(s) to produce a minimum viable product.

Product Backlog Item

A single Epic will consist of many features and PBI. The Product Backlog should not be confused with the Sprint Backlog, since these are two entirely different things. Another new item in this post is the concept of a “minimum viable product”, which represents the minimum set of features or work that is necessary to deliver a set of changes to the customers. Determining the MVP is going to be used in the release planning process. A PBI is a type of user story that is defined by the stakeholders and then gets refined by the Product Owner and the Scrum Master into Sprint User Stories.

Difference between a PBI and a Sprint User Story

A PBI is used by the business stakeholders and it contains the business requirements that need to be met as a result of the work effort. A Sprint User Story is used by the development team and, while it also describes a set of work, it will also contain the requirements by the IT department to meet the standards that have been set. An IT department will have either an Architect or senior developer that leads others when it comes to adhering to policies, and ensuring a well designed set of work. As you can see, the IT department has their own set of requirements that must be met, which is why we break a PBI up into Sprint User Stories and add the necessary IT requirements. Additionally, the business doesn't need to become Technology experts, and they can focus on the stories as they relate to the end user.

Sprint Tasks

The purpose of the Sprint Task is to assign work to an individual, establish guidelines for time management and evenly distribute work. Repetitive tasks are identified easily and then automated or replaced with a reusable component.

As you can see, the adoption of the Agile methodology is something that the entire organization must embrace. Agile is a powerful tool for creating an SDLC that enables everyone in the organization to have input, while continuously delivering work even if the requirements change.

Share

Subscribe now

Previous Next

Epic

One of the definitions that describes an Epic comes from scrum.org: “A user story or requirement which aggregates multiple other such items in a way which gives them coherence”, (Gross Definitions: 144 Agile Terms You Simply Have To Know, https://www.scrum.org/resources/blog/gross-definitions-144-agile-terms-you-simply-have-know)

An Epic is the highest level of User Story in any product.

Feature

A feature is a requirement that is specific to a product and delivers a solution to meeting the need of an end user. Feature development might require multiple Sprints to reach completion.

User Story

A User Story is used to describe a component that will be developed, and who it will be consumed by. In general, these follow the example format “As a consumer of the API, I would like to receive responses with http status codes”.

Sprint Tasks

These are the specific tasks necessary to achieve the completion of a well-defined and fully groomed user story. A User Story usually will require several tasks for it to be considered done.

Conclusion

Notice that the term “product” is used throughout these definitions. The Agile methodology is a product development process that promotes continuous development. Agile is not a project management tool that reaches an end. The continuous work effort done in Sprints, is what allows Agile teams to respond to changes in requirements quickly. The Agile methodology includes a release plan that will target dates for shipping a releasable subset of work from Sprints.

Share

Subscribe now

Next