Java Test xUnit PMP QA ITIL

Studies have shown that have indicated that that 68% of IT projects fail. Gathering examples of IT project failures may not a very hard task. What is hard is to get a fair assessment of the issues and determine the extent of the failure. What is even harder is to get all the stakeholders to agree the cause of the failures and where the responsibilities lie. Organizations are known to have high expectations of Project managers.  Project Managers are considered to be bright, very experienced, motivated and knowledgeable in the subject area. At initiation, a project is deemed strategic and most often the best of the resources are generally pulled into the project. And frequently if we look at the statistics - projects fail, thereby demonstrating that the best of the ingredients do not make broth that is good enough! Evidence that IT project failure is not just occasional is best indicated with projects that involve "public money". When the budget is higher and funding an

The transition to agile seems challenging to developers and organizations. The agile manifesto prescribes working code to comprehensive documentation. This principle, when isolated seems to confuse agile practitioners. Recently I was involved in a scrum project, where there was absolutely no requirement definition. While the developers were eager to make scrum “work” for them, there were considerable challenges for the people who were newer to the organization. Organizations that have matured over the decades rely on senior workers to provide subject matter expertise. This may not really be a good idea, since agile projects are fast paced and developers who are also tasked with being SMEs will be challenged for time. A business analyst is critical to agile teams to provide requirements, unless the product owner is able to fill in all the required details for user stories, which does not seem practical. Producing extensive bulky documentation with obsolete information is totally wor