• Permalink

    The use of Kanban to support a well defined Software Development Life Cycle

The use of Kanban to support a well defined Software Development Life Cycle

In our last blog I discussed how the Scrum process supported the Software Development Life Cycle. Partnet uses two different proven Agile development methodologies for development: Scrum and Kanban. A specific method is chosen based on the nature of the work.

Scrum: Used for complex projects where increments of work can be flexibly managed and assigned into sprints. Work assigned within a sprint can be completed without disruption.
Kanban: Used for less-complicated projects (e.g., Problem Reports) where priorities frequently change.

Kanban is a backlog-pull model that emphasizes just-in-time delivery of work and avoids process bottlenecks by limiting in-progress work. Kanban also allows for customer-driven prioritization as tasks are regularly prioritized to match their current needs. This means that if an emerging requirement suddenly takes precedence over existing priorities, the team can flexibly respond without affecting project goals or progress. Kanban uses the same Delivery Team roles and responsibilities employed in Partnet’s Scrum process. Partnet employs Kanban for Problem Report work since this work is often subject to shifting priorities.

Partnet’s Kanban process pulls new requirements from a Customer prioritized backlog. Tasks are created and assigned to release versions based on these priorities. The process defines a series of work queues that simultaneously identify the current status of a given development task, and the assigned resource.

Together, the work queues establish a linear workflow for completion of assigned development tasks, as shown below.

 Work Queues and Linear Workflows

Work Queue
Status

    Assigned Resource

To do
Backlog task; not actively being worked on by any project team member
   Backlog

Needs Requirements
Undergoing requirements analysis to define new functional requirements; assess impact to existing functionality
    Requirements Manager

Ready for Development
Requirements analysis complete or not needed

    Developer

Development in Progress
Development and integration underway; includes unit testing and code reviews
  […]

How Scrum supports the Software Development Life Cycle

Last month I did a blog series on the importance of having a well define Software Development Life Cycle. Today I am going to talk about a methodology which supports the Software Development Life Cycle to keep it on track and humming.

Scrum is an iterative software development framework that employs time boxed “sprints” to deliver software quickly and incrementally. Scrum’s short development cycles offer flexibility to react to change by demonstrating functionality at the end of each iteration, promoting frequent customer interaction, and having the customer as part of the team. Scrum is used for larger efforts where work can be prioritized in batches, with each batch being of a scope and complexity such that it can proceed uninterrupted.

A Scrum team is made up of a number of players with differing roles and responsibilities.

Roles
Responsibility

Scrum Master
Enforces adherence to the Scrum methodology. Responsible for removing impediments for the Delivery Team. Ensures project objectives are met while balancing constraints, budgets, schedules, resources, and risk.

Delivery Team
Responsible for delivering the work. The team is made up of the following roles:

Product Owner: The voice of the customer. Has the responsibility to deliver a successful product in terms of vision and features. The  Project Lead would be the ideal person to fill this role.
Requirements Manager: Elicits, refines, and manages the solution requirements
Architect: Defines the architecture and technologies employed by the software solution
Technical Lead: Oversees software design and development
Developer(s): Codes and integrates the software
Software Test Engineer(s): Validates the software against solution requirements; enforces applicable quality standards and documents identified defects
Configuration Manager: Stages and deploys software changes to Development, Staging, and Production environments
Data Architect: Defines data architecture and allocation of data assets
Database Administrator (DBA): Maintains database; manages data access, import/export processes, and migration […]

  • Permalink

    Part 5: System Development Life Cycle – Release Planning and Deployment

Part 5: System Development Life Cycle – Release Planning and Deployment

The Release Planning and Deployment stage begins upon completion of software testing. During this time, no changes to the software are permitted excepting those explicitly directed by the Customer. Release Planning and Deployment is performed in three phases: Pre-deployment, Deployment, and Post-deployment

Pre-Deployment

The Pre-Deployment Phase addresses three major tasks simultaneously:

Release Planning
Training and Documentation
User Acceptance Testing (UAT)

In most cases, software deployments to the System Users will be transparent to end users.

However, careful release planning and coordination is essential for ensuring that the Customer is consulted on all new or altered code and the decision to release it. Release planning also includes identification of active and standby resources, as well as specification of a roll-back strategy in the event it becomes necessary to revert or roll back the deployed code.

Partnet will collaborate with the Customer and any associated Change Control Board (CCB) representatives to create a release deployment plan, to include:

A cutover schedule, identifying the date and time for the release.
A listing of the features and/or problem reports that will be contained in the release.
Identification of a release coordinator.
A release impact assessment, including impacts to integration partners.
A roll-back plan, outlining a contingency process for removing new changes should it become necessary.

The following tasks can then be performed as part of the pre-deployment phase:

