Project Management CTC-ITC 310

Fall 2018Howard Rosenthal

Notice� This course is based on and includes material from the text:

A User’s Manual To the PMBOK GuideAuthors: Cynthia Stackpole SnyderPublisher: WileyISBN: 978-1-118-43107-8, Copyright 2013

� It also utilizes general information and figures from the PMBOK: A Guide to the Project Management Body of Knowledge (PMBOK 5TH Edition) Publisher: Project Management InstituteISBN: 978-1-935589-67-9, Copyright 2013 and

A Guide to the Project Management Body of Knowledge (PMBOK 6TH Edition) Publisher: Project Management InstituteISBN: 978-1-628251-84-5, Copyright 2017

� The course also includes and intersperses some materials, most often diagrams, provided by Mr. Wysocki’s PowerPoint slides, at the website:www.wiley.com/go/epm7eAnd the bookEffective Project Management - Traditional, Agile, Extreme 7TH EditionAuthors: Robert K. WysockiPublisher: WileyISBN: 978-1-118-72916-8, Copyright 2014

2

Lesson Goals

� What are the immutable processes in any project� What are the different project management models

� Traditional Project Management (TPM)� Agile Project Management (APM)

� How do you pick the best lifecycle models within a project management framework� Predictive� Iterative� Incremental� Agile-Adaptive� Adaptive and Agile are often used synonymously in the

PMBOK� Describe Development-Operations (DevOps)

3

4

Project Management Processes and Phases� A Project Management Life Cycle is a series of processes that include:

� Initiating Process� Planning Process� Executing Process� Monitoring and Controlling Process� Closing

� A project phase, which culminates in one or more deliverables, will go through each of the above steps at least once.

� Various project phases that are used in a product include some or all of the following:� Concept Development� Feasibility Study� Requirement Development� Prototyping� Architecture and Design� Deployment� Closure

� A project phase includes:� Name� Duration� Resource requirements� Entrance and exit criteria

� The order of the steps and the number of iterations/increments/cycles depends on the life cycle that is chosen

5

Definable Work vs. High-Uncertainty Work

� Project work ranges from well defined to highly uncertain

� Different life-cycle models may be employed based on the degree

of uncertainty

� Example of well defined work may include those with

reproducible processes and outcomes

� Installing new wiring or computer systems using off-the-shelf

products

� Mass production of Army boots

� High-uncertainty projects have less well-defined requirements,

require technical advances, or are subject to changing priorities

� Building a space telescope

� Creating the first iPhone

� Implementing upgrades and new features in an IT project amidst

changing priorities and limited resources

� Changing weapons design as battlefield conditions evolve (i.e.

Humvee design)

6

Project Management Life Cycles� A project lifecycle is the series of phases that a project passes through

from start to finish.� Phases may be sequential, repetitive or even overlapping

� The PMI defines four life cycle models� Predictive life cycle

� A traditional approach with most planning occurring before the actual development begins. The waterfall model is the best example

� Iterative life cycle� Allows for feedback and modification during the development to improve the

product before it is released� Incremental life cycle

� Finished deliverables are provided and then a new increment starts over.� Agile life cycle (sometimes called adaptive)

� An approach that refines work and delivers new capabilities on a regular basis. Similar to Incremental but more rapid turn around.

� The development team gets early feedback and interacts with customer on a continuous basis to obtain feedback.

� Early return on investment helps keep the project going.� Hybrid life cycles are a combination of the above life cycles

� Most projects aren’t completely pure� The type of project you are working on will impact the type of

management life-cycle approach that you adopt

7

Planning Is A Part Of Any Life Cycle� Much of project management involves planning� Every life cycle model requires planning

� The difference between life cycles is how much planning is done, and how often it is done

� Predictive� Most planning is done once, up front� Plan drives the work� Requirements are all defined up front

� Iterative� Includes prototypes and proofs that may lead to modification of the original

plan� However there is still one big delivery at the end

