Harvey Nash Software Development

Design guideline for Scrum Project

Version 1.0

Huy Nguyen Tuong, Process owner 18 Oct 2011

364 Cong Hoa Street Tan Binh District Ho Chi Minh City Vietnam Tel: (84) 8 3810 6200 Fax: (84) 8 3810 6201

Harvey Nash

Offshore Software Development

DOCUMENT HISTORY

Version 0.1

Details Initialized the document

Author Huy Nguyen

Reviewer Minh.Bui, Nhan.Nguyen, Nghia Nguyen Cuong Nguyen

Approver

Date 18 11 Oct,

1.0

Get Approval

Cuong Nguyen

Nov 11

23,

CONFIDENTIALITY This document is distributed on a restricted basis, is commercial in confidence to the recipient, and may not be used for any purpose other than that associated with a Harvey Nash project. The contents of this document may not be disclosed to any third parties without the expressed advance written authorisation of Harvey Nash.

PIP - Design Process For Scrum Project

TABLE OF CONTENTS
1 2 3 4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS ................................................................ 1 POLICY STATEMENT ............................................................................................................... 1 SCOPE ...................................................................................................................................... 1 PROCESS ................................................................................................................................. 1 4.1 4.2 4.3 Purpose ........................................................................................................................... 1 Process Overview ........................................................................................................... 1 Process Details ............................................................................................................... 2

Harvey Nash

Offshore Software Development

PIP - Design Process For Scrum Project

1
Term
CI QAO

DEFINITIONS, ACRONYMS AND ABBREVIATIONS

Explanation
Continuous Integration Quality Assurance Officer

POLICY STATEMENT

Harvey Nashs Technical Solution for SCRUM methodology based project policy statement is the following:

Ensure that design effort is considered and planned properly along with functional requirements Ensure proper team structure is formed to perform design The design must be reviewed The design must be properly hand-over to development team Product components are implemented based on the baseline designs, and unit tested before integration. The development must be followed the standard guideline and environment QAO conducts audit TS activities on assigned projects as per this process.

SCOPE

The following procedures apply for all Harvey Nash (commercial or internal) projects that use SCRUM methodology.

4 4.1

PROCESS Purpose

To design, develop, implement, and document solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related lifecycle processes either singly or in combination as appropriate while still fit nicely to agile nature of Scrum methodology.

4.2

Process Overview

Scrum methodology aims to deliver the product/project incrementally with many iterations or sprints, regardless of that any deliverable code needs to be done only after design step has been finished. The design step in any iteration or sprint should always Begin with proper planning for design related activities and team structure, role and responsibility

Harvey Nash Offshore Software Development

Offshore Software Development

PIP - Design Process For Scrum Project

Next with proper requirement analysis for necessary design constraints and technical requirements Base on analysing result, design decisions/solution should be discussed and approved Base on design decision necessary design document, framework, code sample should be developed, reviewed, approved and properly hand-over to development team. Beside detailed design activities that are addressed in each iteration or sprint, there should be activities to address architecture vision to keep it well support the project goal. These activities also need to be properly planned and tracked carefully.

4.3

Process Details

4.3.1. Design Team or Design Activities Owner Design team structure and owner role should be discussed and decided depend on project complexity, team size, skill level and gap between team members, team experience. Some possible options: Cross functional team for medium and big project that can include domain experts and normal developer (as framework can be an output of design step) Group of domain experts or design board. External designer if design is from client Single man designer if the project is too small. Entire team if the team is all domain experts in the project and the team are small. 4.3.2. Design approaches When to do design: Big up front design: if the project domain is simple or it has been done many times with the team so old design and framework can be built up in a very short of time (just in Sprint 0). Another important factor to choose this approach is the chance of new things will be introduced is very small. Just-in-time design: Make necessary architectural or design decision available just before the implementation activities happens, however architecture vision should be followed, risks (possibility of available on time, possible big changes in the futures that lead to big rework) need to be addressed and decisions need to have enough time to be discussed and decide upfront. 4.3.3. Design Activities Planning and Tracking Sprint 0 should be there to for initializing design activities to make development team ready in implementation. Mayor changes or new items in architecture and framework level should need to be careful planned and addressed up front every mass implementation unless it is from clients. A good timeframe for those activities can be one or two sprints ahead compare to the mass implementation one. The design activities should be captures as technical or architecture spikes and tracked within the product backlogs and then should be prioritized and picked just like any normal backlogs. Design for a new system, using new technologies also usually can be done with proper researches and doing proof of concepts. Those activities again should also be tracked as spikes like above.

