СамоСМиИ-2024-АК. Непрерывная разработка

Успех достигается не разовым усилием, а через постоянное совершенствование процессов и продуктов, с акцентом на быстром реагировании на изменения и тесном сотрудничестве между командами.

Все рассматриваем вместе и разные процессы друг на друга влияют. И их нужно подстраивать/изменять под текущие условия.


Как я понял - проблема с требованиями в том как они “добываются”. Обычно их кто-то приносит: “нам продакт принес требования”, “иди уточни требования”. Что я раньше не замечал - что “конвертация требований” происходит на многих уровнях, и логично что проблемы возникают при копировании/конвертации информации.
Ну и, конечно, фиксированные требования добавляют проблем. Писал немного про это тут СММ-АК-2024. Водопад на производстве. Из-за того, как они добываются - легко получить ошибку, а когда работаешь в парадигме “требования утверждены и изменению не подлежат” все может легко пойти как попало: лишние ресурсы будут потрачены, чтобы выполнить “букву требований”, а пользователям от этого разницы особой не будет.
У меня даже в начале моей трудовой практики такой пример был, когда по требованиям нужно было какую-то фичу сделать(уже не помню какую), но помню что сделать именно так у меня не получалось. И вот я день сижу, два, три, неделю, а все никак. Пошел “сдаваться” к своему начальнику, показал/рассказал, а он такой: ок, не делай это, мы это из скоупа совсем уберем, это далеко не критическая функциональность. [а че так можно было??.png]
Но естественно, просто заменить требования на юз-кейсы нельзя, т.к. тут всю стуктуру переделывать надо:

  • гибкие методологии
  • инкрементальная разработка
  • прямое взаимодействие с пользователями и стейкхолдерами, эволюционное развитие, понимание разработчиками бизнес-домена(и немалые инвестиции в это)
  • неразрывность разработки и организации процесса разработки
  • и т.д.

В разработке софта применяется подход формирования кросс-функциональной команды. В такой команде есть люди, с разным набором навыков, необходимые для доставки какой-то пользы. Сейчас вспоминаю свой опыт кросс-функциональных команд: почему-то никогда не включали маркетологов, customer-service specialists, да просто каких-то бизнесс-людей. Есть пространство для роста.




В разделе “непрерывное уточнение концепции” отдельно подчеркивается важность наличия “альтернативных концепций”. Указывается что без наличия альтернатив не будет “прохождения развилок”. А почему прохождение развилок важно? Конечно развилки важные не сами по себе, а что в них важно?
Я так понимаю, что важно в них именно то, что их несколько и они субоптимальны. Если их несколько - есть довольно большой шанс, что они как минимум “не очень плохи”. Но если ты сгенерировал один вариант и его же принял - шанс на какашку значительно выше.
Так же если вариантов несколько - это заставляет думать: а что действительно важно, а что не важно, может это приведет мысль куда-то и откроет новую перспективу на рассматриваемую проблему.
Отдельное место тут занимают ADRs. Документирование принятых решений позволяет понимать путь развития. Почему именно так, а не иначе. Не раз замечал в работе: приходит новый человек в проект и не понимает почему “так плохо принимали архитектурные решения”, “там идиоты что-ли проектировали это все?” и начинает стараться переделывать/растаскивать все, чтобы сделать лучше. Но наступает на те же грабли из-за которых данные решения и были сделаны. В итоге: фрустрация, злость, обида(оказывается проектировали не такие уж и дибилы).

  • Там случился шибко умный джун. Решил “выдернуть” старый костыль на проде, по древнему тикету
  • При близком осмотре костыль оказался позвоночником




Глава “Нейтральное по отношению к конструкции выражение функции: use case”. Оказывается use-caseы можно прекрасно описывать и текстом, я почему-то был застрявшим в визуальном выражении. Нужна небольшая сноровка, но вкатиться довольно просто. И как замечено ранее в учебниках - текстовую версию легче редактировать. Хотя для презентации кому-то(а не для постоянного использования) визуальную схему лучше использовать, лучше “продается”.




Глава “Сценарии использования и «управление делами»”. Хороший алгоритм опредления альф:

  • определите ключевые объекты или компоненты системы, которые важны для ее функционирования
  • опишите возможные состояния каждой альфы и критерии перехода между ними
  • выявите действия или процессы, которые влияют на состояния альф

Нужно думать про выявление ошибок как можно раньше

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

Чтобы сделать хорошо - надо убрать людские операции)

меньше человеков - лучше!
Правда есть интересный момент с over-automatisation. Это не такой гибкий процесс, как людской, но ошибок меньше
“automation is good, so long as you know exactly where to put the machine”

2 лайка

Хех. Знакомо. Знаешь тут два момента интересны. С одной стороны, я для себя зацепила идею “никто не дурак и не злодей”. Т.е. видя странное на первый взгляд решение мы прикидываем, что скорее всего были основания сделать именно так. Но) Обратная сторона в том, что многие штуки продолжают делаться неоптимально по “историческим причинам”. Sota? Не, не слышали. Выбор метода? Не, не слышали.

Я сейчас стараюсь себя проверять в обе стороны. Сначала собрать контекст ситуации, потом подумать варианты, потом подумать какие из этих вариантов мы можем себе позволить…

1 лайк

Кстати да, после МиС стала задавать вопросы на работе “Почему мы делаем именно так?” И в ответах можно много интересного откопать :grinning:

2 лайка