� Incremental� Actual deliveries are planned in advance, perhaps one at a time or in succession� Goal is to deliver pieces of the project for an initial use or some other reason

� Agile� The key difference here is the team plans and replans at the end of each cycle. � The cycles are usually very short� The next delivery will be determined based on project priorities and available

resources

8

Project Management Types and Associated Life Cycles� There are two different Project Management Types

that employ different life cycle models� Tradition Program Management (TPM) —Predictive

and Iterative Life Cycle Models� Used when the goal and solution are clear� 20% of all projects� Example – Install a network in a building

� Agile Program Management – Incremental and Agile Life Cycles Models� Used when the goal is clear but the solution is not� Used when the final goal is changing so that the solution must

evolve due to market changes, technological advancement, business needs, etc.

� 80% of all projects� Example – Send a crew of 5 to Mars and return them safely to

Earth before 2030

9

Picking The Correct Life Cycle Model

10

PMBOK V6 Agile Fig. 2-5

The Life-Cycle Continuum

11

PMBOK V6 Agile Fig. 3-1

Differences In The Project Life Cycles

12

PMBOK V6 Agile Table 3-1.

13

Traditional Program Management (1)

14

Predictive Life Cycle Model

Characteristics Of Good Use Of The Predictive Life Cycle

• Well understood and defined requirements with constraints identified

• Serial execution of the project in accordance with the plan

• Lower complexity • Low risk

• Widely used • Experienced and skilled project teams

• Well-understood technology infrastructure

• Should not be used for research or development projects

• Leader minimizes change during the project

• Changes can lead to unanticipated costs

PMBOK V6 Agile Fig. 3-2

Traditional Program Management (2)

15

Iterative Program Management Life Cycle Model

Characteristics Of Good Use Of The Iterative Life Cycle

• Successive prototyping • Prototyping leads to lowered risk during development

• New information incorporated based on learning experience

• Experienced and skilled project Teams

• Recognizes the complexity of some projects and identifies and solves unknowns iteratively

• Still has a single plan up front, but it is more of an outline that is progressively elaborated as more data becomes available

PMBOK V6 Agile Fig. 3-3

Advantages And Disadvantages of TPM Projects� Advantages

� Easy to understand and implement.� Widely used and known (in theory!).� Reinforces good habits: define-before- design, design-before-code.� Identifies deliverables and milestones.� Document driven, User Requirements Document (URD), Systems

Requirements Document (SRD), ... etc. with published documentation standards

� Works well on mature products and weak teams� Disadvantages

� Idealized view� Doesn’t match reality well

� Doesn’t reflect iterative nature of exploratory development.� Unrealistic to expect accurate requirements so early in a project, especially a

large complex project� Often leads to cost overruns

� Replanning and rebaselining not included� Software is delivered late in project, delays discovery of serious errors� Difficult to integrate risk management� Difficult and expensive to make changes to documents,� Significant administrative overhead, costly for small teams and project

16

Differences Between The Predictive And Iterative Life Cycle Models� The predictive model holds the contractor’s feet to the fire

� Must live within baselined cost and schedule� No rework is expected

� The structure of the Iterative PMLC model encourages change based on experience� The initial release of a partial solution gives the client and the end

user an opportunity to experiment with the partial solution in a production scenario and find areas that could be improved encouraging change requests

� The full solution is decomposed into partial solutions whose development would then be implemented in a sequential fashion � However, there is “no replanning” in this model even though there will

undoubtedly be changes to the design and implementation based on the results of prior iterations

� The release schedule needs to be consistent with the dependencies that exist between each partial solution especially if there is parallel development

17

Classic TPM Is The Waterfall Model

18

The Waterfall In Reality

19

In reality there are almost always unknowns and changesThis leads to the potential to circle back at any step to a prior step in the life cycle

The V-Shaped Model Is A TPM Variation On The Waterfall

20

Advantages Disadvantages

• Higher chance of success over the waterfall model due to the early development of test plans during the life cycle