Harvey Nash Offshore Software Development

Offshore Software Development

PIP - Design Process For Scrum Project

Key technical requirements, challenges, constraints analysing

Initial high level architecture modelling, documenting

Initial high level architecture sharing, reviewing, update if required

Build up or adopt initial framework, solution structure, design/coding standards, CI environment for standards enforcement

Initial framework, standards sharing reviewing, update if required Sprint 0

New or detail technical requirements, challenges, constraints analysing

Specific design modelling, documenting as technical notes

Design model, technical notes reviewing, update this and high level one if necessary

Build up proof of concept, update framework if necessary Sprint 1

Share and review framework with developers, update if necessary

Sprint 1 Sprint 1

Harvey Nash Offshore Software Development

Offshore Software Development

PIP - Design Process For Scrum Project

4.3.4. Sprint 0 Architecture vision should be initialized and discussed. First version of high level architecture should be discussed and documented down Key technical challenges, constraints High level system overview High level architectural break down with requirement and solution High level components view Touch points, integration points between subsystems or sub components. Design and coding standards, design and coding review check list need to be tailored and approved. They should includes Customized rules set for automatic design and coding metrics analysing tools Design and code guidelines and review check list for each type of component or technologies used. For example: design guideline and check list for database, design and implementation guideline and check list for security Base framework and solution structure and related documents also need to be ready. Optionally draft plan for key design activities need to be defined and tracked as technical spikes 4.3.5. What need to be designed

Just like in traditional methodologies, design items and concerns are still the same Database design from logical model to physical model Logical application design for static, dynamic, data views Interface design for component integration Physical design, deployment model Design for proper performance, reliable, maintainable, scalable and security

4.3.6. Design Deliverables Agile doesnt mean no documentation should be written, instead in design documents should be there to help in capturing and communicating design related information not only for current needs but also future. However it should be as light as possible that fit to the need only. It is advised that following documents should be composed (depend on size and nature of the project) Database design model, database dictionary if the application store data to database High level architecture design includes Key technical requirements or constrains high level system overview Key technical decisions to address all technical constrains Interface design for subsystem or component integrations API document for all public components or common code in the core framework Technical notes to address any key technical decisions and design parts that happen in any iterations Detailed design and implementation guidelines/rules. Design and code review check list possible for entire system or for each technology, component depend on how big and complex the system is. Rule set for automatic design and code review.

Harvey Nash Offshore Software Development

Offshore Software Development

PIP - Design Process For Scrum Project

The documents should be tracked in a document management system or source control or even wiki for better collaboration Beside documents, it is advised that design decision should be transformed to a form that understandable and follow-able to developers i.e. frameworks, sample code, wireframe, solution 4.3.7. Design communication It is important to get all design decisions and vision well communicated to all related stakeholders and developers Architecture vision, high level architecture design, common design and implementation guidelines/rules and initial solution structure and framework needs to be explained at sprint 0. Any new design decision arises during next iterations also need to be informed widely to all related stakeholder. Framework or common code also needs to be explained as well accompany with proper documentation level. Depend on the need the communication can be done by emails, direct communication or official meeting, however traceable methods are preferred. 4.3.8. Design Quality Control Following actions are advised to control the quality of the design outputs Define, adopt and follow design standards to make the design consistent, the standards should be from company level standards and/or approved from clients Important design decisions and design outputs need to be shared, discussed, reviewed with stake holders: clients technical leads, team leaders, technical leads, technical coaches and possible key developers Frameworks, library and related documents need to be shared to developers by team meeting or technical coach. Feedbacks from developers need to be tracked Design should have proper documentation level; at least we should have a high level architecture document to capture key technical requirements and system overview and technical notes for each important technical decision.

Harvey Nash Offshore Software Development

Offshore Software Development