By Ben Linders
The serie on “What Drives Quality” continues. Previously covering Requirements Quality, Architecture and Design Quality Coding Quality, and Review and Inspection Quality, this post covers Testing. Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money.
Testing covers many ways of verifying and validating the product. For example it can start with functional testing, followed by system testing, integration testing up to and including release testing. These are just examples, most companies define their own testing stages. There is a lot published on testing, I guess it’s number 1 in Quality Assurance wrt publications, conferences, and professional network. However, QA is not testing, and many of the defects that are found with testing could have been found earlier in a more economical way. But ok, testing is important to quality, so that’s why this blog posting looks at how testing can drive and contribute to better product quality.
Some factors that influence testing quality are:
Article posted from link
Millions of dollars are invested in Agile & DevOps initiatives within software organizations, yet real process improvement and return-on-investment data have been difficult to come by. Fragmented processes and tooling for all the various aspects of the software development lifecycle make data-driven decision-making even more challenging.
Learn how integrated Agile & DevOps can help you make better decisions and accelerate software delivery in this overview of our webinar, Integrate Agile & DevOps with VersionOne.
The DevOps BuzzThe term “DevOps” typically conjures up thoughts of automation. But DevOps – just like Agile – has as its ultimate goal the “[conversion] of business needs into capabilities and services that provide value to [your] customers.” And both emphasize constant collaboration and the frequent delivery of working software.
Today, actually, the expectation is increasingly becoming not just “frequent delivery” but “continuousdelivery”. This just isn’t possible to sustain, without both Agile AND DevOps working together.
Agile and DevOps both have their philosophical roots in Lean, and they are really complementary disciplines that fall under the larger umbrella of the Lean concept of Value Stream Management.
It Starts With the Value StreamThe term “value stream” simply means all of the steps required to create and deliver something of value, such as an epic, feature, or product. Your value stream starts at ideation, continues through development as value is created, and ends when the feature, product, or service has been delivered to your end users.
Value Stream Management GoalsThe core objective of Value Stream Management is to perpetuate business success by continuously and efficiently delivering value to your customers. In a nutshell, the details of value stream management involve:
Read the rest at link
Below article is a repost from link
Adaptive project management is a structured and systematic process that allows you to gradually improve your decisions and practices, by learning from outcomes of the decisions that you took at previous stages in the project. As the name suggests, project management process changes and adapts to the needs of the organization, ultimately boosting business value.
Adaptive Project Framework (APF) has a number of variations, with adjusting scope at each iteration. Robert K. Wysocki, the author of Adaptive Project Framework, says that APF is more like creating a recipe than following one. He also explains that project managers are in charge of the approach, meaning they need to understand the situation and adapt their approach and techniques.
Main characteristics of Adaptive Framework are:
Why do we need Adaptive project management?Traditional projects have a clear structure and a static strategy where project managers distribute tasks and keep the entire team under control. But the fast-paced technological advancements and ever-increasing demands of today’s market have changed project management in three key areas:
Wysocki uses the analogy of a chef and a cook to explain the difference between the traditional and the adaptive project management: while a cook follows a recipe to the letter, a chef doesn’t only have the knowledge and experience to create a recipe but also the ability to improvise if something unexpected happens.
Read the rest at link
The Program Plan ensures that all project teams and stakeholders understand how the related Projects will be chartered and managed to deliver the overall Program Benefits. It communicates the program management approach and degree of overall coordination which will be used to coordinate the projects and project releases within the overall program (vs level of project independence). Project Charters detail scope for each project.
Program Plan details include:
Details for the Program Plan may be adapted as applicable, and may also be added into the Project Charters.