• Software is developed during the implementation phase, so no early prototypes of the software are produced

• Each phase has specific deliverables • Little flexibility and adjusting scope is difficult

• Simple and easy to use • Very rigid like the waterfall model

• Works well for small projects where requirements are easily understood

• This model does not provide a clear path for problems found during testing phases

The Spiral Model Combines The Traditional/Predictive Lifecycle Model With Prototyping – It Is Iterative

21

IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 5, September 2010 ISSN (Online): 1694-0814 www.IJCSI.org

99

x Spiral model sectors 1. Objective setting :Specific objectives for the phase are

identified. 2. Risk assessment and reduction: Risks are assessed and

activities are put in place to reduce the key risks. 3. Development and validation: A development model

for the system is chosen which can be any of the general models.

4. Planning: The project is reviewed and the next phase of the spiral is planned [1].

Fig. 7 Spiral Model of the Software Process[1].

x WinWin Spiral Model The original spiral model [Boehm 88] began each cycle of the spiral by performing the next level of elaboration of the prospective system's objectives, constraints and alternatives. A primary difficulty in applying the spiral model has been the lack of explicit process guidance in determining these objectives, constraints, and alternatives. The Win-Win Spiral Model [Boehm 94] uses the theory W (win-win) approach [Boehm 89b] to converge on a system's next-level objectives, constraints, and alternatives. This Theory W approach involves identifying the system's stakeholders and their win conditions, and using negotiation processes to determine a mutually satisfactory set of objectives, constraints, and alternatives for the stakeholders. In particular, as illustrated in the figure, the nine-step Theory W process translates into the following spiral model extensions: 1. Determine Objectives: Identify the system life-cycle stakeholders and their win conditions and establish initial system boundaries and external interfaces. 2. Determine Constraints: Determine the conditions

under which the system would produce win-lose or lose-lose outcomes for some stakeholders. 3. Identify and Evaluate Alternatives: Solicit suggestions from stakeholders, evaluate them with respect to stakeholders' win conditions, synthesize and negotiate candidate win-win alternatives, analyze, assess, resolve win-lose or lose-lose risks, record commitments and areas to be left flexible in the project's design record and life cycle plans. 4. Cycle through the Spiral: Elaborate the win conditions evaluate and screen alternatives, resolve risks, accumulate appropriate commitments, and develop and execute downstream plans [8]. 3.5 Extreme Programming

An approach to development, based on the development and delivery of very small increments of functionality. It relies on constant code improvement, user involvement in the development team and pair wise programming . It can be difficult to keep the interest of customers who are involved in the process. Team members may be unsuited to the intense involvement that characterizes agile methods. Prioritizing changes can be difficult where there are multiple stakeholders. Maintaining simplicity requires extra work. Contracts may be a problem as with other approaches to iterative development.

Fig. 8 The XP Release Cycle

x Extreme Programming Practices Incremental planning: Requirements are recorded on Story Cards and the Stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development "Tasks". Small Releases: The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release.

The Spiral Model Follows A Path That Leads To Requirements Discovery (1)� The new system requirements are defined in as much detail

as possible. � This usually involves interviewing a number of users

representing all the external or internal users and other aspects of the existing system.

� A preliminary design is created for the new system.� A first prototype of the new system is constructed from the

preliminary design. � This is usually a scaled-down system, and represents an

approximation of the characteristics of the final product.� A second prototype is evolved by a fourfold procedure:

� Evaluating the first prototype in terms of its strengths, weaknesses, and risks

� Defining the requirements of the second prototype� Planning and designing the second prototype� Constructing and testing the second prototype.

22

The Spiral Model Follows A Path That Leads To Requirements Discovery (2)� At the customer's option, the entire project can be aborted

if the risk is deemed too great. � Risk factors might involve development cost overruns,

operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.

� The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.

� The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.

� The final system is constructed, based on the refined prototype.

� The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

23

Advantages And Disadvantages Of The Spiral Model

