Project Management in 3 Slides
- 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.