A.F.S.T или ваше среднее время доставки функций в программном обеспечении — это больше, чем просто кодирование и тестирование, а затем git push в вашей удаленной ветке.

Все это делает идею ежедневной CI/CD сложной.

Эффективное разделение — более сложная задача, чем мы думаем, и ею не всегда занимаются высокопоставленные люди, а иногда и вовсе не инженеры, и это плохо, если вы хотите точно оценить шансы.

Каковы шансы?

  • Переменные реального мира (личные/семейные проблемы/проблемы со здоровьем или связанные со стрессом, они настолько распространены, насколько это возможно, поэтому они занимают первое место)
  • Задержка отдела (Предположим, вам нужна незначительная вещь из другого отдела, но вы не центр их вселенной, странно, я знаю, но просто оставайтесь со мной до конца этого)
  • Технические проблемы (это может произойти, и это может привести к потере, возможно, даже целого дня, это основа, на которой основано МНОЖЕСТВО технологий, таких как Docker и другие онлайн-платформы IDE с готовыми переменными среды)
  • Неясные рамки продукта / логические ошибки (само собой разумеющиеся, а также основа настоящего гибкого процесса и почему мы используем его в большинстве, но не во всех случаях)
  • Операционная корпоративная волокита (сам дьявол, она должна быть №1, но она прячется в тени, может быть, замаскированная под Scrum/SaFe/Kanban или вашу идею смешивать kanban со Scrum.)
  • Задержка внедрения (она начинается с нового инструмента, языков и новых людей в команде, всему новому потребуется период корректировки/интеграции, ваш менеджер так не думает, и поэтому это может стоить команде в будущем).
  • Неизвестные факторы (правильно было бы добавить 5% вашего времени на всякий случай, иначе ваша 8-часовая рабочая неделя не будет длиться 8 часов долго)

Я уверен, что многие люди заявляют, что знают, как эффективно вести свой бизнес, но приведенные выше шансы не являются чем-то незначительным, несчастные случаи по определению не имеют намерения, потому что, когда они случаются, они не преднамеренны тем, кто принимает участие или имеет. полная ответственность за несчастные случаи, подумайте об этом, как когда ваш телефон падает и ломается, и у вас есть вся эта информация в нем, нет ни единого шанса, что вы ожидали, что это произойдет, и все же это было вне вашей власти, и так случилось, так работает большинство оценок, когда вы не знаете множественных шансов, поэтому опыт имеет большое значение, определение APM (Действий в минуту) по сути одно и то же, при втором прохождении теста ваши результаты будут быть повышен более чем на 35% по сравнению с первым разом, потому что теперь вы будете более опытны в этом процессе. Оценка программного обеспечения также похожа на эту.

Чего не хватает APM, так это человеческого фактора, когда ты пытаешься играть красиво и многообещаешь, поэтому будь пессимистом и скромничай, когда дело доходит до твоих навыков, не говоря уже о командных навыках, о которых ты ничего не знаешь или, что еще хуже, думаешь, что знаешь. .

Итак, как рассчитать A.F.S.T, некоторые методы упомянуты в моей предыдущей статье об оценке хаоса, но правда в том, что все, что работает для вас, хорошо для мира, пока это работает, хотя расчет этих шансов является вещь, которая склеит все воедино, независимо от того, как выглядит ваша модель или насколько сложным может быть ваш новый проект.

Спасибо за прочтение.