� Advantages� High amount of risk analysis� Good for large and mission-critical projects� Software is produced early in the software life cycle

� Disadvantages � Can be a costly model to use

� Doesn’t work well for smaller projects � Project’s success is highly dependent on the risk analysis

phase� Risk analysis requires highly specific expertise

24

25

Agile Project Management (1)

26

Incremental Life Cycle Model

Characteristics

• A previously untapped businessopportunity

• Critical to the organization

• Early delivery of a partial solution – new features can be added later

• Meaningful client involvement isessential

• Initial deliverables planned at project onset – later deliverables defined as project evolves

• Use small co-located teams

ScopePlanIncrement

LaunchIncrement

Monitor & Control

Close Project

CloseIncrement

Next Increment

Yes

No

PMBOK V6 Agile Fig. 3-4

Agile Project Management (2)

27

Agile/Adaptive Life Cycle Model

Characteristics

• Really very similar to incremental

• Requirements not fully understood at outset

• Each Agile iterative/incremental cycle helps uncover new requirements

• Meaningful client involvement isessential

• Fulfills the Agile Manifesto (see next section)

• Customer satisfaction increases with early and continuous delivery of new value – this keeps the project sold

Comparing The Incremental and Agile/Adaptive Life Cycles (1)

� Incremental life cycles are ones in which project phases intentionally repeat one or more project activities as the project team’s understanding of the product increases� However, the entire scope of the project is defined up front

� The Incremental Life Cycle is used for projects where change in the scope needs to be managed � In this life cycle a plan is detailed for the near-term increments and a high level

vision is created for rest� New plans are detailed for each increment

� In this approach project phases proceed through sequential or overlapping modes in every increment

� Change during the project is naturally handled in upcoming increments � The end result is delivered at the end of each increment

� For instance, yearlong project will have 3 months increments and each increment will execute Planning, Analysis, Design, Code, Testing phases and deliver the result at the end of the increment

� The difference between the incremental life cycle and the adaptive/agile life cycle is that the increment life cycle allows for longer spans of time between deliveries, while each cycle in the adaptive life cycle is typically 2 to 4 weeks

28

Note: Remember that PMBOK and others use Agile and adaptive interchangeably at times

Comparing The Incremental and Agile/Adaptive Life Cycles (2)� Adaptive life cycles are intended to respond to high levels of

change and ongoing stakeholder involvement. � This life cycle is used for projects where changes are expected and

scope is not possible to define up front � In this life cycle model scope is decomposed into a set of

requirements known as product backlog and getting picked as per priority from the set in every cycle

� With this, project phases proceed through sequential or overlapping mode in every cycle (to distinguish from iteration)

� Change during the project is naturally handled in rapid cycles. The end result is delivered at the end of each 2-4 week cycle

� E.g. a yearlong project will have multiple 2-4 week cycles and each cycle will execute Planning, Analysis, Design, Code, testing phases and deliver the result at the end of the cycle

� The Adaptive life cycle is the one most often associated with the term Agile

29

Iteration-Based and Flow-Based Agile

30PMBOK V6 Agile Fig. 3-5

Iteration-Based v. Flow-Based Agile � Both iteration-based and flow-based Agile follow the principles of the Agile

Manifesto� Customer satisfaction increases with early and continuous delivery of new

value-added products� Very popular in established IT world

� Iteration-Based Agile� Teams work in time-boxes of equal duration to deliver completed features� Features are defined so that they fit in the time-box� Team works on most important feature collaborating as a team� It is possible to put multiple requirements in an Agile increment, but not all

(that would be waterfall)� Flow-Based Agile

� Team pulls features from a backlog (queue)based on its capacity to start the work rather than based on the schedule� Considerations include not just priority but availability of human and physical

resources� For instance, you may need to test a part, but can only do so when the test facility is

available� Different features may require different amounts of time to finish

� Still try to keep the features small enough to allow a continual pipeline of value-added features

31

Advantages And Disadvantages Of The Agile Model � Advantages

