Introduction to Project Management

1
(No Transcript)
2
IT COMPANIES
IT
ITES
ITeS stands for Information Technology Enabled
Services
IT stands for Information Technology
IT focuses on developing and maintaining
technology systems
ITeS focuses on providing services that improve
business operations
3
SOFTWARE DEVELOPMENT HIERARCHY
Chairman
Intern Software Developer
CEO
Junior Software Developer
CTO
Software Developer
CIO/Chief Digital Officer/Chief Innovation Officer
Software Engineer
Senior Software Engineer/Senior Software Developer
VP of Engineering/Director of Engineering
Technical Lead/Engineering Lead/Team Lead
Chief Architect
Engineering Project Manager/Engineering Manager
Software Architect
4
(No Transcript)
5
(No Transcript)
6
(No Transcript)
7
(No Transcript)
8
(No Transcript)
9
(No Transcript)
10
(No Transcript)
11
(No Transcript)
12
(No Transcript)
13
(No Transcript)
14
(No Transcript)
15
(No Transcript)
16
(No Transcript)
17
(No Transcript)
18
(No Transcript)
19
(No Transcript)
20
(No Transcript)
21
(No Transcript)
22
(No Transcript)
23
(No Transcript)
24
(No Transcript)
25
WHAT IS AGILE PROCESS

• Def 1 The Agile methodology is a project
  management approach that involves breaking the
  project into phases and emphasizes continuous
  collaboration and improvement.
• Def 2 Agile methodology is a project management
  framework that breaks projects down into several
  dynamic phases, commonly known as sprints.
• Def 3 The Agile methodology is a project
  management and software development approach that
  emphasizes flexibility, collaboration, and
  customer-centricity. It follows the iterative as
  well as incremental approach that emphasizes the
  importance of delivering of working product very
  quickly.
• Def 4 Agile methodologies are iterative and
  incremental, which means its known for breaking
  a project into smaller parts and adjusting to
  changing requirements.

26
WHY AGILE PROJECT MANAGEMENT
27
(No Transcript)
28
(No Transcript)
29
(No Transcript)
30

• Phases of Agile Model
• Following are the phases in the Agile model are
  as follows
• Requirements gathering In this phase, you must
  define the requirements. You should explain
  business opportunities and plan the time and
  effort needed to build the project. Based on this
  information, you can evaluate technical and
  economic feasibility.
• Design the requirements When you have identified
  the project, work with stakeholders to define
  requirements. You can use the user flow diagram
  or the high-level UML diagram to show the work of
  new features and show how it will apply to your
  existing system.
• Construction/ iteration When the team defines
  the requirements, the work begins. Designers and
  developers start working on their project, which
  aims to deploy a working product. The product
  will undergo various stages of improvement, so it
  includes simple, minimal functionality.
• Testing In this phase, the Quality Assurance
  team examines the product's performance and looks
  for the bug.
• Deployment In this phase, the team issues a
  product for the user's work environment.
• Feedback After releasing the product, the last
  step is feedback. In this, the team receives
  feedback about the product and works through the
  feedback.

31
(No Transcript)
32
HAPPY CUSTOMER
Deliver Value
That Meets customer Needs
People in a Company
Customer Needs Change
Customer Feedback gets reflected in Roadmap
Customer Feedback is Implemented
33
(No Transcript)
34
(No Transcript)
35
(No Transcript)
36
(No Transcript)
37
(No Transcript)
38

1. Developers develop their code
2. Commit the code to local Git repository (Git
   keeps track of source code changes in developers
   local system)
3. Once code is ready, developers push the code to
   remote GitHub repository. When multiple
   developers are working on a common project,
   GitHub distributed repository ensures code
   integrity and solves collaboration issues between
   developers
4. We use Jenkins to integrate all the tools and it
   ensures that the code moves from one stage to
   another stage automatically. So, Jenkins clones
   the GitHub repository
5. Jenkins will execute Maven command for build
   process. Maven compiles and packages the source
   code into an artefact
