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.
Top Related