� Customer satisfaction by rapid, continuous delivery of useful software.� People and interactions are emphasized rather than process and tools.

Customers, developers and testers constantly interact with each other.� Working software is delivered frequently (weeks rather than months).� Face-to-face conversation is the best form of communication.� Close, daily cooperation between business people and developers.� Continuous attention to technical excellence and good design.� Regular adaptation to changing circumstances.� Even late changes in requirements are welcomed

� Disadvantages� In the case of some software deliverables, especially the large ones, it is difficult

to assess the effort required at the beginning of the software development life cycle.

� There is lack of emphasis on necessary designing and documentation.� The project can easily get taken off track if the customer representative is not

clear what final outcome that they want.� Only senior programmers are capable of taking the kind of decisions required

during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.

� Upper management loves certainty and earned-value measurement which can only be easily measured for the increment being created

32

33

Hybrid Life Cycle Models

� Many programs combine different approaches based on the nature of the activity� Some programs involve both well-defined and less well-

defined elements� Research and development often uses the spiral model, with

subsequent development done in an incremental or Agile fashion

� The deployed infrastructure may be more well-defined, allowing the underlying infrastructure to be deployed following a waterfall model

� Many-times the programs spins off subprojects run with different models

� Tailoring of project life cycles often occurs to improve the fit

34

Tailoring Options May Be Based On Different Project Factors and Priorities (1)

35

PMBOK V6 Agile Table X2-1

Tailoring Options May Be Based On Different Project Factors and Priorities (2)

36

PMBOK V6 Agile Table X2-1 (Cont.)

Tailoring Options May Be Based On Different Project Factors and Priorities (3)

37

PMBOK V6 Agile Table X2-1 (Cont.)

38

As The Degree Of Uncertainty Increases The Appropriate Management Model Evolves From the Predictive To Highly Adaptive� The models form a natural ordering (Predictive, Iterative,

Incremental, Agile/Adaptive) by degree of solution uncertainty� The processes that form repetitive groups recognize the effect of

increasing uncertainty as you traverse the natural ordering� Those groups move more toward the beginning of the life cycle as

uncertainty increases� Complete project planning is replaced by just-in-time project

planning as the degree of uncertainty increases� Risk management becomes more significant as the degree of

solution uncertainty increases� The need for meaningful client involvement increases as the

degree of solution uncertainty increases.

39

Selecting The Right PMLC� Predictive (TPM)

� Clearly defined solution and requirements� Not many scope change requests expected� Routine and repetitive projects� Uses established templates

� Iterative (TPM)� Same as predictive but delivers business value early and often� Some likelihood of scope change requests

� Incremental (Agile Management)� Unstable or or incomplete requirements and functionality� Learn by doing and by discovery

� Adaptive (Agile Management)� Goal known but solution not known� Solution highly influenced by expected changes� New product development and process improvement projects

40

Additional Factors In Selecting The Right PMLC (1)� Total Cost

� As the total cost of the project increases, so does its business value and so does its risk. � Losses are positively correlated with the total cost, so you should be able to justify spending more on

your mitigation efforts than you would for a project of lesser cost.� Need to place more emphasis on the risk management plan than is called for in the chosen

model. � Appoint a separate Risk Manager

� Duration � A longer duration project brings with it a higher likelihood of change, staff turnover, and

project priority adjustments. � Pay more attention to your scope change management plan and the Scope Bank

� The Scope Bank contains all of the suggested ideas for change that have not been acted upon and the total labor time available for their integration into the solution.

� Put more emphasis on the mitigation plans for dealing with staff turnover. � Market Stability

� One way to protect the project would be to implement deliverables incrementally. � Shorter increments might make sense. � As each increment is implemented, revisit the decision to continue or postpone the

project.� Ultimately determine if earlier product release makes sense.

� Technology � Technology is changing at an increasing rate

� Difficult to keep up with it� Difficult to leverage it to your best advantage

