The document discusses integrating agile methodology and Visual Studios for a project. It includes slides on project management, planning, requirements gathering, design, development, testing and deployment. Comments are provided throughout discussing challenges with different methodologies, testing approaches and roles.

1. Project Management, Integrating
Agile Methodology and Visual
Studios in Three Slides
Bonus Slide to Visually Present Testing concepts.

2. EDW Project ManagementProjectIntakeSolutionDesignTechnicalDesign
PrepareforActive
Development
Planning
Use Case
Collection for Project
Business Requirements Gathering
Feasibility Study
Resource Requirements
And priortization
Project Initiation Project Charter
Proposal Selection
Internal
RFP
Solution Design
Design Review
Design Selection Business Solution
Document
Gather Technical
Requirements
Submit Technical Design
Technical Design Review
Approve Technical Design
Technical
Document
Project Mgr
Create Project Plan
Select Project Team
Sprint Planning Meeting Sprint Schedule
Create Project Work Item
Attach 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

3. EDW Project ManagementSprintPlaningSprintTestingInQA
Agile Development
Product Team
Select Duration
Identify Included
Features
Clarify
Requirements
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 Tests
Are 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
Integration
Testing
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.
System
Testing
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!

4. EDW Project ManagementDeploymentReleaseCloseout
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 Signoff
UAT 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.

5. The What Where and When of Testing:
EDW Project Management
CodeUnitTesting
AssembledComponents
UnitTesting
IntegrationTestingSystemTesting
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.