Почему исторический экскурс в жизненный цикл имеет значение? Чтобы не обманывались и не воспринимали слово “цикл” буквально?
Ну наверное, не то чтобы я сильно обманывался по этому поводу раньше. Все же очевидно, что инженерные системы не работают сами по себе, пока. Есть концепт Von Neumann probe есть ли у таких зондов жизненный цикл? Все еще не биологический но может уже цикл? Есть классный SCI-FI на эту тему: We Are Legion (We Are Bob) но тут точно есть жизненный цикл с эволюцией.
В целом интересный экскурс в историю как менялся подход и понимание концепта жизненный цикл. Интересно что сейчас больше и больше подходит эволюционное понимание… всего. Эволюция везде, “выращиваем” все. Все непрерывно, проект нельзя завершить - его можно только остановить, нет четких границ, это вроде как более интуитивно, но менее понятно как отслеживать. Так же тут мало того, что нет четких границ так и процесс происходит не линейно, а в виде “дерева”
Понравился алгоритм распожаризации
Распожаризация
- выкинуть то, что можно не делать. Чем больше тем лучше
- наладить управление конфигурацией что бы сократить количество переделок(чеклисты, документация, коммуникации)
- устраняем паузы в работе
- ускорять операции на критическом пути(более эффективные методы)
- перейти на пункт 1
Сразу не понял, что такое управление конфигурацией в данном случае. Примеры из разработки софта:
- использование системы контроля версий(например Git) - постоянное отслеживание изменений
- автотесты
- регулярные стендапы/планерки для обновления статуса
Во всё большем и большем числе проектов (начиная с айтишных проектов) признавали, что нельзя сделать никакого предварительного (up-front) планирования отдельных работ
Это кстати одна из моих ошибок когда я занимал лидерские позиции. Пытаться все распланировать, получить чувство контроля и успокоится. Было нескольких попыток, когда потратил кучу времени на план, а потом он все равно расползается т.к. там что-то забыл и тут что-то не учел. И это у меня-то проекты маленькие, на 4-5 человек. Еще проблема, что я был не менеджер, а ТехЛидом т.е. понимаю как именно нужно сделать, и все это, до мельчайших деталей пытался запихнуть в план.
Сначала думал, что, чтобы план не разваливался нужно просто лучше и больше планировать, но когда планирование уже превысило все мыслимые пределы что-то щелкнуло и я успокоился.
Я все еще планирую, но стараюсь потратить на это как можно меньше времени и сил и учесть только “самое важное”: какие-то проблемные интеграции, какие-то специфические компетенции(которых в команде нет) и т.д., а остальное просто как примерную дорожную карту использовать.
Зародилась концепция «непрерывного всего», в которой декларировалось, что придётся постоянно работать над изменениями — да ещё и подразумевалось, что проект при этом никогда не кончится (несмотря на все подписанные контракты, «никакой контракт по проекту не является последним»).
Хороший пример: в универе фрилансил, занимался веб-разработкой(сайты на друпале делал), и в то время очень любили “проекты под ключ”, с оплатой в две стадии. Естественно(это я сейчас понимаю, что естественно) “под ключ” ни разу не получилось т.к. :
- то заказчик в требованиях чего-то не учтет, я это не сделаю, а ему это надо и он хочет чтобы я доделал и без этого денег не переводит, а у меня уже следующий заказчик на очереди
- то, бывало, я как-то не так пойму требования и потом переделывать приходится, а рядом с переделками уже и “ну доделай еще тут и тут”
- то вообще важный функционал забыли в принципе обсудить
Потом из-за этого начинались всякий терки и попытки дожать друг друга: с моей стороны - чтобы часть денег уже пришли, с их стороны чтобы я еще “чуть-чуть” доделал.
Всякие предложения перейти на аджайл-подобную методологию, с итерациями и оплатой по итерациям никто не хотел рассматривать. В основном потому что:
- “а зачем, тут же все понятно что нужно делать! Тебе что, что-нибудь непонятно?”
- “я заплачу за 70-80% проекта, а потом ты уйдешь и кто будет доделывать?” - как будто когда я “сдам” проект никакие доделки не потребуются. Кто-то же их будет делать?
Как ни крути, без описания методов/«инженерных практик» внятно описать, как же устроены работы, в проекте не получалось. Поэтому в 80х годах прошлого века была предпринята радикальная замена водопадной модели жизненного цикла с приматом описания последовательности работ-стадий (жизненный цикл как «план работ») на другую, больше похожую на функциональную модель — представление разложения методов создания и развития целевой системы.
Из того, что я понял - успешная разработка систем требует фокуса на методах и практиках инженерии, а не только на планировании последовательности работ.
И как я понимаю, это раскрывается как альтернатива “водопадным моделям”. Но неужели там никто не думал о методах и практиках? Ну может не такими словами называли, но если сначала разрабатывали всю документацию то там же где-то наверняка указывалось, что сварка таких-то труб должна быть произведена? Или там просто - эта труба, такого диаметра, отсюда, подходит к трубе такого-же диаметра сюда? Т.е. должно же был быть какой-то упор на методы? Никогда с водопадными проектами не сталкивался, кто сталкивался - расскажите как с методами?
Или упоминания методов были, просто не особо много думали над тем какие именно методы эффективны/лучше в данном конкретном случае?