Обсуждение

Совершенно другое (лучшее) впечатление от прочтения, по сравнению с первой книгой. Пусть и субъективное.

Это все говорят )))

Про нвидию с её последними заявлениями будет пост?

Про какие именно её заявления идёт речь? Про ограничение титанов для датацентров -- https://www.cnbc.com/2017/12/27/nvidia-limits-data-center-uses-for-geforce-titan-gpus.html ? Не понимаю, что там комментировать. Что Титан Volta не для всех вычислений в разы круче Pascal, а только в некоторых узких (хотя и важных) классах? Тоже понятно и широко обсуждается. О чём писать-то?

Виды жизненного цикла и виды практик управления работами описаны вперемешку. Проблема в том, что у "традиционного вида жизненного цикла" нет своего названия. Не назвав его, ты перечисляешь относящиеся к нему виды практик: управление проектами, программами и процессами. Потом ты вдруг вводишь название нового вида ЖЦ - agile, но делаешь это в том же разделе, озаглавленном "Виды практик управления работами". И для него называешь одну практику - управление кейсами. Ну и в воздухе висит фраза "Эти гибкие методологии считают относящимися к разновидностям спиральной модели. ". Как это понимать? Что есть иные разновидности спиральной модели, являющиеся "традиционными" видами ЖЦ? А что такое сама спиральная модель? Общий надкласс гибких и негибких моделей?

Конечно, тут маленький кусочек седьмой главы про виды жизненного цикла, три страницы из двадцати. А само понятие ЖЦ, водопад и спираль вводятся в большой шестой главе. Поэтому обсуждать эти все вопросы только по махонькому кусочку текста даже не знаю как. Слово "традиционный" у меня в этом кусочке текста относится к аэрокосмическим проектам как традиционным для системной инженерии. Вот проекты пищевой промышленности не традиционны, а аэрокосмос -- традиционен. Никакого "традиционного вида жизненного цикла" ни в одной главе нет. Есть противопоставление водопада с последовательными стадиями, игнорированием практик и гейтами, а ещё спирали как общей формы всего остального -- где практики нелинейно расположены по времени. Agile тут вариант спирали, к традиции никакого отношения не имеет.

Попробуй нарисовать полную картинку - дерево видов ЖЦ и внизу относящиеся к каждому виды практик управления работами. Увидишь, какие клеточки остаются без названий.

>> кусочек черновика седьмой главы моего нового учебника "Системное мышление". Прочитал пост на одном дыхании, класс. Могу ли помочь в вычитке книги\глав? (я бы купил даже, не вопрос) Я месяца два в неспешном порядке читаю, как гармонизировали ГОСТ Р 57100-2016 (который "Системная и программная инженерия.") и ГОСТ Р 57098-2016 (который "Системная и программная инженерия. Управление жизненным циклом.") с "пониманием в русскоязычном мире" - и ощущение, что некуда отослать почитать. Первая версия вашей книги мало для этого подходит. -- Кстати, в 57100 есть интересная отсылка: Приложение А, "А.З Интересы", цитата из книги E Osger, W. Dijkstra. 1974, "... Это то. что я подразумеваю под «сосредоточением внимания на некоторых аспектах», что не означает игнорирования других аспектов, а только оправдывает факт того, что с точки зрения этого аспекта другой является неактуальным. Это — одно- и многократное отслеживание, рассматриваемое одновременно»"

Две книги станет.

"...месяца два в неспешном порядке читаю, как гармонизировали..." Можно уточнить, это вы у кого читаете?

С Новым Годом вас! >> Можно уточнить, это вы у кого читаете? Перечитал несколько раз вопрос, вот и неявная семантика сыграла: "читать у кого" и "читать что". Я имел ввиду, что ISO 42010 имеет смысл только с точки зрения "традиции мышления", и хорошо бы уметь отсылаться к тем, кто в русском языке "держит в руках" образы и онтики "об системная инженерия". И вот этот пример - с фразой "... в неспешном порядке читаю, как гармонизировали ...", которая вполне по правилам читается как "читать кому-то" - меня сейчас подвинул в сторону темы http://ailev.livejournal.com/1289718.html и "human biases". Забавно.

При указании варианта жизненного цикла команде не нужно говорить SCRUM.... Вряд ли сегодня какая-то команда использует эти методологии во всей их полноте. Есть огромное количество команд, которые пользуются SCRUM во всей полноте! Посмотрите https://www.facebook.com/scrumua или https://www.facebook.com/scrumalliance/ и свяжитесь с тренерами, они могут дать огромное количество деталей о таких командах. Вопрос - где в гибких методологиях упоминается управление кейсами? Упоминают ли управление кейсами где-либо в своих трудах Kent Beck, Martin Fowler, Jeff Sutherland и другие? Приведите, пожалуйста, источники информации о кейс менеджменте. Вы нигде не упоминаете специфики, связанной с рыночной высококонкурентной средой, в которой разрабатываются многие продукты. И тем, как это влияет на модели и методы управления этой разработкой. А это влияет и очень сильно. Именно такая высококонкурентная динамичная среда и есть основной источник непредсказуемости требований, контрольных точек, сроков, ресурсов и тд