6. Once build is success, Jenkins will ask Maven to
   push the source code to sonarqube for code
   quality analysis
7. Once code quality is Pass, Maven publishes the
   artefact to JFrog artifactory
8. Once artefacts are ready in JFrog artifactory,
   the artefacts can be deployed to application
   servers. The app server can be a standalone
   (apache tomcat) OR it can be a Docker container
9. Jenkins calls Ansible scripts to run playbooks to
   create custom docker image (that includes our
   artefact). Ansible playbook will take care of
   publishing custom images to the docker hub
10. Once customized image is available at docker hub,
    Jenkins will run the deployment manifest and
    service manifest on kubernetes cluster. The
    kubernetes master starts creating the application
    instances (viz deploy the application) on the
    worker nodes (pods)
11. Once the application is running successfully, we
    can now access the application using a URL which
    is mapped to specific application endpoint. End
    users can now access the application.

39
(No Transcript)
40
(No Transcript)
41
(No Transcript)
42
(No Transcript)
43
What is Scrum
Scrum is a management framework that teams use
to self-organize tasks and work towards a common
goal. It is a framework within which people can
address complex adaptive problems while the
productivity and creativity of delivering
products are at the highest possible value.

• Scrum allows us to develop products of the
  highest value while making sure that we maintain
  creativity and productivity.
• The iterative and incremental approach used in
  scrum allows the teams to adapt to the changing
  requirements.

44

• Key Components of Scrum
• Scrum Team Usually consists of a Product Owner,
  Scrum Master, and Development Team.
• Product Backlog A prioritized list of features,
  enhancements, and fixes to be worked on.
• Sprint A time-boxed period (usually 2-4 weeks)
  during which a set of work from the product
  backlog is completed.
• Daily Scrum A short daily meeting where the team
  discusses progress and plans for the next 24
  hours.
• Sprint Review A meeting at the end of each
  sprint to review what was accomplished.
• Sprint Retrospective A meeting after the Sprint
  Review to discuss what went well and what can be
  improved.

45
(No Transcript)
46
Extreme Programming (XP) is an Agile software
development methodology that focuses on
delivering high-quality software through frequent
and continuous feedback, collaboration, and
adaptation. XP emphasizes a close working
relationship between the development team, the
customer, and stakeholders, with an emphasis on
rapid, iterative development and deployment.
Extreme programming is one of the most popular
and well-known approaches in the family of agile
methods. an XP project starts with user stories
which are short descriptions of what scenarios
the customers and users would like the system to
support. Each story is written on a separate
card, so they can be flexibly grouped.
47

• Code Review Code review detects and corrects
  errors efficiently. It suggests pair programming
  as coding and reviewing of written code carried
  out by a pair of programmers who switch their
  work between them every hour.
• Testing Testing code helps to remove errors and
  improves its reliability. XP suggests test-driven
  development (TDD) to continually write and
  execute test cases. In the TDD approach, test
  cases are written even before any code is
  written.
• Incremental development Incremental development
  is very good because customer feedback is gained
  and based on this development team comes up with
  new increments every few days after each
  iteration.
• Simplicity Simplicity makes it easier to develop
  good-quality code as well as to test and debug
  it.
• Design Good quality design is important to
  develop good quality software. So, everybody
  should design daily.
• Integration testing Integration Testing helps to
  identify bugs at the interfaces of different
  functionalities. Extreme programming suggests
  that the developers should achieve continuous
  integration by building and performing
  integration testing several times a day.

