Both Android and iOS require developers to “sign” their apps before they can be distributed and installed. An app is signed with a certificate identifying a developer as the author of that app and verifying the app has not been modified since it was last signed. Apps are self-signed with private certification keys.
The most agile teams we know of are consistently delivering the highest business value the fastest, and over the longest period. The most agile teams do seem to be the most efficient. But agility is not easy. While built on a set of very simple concepts, agility represents a fundamentally different way of doing business. High levels of agility require a substantial commitment to education and training, new tools and techniques, patient transition, and cultural change. This commitment must flow from management downward, and from the team upward.
Such change is not for everybody. Organizations that don't promote and value open communication, trust, and teamwork may not provide the most fertile ground for agility to succeed. This does not mean that agile cannot work for such organizations. Agility is a spectrum. Some teams are more agile than others, which are in turn more agile than yet others. It may be well worthwhile for your team to start with modest increases in agility, and to gradually seek a most comfortable and workable spot on the agile spectrum.
Ultimately each organization is responsible to itself for its agility. With any process or methodology implementation, practices will need to be adapted and localized. The key is not the specific practices, but the mindset and manner in which they are applied. In Ron Jeffries' words, "The practices are not agility. They are a way to find agility."
Although by no means scientific, use our agile assessment as a test of your agility, try rating your team from 1 to 5 on the following 10 agility factors, with 5 being the most agile (note: everyone gets a 1 for each criterion just for showing up to take the test). Virtually no organization will line up straight down the right of the diagram, but the best ones will continue to push themselves further and further as opportunities arise.
Planning and estimating in the agile world depend on a single key metric: the development team's velocity, which describes how much work the team can get done per iteration. (We describe velocity in detail separately.) Given a team's known velocity for its last project (if it is known), a release plan represents how much scope that team intends to deliver by a given deadline.
Release deadlines are often fixed, imposed externally by such things as tradeshows, accounting pressures, or contractual obligations. But since the goal is to get working software into the users' hands as quickly as possible in order to make "course corrections" as soon as possible, every effort is made to keep release software development cycles as short as possible. Agile release cycles should certainly be kept shorter than a year, and are often as short as 6 months or 3 months. A release is, in turn, made up of iterations. For a given project, iteration length will typically be fixed at a length somewhere between a week and a month. If the release is in 6 months and iterations are going to be 2 weeks each, the release will consist of 13 iterations.
In agile development, a feature is a chunk of functionality that delivers business value. Features can include additions or changes to existing functionality. For planning purposes, some agile methodologies also use the notion of "work items" that can include features, bug fixes, documents, and other artifacts. But features are the main unit of planning. Ideally, a feature should adhere to the following criteria:
It should provide business value
It should be estimable - it must have enough definition for the development team to provide an estimate of the work involved in implementing it
It should be small enough to fit within an iteration - therefore, if it is too big, it should be broken down further
It should be testable - you should understand what automated or manual test a feature should pass in order to be acceptable to the customer
The different methodologies use different terminology to refer to features. It is up to the team to decide which methodology or terminology to use. Extreme Programming (XP) uses the terms User Stories or Stories to represent features; Scrum uses Product Backlog to describe a feature list; Feature-Driven Development uses Feature; and DSDM uses Requirement. Similarly, there are various lightweight versions of the Unified Process, or Agile UP, that use Requirement and/or Use Case to define incrementally deliverable functionality. Ultimately, the goal is the same - to deliver business value regularly in small increments, and sooner rather than later.
Velocity is an extremely simple, powerful method for accurately measuring the rate at which scrum development teams consistently deliver business value. To calculate velocity of your agile team, simply add up the estimates of the features, user stories, requirements or backlog items successfully delivered in an iteration.
There are some simple guidelines for estimating initial velocity of your Scrum team prior to completing the first iteration (see FAQ's below), but after that point you should use proven, historical measures for planning features. Within a short time, velocity typically stabilizes and provides a tremendous basis for improving the accuracy and reliability of both near-term and longer-term planning of your agile projects. Agile delivery cycles are very small so velocity quickly emerges and can be validated very early in a project and then relied upon to improve project predictability.
Code obfuscation is transforming a software program into code that’s difficult to disassemble and understand yet maintains its original functionality. In this way, the software remains completely functional but extremely resistant to reverse engineering and tampering attacks.
App security refers to the practices and policies that shield high-value mobile applications from reverse engineering, tampering, and other app-centric attacks. App security includes application hardening to obscure code, runtime application self-protection (RASP) and self-healing measures, White-Box Cryptography to encrypt critical data & keys, and real-time app threat telemetry for closed-loop threat intelligence as the original. In this way, the software remains completely functional but extremely challenging to reverse engineer.
Application hardening is a process of taking a finished application and making it more difficult to reverse engineer and tamper. Combined with secure coding practices, application hardening is a best practice for companies to protect their app's IP and prevent misuse, cheating, and repackaging by bad users.
Code Refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior. Agile teams are maintaining and extending their code a lot from iteration to iteration, and without continuous refactoring, this is hard to do. This is because un-refactored code tends to rot. Rot takes several forms: unhealthy dependencies between classes or packages, bad allocation of class responsibilities, way too many responsibilities per method or class, duplicate code, and many other varieties of confusion and clutter.
Every time we change code without refactoring it, rot worsens and spreads. Code rot frustrates us, costs us time, and unduly shortens the lifespan of useful systems. In an agile context, it can mean the difference between meeting or not meeting an iteration deadline.
Refactoring code ruthlessly prevents rot, keeping the code easy to maintain and extend. This extensibility is the reason to refactor and the measure of its success. But note that it is only "safe" to refactor the code this extensively if we have extensive unit test suites of the kind we get if we work Test-First. Without being able to run those tests after each little step in a refactoring, we run the risk of introducing bugs. If you are doing true Test-Driven Development (TDD), in which the design evolves continuously, then you have no choice about regular refactoring, since that's how you evolve the design.
Deployment automation enables software deployment to testing and production environments automatically with a single action. Automation in software deployment reduces risks for production deployments and provides efficiency in release pipelines.
The Ultimate Guide to DevOps in 8 Foundational Concepts
Are you trying to get a better handle on what is DevOps? Here are the eight foundational concepts you have to know!
DevOps has become an overloaded buzzword that means a lot of different things to a lot of people. That's a challenge when you are trying to understand what DevOps is or define DevOps. Instead of trying to define DevOps, we are going to describe the foundational concepts that different people associate with DevOps and the history of how the DevOps movement evolved to help you get a holistic view:
An Enterprise App Distribution platform allows organizations to securely deploy and manage policy-enabled mobile apps through a variety of distribution methods, including direct links to users, a corporate portal, a private app store, or MDM/EMM systems.
An Enterprise App Store is an HTML or native iOS, Android, or Windows private app catalog for mobile workers in the extended enterprise to discover and download corporate-sanctioned and secured mobile apps. A best-of-breed enterprise app store is custom-branded, solicits feedback and ratings from users, does not require device management, and sits on top of an easy-to-use admin console that secures any app and supports the full app lifecycle.
Kanban is a method for managing the creation of products with an emphasis on continual delivery while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively.
Mobile Application Management (MAM®) refers to the workflow for security, governance, and distribution of mobile apps in the enterprise. Best-of-breed app management provides app-level security for any app, deploys apps to every user in the extended enterprise because it is device management agnostic, manages the complete app lifecycle, and enables multiple app distribution methods, including an intuitive, custom-brandable enterprise app store.
Release Orchestration is the process of orchestrating the activities required to deliver an application from code commit to production, enabling organizations to manage and optimize the flow of value across the DevOps value stream. Release Orchestration automates many tasks that are often done manually by release management. With Release Orchestration, DevOps teams are able to model software delivery pipelines, coordinate automated tasks with manual work, integrate a variety of tools for building, testing, and deploying software, and use data to identify bottlenecks and areas for potential areas for improvement.
Release Orchestration is also known as Application Release Orchestration (ARO), Application Release Automation (ARA) or Continuous Delivery and Release Automation (CDRA).
A release pipeline is made up of the manual and automated steps needed to move a code change from development, through build and test activities, to deployment in production. Manual steps can be executed by technical team members or business stakeholders and include both release processes and approval gates. Automated steps are executed by the tools within the DevOps landscape.
Digital.ai’s application and mobile app protection solutions go beyond Runtime Application Self-Protection (RASP) by providing layered and adaptive app protection and data encryption ensuring apps are protected against run-time attacks, are defended against reverse engineering, and are able to maintain secure communications with key encryption.
Use Scrum Project Management to Deliver Working Products with More Business Value Scrum project management is a methodology for managing software delivery that comes under the broader umbrella of agile project management. It provides a lightweight process framework that embraces iterative and incremental practices, helping organizations deliver working software more frequently. Projects progress via a series of iterations called sprints; at the end of each sprint the team produces a potentially deliverable product increment.
Agile teams often find that the closer the unit test coverage of their code is to some optimal number (somewhere between 75% and 85%, many teams find), the more agile their code is. Which is to say, it is easier for them to keep the defects in the code to very low levels, and therefore easier for them to add features, make changes, and still deliver very low-defect code every iteration.
After experimenting with different ways to keep test coverage up at those optimal levels, agile teams hit upon the practice of Test-First programming. Test-First programming involves producing automated unit tests for production code, before you write that production code. Instead of writing tests afterward (or, more typically, not ever writing those tests), you always begin with a unit test. For every small chunk of functionality in production code, you first build and run a small (ideally very small), focused test that specifies and validates what the code will do. This test might not even compile, at first, because not all of the classes and methods it requires may exist. Nevertheless, it functions as a kind of executable specification. You then get it to compile with minimal production code, so that you can run it and watch it fail. (Sometimes you expect it to fail, and it passes, which is useful information.) You then produce exactly as much code as will enable that test to pass.
Value stream mapping is a Lean-Agile management tool that helps organizations visualize the process steps needed to take a product from creation through delivery to end users. Value stream mapping helps you understand your business better so you can eliminate waste and improve process efficiency.
Scrum is an agile project management methodology or framework used primarily for software development projects with the goal of delivering new software capability every 2-4 weeks. It is one of the approaches that influenced the Agile Manifesto, which articulates a set of values and principles to guide decisions on how to develop higher-quality software faster.
White-Box Cryptography uses encryption, obfuscation, and mathematical transformations to secure keys and critical data inside applications running in untrusted environments. Common practice is not to assume cryptographic keys will be stored in untrusted environments, making them vulnerable to application attacks, such as reverse engineering.