Here is what I think
Thursday 16 May 2013
Social Gaming : Changing face of Computer Games
Social gaming has brought in a huge change in the pattern of computer gaming in the last 5 years or so. There used to be a time during our college days when people were crazy about Car racing games (like NFS) or War games (like Call of Duty). Unfortunately these games were popular only among a age group and section of the society.
Social gaming has brought in a huge inclusion of people including senior people, college goers, kids, housewives etc.
The console based video games market has lost the market considerably to the mobile game market.
One of the key reasons for its popularity is that this is a much relaxed form of a game and does not need you to do lot of things in rush. It does not require much concentration and so can be a quick way of relaxation.
Facebook games make the user experience much better and easy to understand for everyone. There is no disadvantage of starting late in such games and one can catch up very fast with one's peers.
People can form a group of friends who can help each other and get benefited Instead of being possessive to not provide any help to others, people tend to share things to advance in the game.
The interactive dashboard makes everyone competitive with their peers. The games are very very easily accessible and does not need any high configuration/resolution hardware.
Researches say that more than 80 million people play social games atleast once a day and around 50 million play multiple times a day.
Farmville & Mafia Wars are still the most popular games in US & UK.
Casino related games like Casino, Soloto mania are the most popular so far followed by Hidden object games like Gardens of Time, Criminal Cases etc.
Role playing games like Zombie Lane also are very popular among people.
The primary developers are Zynga, EA, Woonga etc with various products for various choices & options.
Friday 28 December 2012
Smarter Release Management with Continuous Integration & Continuous Delivery
About this Article
Continuous Integration and Continuous
Delivery
What facilitates the process
Benefits
Core principles of the Practice
1.
Continuous Integration – across sites and
timezones
2.
Continuous Delivery – to the “remote” customer
Conclusion
This white paper aims to help readers
understand Continuous Integration and
Delivery as a concept and practice in software development projects that
follow the Agile methodology.
The content organization is as follows:
- The first section explains the benefits of the model.
- The next section describes the processes to be established for Continuous Integration and Continuous Delivery.
- The conclusion summarizes how Agile methodologies involving Continuous Integration and Continuous Delivery can help improve considerably the customer/market readiness of product releases.
Continuous Integration and Continuous
Delivery
Releasing software is a complex and at times arduous process,
well known for compelling already overworked professionals to extend their workdays/nights and weekends to ensure that the release is made. It always tends to become a stretched
effort despite project scheduling and task estimates.
Over time we realize that
the stretch and slippage is because of multiple factors which can be
categorized as known knowns and known unknowns that inevitably surface in the
course of a release.
Continuous Integration
and Continuous Delivery is a practice recommended by the Agile software development
methodology which has been able to deal with some of the traditional challenges
of development to help product teams optimize and create a streamlined
iterative release management process
that is predictable to a large extent.
What facilitates the process
Mindset of Minimum
Viability: In Continuous Integration
and Continuous Delivery we develop a small but fully functional feature-set
rather than sweat over an ambitious list of features that inevitably results in partially functional and often a buggy release.
The key is to change the mindset of the team. Every team member needs to
understand that the customer needs a set of completely working features rather
than a big list of partially functioning
ones.
Right size Rule: Y.A.G.N.I. or the You ain’t
gonna need it principle helps make the change. During product development
the team should question and challenge the premise of the release so that we
arrive at the “right size” of the release that
meets the customer’s expectations of the product.
Benefits
Product watchers have found that typical user communities use only a part of a
product’s feature set. For instance, survey statistics indicate that 90% of MS
Word’s user community uses just about 10% of its functionality. Hence it is
very important to develop the right set of functionality and release to the
customer when they need it. The benefits of this approach are multifold.
·
Faster
go-to-market
Agile teams are better equipped to make
interim, small and more impactful releases to meet the needs of customers/market as compared to non-agile teams.
·
Smart
Product Backlog Management
Features and releases can be made available
as per the request and need of customers, and yet at the same time product teams
can continue work on their planned monthly or quarterly releases.
·
Real time response to Customer issues
Value and viability of a product’s
features cannot be realized until the product is delivered to the customers for
their use. If delivery and usage is established in cyclic and short time frames
the feedback-response cycle can be addressed in almost real time.
The continuous delivery model helps to get iterative and quick feedback from
the customers as to what is right, what is wrong and what they really want
features to do. By this Agile method, instead of building the whole product we
build the smallest possible useful part and give it to users, for validation.
·
Customer Delight
In the Agile development model, incremental
cycles of two to four weeks of development and delivery enable the development
team to release what one can term as the
Minimum Viable Product (MVP) or Minimum Marketable Features (MMF) within
projected timeframes. Meeting customer friendly deadlines in this manner
indicates that product releases when driven by customer needs leads to a higher
level of customer satisfaction.
·
Investing
in the right areas
One of the real challenges in developing software products
is to ensure investments both monetary and effort are channeled in the right
direction.
The Continuous Integration and
Delivery model helps mitigate the risk that
comes with the question “Are we building the right product?” to a large
extent. Since this methodology is
inherently nimble it enables immediate course correction in terms of ensuring
the right features are released to customers. Figure1, gives picture of the
itirative processes which form the complete cycle.
Figure 1 (Source: http://www.collab.net/solutions/devops)
·
Minimal
risk of failure
It is important to have the features ‘Production ready’ always, even after changes are
made to the code, database or configuration. Incremental development, testing
and release
reduces the quantum
of ‘untested’ or ‘unreleased’ features as illustrated in Figure 2. This not
only makes it easier to control the quality of the deliverable but also enables
easier roll back to the pre-change state, in case of failures.
Figure 2 (Source:
http://www.collab.net/solutions/devops)
Core principles of the Practice
1.
Continuous Integration – across sites and
timezones
The essential requirement
here, for the multi-function teams –
development, testing and documentation, is that the features are
continuously built, tested and integrated. This process also supports teams
working in multiple geographical locations and across time zones to effectively
collaborate and deliver fully functional releases.
·
Test as
you develop the product
The cost of quality of any software product is closely tied to the time of finding errors
in its functioning. In other words, for every bug detected early in the
development process, the cost of quality reduces dramatically.
In a
typical waterfall project we get to the testing phase in a sequential manner after the
development phase is completed. This not only delays the point of catching defects but
also increases the impact of the bugs in the form of re-work which in turn
impacts delivery schedules. One way to mitigate the risks of increase in cost
of quality and impact due to missed deadlines, is that testing should go hand-in-hand
with development.
The
question is can this be done? Figure 3 explains the process flow which can help
to resolve this issue.
The
key is to continuously integrate development and testing activities in a manner
that enables software to get tested incrementally along with development so that the issues get detected and fixed at the earliest.
·
Automate
the Build process
For product testing to be in synch with development so that it is effective,
the QA team has to have their test environments (also
known as the QA Build) ready at any
point in time to be able execute their test cases. The key requirement here is to have a process that “builds
and delivers” the QA Build on a
regular basis. Automating the build creation process becomes
key in order to ensure that the QA Build is ready for deployment well before the QA team is ready to start
testing. Further, this automation also releases considerable amount of time for
developers to focus on core development activities as opposed to tasks
associated with the process of packaging and building the release for testing.
Ready to use build-automation applications can be used to establish such an
automated build mechanism.
For
the purpose of this paper, we refer to the following tools:
·
Microsoft
Unit Testing framework – used to execute automated service testing for every
check-in
·
FinalBuilder
– used to automate the generation of a daily build. Figure 4 shows a snapshot
of FinalBuilder setup.
Figure 4
·
Build the
product on every code commit
For build-automation to be successful, integrity of the code-base
has to be such that the software product
can easily be compiled without any error. The bigger the code base the higher
the risk of integrity-loss and error free build.
For example, in a team of 40+ developers if every developer encounters even an
hour of code-integrity related issue it leads to a 40 hour loss in
productivity. It is therefore very important that every piece of code written, is checked-in
or committed to the main baseline at least once in a day so that the next build can reflect the updates.
Use
of the testing frameworks such as Microsoft
Unit Testing framework to execute automated service testing, helps ensure
that the impacted services work as expected with every check-in. A snapshot of
such unit test configuration is given in Figure 5.
Figure 5
The build-automation
process must trigger a build after every commit to the main baseline code base
and it must also ensure that there are no build related issues after every
check-in/commit.
Tools such as FinalBuilder reports check-in issues to
the concerned developer. An integrated messaging and reporting system built
into it reports build-failures to a team
of build owner(s). As a result the build owner(s) can immediately log in (even
from home) to resolve the reported
issue, thereby minimizing the risk of non-availability of the QA Build for the testers on any given
day. This particular ability allows distributed agile teams to work effectively
withou any loss of time due to possible time zone issues. The QA team starts
every day by installing a fresh build to carry forward product testing.
Automating a timed-install of the QA Build can make it even better by freeing
the time spent in manual installation for testing.
·
Automating
regression testing
The Scrum model usually discourages manual regression testing. This is
because in a development cycle defects
are expected to be fixed and closed during the scrum cycles – known as sprints. There is no room for defects to
creep to a ‘regression test cycle’ in this methodology. In real practice
however, despite incremental development and testing there can
be integration or system level issues that necessitate additional testing. Assigning
resources to such testing can lead to unavailability of testing bandwidth for the planned sprints. The recommended practice
to minimise time and resource investment
for regression testing will involve the following steps
o
learning from the previous regression cycles
o
identify such defects or patterns of defects
o
set up automated procedures for testing them
o
run the automated procedures regularly to test
the stability of critical functionality
·
Simulate a
production-like environment for daily testing
Considerable time and effort is spent by developers and testers trying to
replicate reported defects It is therefore
very important to simulate the real-time environment to enable effective
testing of software. For all practical
purposes, there should be a production like environment that mimics the actual
set up at the customer site. This allows
the QA team members to not just catch the functional issues but also test the environment or installation related parameters
as well.
2.
Continuous Delivery – to the “remote” customer
The essential requirement here is to deliver to the
customer who is “remote” in relation to the development teams.
·
Delivery
Pipeline
The Continuous
Integration processes both manual and automated, create a pipeline of steps where one process
or step waits for the previous one to be
complete.
If not well planned, this approach poses the risk that it will not be possible
for the product team to optimize the time for complete deployment. This
situation as illustrated in Figure 6, is termed as ’Insufficient Parallelization’.
Figure
6 (Source: Continuous Integration, Martin Fowler
& Jez Humble)
The most preferred way to
overcome this is to make the pipeline as wide and short as possible. Conscious effort has to be made to eliminate
the risk of queuing up the processes. Figure 7 illustrates how to bring
in parallel processes to decrease the waiting time for deployment.
Figure 7 (Source:
Continuous Integration,
Martin Fowler & Jez Humble)
·
Automated
Continuous Deployment
Continuous Deployment is a part of
the Continuous Integration and Continuous
Delivery process where every build gets deployed into a production like environment. This environment can be used by the QA team or even
the customers. Any such deployment can happen easily with an automated process
in considerably less time as compared to manually deploying the application
components.
With
the latest software always
made available to customers for exploration
and use at their own time it has given them great flexibility to use and validate regular
releases.
·
Automated
Acceptance Test
Acceptance Testing (AT) is very much a relevant process that
contributes tremendous value in the
development and release phases. It is the most effective way to know if the
software is meeting the objectives of the customer . It answers the question-
are we building the right product?
Teams
create one or more AT for each user story
to ensure that the feature works per expectations. The acceptance test process is
automated with the test results made visible to the stakeholders. As active stakeholders,
customers are responsible to check the
results and set the priority for resolution of the reported cases. Ultimately it
is the responsibility of the development team to allocate time to correct the features that have failed the acceptance tests.
Conclusion
In today’s world customers
are not prepared to wait for long time-frames to receive features and then find
out that the product is only partially meeting their needs. This has intensified
the challenge for software development
organizations to find ways to deliver periodic releases as and when the
customers want.
We believe Continuous Integration and Continuous Delivery
is gaining more acceptance in the industry because of its capacity to enable
teams to deliver solutions of value, in considerably shorter timeframes.
Industry studies report that
most organizations take to Agile methodologies very well in the engineering phase
but almost always follow a more tradtional release plan of doing a few fixed
releases a year. Here again, Continuous Integration and Delivery can
help release well tested list of features in small bit sized chunks that lead
to greater adoption by customers . There are industry figures that indicate
upward of 80% improvement in testing and
release effectiveness, when this methodology was deployed.
The approach being very
much customer centric ensures that the
customer is co-opted into the development process, and results in an inherent
commitment on the part of the customer to adopt the product and use it. This leads to a win-win relationship both for
the customer as well as the vendor developing the software.
References:
1.
Rapid Development: Taming Wild Software Schedules, Steve
McConnell, Microsoft Press, 1996.
2.
Continuous Integration, Martin Fowler & Jez Humble
7.
http://www.collab.net/solutions/devops
Subscribe to:
Posts (Atom)