Project Management, Integrating Agile Methodology and Visual

Studios in Three Slides

Bonus Slide to Visually Present Testing concepts.

EDW Project ManagementP

roje

ct In

take

Solu

tio

n D

esig

nTe

chni

cal D

esig

nPr

epar

e fo

r A

ctiv

e D

evel

opm

ent

Planning

Use Case Collection for Project

Business Requirements GatheringFeasibility Study

Resource RequirementsAnd priortization

Project Initiation Project Charter

Proposal SelectionInternal

RFP

Solution DesignDesign Review

Design Selection Business Solution Document

Gather TechnicalRequirements

Submit Technical DesignTechnical Design Review

Approve Technical DesignTechnicalDocument

Project MgrCreate Project Plan

Select Project TeamSprint Planning Meeting Sprint Schedule

Create Project Work ItemAttach Charter

Attach Solution Document

Attach Technical Document

Create Sprint Work Item as Child

At this point I hadn’t decided whether to integrate Agile Methodology until that final graphic. Until then there was no need to. But for the sake of accuracy, I should have called that the Scrum Team instead of Project Team. Having made that gross error my big fear is being slammed by hoards of agile perfectionists. (Because that is, after all, the only perfect method for software development.)

Getting Started!

I HATE collective brainstorming sessions. If I could have back all the wasted minutes of my life where I wasn’t allowed to say “That is just stupid!”

I do like the concept of internal RFP. A little friendly competition amongst the team for the best solution is likely to provide a better solution quicker than a retreat with charts and no permission to type wtf!!!

Gold boxes throughout or recommended Visual Studios Activities

EDW Project ManagementSp

rin

t Pl

anin

gSp

rin

tTe

stin

g In

QA

Agile Development

Product Team

Select Duration

Identify Included Features

ClarifyRequirements

As a usertype, I want to do this, so I can achieve that.

Define Tasks as deliverables

Create Work Item for Each Task as Child of Sprint

Create Work Item for each requirement as Child of Sprint

Project Developers work on assigned tasks

A unit test is performed and the passing results

documented and attached before a task is marked as completed

Unit TestsAre written each

Task and attached to the work item

When all tasks are completed Integration Testing is performed

in Development Environment

Product is Deployed to QA environment

IntegrationTesting

QA integration testing is performed to verify that the system deployed is functional at the modular interfaces as well as within the modules. It relies on the ability of the combined system to give the correct outcome both at the interfaces between modules and in the final results. Defects found are attributable to individual modules.

SystemTesting

System testing is meant to simulate how the system functions in the real complex word of integrated service architecture. System testing covers many different testing types like sanity, usability, maintenance, regression, retesting and performance. Defects found here is regarded as a defect of the whole system rather than being attributable to a specific part of the system.

UAT Testing

User Acceptance Testing is the last phase of testing. It is conducted by real users make sure that the product can handle the real world activities and workflow that occurs on a day to day basis.

After a task is completed it’s work item is marked as

Completed prior to moving to the

next task.Sprint state is changed

to ready for testing.

A Test Child Work Item is created for the Sprint

Work Items for failures to meet functional requirements during testing are created as Bugs

Work Items for failures to meet non-functional requirements during testing are created as Requests

Get ‘er done!

I am not the train conductor where I work, nor do I get to ring the bell. So when I tell you that we use something that might be better called an Agile Waterfall methodology, be kind. Change is hard. So we mostly change what we call things. However, the two sprint related swim lanes are true to the suggested methodology. I would really like to try it some day.

Yes because I am in QA Included this QA Test flow in addition to the bonus slide because if you haven’t notices by now, we are EVERYWHERE. Just like your mother. And we love to catch you doing something bad, just like your little brother. Then we snitch to all high heaven about what we found to cover all our asses. I don’t get invited out for drinks with the guys much anymore. It reminds me of when I was in the fourth grade in the student patrol with that white cross over belt. Oh the power!

EDW Project ManagementD

eplo

ymen

tR

elea

seC

lose

ou

t

Release and Deployment

All bugs must be verified as completed prior to deployment to production or requirements must

be changed, documented and approved by stakeholders.

Submit Cadence

Plan

Submit Change Control

Required Approvals

Change Control SIT SignoffUAT Signoff

Deployment Meeting is Scheduled

All active request Work Items must be completed prior to

product release.

Required user training and materials must be provided prior to release.

Support and Maintenance Knowledge Transfer must occur prior to release.

Stakeholder notification must be provided prior to release

Release Date should be provided in advance of Release

Create Deployment Work Item

Attach Cadence Plan

Note Release Date in Sprint Work Item

Close Sprint Work Item

Hold Sprint Review

Meeting

Move Sprint Attachments to appropriate TFS Location

Enjoy the moment

Finish him!This is just stuff that developers try to ignore because they were done when they deployed it to the QA environment and users ignore because they wanted the product yesterday. Oh yeah, until something happens and the new shiny object loses its luster.But in my dream university. Nothing is deployed or released until I can bet someone else's life on it with good conscience. If it were my life we’d still be using Borland products.

I was once told by a developer that their product was good enough. Not that it meets requirements, not that it was the best that he could do just that it was good enough. It turns out it wasn’t after a little system testing my way. But we are still friends AND he was kind of glad that what I discovered happened to me in QA and not to us in production. I still snitched all over that Systest document.

The What Where and When of Testing: EDW Project Management

Cod

e U

nit

Tes

ting

Ass

embl

ed C

om

pone

nts

Uni

t Te

stin

gIn

tegr

atio

n T

esti

ngSy

stem

Tes

ting

Testing

Module 1 Module 2

Module 1 Module 2

Unit A

Unit C

Unit C

Database Farm

Module 1 Module 2Completed Product

Installation Servers

Users

Other Servers sharing providing shared services and using shared resources

Development

Other Services and Applications

Functions, Stored Procedures, SQL Queries, Closed Code

Jobs, Packages and Services

Completed Product

Simulated Production Environment (QA)

Local Environment

Development Environment

Development Environment

QA Environment

Completed Product

Developers just don’t understand. I don’t do unit testing. I don’t even care if they did unit testing and the thing passed a billion times. I begrudgingly do integration testing in the development environment when the person that writes my checks tells me I have to do it.Why? Because none of that matters and anything I do there I will have to repeat in QA. Besides, I should never get anything that fails unit testing, or integration testing in QA. If I do then either they didn’t test their own code (stupid); they deployed the wrong code (stupid) or they didn’t configure things correctly for QA. (forgiven).Ultimately, what everyone wants to know, and I do know my audience, is will this product work correctly and reliably in the real world with users who do crazy things and data that is really messed up some times. My job is to do everything possible to make sure the answer to that question never turns out to be no and we didn’t know it.