� If the new technology will leverage you in the market, you might want to wait but make sure you can integrate it when it is available.

� Rapid response is to your advantage.41

Additional Factors In Selecting The Right PMLC (2)� Business Climate

� The more volatile the business climate, the shorter the total project duration should be.

� For APM projects, the cycle time boxes could also be shorter than typically planned.

� Partial solution releases will have a higher priority than they would in business climates that are more stable.

� Number of Departments Affected � As the number of departments that affect or are affected by the project

increases, the dynamics of the project change. � The requirements needs of several departments will have to be taken into account.

� Could lead to scope creep during the project scoping process as each department will have its list of “must haves” and “wouldn’t it be nice to haves.”

� Higher incidence of “needs contention,” which means the needs from two or more departments may contradict one another. � Must resolve the conflicts as part of validating requirements.

� Organizational Environment � If your company announces reorganizations and changes in senior-

management responsibilities quite frequently you have a problem. � The single most-frequent reason for project failures as reported in the past several

Standish Group surveys is lack of executive-level support, including loss of support resulting from company reorganization. � If you had a sponsor who was very enthusiastic about your project, and a strong and

visible champion for you, and who has been replaced, how the new sponsor feels is critical to continued project success.

42

43

Material for this section is drawn from:https://www.guru99.com/devops-tutorial.html

What Is DevOps

� DevOps is a culture which promotes collaboration between Development and Operations Team to deploy code to production faster in an automated & repeatable way� The word 'DevOps' is a combination of two words

'development' and 'operations’� DevOps helps to increase an organization's speed in

delivering applications and services� It allows organizations to serve their customers better

and compete more strongly in the market.� In simple words, DevOps can be defined as an

alignment of development and IT operations with better communication and collaboration

44

DevOps Management Principles� Customer-Centric Action

� DevOps team must take customer-centric actions that by constantly investing in products and services

� End-To-End Responsibility� The DevOps team needs to provide performance support until end-of-

life for the system.� Continuous Improvement

� DevOps culture focuses on continuous improvement to minimize waste. It continuously speeds up the improvement of products or services offered.

� Automate Everything� Automation is a vital principle of DevOps process. This is not only for

the software development but also for the entire infrastructure landscape.

� Work As One Team� In the DevOps culture the roles of the designer, developer, and tester

are already defined.� All they needed to do is work as one team with complete collaboration.

� Monitor and Test Everything� It is very important for DevOps team to have robust monitoring and

testing procedures.45

When Is DevOps Needed?

� Before DevOps, the Development Team and Operations Team worked in complete isolation� Testing and Deployment were isolated activities done

after design-build. Hence they consumed more time than actual build cycles.

� Without using DevOps, team members are spending a large amount of their time in testing, deploying, and designing instead of building the project

� Manual code deployment was leading to human errors in production

� Coding & operation teams have their separate timelines and are not in synch causing further delays

46

Comparing DevOps and Older ProcessesOlder Process DevOps

After placing an order for new servers, the Development team works on testing. The Operations team works on extensive paperwork as required in enterprises to deploy the infrastructure.

After placing an order for new servers Development and Operations team work together on the paperwork to set-up the new servers. This results in better visibility of infrastructure requirement.

Projection about failover, redundancy, data center locations, and storage requirements are skewed as no inputs are available from developers who have deep knowledge of the application.

Projection about failover, redundancy, disaster recovery, data center locations, and storage requirements are pretty accurate due to the inputs from the developers.

Operations team has no clue on the progress of the Development team. Operations team develop a monitoring plan as per their understanding.

In DevOps, the Operations team is completely aware of the progress the developers are making. Operations team interact with developers and jointly develop a monitoring plan that caters to the IT and business needs. They also use advance Application Performance Monitoring (APM) Tools.

Before go-live, the load testingcrashes the application. The release is delayed.

Before go-live, the load testing makes the application a bit slow. The development team quickly fixes the bottlenecks. The application is released on time.

47

