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.

Notes and Tips about Jira

New product or project development:

1. Create a new JIRA project

You need to have the project administration permission to do so.
In an organization, this permission will not be granted to many people.

You can give it a key.  The key will be prefix of issues number for issues created in the project.
You can give it a unique icon, call Avatar.

A JIRA project is sometime mapped to "Product" within software organizations.  A new product may be a "project", but when you have multiple releases and start maintenance cycles, you are developing and maintaining a product which is typically created as a JIRA project.

2. Create a Board

For a new development project, a new broad can be created for an existing JIRA project, or for a JQL, which is a query for collecting issues from multiple projects.

This is a very good way to run an "integration" project, when a project involves the teams that are from multiple product and from multiple organizations.

You can create multiple boards.  Multiple boards can exist simultaneously.  A board is actually just a view of the issues in different columns.

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.

Acquisition and merging of companies and manager's jobs and challenges

It is a very healthy and productivity improving activities for the society and for shareholder and requires special skilled people to manage the process and make it smooth.  The goal for management is really about how to make the values from the acquired company to form the synergy, so one plus one is not just equal to two but greater than two.

This is about the value, which is a lot of times measured as Return on Investment.  From shareholder perspective, in a standard financial term, it is the EPS.  This is not about the size of the merged company.  The number of employees may increase or decrease.  The number of sites may increase or decrease.  The number of customers may increase or decrease.  The number of products may increase or decrease.  The point is the share holder's value should be increased.

Whether you within a merged and acquired company are on the increased or decreased sides, it really depends on what is the net contribution you and your organization are is on the equation.

Team Work and Lan Yu Chong Shu

Here is a Chinese Story about 濫竽充數 ( Lan Yu Chong Shu):

During the warring states period (475 – 221B.C.) in ancient China, the King of the state of Qi was very fond of listening to music played on Yu, a wind instrument made of bamboo and wood.   The King convened musicians from all the states and formed a large royal band with 300 musicians.  When he wanted to listen to
the music, he would call in the whole band to play Yu together.  The ensemble was spectacular and the sound was thunderous to ears, but the King seemed to quite enjoy the effect, so he kept this habit all the time.

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.

Task Management

Five good tips:

1. Use a software for tracking tasks

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

Identify testing scenarios as part of defining the requirement

When defining the requirement, it is also the time to define the acceptance criteria.  The requirement is about "I want the system to be able to do...".   When I started writing requirements, I also try to start with the sentence "You should be able to ...".

For example, the requirement is "You should be able use the same password to login to BI as the password used to login to Apps".  The testing scenario will be:

Some examples of Sprint Burndowns

Sprint Burndown Chart is a tool for the team to help the team focus.







I found this video helpful.

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.

Release Planning & Project Selection Process

The scope of a product release needs to be identified as part of the release planning process.
The release planning process is for coming up the scope and the schedule for a software product release.
There are internal factors from the development, but there are also external factors, for example, the constraint or the request from marketing or product management department.

Depending on the market condition, sometimes, the time to market may be important and the duration for a given release may be shorten.  One or few features drive the release schedule and the rest of product features are added more like catching up a train.

--

Project Initiation - Project Charter

During the project initiation phase, a project charter can help facilitate the initialization process.

In the past, we have been asked to write such document and schedule the review with the stakeholders, before we kick off a project.

It describes what a project looks like and what resources needed, and how big the project will be.   It identifies the interim or final deliverables expected from the project.

I feel that this process is still important.  It is kind of like writing a contract.  People need to agree with the term and conditions before start working on the project.

For the internal software development projects, the quantified dollar values and the costs may not need to be tracked, but it is still helpful to write down the resource requirements and the business values the project may produce so people know why we do a project.

The system we are using for tracking the software projects can be used for tracking the project initiation as well.

Here are the information we need to enter:

CMR - Change Management Request

Change Management is part of the project management discipline to control the changes.

Change Management process is an important way to avoid the Scope Creep.
Sometime, people are not aware of the impact of a "small" change to the overall schedule or the quality of the product.  The formal change management process can help management and stakeholders realize that nothing is free.

Change management is not just for managing scope.

Managing a Programming Project

I found this book in a library used book sales.

http://amzn.com/0135507723

This book first published in 1973 and the book I got is the 1981 version.

This book is still relevant.

It describe the SDLC as six phases:

Software Development Project Management

Software projects have some additional project management requirements. It uses some management tools which may not be commonly used in other type of projects.

Here are some terms:

Software Release: It can be represented as a number. The historical projects are associated with a release that is already available to the customer. Otherwise, projects are associated with a release that is currently actively being worked or a future release.

Staffing: The project management for all different types of projects need to have the staffing function. Some typical roles involved in the software development projects are Dev, QA, Doc, Performance, and Product Management. When it comes to the stage of planning, a another common seen categorization is in-shore, off-shore, and near shore.