Identify the deployment team, including: Release Project Manager, Change/Configuration Manager, Database Administrator, Technical Lead, Software Test Engineer, End User Tester
Prepare a draft deployment schedule which:

Chronologically outlines required deployment tasks and estimates, including tasks to be performed by external third parties.
Identifies the complexity, timeframe, and task owner of each deployment task.

Execute a mock deployment on the Staging environment, which allows the team to rehearse deployment tasks and validate estimates.
Execute the roll-back plan on the Staging environment […]

  • Permalink

    Part 4: Software Development Life Cycle – Software Development, Testing, and Quality Assurance

Part 4: Software Development Life Cycle – Software Development, Testing, and Quality Assurance

Agile best practices recommend overlapping development and testing cycles. This helps identify and resolve software defects early, while minimizing scenarios where developers are simultaneously trying to fix old bugs and build new features.

Overlapping development and testing cycles also promotes the incremental delivery of working code. This process allows new features and bug fixes to be rapidly promoted, while allowing the Customer to review new features as they are developed, and make decisions about when specific features are ultimately deployed to Production.

Partnet’s software development process is enhanced by the incorporation of continuous delivery methodologies. Continuous delivery is a collection of techniques designed to improve and automate software delivery. These techniques include:

Continuous delivery pipeline
Automated testing
Mainline development
Continuous integration

Continuous delivery allows software to be developed to a high standard, easily packaged, and rapidly deployed to the various environments. Additionally, new features and bug fixes can be rapidly promoted to the Production environment with minimal risk and overhead.

Our developers use a continuous delivery pipeline to implement continuous delivery principles.

The deployment pipeline is like an automated assembly line which the code passes through to ensure it is ready for Production. This assembly line includes:

Building the software
Running unit tests
Building the application deployment
Running automated User-Interface (UI) tests

This method allows functional software to be rapidly promoted to non-Production environments for Customer inspection; or promoted directly to Production in cases where a feature or bug fix is immediately required.  For projects employing the Scrum process, this cycle repeats within each sprint until the Product Owner signifies all requirements have been met and the feature is Production-ready

Automated Testing

Automated testing requires close interaction between software developers and test engineers. The following process is employed within each development cycle (Scrum or Kanban):

Test engineers write test outline(s) for […]

  • Permalink

    Part 3: Software Development Life Cycle — The Solution Design

Part 3: Software Development Life Cycle — The Solution Design

The Solution Design stage begins upon Customer and stakeholder approval of the System Requirements Review (SRR) and its associated artifacts. Solution Design is specific to Scrum projects only. Design is not typically required for Kanban process cycles involving Problem Reports and smaller “break-fix” tasks. Partnet’s Solution Design stage consists of two elements: functional design and technical design.

Functional Design: User stories form the basis for functional design and planning. User stories are short, textual statements corresponding to a specific feature or business need that the software solution must fulfill. Requirement Managers write user stories based on the approved solution requirements. During functional design, user-story reviews are convened with members of the Delivery Team to formally discuss each user story in detail and specify its acceptance criteria. All outstanding questions and assumptions are documented for follow-up with the Customer and other external stakeholders. User stories are then allocated into specific development tasks and subtasks that constitute the Product Backlog.

Technical Design: In parallel with user-story reviews, our development and engineering group prepares the technical design solution. Aspects of the technical design include:

Analysis of necessary changes to the general solution architecture.
Review new interfaces for third parties.
Protection of system security posture.
Identification of required hardware components, operating systems, and network architecture.
Research supporting software technologies and libraries.
Determination of necessary changes to the data model(s).

Partnet convenes an internal design review to collect and incorporate final feedback on the designed solution from Software Developers, Test Engineers, Configuration Managers, Project Managers, security specialists, and support staff. This review focuses on specific items affecting the solution design, such as:

