Project Planning and Scrum

 One of the major drawback of the Scrum Method is that it overlooks the fact that many changes have to be done in a longer period of time and those big project has to be managed in a different lifecycle across multiple sprints.

Here are some possible ways:

Preview release

A preview release is a preview.  It should never been used in production.

The reason that it is a preview is that

Modern software documentation

Write markdown pages. Use a tool such as Visual Studio Code

Push via wiki, such Docusaurus

Using the same version/source control, such as Github

• Check-in/out for concurrent updates
• Versioning for comparison over time

Documentation is part of the product

A product has the lifecycle:

• Request via Jira
• Assign to an owner/creator
• when doc resource is a constraint, prioritize them
• Reviewed by PM, DEV
• Verified by QA
• Release via publishing
• Change/Correction, Enhancement via Jira

GitFlow

GitFlow is a branching strategy.  It advises when to branch, and which branch changes should be committed to depending on the nature of the change and the phase of the release cycle.

It can handle critical bug fixes (patch) and scheduled releases (new feature, bug fix, stabilization).

Here is the doc - Introducing GitFlow

Test Failure and Test Blocker

Test Blocker

Blocking QA from testing may just require a small code fix or may just need a fix to the QA env configuration.

It affects the QA testing and affects the QA testing schedule and productivity.  Unblocking QA is critical and needs to be treated as an urgent issue.

Separate Environments Needed for Development

When I worked in a big company, these things are so obvious and I never really paid much attentions.

Having separate environment is so basic.  However, it requires some efforts to make people understand these requirements.

Here are the environments required for different purposes:

1. Development Env

• Dev team owns this. Ops may create it for Dev
• Developers have full access.
• Dev perform unit testing in this env
• Backup may be required so when Dev does something that may affect each other, we can restore to a clean env
• Creating such env from and old QA env, or refresh from QA env, so Dev can have some testing data is a good practice.

2. QA Environments

• Ops team creates it for QA
• Builds are applied to QA env for testing

There are various QA environments:

2.1 Feature development
Apply the latest builds for QA testing

The About Page

To let the customer know which version of the software they are using, you can include the About page.

Some of the information is specific to the installation.

• Name of the Software
• Version Number
• Type of License

It is a good practice to include the following as well:

Review: Aha

Aha demonstrates how a cloud apps works.  It is a requirement tracking software.  It has the integration to JIRA.

It manages the lifecycle before the requirements come to development in JIRA as a user story.



Releases are created for managing the target delivery for a specific deadline.  A release has a start date and an end date.
 https://support.aha.io/hc/en-us/articles/201226575

Releases are draw in a Gantt chart, called Releases Roadmap. The visualization using a Gantt chart is very powerful tool.  
https://support.aha.io/hc/en-us/articles/115001477463

Master Features are created as containers of user stories.
https://support.aha.io/hc/en-us/articles/115001477463

Master Features are added to Releases.  Or more specifically, User stories from master features are added to releases.  When you view the user stories, you can optionally view the major features of that release, before drilling into the details to view individual user stories.

Use Planning Poker for release planning

Let people to contribute and resolve the disagreement and reach a consensus.

A good Youtube video

Release Management

Release Planning

A list of features should be scheduled as part of the planning process.  In scrum method, each sprint is a release.  The release planning is handled as the sprint planning.
The features or fixes are prioritized.  They are documented as backlogs in the scrum system.

Release Notification

A list of customers may be waiting for a fix or a feature for a given release.  You will need to notify the customers that a release is available.

Documentation

The release note should mention what fixes and features are available.
The release note should be searchable.  A customer should be able to know what is the minimum required version for getting a specific fix or a feature.

Release Tracking on the Customer Site

For a given instance, you should be able to know the update history.  What is the version of the installation and what patches were applied.

It is particularly useful for the hosted environment.  The hosted customers should be able to submit the change requests.  Once the change is applied, the change history should be kept.  The change requests become the orders for DevOps.

When your software is solid, few customers may need or want to take an update.  The frequency can vary depending on the status of the product.

Cloud Operator Acceptance Testing before deploying into cloud

The software package is developed in the dev env.  The dev env does not necessary reassemble the real production env.   It supposes to be a simple, isolated env for dev to code and perform unit testig.  That's why we need the QA env.  The QA env should cover the testing cases that represent the customer's deployments.

However, a cloud env may have additional requirements.

Only backport bugs already fixed in the main line

A development organization may need to maintain multiple branches for supporting previous releases and for developing some features that have huge impacts to the stability of the codes.

We should always have a main line that is whether the branches were forked from and will be synchronized with.

A bug fix should be fixed in this main line and then

No regression bugs

How to ensure that there is no regression bugs while introducing new features?

Here are my thoughts:

1. Knowledge Sharing

Developers need to have the knowledge about the whole product, especially about how the feature he or she is responsible is being used.

No one would intend to make the code broken unless for political reasons, such as avoiding dependencies.  We can argue that the developers are careless.  However, in my experience, most of the cases, lake of the knowledge is the reason.

2. Document the dependencies

Release notes for your software

Release notes are created for the released versions of the software.

It should describe

• What are the new features ?
• What bugs are fixed?
• What are the known issue?

Other optional sections

Identify test plan availability for each bug

It was a good practice followed by QA in the company I worked before.

It is enforced by the QA manager but also known by several Dev Managers.  It is for close loop analysis.

Doc Plan

Doc Planning is as important as the Dev/Feature Planning.
The Doc Plan should be part of the overall release plan.

Without documentation, the client may not know how to use your product.  The client may not even know that a feature exists.

Differences between a main release and a patchset

A product feature that requires the full cycle of planning, designing, test planning, test execution, packaging, documentation, etc. should be put into the main releases.

A patch or a patchset that are release vehicles for delivering the fixes to the products and we should avoid to put product features into it.  It will makes the cycle of of delivering patches becomes longer and will actually introduce uncertainties to the patch.

A developer who want to put the features into a patch typically does not mean to create any harms.  They have eagers to contribute to the product and should not be discouraged.

We  just need to help people to get familiar with the development methodologies.

That is why the in-job training is important for the quality of the products.

Markdown is difficult to read

The markdown files are great when we read from Github or the sites that can publish it as HTML files.

However, when we ship the readme files to customers, the customers do not know how to read them. 

SaaS vs Custom Sotfware Hosting

Software as a service means that you, as a client, do not need to install and deploy software.  You can just use your browser to access your application.  On premise deployment, on the other hand, means that you have to deal with installation, deployment, and customization yourselves. I recently learned a new type of software hosting service for on-premise deployments.

The service is exactly focusing on the pain point, dealing the customization of the software.  

Even for the software you deployed on premise, nowadays you can get the standard software from the software vendors online.  The installation and upgrade can be handled already via some automation.  However, the software package you get is still the standard software like everyone else has.

The new concept is that the customized software and configuration information are stored in the service provider.  You never really customize the software yourselves.  Instead, the service company provides the customized software for you.  The software you have is kind of a branch of the standard software and maintained by the service provider.  Also, the configuration files or metadata are deployed from the testing instance that the service hosted.  You are the client of the service provider and they maintain your software packages for you.  However, when it comes to deployment, you still have it in your facilities and still inside your firewall.

QA Test Plan Review and Sign Off

QA should come up the test plan that describes what will be tested and when the test execution will be started and will be done.

The Dev team should review and sign off the test plan.