Ох, всегда найдутся фанаты, но когда их будут проверять другие фанаты, то окажется, что никакой полноты следования канону там не будет -- а будут глубоко адаптированные к условиям организации практики, сохраняющие тем не менее "трейдмарк" для удобства окружающих. Это нормально, только об этом (первичности адаптации и вторичности канона) надо говорить явно. В моём тексте речь идёт не о программистах! У меня общий текст, для самых разных проектов. Про управление кейсами (адаптивное) я дал ссылку в тексте -- http://ailev.livejournal.com/946134.html, и там внутри ссылка на книжку http://www.amazon.com/Mastering-Unpredictable-Management-Revolutionize-ebook/dp/B003IX0GZ0/. Хотя эти ссылки 2011 года, с тех пор много чего поменялось, но это на данном уровне подробностей неважно. Про рыночную высококонкурентную среду я молчу, посколько других сред не бывает (про госпроекты у меня специальная оговорка в учебнике, что с ним по норме не получится работать).

Спасибо за ваш ответ! SCRUM используется не только для IT проектов, вот здесь например есть кейсы из других отраслей. Но наверное действительно это сейчас скорее исключение, чем правило. С другой стороны, было бы интересно посмотреть на статистику - сколько проектов в каких странах в каких отраслях используют ту или иную методологию. Вот Standish Group говорит, что проекты использующие Agile методологии показывают более высокий процент успешности. Спасибо за ссылки по case management, это новое понятие для меня, буду изучать.

Мой пойнт в том, что используют как раз сейчас не целые методологии, а кастомизированные наборы практик. Agile methodology обычно означает именно такой набор практик, а не что-то конкретное в объёме толстой книжки "от и до". Представление о необходимости работы по полной методологии было общепринятым лет десять-пятнадцать назад, и я даже понимаю, что осталось до чёртиков ещё последователей этой идеи, но сама идея уже умерла, всё, аминь. Будут брать отдельные практики из SCRUM, что-то из kanban for development, что-то даже из древнего XP. И называть это agile methodology. Вот это и есть современный подход.

Вышел на этот пост по ссылкам из анонса нового курса, перечитал и появились мысли, которыми хочу поделиться - может, пригодиться для развития курса. Управление жизненным циклом - это по сути управление потоком создания ценности в проекте. При этом через нужды и требования создание ценности преобразуется в поток работ, которые, при правильном проектировании, должны эту ценность создать и доставить потребителю. И классический менеджмент исходил из того, что проектирование будет сделано правильно (качественно), хотя и предусматривал в конце фазу валидации. И рисков неверного проектирования - не закладывают. А Agile, наоборот, стоит на том, что обеспечить этого в принципе невозможно, проект чаще всего имеет статус гипотезы о проекте и проверять надо как можно чаще. В Scrum sprint review как раз и задуман как такая проверка - что разработка не просто выполнена, а что она удовлетворяет нуждам стейкхолдеров, решает их проблемы - то есть несет ценность. Понятно, что просто демонстрацией это не всегда проверишь - тогда надо применять более сложные практики, вплоть до выкатывания в продакшн и A-B тестирования и на демо показывать графики охвата аудитории (например). И вот если мы от просто исполнения заранее (в проекте) определенного набора работ переходим к потоку работ и управлению этим потоком, то как парное к нему переходить к управлению потоком создания ценности, удерживая при этом gap между ними (работы выполнили, а ценность не создали). И именно в этом (вроде как) заключается управление жизненным циклом (продукта). Ну и дальше можно апеллировать к тем практикам Lean и Kanban, которые как раз работают в терминах потока создания ценности и соответствующей теоретической базе. Мне кажется, что этот образ может более четко прояснить, чем управление жизненным циклом отличается от управления потоком работ. А еще здесь есть явный провал у многих практиков, да и у тех, то занимается методами, который надо закрывать образованием. Иначе освоение бюджета без достижения результата воспринимается чисто как вина исполнителей, а не проблема методологии. А она означает, если рассматривать идеальную конструкцию, что мы разрыв между потоками создания ценности и выполнения задач упустили.

Да, именно так -- только я обычно не "ценность", а "полезность" перевожу. И подчёркиваю, что управление работами -- в работах различаются ресурсы, а характер самой работы неинтересен. А в жизненном цикле 2.0 наоборот -- ресурсы плевать, но в чём суть работы важно. Жуть же в том, что формально в жизненном цикле и практики, и работы вместе, да ещё и рабочие станции (размещения!). И УЖЦ -- это по факту модульный синтез, назначение работ на практики. Одно без другого не живёт, но "чтобы объединиться, нужно сначала размежеваться".

Не только размежевать УЖЦ и управление работами, но и еще УЖЦ дотянуть, что полезность в результате получена: проверить ее, и если проверка не прошла - предпринять меры по этому поводу. Я пост перечитал - там как раз про полезность нет. И в результате получается стандартный ответ "мы сделали все по плану, а исправим в следующей версии когда-нибудь потом за отдельные деньги". Главная проблема не деньги а именно это самое "потом": ресурсы уже забукированы на что-то другое, доделать некем, а в результате полезность просто рассыпается. Может, у Вас в курсе это есть, просто в другом месте. Но грабли очень проблемные.

Это в курсе контролируется через понятие целевой системы: при обсуждении ЖЦ, его практик, целевой системой всё одно является то, над чем эти практики работают. И вся полезность именно там. "Мы сделали всё по плану" это уже а) управление работами, ибо план это не ЖЦ, и б) целевая система в этот момент забыта, потому как план это одно из описаний обеспечивающей системы. То, что целевая система не забывается, жёстко контролируется. Так что "потом" не проходит, всё контролируется прямо сейчас, на каждом такте.