Да, далека. Подтверждаю, как свидетель тех самых времен —
Якщо AI Subscription буде дешевше ніж найєм програміста, Goodbye my love, goodbye... Питання в тому, чи ви взмозі демпінгувати і далі, як всі наші власники гелєр звикли у скрутні часи?
Думаю, значно раніше! :)
Навіть програмісти на асемблері та фортрані, потребують щоб хтось сформулював для них завдання — що робити. Саме з тих часів, коли асебмблер та фортран були в тренді, жодного разу не бачив в очі програміста який без належного тлумача одразу розумів, що треба програмувати. Сьогодні, коли тлумачення того, що треба робити перетворюється в промпт-інжинірінг, доля фортран- або асемблер-кодера може вважатись вирішеною... :)
До того ж, якщо Ви бачите, що десь програмісти фортрана чи асемблера ще не зникли, то значить тількяи те, що AI до цих дрімучих глушин ще не дістався... :)
Навіть якщо Ваш персональний добробут не залежить від хедж фондів, це не не значить, що цей індус не дістанеться до Вас... :)
Вы точно подметили ключевой момент всей этой затеи. Эти две ключевые бумажки Вы сможете увидеть только непосредственно перед подписанием.
Зачем сразу так плохо о ПМе? :) Как говорится, не стреляйте в пианисткe, она играет, как может! :) В той ситуации, в которую попала. Другое дело, что попытка натянуть практики проектного менеджмента на сугубо сервисную функцию девопс выглядит, мягко говоря, не совсем адекватно. Здесь реально рулит классика ITIL/ITSM. Между разрабами и командой девопсов должен быть SLA с оговоренными сроками реагирования на заявки. Да и вообще, весь процесс лучше отслеживать не как задачи в обычной Jira Software для управления проектами разработки, а как тикеты в Jira Service Management.
Ну, скрам нужен не для продуктивности. Иногда (а вернее — во многих случаях), заказчику нужно регулярно (например — раз в 2 недели) показывать что-то работающее. Дабы у него не пропадало желание и дальше оплачивать работу :). Ежели команда не в состоянии показывать прогресс ежедневно, топчется на месте и у нее всегда все в in-progress, вот тогда — scrum может и помочь. Если с умом подойти...
Это верно! Вот если еще «менеджера» переименовать в старорежимного «приказчика» на службе у «заводчика» — то все становится на свои места :)
Канбан — абсолютно адекватный подход. Тойота. Классика конвейера. Pull system. Задачи вытягиваются из бэклога тогда, когда высвобождается ресурс для ее выполнения, а не тогда, когда наступает какой-то высосанный из пальца дедлайн. Вообще — нехорошо высасывать из пальца. Как минимум — это не гигиенично... :)
Внезапно! Менеджмент может выдать любую глупость за полезную штуку :)
Интересно, кто платит за такое счастье? :)
Точно! Иногда выбрасывание чего-то из продукта ведет к множественным переделкам в других местах. Ибо любая система — не есть простая сумма входящих в нее компонент. Впрочем, для многих менеджеров это не вполне очевидно... )))
Вотерфол — это когда дизайн не начинается, пока не утверждены все требования, а девелопмент не стартует, пока не утвержден весь дизайн, а тестирование не начинается, пока не готов весь код. Полагаю, реально это имеет место разве что в строительстве. Где колышек в землю не вобъешь без получения разрешения землеустроительных инстанций, а строительство не начнешь, пока не будет утверждена вся проектная документация, ну а дальше — понятно, нельзя строить
Да, слова аджайл мы тогда не знали, Дима :). Однако, было примерно так:
1. Были алгоритмисты (очень много), которые по стандарту, придуманному программерами, рисовали алгоритмы бортовой системы управления полетом КА (космического аппарата), исходя из его предназначения. Там было все и управление ориентацией объекта и коррекция орбиты и решение множества всяких служебных задач, включая управление многочисленными системами и устройствами аппарата. Алгоритмы рисовали сверху вниз — от самых высокоуровневых (типа дистетчера задач) до самых низовых. Начинали сверху — общая логическая схема режима функциониррования системы управления, согласовывали и сразу отдавали программерам. Потом переходили к детализации и по мере готовности отдавали программерам. При необходимости корректировали общую схему режима и тут же передавали ее программерам
2. Программеры работали параллельно с алгоритмистами. Их тоже было много. И они тоже выкатывали новые версии софта на комплексный стенд отработки практически раз в два дня. В крайнем случае — не реже раза в неделю. Новые вресии содержали пустышки в тех местах, где еще было не готово. К каждой версии прилагался список пунктов программы отработки, которые имело смысл прогонять на стенде. Здесь надо отметить, что программу отработки с описанием тест-кейсов выпускали и обновляли алгоритмисты по мере выкатывания алгоритмов. Таким образом тестировщики (испытатели) на комплексном стенде имели актуальный план действий.
3. Задача максимум тестировщика — установить, где дефект — в алгоритме или в коде. Тестирование было автоматизировано — специальная наземная ЭВМ в соответствии с пунктами программы отработки по своим алгоритмам запускала тестовые последовательности стимулирующих воздействий на датчики или их имитаторы, снимала с борта телеметрию и сравнивала с эталонными данными. Здесь надо отметить, что алгоритмы бортовой и наземной машин проверочной машин рисовали одни и те дже алгоритмисты. Они же придумывали все возможные и невозможные тестовые ситуации и включали их программу отработки системы управления. Поскольку поначалу ничего не работало либо вообще, либо работало не так, тестировщикам приходилось отыскивать — где ошибка. После того, как определили место ошибки — дефект отписывался в бортовом журнале испытаний и на стенд вызывали виновника торжества. Если своими силами отыскать не удавалось, вызывали алгоритмиста и он в бортжурнале писывал частную методику поиска отказа или брал вопрос на проработку до конкретной даты и давал рекомендации, как проводить испытания дальше с учетом этой проблемы. Учитывая темп поступления завершенных алгоритмов и программ, а также фиксы ранее обнаруженных дефектов, реально все работали параллельно. Особо отмечу — отыскание места ошибки было обязательно. Делать обходные маневры было запрещено. Изделие с невыясненными до конца причинами отказов при испытаниях к полету не допускались.
4. Пара слов об управлении проектом. Поскольку не только софт, но и железо для системы управления создавалось и изготавливалось на заводах параллельно, был общий сетевой график по изделию, в котором отражались обязательства многочисленных участников этого дела. Глобально было несколько клюевых вех, отражавших зрелость конечного продукта. От стендовых прототипов до финальной готовности к летным испытаниям таких этапов могло быть до десяти и больше. В конце каждого этапа выкатывался релиз полностью отработанного софта с ограниченным функционалом, необходимым для отработки задач следующего этапа. Весь функционал необходимый для летных испытаний появлялся только к финалу. Внутри каждого этапа, как я уже писал, функционал наращивался и отрабатывался инкрементально. Своего рода канбан... Надо также сказать, что вместе с софтом на комплексном стенде отрабатывалось и многочисленное железо, которое тоже делалось и доводилось до ума инкрементально от макета до пригодного к работе в условиях реального полета образца. Железо конечно релизилось реже... :)
Ну вот как то так... Даже не знаю, ка это назвать. Могу только подчеркнуть — сотни предприятий, участвовавших в создании космической техники все работали примерно так и по такому жизненному циклу. И параллельно, не дожидаясь, когда смежник закончит свою часть. Пользовались заглушками, макетами, матмоделями, но не стояли и не ждали готовых комплектующих. Можно ли это назвать ватерфолом? Не думаю...
И да — забыл отметить. Это был типичный Time & Material. Если где-то и было бюджетное ограничение, то ближе к пуску его все одно снимали. Премии и всякие стимулирующе-мотивирующие плюшки только росли...
Ну здесь все просто. Определитесь, зачем вам нужен CAB? Какую конкретно проблему, как Вам кажется, это может решить? Пока не ответите себе на этот вопрос, нет никакого смысла обсуждать, как оно будет сожительствовать с помянутыми подходами... :)
Тема действительно интересна. Как по мне, то если речь идет о развитии компетенции Service Management в компании, то я бы все-таки отодвинул PMBoK на второй план и сделал бы упор на ITSM (ITIL). С другой стороны, ITSM — уж очень монструозен, и если речь идет о быстром развитии компетенции с нуля или околонуля, то стоит присмотреться к вышедшей недавно модели CMMI v2.0. CMMI Institute сделал большой шаг вперед по сравнению с версией 1.3. В новой версии реально интегрированы Development, Services и Acquisition, убрано дублирование, радикально упрощен язык. Модель стала понятна не только спецам, но и бизнесменам... :) И, мне кажется, это лучше ITIL.
В полете — да. Но в данном случае ФБР и Минюст уже начали выемку документов и проверку всей процедуры прохождения сертификации 737МАХ.
Так, не все так просто. Якщо виникає питання заміни легасі, яку вже не можна підтримувати далі (а її дійсно вже не можливо підтримувати далі сьогодні), то перше, що бізнес-відповідальні люди повинні зробити — запитатись, чи є вирішення цієї проблеми, та в чому воно є? Думеєте, бізнес-відповідальні люди не скористаються ChatGPT щоб отримати відповідь? :) Якщо в Вас є сумніви, що бізнес-відповідальні люди отримують належну відповідь через декілька ітерацій, Ви втрачаєте адекватність просто тому, що Вам не подобається об’єктивна реальність...