Frank Millstein - DevOps Handbook: What Is DevOps, Why You Need It And How To Transform Your Business With DevOps Practices

DevOps Handbook

What Is DevOps, Why You Need It And How To Transform Your Business With DevOps Practices

By Frank Millstein

WHAT IS IN THE BOOK?

Copyright 2018 by Frank Millstein- All rights reserved.

This document is geared towards providing exact and reliable information in regards to the topic and issue covered. The publication is sold with the idea that the publisher is not required to render accounting, officially permitted, or otherwise, qualified services. If advice is necessary, legal or professional, a practiced individual in the profession should be ordered.

From a Declaration of Principles which was accepted and approved equally by a Committee of the American Bar Association and a Committee of Publishers and Associations.

In no way is it legal to reproduce, duplicate, or transmit any part of this document by either electronic means or in printed format. Recording of this publication is strictly prohibited, and any storage of this document is not allowed unless with written permission from the publisher. All rights reserved.

The information provided herein is stated to be truthful and consistent, in that any liability, in terms of inattention or otherwise, by any usage or abuse of any policies, processes, or directions contained within is the solitary and utter responsibility of the recipient reader. Under no circumstances will any legal responsibility or blame be held against the publisher for any reparation, damages, or monetary loss due to the information herein, either directly or indirectly.

Respective authors own all copyrights not held by the publisher.

The information herein is offered for informational purposes solely and is universal as so. The presentation of the information is without contract or any type of guarantee assurance.

The trademarks that are used are without any consent, and the publication of the trademark is without permission or backing by the trademark owner. All trademarks and brands within this book are for clarifying purposes only and are owned by the owners themselves, not affiliated with this document.

INTRODUCTION

B y combining project management pitfalls with software development obstacles and other challenges, entrepreneurs create a recipe for large problems for their companies. However, these issues are assuredly preventable.

When it comes to software development and project management, there is no exact science. Nevertheless, when software development issues emerge, it can be disastrous.

There are a wide range of different mistakes made by project management while working on software development.

Some of the major mistakes are not purely related to software development projects, but they can be highly damaging to those projects.

O ne of the primary mistakes management will make in these situations is that when new software is being created and a problem arises, they will add additional people to working on the job, i.e., fixing the problem.

By those so, there is a certain amount of friction that is added and created by each person. It adds more to the overall project. The new personnel coming must have time to acclimate themselves to the project, i.e., get up to speed, so they can coordinate their work with the personnel who have been working on the project the longest. In turn, the personnel who have been involved with the project say from the beginning dont necessarily want to have to stop and teach the newcomers all about the project unless they are instructed to do so. It tends to feel like a setback to them in building new code or dedicating more time to finding a fix to the problem themselves. Hence, the friction is generated.

Moreover, adding more people to your software development team can also significantly slow down your work rather than speeding it up which is the main reason for adding more people to the team. This slowing down of the work is especially true during those initial months of working on the project.

Adding more people onto the board also causes issues as there are some software development tasks which cannot be split up and be done on time by all people working on the team at once. These common tasks, in fact, must be done step by step, taking one task, solving it and moving onto the following task.

With this problem of software development projects and teams, you see that adding more people who are working on the different tasks requires a lot of coordination for it to work out smoothly and operate at a good pace.

By adding more people, more time is needed for them to get to know the project, to coordinate with other people, so instead of speeding up the overall project, you slow it down significantly which once again leads to other software development issues.

Besides this issue when project managers add more and more people to work on the board, other issues emerge when project managers use the wrong metrics.

Project managers need different metrics for several reasons. One of the main reasons for using the metrics is to measure the overall success of the project, to review performance feedback of the projects, to perform accurate analysis of the projects and many other.

Using wrong metrics in addition to the previously mentioned issue is one of the most common problems project managers find themselves facing. This mistake commonly occurs as collecting different metrics takes almost no time.

In fact, project managers can easily collect different metrics, but as they do so, it is more likely that their performance and other project metrics are measuring nothing useful for the project in general.

Another issue here regarding the wrong metrics is that those easiest to collect metrics are obtained simply because of ease-of-use. Since they are easily obtainable, project managers tend to collect the easiest metrics, but looking in the long run, those easily obtained metrics are more likely to be useless.

Lets imagine that you need to bug tickets. Here, it is very easy to count all the tickets which got entered. However, looking at the big picture, collecting and bugging tickets using this approach is not a meaningful and useful measurement because the number of tickets entered are most often user error.

Due to the issues created by using this approach, project managers will typically use other metrics such as the overall ticket resolution rate which can be determined by how long the ticket was open and the amount of time it took to resolve the issue.

If the project includes a helpdesk where tickets are open and closed for numerous reasons, the mangers must deal with many other issues such as duplication of tickets. Tickets get opened on harder to solve problems which means they may be open longer until the problem is resolved.

Instead of getting some serious work done to help their users, the project managers and their organizations are focused on resolution rates. They tend to exist only to open as many tickets as possible and then close them as soon as possible to get those resolution rates up.

However, to benefit the actual users, a much better idea is to leave those tickets open until their users fully accept the new ticket resolutions. Moreover, there is another, better metric which is the ratio of actual bug tickets crafted in relationship to tickets features which come deployed. This is a better measurement, but it is also the hardest one to measure.