![](bg3.png)
can be used during application development. The API
updates status periodically and whenever there is a
change in the charge and/or the temperature of a bat-
tery or not (typical frequency of the updates ranges
between 0.25Hz to 4Hz (Zhang et al., 2010)).
Hence, the measurement type and the data coming
via API about energy consumption require from mo-
bile application developers to follow one of the fol-
lowing three major approaches: utilization-based en-
ergy requirements (Zhang et al., 2010), event-based
energy requirements (Pathak et al., 2011), and the
ones based on code analysis. The first and the sec-
ond approaches to requirement specification needs a
real device to run an application. Thus, for our study
the third approach is more relevant. This approach
relies on the analysis of the program code to be exe-
cuted. The approach is exemplified, for instance, as
an instruction-level model, which works by relating
the power consumption of a piece of code with each
instruction executed. This requires the evaluation of
power consumption for each of the instructions of the
software considered. Clearly, this can be applied at a
level of functions, procedures, or subroutines.
Selecting a proper energy profiler forms another
requirement for mobile development. The models and
approaches described above have been implemented
in the on-device profilers such as Sesame(Dong and
Zhong, 2011), PowerBooter(Zhang et al., 2010), V-
Edge(Xu et al., 2013) etc. The choice of a profiler
for a typical developer is not straightforward. Along
with their accuracy, other requirements are important,
including availability, hardware support, ease of use
and installation, and expertise of the developer.
Additionally, there are requirements related to the
privacy issues. As it is discussed in (Diamond et al.,
2018) collecting data about energy consumption (ei-
ther of the device as a whole or in an application)
can clearly cause privacy concerns. Thus, a devel-
oper of the mobile energy-efficient application should
consider such requirements as transparency, appropri-
ation and security in the usage of the energy consump-
tion data.
3 DESCRIPTION OF THE
EXPERIMENTAL SETTING
3.1 Situation That Induced the Change
During several years traditional Banking sector in
Russia has been suffering from aggressive com-
petition with FinTech companies providing game-
changing easy-to-use financial products to customers.
Ak Bars Digital Technologies (ABDT) was founded
in October 2016 in response to this process.
First product teams were created as soon as the
company was established. The development process
in the teams was based on Scrum framework de-
scribed in Scrum Guide
2
. All teams in the company
incorporates all mandatory events and artifacts pre-
scribed by Scrum.
There were several reasons to use Scrum as a pro-
cess framework. Firstly, developing digital product is
a complex task due to high level of uncertainty and
a lot of dependencies between systems and compo-
nents (20 main systems and 2 mission-critical devel-
oped in parallel by different teams inside and out-
side the organization). Secondly, there are no stable
requirements: they constantly change in response to
new requests from customers, implementation of new
features by competitors and claims of government in-
stitutions. Finally, the product should be developed in
a competitive environment, thus fast delivery of new
versions of a product and adaptability are extremely
important. Taking into account these issues choosing
Scrum is looking quite reasonable: Scrum is based on
the empirical process, which allows to identify and
tackle emerging problems in a rapid pace. It creates
framework, inside which teams could establish their
own process that satisfies their needs.
In this article we analyze the process in one prod-
uct group that develops Ak Bars Online system which
provides banking and financial services for customers
among various digital platforms. The whole product
group consists of 8 cross-functional agile teams and
Product management team. Two of these agile teams
includes vendor developers who works by out-staffing
agreement. Agile teams use Scrum framework and in-
clude from 5 to 10 developers. By “developers” we
mean all people who analyze, design, implement and
test the system. In total the product team includes 65
people, among them: 11 back-end developers, 5 iOS
developers, 5 Android developers, 3 web developers,
12 QA-engineers, 4 user interface designers, 2 sys-
tem analysts, 2 site reliability engineers, a system ar-
chitect, a data scientist, an UX expert, an application
security expert, 5 outstaffing specialists and product
management. The product management includes a fi-
nancial expert, a web analyst, marketing and content
experts. Also we have 5 Product Owners and three
Scrum Masters. Due to lack of Some Scrum Masters
and Product Owners work with several agile teams
due to lack of the competences on the market.
The product group develops Android, iOS, web
applications and back-end using SOA (service-
2
https://www.scrumguides.org/docs/scrumguide/v2017/
2017-Scrum-Guide-US.pdf
ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering
524