Why Is DevOps Used? (1)

� Faster to market� DevOps allows Agile Development Teams to implement

Continuous Integration and Continuous Delivery that helps them to launch products faster into the market

� DevOps reduces the time to market up to 50% through streamlined software delivery

� This is particularly the case for digital and mobile applications

� Predictability� DevOps offers significantly lower failure rates with new

releases� Reproducibility

� Version everything so that earlier version can be restored anytime

� Maintainability� Effortless process of recovery in the event of a new release

crashing or disabling the current system48

Why Is DevOps Used? (2)� Improved Quality

� DevOps helps the team to provide improved quality of application development as it incorporates infrastructure issues

� Reduced Risks� DevOps incorporates security aspects in the software delivery

lifecycle� It helps in reducing defects across the lifecycle.

� Resiliency� The operational state of the software system is more stable and

secure, and changes are auditable.� Cost Efficiency

� DevOps offers cost efficiency in the software development process which is always an aspiration of an IT companies' management

� Breaks larger code base into small pieces� DevOps is based on the Agile programming method, allowing for

the breaking of larger code bases into smaller and manageable chunks

49

When To Use DevOps

� DevOps should be used for large distributed applications such as eCommerce sites or applications hosted on a cloud platform

� DevOps should not be used in a mission-critical application like bank, power and other sensitive data sites� Such applications need strict access controls on the

production environment, a detailed change management policy, access control policy to the data centers

50

The Continuous Development Life-Cycle� Development

� In this DevOps stage the development of software takes place constantly

� The entire development process is separated into small development cycles allowing the DevOps team to speed up the software development and delivery process

� Testing� The QA team uses tools to identify and fix bugs in any new piece of

code.� Integration

� In this stage, new functionality is integrated with the prevailing code, and testing takes place

� Continuous development is only possible due to continuous integration and testing.

� Deployment� In this phase, the deployment process takes place continuously� It is performed in such a manner that any changes made any time in the

code, should not affect the functioning of high traffic websites� Monitoring

� In this phase, operation team will take care of the inappropriate system behavior or bugs which are found in production

51

The DevOps Lifecycle

52

Comparing Agile and DevOpsAgile DevOps

Emphasize breaking down barriers between developers and management

DevOps is about software deployment and operation teams

Addresses gap between customer requirements and development teams

Addresses the gap between the Development Team and the Operation Team

Focuses more on functional and non-functional readiness

It focuses operational and business readiness

Agile development pertains mainly to the way development is thought out by the company

DevOps emphasis is on deploying software in the most reliable and safest ways which aren't necessarily always the fastest

Agile development puts a huge emphasis on training all team members to have varieties of similar and equal skillsWhen something goes wrong, any team member can get assistance from any member in the absence of the team leader

DevOps, likes to divide and conquer, spreading the skill set between the Development Team and Operation TeamIt also maintains consistent communication between the stakeholders

Agile development manages on "sprints. It means that the time table is much shorter (less than a month) and several features are to be produced and released in that period

DevOps strives for consolidated deadlines and benchmarks with major releases, rather than smaller and more frequent ones

53

The Roles, Responsibilities and Skills Of The DevOps Engineer (1)

� A DevOps Engineer is an IT professional who works with software developers, system operators, and other production IT staff to administer code releases. � A DevOps Engineer should have hard as well as soft

skills to communicate and collaborate with development, testing, and operations teams.

� A DevOps engineer will work with development team staff to tackle the coding and scripting needed to connect elements of code, like libraries or software development kits.

54

The Roles, Responsibilities and Skills Of The DevOps Engineer (2)

� The DevOps engineer:� Is able to perform system troubleshooting and problem-

solving across platform and application domains.� Manages a project effectively through open, standards-based

platforms� Increases project visibility thought traceability� Improves quality and reduce development cost with

collaboration� Analyzes, designs and evaluates automation scripts & systems� Ensures critical resolution of system issues by using the best

cloud security solutions services (for certain applications)

55