Ensuring the design minimizes development and maintenance costs.
Identifying opportunities for business-user configuration (i.e., administrative utilities that allow the Customer to configure and manage the software without new […]

  • Permalink

    Part 2: Software Development Life Cycle — Incorporating New and Emerging Requirements

Part 2: Software Development Life Cycle — Incorporating New and Emerging Requirements

Partnet’s development team understands that requirements are volatile by nature and are inevitably subject to change during the course of development. New and emerging requirements often occur as the result of unforeseen constraints, capability gaps, user implications, or newly-identified stakeholders. Our Agile methodologies provide the flexibility required to quickly and responsibly react to such changes without putting other priorities at risk.

New and emerging requirements should be presented to the Partnet development team by the customer in the form of a new or updated functional specification. Our Requirement Managers follow industry best practices to thoroughly assess all new requirements. Careful business analysis is performed to:

Determine any impacts to the existing system.
Identify the best implementation approach.
Mitigate risk to the customer and end users.

Upon identification of a new requirement, Partnet will work with the customer to define business objectives and desired outcomes. Requirement Managers will carefully assess the new requirement against the deployed defined or existing solution to:

Identify capability gaps.
Assess impact to current functionality.
Identify affected stakeholders.
Identify transition requirements.
Document risks and constraints.

Partnet Requirement Managers will present this assessment in the System Requirements Review (SRR). The SRR will document the stated, unapproved requirements along with a recommended implementation approach. Also, the Partnet Project Manager will identify the estimated cost and time necessary to implement the new requirement. Once the additional cost and time are approved by the customer, Partnet will follow its standard requirement procedures elicit, refine, and formalize the solution requirements. Requirement Managers thoroughly maintain requirements traceability to ensure that substantive changes are documented and versioned as new requirements are incorporated into the designed solution.

Partnet expects the customer to be a key stakeholder in the gathering and approval of all requirements—including new and emerging requirements. Consequently, the customer […]

  • Permalink

    Part 1: The Importance of a Defined Software Development Life Cycle

Part 1: The Importance of a Defined Software Development Life Cycle

I’ve been thinking lately about how important it is for a company to have a well-defined process for the Software Development Life Cycle, or SDLC as we like to call it. I’m going to do a series a blogs to share our SLDC process.

Partnet’s SDLC employs industry-best practices in accordance with Agile principles and methods. Our approach ensures that the right product is delivered in the required time frame, while providing visibility into the solution’s development. As part of our Agile Development approach, we employ both Scrum and Kanban methodologies.

Partnet’s SLDC is a multistage process. The first step in the SDLC is to make sure that each development projects start with stable, well-defined requirements. Our Requirement Managers use industry-best requirement management practices as defined by the Business Analysis Body of Knowledge (BABOK).

The requirements manager coordinates and schedules requirements gathering activities with each stakeholder group. These activities may take the form of interviews, video teleconferences, requirement workshops, questionnaires, or other forms of outreach. In some cases, multiple rounds of requirements gathering activities may be required as the results are documented and consolidated.

This step ends with the preparation of a formal requirements package. The requirements package describes desired outcome(s), assumptions, and constraints associated to a given business requirement. A requirements package may be presented in any number of formats, including but not limited to:

Functional specifications
Screen mockups and page wire frames
Flowcharts, sequence diagrams, data flow diagrams and other visual models
Data dictionary
Use cases and scenarios
User Roles
Goal or desired outcome
Benefit to the customers and stakeholders

The Partnet team completes the Requirements Step by meeting with the customer and other stakeholders to conduct a formal System Requirements Review. This involves distribution of the requirements package(s) for stakeholder approval. Signatures are collected […]

EasyMock Fundamentals Series — Part 3

Welcome to the third installment in my EasyMock Fundamentals series where I take you through the ins and outs of the open source Java library.

By |May 28th, 2013|General|0 Comments|

EasyMock Fundamentals Series — Part 2

Each way gives you a mock object with slightly different behaviors/restrictions. Consult the EasyMock API for specifics, but unless you have valid reason to not, the preferred method is createNiceMock().

By |May 21st, 2013|General|0 Comments|

EasyMock Fundamentals — Part 1

In my three-part EasyMock Fundamentals series, I will take you through the ins and outs of the open source Java library. EasyMock can be used in conjunction with a unit testing framework, such as JUnit or TestNG, to facilitate better unit testing without all the 2nd degree dependency issues. EasyMock provides the means (through the use of mock objects) to specify the response that will be returned when the code being tested makes calls to external methods. This will allow the result of the unit test to be isolated from variables outside of the scope of the unit test code.
An Introduction to EasyMock Fundamentals

Refer to the official EasyMock documentation for more detailed explanation of the tool (latest as of this writing EasyMock3.1 Docs) including download, setup, and a brief usage example.

Please note that, for the sake of simplicity, not all the details of the code examples have been included.
Stubs vs. Mocks
An alternative to using a mock object is to create a stub object; a lightweight implementation of the interface for the external methods, that just return the expected response. These two approaches are best illustrated with an example.

Let us say you want to write a unit test for an object Foo that does something cool, doSomethingCool(), and uses another object, Emailer, to send emails while doing something cool as follows:
package com.partnet.foo;
public class Foo {
  private Emailer emailer;
  public Foo(Emailer emailer) {
    this.emailer = emailer;
  }
  public void doSomethingCool() {
    // something worthy of being unit tested
    emailer.sendEmail(…);
  }
}
package com.partnet.foo;
public interface Emailer {
  boolean sendEmail(…) throw EmailerException;
}
If you’re trying to test the doSomethingCool() method, you don’t want to, shouldn’t have to, and thankfully don’t need to worry about what emailer.sendEmail() does (assuming the implementation of the call has no impact on the code you’re testing of […]

By |May 14th, 2013|General|0 Comments|
Google+