This article looks at the CUBA Platform – an open-source framework combining solid architecture, "must-have" features for enterprise applications, and rapid application development tools.

The author shows us what goes into creating material themes on Android and shows you some simple ways to use AppCompat to get it done.

It really pays to have a Product Owner or a product champion to streamline the development process.

Stop having your restrospective indoors! Why not drag your team outside and enjoy the sunshine. Enjoy this 8 point plan for an outdoors reflection.

A list of exactly what Agile does differently than Waterfall.

For some reason, web dev teams always find themselves slipping into the old way of testing. Why?

Can you read the table to go along with what everyone else picked during planning poker? Is that even a good idea?

Why managers in charge of software projects need to understand tech in order to manage effectively.

Agile software development, when done right, results in a stronger application that respond more quickly to ever-changing consumer demands.

DZone user Stefan Wolpers at Age of Product shares a custom checklist to use within your team and business to see how agile you are.

Many departments with "agile" operations are full of whiteboards-turned progress updates. Here's a look at the concept of "information radiators."

You're likely familiar with the SOLID principles. Here's a breakdown of the SOLID principles in a real-world setting.

Taking the SCIPAB approach for starting conversations and presentations for agile use cases.

Check out how to get up and running with JBoss Enterprise Application Platform 7! This comprehensive video will get your going with JBoss EAP 7.

Developers can write applications to Couchbase using many different languages and multiple SDKs. This post explains how to deploy and access a NoSQL database from JBoss EAP 7.

It's commonly said that everyone does Agile differently. In my experience, it's also common to do basically whatever you want and call it Agile. It can be useful to occasionally reset and examine what canonical Agile recommends.

Things I learned on my path from a Technical Lead to a Scrum Master. My transition flowed from ScrumDude, to ScrumMom, to finally Scrum Master.

Insights on how to make an average velocity concept a powerful tool for your Agile team.

Written by Jim Magers for LeadingAgile. When I’m teaching an agile bootcamp class and talking about work in process, I always make a point (usually multiple times) to tell the attendees that agile is about finishing work…not about starting work. I reinforce this by pointing out that you can have a glorious looking burndown chart for the duration of the sprint but completely fail in your mission to meet your commitments and finish stories. The team can be burning down hours beautifully on a daily basis, with the remaining task hours looking like they are tracking right along the ideal line, and then boom… It’s closing time for the sprint and no stories actually got completed. Remember that notion of building working, tested software? Didn’t happen. The team started too many stories at once and ended up not being able to bring any of them across the finish line when the bell rang. This notion of finishing work applies to sprint planning as well. If you short-change the time it takes to do good sprint planning, and the team meanders off to begin writing code and test plans too soon, there is a risk that the team is going to struggle to be successful. Remember what we do in sprint planning. Consider velocity, and load the sprint backlog with high priority stories from the product backlog. Check. Determine capacity for the team to work on sprint tasks over the coming sprint. Check. Break stories into tasks and determine who is doing what. Check. Make sure the work is going to fit. Check. Commit to the work. Check. But what can happen when you don’t take the time to thoughtfully break down tasks and estimate hours of effort? Consider the following burn down chart. In this example, the team left sprint planning thinking that they were committing to 830 hours. But just two days into the sprint they discovered additional task hours and instead found themselves in the awkward position of actually needing almost 1200 hours of capacity to complete the committed stories. Guess what…they did not have 1200 hours of capacity to give, especially since they were now a full two days into the work. In looking more closely at their burndown chart over the course of the two-week sprint, it took them almost 6 days of work to get back to the point where they had 830 hours of work left to do. Six days just to get back to where they thought was their starting point when they concluded their sprint planning meeting. And surprise, they didn’t finish the sprint successfully. So, don’t short-change the value that good sprint planning affords. Yes, it takes time. Yes, it can seem tedious. Yes, the team is anxious to get started. But good sprint planning pays dividends. Remember that it is about finishing work, and not about starting work.

Every business has unique characteristics that set it apart from other organizations, even within the same industry. For this reason, it shouldn't be surprising that there's not a one-size-fits-all approach to app security testing. Each company has certain protection expectations and regulations to adhere to, making it essential to find the best way to achieve these goals. Here are a few examples of security testing methodologies available for quality assurance teams to leverage: Black box With black box testing, QA professionals put themselves in the shoes of the hacker and attempt to break the app through various attack vectors. This methodology can yield a lot of information and help better secure the program from actual threats. A white paper by Security Innovation noted that software testers first analyze the system's architecture and business model to identify any security vulnerabilities. Looking over the software logic in this way can uncover subtle security and privacy issues that may not have been noticed otherwise, such as defects in design, input, system dependency, authentication, cryptography and information disclosure. "Although white box code inspection is good for analyzing static behavior, only black box exploratory testing can determine the dynamic behavior of how a system is implemented and used, the coupling between systems and the interactions of the distributed systems," Security Innovation wrote. Dynamic For QA teams that like to execute code, dynamic testing is the approach for them. This methodology checks the running application for how it behaves and responds to a variety of inputs. This is done to ensure that the product meets up with established regulations and is giving the expected outcomes. IBM noted that dynamic analysis is especially useful to identify code coverage, as it can discover bugs in paths that have gone untested. While dynamic testing can be manual work for testers, it can also yield significant information that will help mitigate defects and produce quality products. Static In contrast to dynamic testing, static approaches directly review the source code, often through an automated test management solution. TechTarget contributor Michael Cobb noted that this methodology occurs at the implementation phase, rather than when the app is running, and often helps mitigate vulnerabilities involved with industry compliance standards. Automation in this area can reduce the amount of time it takes to complete these tasks. However, it may not be able to detect sophisticated threats, which can be supplemented by dynamic security testing. "A thorough source code review has an advantage over dynamic testing," Cobb wrote. "Nothing is hidden from analysts during a source code review, so they can examine exactly how data flows through a program. By solving the problem at the code level, static testing reduces the number of security-related design and coding defects, and the severity of any defects that make it through to the release version, thus dramatically improving the overall security of the application." There are a number of security testing methodologies that organizations can pursue, and designing a combination of approaches may result with a solution that's best for their needs. Using these strategies, companies can better ensure the protection of sensitive information while providing users with the software testing tools needed to succeed.