48
(No Transcript)
49
1. Incremental Development - XP promotes
incremental development, where software is built
in small, manageable increments. Teams deliver
working features frequently, allowing
stakeholders to provide feedback early. -
Example Imagine a startup building an e-commerce
platform. Instead of waiting months to release
the entire system, they develop and
release individual features like user
registration, product search, and checkout one by
one. 2. Continuous Integration (CI) - CI ensures
that code changes are integrated into the main
codebase frequently. Developers commit their
changes multiple times a day, and automated
tests run to catch any regressions. - Example A
startup team commits code to the shared
repository several times a day. Automated tests
validate the changes, preventing integration
issues. 3. Test-Driven Development (TDD) - TDD
is a fundamental XP practice. Developers write
tests before writing the actual code. This
ensures that code meets requirements and remains
maintainable. - Example A developer working on a
payment gateway feature writes a failing test
for processing payments. They then implement the
payment logic to make the test pass.
50
4. Pair Programming - In XP, developers work in
pairstwo people at one computer. One writes code
while the other reviews, suggests improvements,
and catches errors. - Example Two startup
developers collaborate on implementing a
recommendation engine. One writes the algorithm,
and the other reviews the code, ensuring
quality. 5. Refactoring - Refactoring involves
improving code without changing its external
behavior. XP encourages continuous refactoring to
keep the codebase clean and maintainable. -
Example A startup team identifies duplicated
code in their inventory management module. They
refactor it into a reusable function, enhancing
code quality. 6. Collective Code Ownership -
Everyone on the team owns the entire codebase. No
single person is solely responsible for specific
modules. This fosters collaboration and knowledge
sharing. - Example A startup developer can
modify any part of the application, even if they
didn't originally write it. This shared
ownership accelerates development.
51
7. Customer Collaboration - XP emphasizes close
collaboration with customers. Regular
interactions help clarify requirements,
prioritize features, and adapt to changing
needs. - Example A startup's product owner meets
weekly with customers to gather feedback. This
informs feature prioritization and ensures
alignment with user needs. 8. Small Releases -
Frequent, small releases allow startups to
respond quickly to market changes. Each release
adds value and minimizes risk. - Example A
startup launches a minimal viable product (MVP)
with essential features. Subsequent releases add
enhancements based on user feedback. 9. Sustainabl
e Pace - XP discourages overwork. Developers
maintain a sustainable pace to prevent burnout
and ensure long-term productivity. - Example A
startup team sets realistic sprint goals,
avoiding excessive overtime. This balance
improves morale and project stability. 10. Embrace
Change - XP acknowledges that requirements
evolve. Teams adapt to changes, even late in
development, to deliver valuable software. -
Example A startup initially planned a mobile app
but later decided to add a web version. The team
adjusted their development approach accordingly.
52
Advantages of Extreme Programming (XP)

• Slipped schedules Timely delivery is ensured
  through slipping timetables and doable
  development cycles.
• Misunderstanding the business and/or domain
  - Constant contact and explanations are ensured
  by including the client on the team.
• Canceled projects Focusing on ongoing customer
  engagement guarantees open communication with the
  consumer and prompt problem-solving.
• Staff turnover Teamwork that is focused on
  cooperation provides excitement and goodwill.
  Team spirit is fostered by multidisciplinary
  cohesion.
• Costs incurred in changes Extensive and
  continuing testing ensures that the modifications
  do not impair the functioning of the system. A
  functioning system always guarantees that there
  is enough time to accommodate changes without
  impairing ongoing operations.
• Business changes Changes are accepted at any
  moment since they are seen to be inevitable.
• Production and post-delivery defects the unit
  tests to find and repair bugs as soon as possible.

