What separates pipe dreams from products that people love, want to buy and use, is execution - we've outlined our agile software development process so that execution won’t stand between you and a successful product or service.
Once the requirements are known and you have completed the visual design, you are ready to begin development. This is where you actually start defining the technology architecture and writing the code that will bring your vision to life.
Full write-up: https://by.dialexa.com/breaking-down-our-agile-software-development-process
Our Agile Software Development Process – System Architecture to Development Cycle
1. Our Agile Software Development Process –
System Architecture to Development Cycle
by Samer Fallouh
https://by.dialexa.com/breaking-down-our-agile-software-development-process
2. Dialexa
We are on a mission to make every
company a great technology company.
We work with organizations to define and
execute digital transformation strategies to
improve business operations and customer
experiences. Our services include:
• Multi-Year Technology Roadmap
• Platform Engineering
• User Experience Design
• Custom Software Development
• Hardware Prototyping /IoT
3. What separates pipe
dreams from
products that people
love, want to buy and
use, is execution -
we've outlined our
agile software
development process
so that execution
won’t stand between
you and a successful
product or service.
Get the full write up of
this slideshare HERE
4. Once the requirements are
known and you have
completed the visual design,
you are ready to begin
development. This is where
you actually start defining
the technology architecture
and writing the code that
will bring your vision to life.
Get the full write up of
this slideshare HERE
5. What is System Architecture?
Get the full write up of
this slideshare HERE
6. Before code comes system
architecture. As the name
implies, it’s somewhat
analogous to building a
physical structure. You
would be ill-advised to start
hammering without
understanding how all the
boards are going to fit
together to support the
house you’re going to live in.
Get the full write up of
this slideshare HERE
7. When it comes to technology, those
boards and nails are analogous to the
technologies you’re going to use and
where the system will reside.
Get the full write up of
this slideshare HERE
8. To read more you can find the full article at
https://by.dialexa.com/breaking-down-our-
agile-software-development-process
10. In the software engineering
world, there are multiple
development methodologies
with names like Waterfall,
Spiral and Agile, and each
has its strengths and
weaknesses. However, Agile
has evolved into the de facto
standard in most modern
development environments
— especially when starting
a new development project.
Get the full write up of
this slideshare HERE
11. There are many reasons for Agile’s popularity in
technical circles, but they can all be traced back to
the reality that programming isn’t predictable and
repeatable in the same way as building a car or a
structure. The process for developing technical
products must adapt and evolve as unknowns
become knowns. Agile allows for quick iterations and
feedback so that this adaptation can occur.
Get the full write up of
this slideshare HERE
12. Like project management itself, Agile comes
in a number of flavors, such as Extreme
Programming (XP), Kanban and Scrum.
Let me elaborate more on Scrum.
Get the full write up of
this slideshare HERE
13. The general idea is to break a
project down into granular
pieces and assign a point value
to each, which in turn
translates into a relative
increment of time. For example,
if we plan on an engineer
having 40 hours of productive
time per week, and we assume
that each point equates to two
hours of effort, then we can
assign this engineer 20 points
per week. If the project is 200
points, then we can estimate
that we’ll be done in 10 weeks.
Get the full write up of
this slideshare HERE
14. As already mentioned, software development isn’t as
linear as other complex processes, so the actual
process never works out quite as it’s laid out, but
going through the Scrum exercise does provide an
idea of what a realistic timeline looks like.
Get the full write up of
this slideshare HERE
15. Development consists of
multiple time-boxed iterations
that incorporate planning, coding
and testing. These timeboxed
iterations are known as sprints,
and they typically last two to
three weeks.
Get the full write up of
this slideshare HERE
16. Perhaps the biggest advantage of taking this
approach is that breaking the project down into bite-
sized pieces allows the team members to see
progress on a very consistent basis and evaluate the
direction as they progress.
Get the full write up of
this slideshare HERE
18. The process starts with backlog planning, which happens
once and sets the direction for the development phase. The
backlog simply is a list of desired features; it begins with the
team, including all product stakeholders, engineering and
design resources, documenting all features and user stories.
Get the full write up of
this slideshare HERE
20. After the backlog
creation the items
are prioritized and
estimated, and the
resulting list forms
the basis of the work
scheduled for each
sprint. The prioritized
backlog creation is
then used to set the
objectives for the
upcoming sprints.
Get the full write up of
this slideshare HERE
21. You want enough items
in each sprint to fit the
time box without
overloading each sprint.
Items can be added to
the backlog at any time
during the development
cycle, but the additions
will only be reviewed at
the appropriate times
during the sprint. The
idea is that you don’t
want to continually
create a moving target
in mid-sprint.
Get the full write up of
this slideshare HERE
22. Create what your users need, not what
your company wants.
Download or free eBook:
The Dialexa Guide to New Product Development
Process for Software
23. Your 10-day Development Cycle
The development cycle consists of
multiple sprints. Each sprint follows a
predetermined schedule that looks
something like this:
Get the full write up of
this slideshare HERE
24. Day 1 – Development Planning/Architecture
The development team meets to discuss the
features assigned to the sprint. The features
are assigned to the individual resources, and
any design/architecture tasks required to
complete the features are performed. Many
times, features are directly lined up to user
stories.
Get the full write up of
this slideshare HERE
25. Days 2-9 – Build
The development team works through the assigned tasks to
complete the features. Coding, unit testing and internal
quality assurance testing occur for each feature. The goal is
to complete all of the features assigned to the current sprint.
Get the full write up of
this slideshare HERE
26. Day 3 or 4 – Demo of Previous
Sprint
The development team
demonstrates the results of the
previous sprint. This is a live
demonstration that focuses only
on what has been delivered in
the previous sprint. The idea is
to be able to frequently gauge
progress and fix issues quickly
as they occur. Of course, there
may be very little to show
initially, but the product will
begin taking shape over time.
Get the full write up of
this slideshare HERE
27. Day 3 or 4 – Backlog
Grooming
The project manager meets
with the development team
to discuss the current
backlog list for each sprint.
The list is reviewed for
content and estimation, and
further clarification of
backlog items may be
necessary. Estimates may
also change based on what
we learn from completed
sprints. Finally, any new
features may be added,
prioritized and estimated.
Get the full write up of
this slideshare HERE
28. Day 10 – Agile Sprint Planning and Reprioritization
At the end of each sprint, the team reconvenes to review the
priorities of the backlog list. Based on the new priorities and the
velocity of the completed features in previous sprints, the
appropriate backlog items will be scheduled for the next sprint.
Get the full write up of
this slideshare HERE
29. Getting Ready for Deployment
Once the product is ready to test with real
users, the release candidate, as it’s called,
must be deployed to an accessible location.
How that works varies depending on whether
the program is a mobile app, a Web app, a
desktop app or other.
Get the full write up of
this slideshare HERE
30. Over the course of the development
cycle, the code lives in various places,
but the two most important
environments are development and
staging, and both are designed to
replicate the environment to which the
application will eventually be deployed
— also known as the production
environment — as closely as possible.
Get the full write up of
this slideshare HERE
31. When it’s time to deploy a version of the product,
the development team does so by moving that
version to the staging environment for the
specified users to access. Typically, this would
initially be done to let some early, “alpha” users
provide feedback and to log any bugs that
weren’t identified in quality assurance testing.
Any bugs found will be incorporated into the
backlog and prioritized as described above.
Get the full write up of
this slideshare HERE
32. Once a release candidate is approved for release to
production, the development team packages it for
production deployment.
Get the full write up of
this slideshare HERE
33. One Final Piece of Advice
We strongly recommend that the production environment, or stack, reside
on the same infrastructure as the staging stack in order to minimize the
number of variables. The less homogeneous the entire stack is, the more
likely you are to experience strange behavior and the more difficult it will
be to troubleshoot when you do.
Get the full write up of
this slideshare HERE