53
(No Transcript)
54
A kanban board is an agile project management
tool designed to help visualize work, limit
work-in-progress, and maximize efficiency (or
flow). It can help both agile and DevOps teams
establish order in their daily work. Kanban
boards use cards, columns, and continuous
improvement to help technology and service teams
commit to the right amount of work, and get it
done!
55
Elements of a kanban board
1. Visual Signals  One of the first things
youll notice about a kanban board are the visual
cards (stickies, tickets, or otherwise). Kanban
teams write all of their projects and work items
onto cards, usually one per card. For agile
teams, each card could encapsulate one user
story. Once on the board, these visual signals
help teammates and stakeholders quickly
understand what the team is working on.
2. Columns  Another hallmark of the kanban board
are the columns. Each column represents a
specific activity that together compose a
workflow. Cards flow through the workflow until
completion. Workflows can be as simple as To
Do, In Progress, Complete, or much more
complex.
3. Work In Progress (WIP) Limits  WIP limits are
the maximum number of cards that can be in one
column at any given time. A column with a WIP
limit of three cannot have more than three cards
in it. When the column is maxed-out the team
needs to swarm on those cards and move them
forward before new cards can move into that stage
of the workflow. These WIP limits are critical
for exposing bottlenecks in the workflow and
maximizing flow. WIP limits give you an early
warning sign that you committed to too much work.
56
4. Commitment point  Kanban teams often have a
backlog for their board. This is where customers
and teammates put ideas for projects that the
team can pick up when they are ready. The
commitment point is the moment when an idea is
picked up by the team and work starts on the
project. 5. Delivery point  The delivery point
is the end of a kanban teams workflow. For most
teams, the delivery point is when the product or
service is in the hands of the customer. The
teams goal is to take cards from the commitment
point to the delivery point as fast as possible.
The elapsed time between the two is the called
Lead Time. Kanban teams are continuously
improving to decrease their lead time as much as
possible.  
57
Agile Crystal is one of the Agile methodologies
that emphasizes flexibility and tailors its
approach based on the size of the team and the
criticality of the project. Crystal focuses on
people, interaction, community, skills, talents,
and communication as the core of the development
process rather than a set of processes and tools.
There are several variants of Crystal, such as
Crystal Clear, Crystal Yellow, Crystal Orange,
and Crystal Red, each suitable for different team
sizes and project complexities.
58
(No Transcript)
59

1. Crystal Clear- The team consists of only 1-6
   members that is suitable for short-term projects
   where members work out in a single workspace.
2. Crystal Yellow- It has a small team size of 7-20
   members, where feedback is taken from Real Users.
   This variant involves automated testing which
   resolves bugs faster and reduces the use of too
   much documentation.
3. Crystal Orange- It has a team size of 21-40
   members, where the team is split according to
   their functional skills. Here the project
   generally lasts for 1-2 years and the release is
   required every 3 to 4 months.
4. Crystal Orange Web- It has also a team size of
   21-40 members were the projects that have a
   continually evolving code base that is being used
   by the public. It is also similar to Crystal
   Orange but here they do not deal with a single
   project but a series of initiatives that required
   programming.
5. Crystal Red- The software development is led by
   40-80 members where the teams can be formed and
   divided according to requirements.
6. Crystal Maroon- It involves large-sized projects
   where the team size is 80-200 members and where
   methods are different and as per the requirement
   of the software.
7. Crystal Diamond Sapphire- This variant is used
   in large projects where there is a potential risk
   to human life.

60
(No Transcript)
61
FDD stands for Feature-Driven Development. It is
an agile iterative and incremental model that
focuses on progressing the features of the
developing software. The main motive of
feature-driven development is to provide timely
updated and working software to the client.
62

• Imagine a Pizza Shop
• Customer Order
• A customer orders a custom pizza with specific
  toppings.
• In Lean Software Development, this represents
  understanding the customer's needs precisely.
• Efficient Toppings Selection
• The chef uses only the freshest ingredients and
  picks them in the exact quantities needed.
• This step is like the "Eliminate Waste" principle
  in Lean, where unnecessary steps and excess
  resources are avoided.
• Quick Preparation
• The chef uses efficient techniques to prepare the
  pizza quickly without compromising quality.
• In LSD, this is akin to "Create Fast Delivery,"
  emphasizing rapid, high-quality delivery of
  software features.
• Continuous Feedback
• The customer tastes the pizza and gives immediate
  feedback.
• This corresponds to the "Build Quality In" and
  "Empower the Team" principles, where continuous
  improvement and team empowerment are key.
• Adjustments
• If the customer wants more cheese or a bit more
  baking, the chef makes those adjustments swiftly.
• This is like the "Optimize the Whole" and
  "Amplify Learning" principles, focusing on
  continual learning and improving the entire
  process.

63
(No Transcript)
64
Eliminate Wastes To maximize value, We must
minimize Waste. For software systems, Waste can
take the form of partially done work, delays,
hand-offs, unnecessary features etc.. Therefore,
to increase the value we are getting from
projects, we must develop ways to identify and
then remove waste. Empower the team Rather than
taking a micromanagement approach, we should
respect team members superior knowledge of the
technical steps required on the project and let
them make local decisions to be productive and
successful. Deliver Fast We can maximize the
project Return on investment (ROI) by quickly
delivering valuable software and iterating
through designs. We find the best solution
through the Rapid Evolution of options. Optimize
the Whole We aim to see the system as more than
the sum of its parts. We go beyond the pieces of
the project and look for how it aligns with the
organization. As part of optimizing the whole, we
also focus on forming better inter-group
relations. Build quality in Lean development
doesnt try to test-in quality at the end
instead, we build quality into the product and
continually assure quality throughout the
development process, using techniques like
refactoring, continuous integration and unit
testing. Defer Decisions We balance early
planning with making decisions and committing to
things as late as possible. For example, this may
mean re-prioritizing the backlog right up until
it is time to plan an iteration, or avoiding
being tide to an early technology-bounded
solution. Amplify Learning This concept involves
facilitating communication early and often,
getting feedback as soon as possible, and
building on what we learn. Software projects are
business and technology learning experiences, so
we should start soon and keep learning.
65

• The example provided covers several key
  principles of Lean Software Development. Let's
  break it down to see how each principle is
  represented
• Eliminate Waste
• Efficient Toppings Selection Only the freshest
  ingredients and exact quantities needed are used,
  avoiding unnecessary steps and excess resources.
• Build Quality In
• Quick Preparation Ensures high-quality pizza
  without compromising the process, similar to how
  Lean emphasizes building quality into the
  software from the start.
• Create Knowledge
• Continuous Feedback and Adjustments Reflects the
  idea of learning and adapting based on feedback,
  similar to how Lean encourages continuous
  learning and improvement.
• Defer Commitment
• Adjustments Making changes based on customer
  feedback before finalizing the product,
  reflecting the principle of making decisions as
  late as possible to keep options open.
• Deliver Fast
• Quick Preparation Emphasizes delivering the
  pizza quickly, just like Lean focuses on
  delivering software features rapidly.
• Respect People
• Customer Order and Feedback Listening to and
  acting on customer feedback shows respect for
  their needs and input, similar to respecting the
  team's expertise and customers' requirements in
  Lean.
• Optimize the Whole
• Efficient Toppings Selection and Continuous
  Adjustments Ensuring the entire process from
  order to delivery is efficient and high quality,
  reflecting the principle of optimizing the whole
  development process.

66

• Characteristics of FDD
• Short iterative FDD lifecycle works in simple
  and short iterations to efficiently finish the
  work on time and gives good pace for large
  projects.
• Customer focused This agile practice is totally
  based on inspection of each feature by client and
  then pushed to main build code.
• Structured and feature focused Initial
  activities in lifecycle builds the domain model
  and features list in the beginning of timeline
  and more than 70 of efforts are given to last 2
  activities.
• Frequent releases Feature-driven development
  provides continuous releases of features in the
  software and retaining continuous success of the
  project.
• Advantages of FDD
• Reporting at all levels leads to easier progress
  tracking.
• FDD provides continuous success for larger size
  of teams and projects.
• Reduction in risks is observed as whole model and
  design is build in smaller segments.
• FDD provides greater accuracy in cost estimation
  of the project due to feature segmentation.
• Disadvantages of FDD
• This agile practice is not good for smaller
  projects.
• There is high dependency on lead programmers,
  designers and mentors.
• There is lack of documentation which can create
  an issue afterwards.