Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Карго-культ управления проектами

Только что вернулся с конференции AGILEEE 2011. Очень интересная вышла конференция, спасибо организаторам: познакомился и пообщался с множеством интересных людей; обсудили животрепещущие темы, и даже собрали с Сергеем Прохоренко мини-jam колумнистов DOU :)

На слайдах большинства докладов присутствовали завлекательные фразы типа «Management 2.0», «Motivation 3.0» и даже загадочное «Management 3.0, v1.20». Ну и неизменные слова «The Next Big Thing», сопровождаемые неизменным же знаком вопроса. Все, похоже, ждут следующей большой вещи в управлении проектами, но никто не знает, где её, эту вещь, искать.

Ещё одним из трендов конференции были со смехом рассказываемые — и с трибуны, и в кулуарах — истории про команды, которые внедрили у себя «типа-скрам» (или «типа-эджайл», или типа-что-нибудь-ещё), но на самом деле воспользовались только одним-двумя ритуалами оттуда, и, конечно же, у них ничего не получилось. Менее продвинутые скрам-тренеры в этом месте настаивали на применении всех практик скрама или икспи одновременно. Более продвинутые скрам-коачи — рекомендовали сосредоточиться на принципах манифеста эджайл — ну и конечно же, применить все практики выбранного эджайл-метода. И пренебрежительно отзывались о тех, кто этого не делает, как о карго-культистах, применяющих методы как ритуалы и надеющихся, что ритуалы эти приведут к успеху.

Здесь — как по мне — лежит основная опасность. Уважаемые мои коллеги, менеджеры, мастера и прочие аунеры — не повторяем ли мы ту же ошибку? Чем, как не карго-культом является наше стремление повторять практики ли, принципы ли только потому, что они выглядят разумно и срабатывают для кого-то другого? Что мы знаем о том, почему тот или иной метод управления проектом, та или иная методология срабатывает здесь и сейчас (и почему она должна продолжать срабатывать завтра и там — что даже более интересно?)

Что мы знаем о границах применимости методологий? Утверждение Алистера Коберна о том, что чем менее критичен продукт (т.е. чем меньше денег и человеческих жизней будет стоить ошибка в нём) и чем меньше количество людей в команде проекта — тем более важным представляется эджайл-методология, выглядит очень логично, и соответствует моим личным наблюдениям, например. Но откуда мы взяли, что это эмпирическое правило будет выполняться всегда?

Что у нас есть в качестве обоснования методов и методологий? Не менее эмпирическая наука психология, которая, похоже, кое-как работает для одного человека и для большого коллектива (желательно толпы), но толком не разработана для средних размеров команды? Статистика, которая, как известно, является одной из разновидностей лжи? Ну и теория ограничений Голдратта — по-моему, единственная наукообразная теория в управлении на сегодняшний день.

Не логично ли было бы искать The Next Big Thing именно здесь? Искать законы, которые объяснят (и докажут!), почему что-то работает в одних обстоятельствах и не работает в других. Строить на основе закономерностей фреймворки для управления проектами, позволяющие достичь успеха с максимальной вероятностью. И понимать, почему и зачем мы делаем то, что мы делаем.

А пока что мы, точь-в-точь как туземцы, строившие фанерные макеты самолётов и надеявшиеся, что прилетят белые боги и принесут много-много вкусной сгущёнки — продолжаем предпочитать людей и взаимодействие процессам и инструментам. И надеяться, что пронесёт и проект удастся и в этот раз.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



85 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Скрам — это бардак, особенно в наших реалиях. Он идеально подходит для бесконечных проектов (ни сроков, ни фиксированного бюджета) — безусловно, более выгоден компаниям (меньше головной боли). Scrum Master — это скорее тим-лидер, но никак не ПМ. О нормальной документации можно только мечтать. И ЭТО называется проектами...

Охотно верю, что в ваших реалиях скрам — бардак.

Имхо, сильно зависит как от реалий, так от скрама. Так что нечего на скрам ответственность сваливать.

В наших условиях (проекты от 2х до 4х недель) — скрам работает прекрасно.

проекты от 2х до 4х недель
спасибо, посмеялся :) Неужели уже и в такие «проекты» скрам впихнули?
Да. Как я и говорил, работает у нас прекрасно.

А у вас хоть что-то хоть где-то работает?

Да. Как я и говорил, работает у нас прекрасно.

у вас — это где? в индустрии выдачи сертификатов-фантиков?

А у вас хоть что-то хоть где-то работает?

что-то где-то как-то почему-то работает, да

Уважаемый ZaQ, я кроме ScrumGudes работаю ПМом в компании, которая пишет свои продукты.

И ещё у меня есть стартап, где мы тоже пишем. Вот там случаются проекты на заказ по 2-4 недели, и именно там скрам сработал отлично.

Кстати, в индустрии сертификатов фантиков скрам рановат, потому что процесс выдачи сертификатов-фантиков далек от стабилизации. Если вы понимаете, о чем я.

ну я предполагал, что вы не только фантики выдаете, а еще и занимаетесь полезной деятельностью, потому и решил уточнить.

работаю ПМом в компании

которая пишет свои продукты

стартап

я не сомневаюсь, что вы инициативный человек и это правильно, но вот подача достижений тоже порадовала :)

Коментар порушує правила спільноти і видалений модераторами.

наконец-то кто-то об этом написал :) agile/scrum хороший инструмент, но уже порядком начали доставать клоуны с эджайлом головного мозга, которые кроме уверывания в «святой скрам» ничерта не умеюи и не понимают.

Может пару имен назовете?
А то честно говоря занадаело уже.

Я видел на порядок больше народа с пиэмаем головного мозга, которые гнобят команду и лижут задницу начальству. Буду ждать, когда Юра об этом напишет.

Ха. Да, у меня аджайл головного мозга, и я этим горжусь.

По-поводу «типа-скрам» — давно существует термин «scrum butt», выросший из фразы: «we have scrum but...». Как раз о чём вы рассказываете.

На мой взгляд, многие не понимают, что scrum есть переложение принципов «бережливого производства» (Деминг, «Дао Toyota» и т.д.) на разработку ПО. В «бережливом производстве» конечно есть принципы, но, как я понял, процесс производства у всех уникальный. И это также нужно понимать выстраивая у себя процессы.

Принципы Lean во многом схожи с Agile (я как раз был на докладе сенсея Тойоты на эту тему на Agile 2011), но фокус отличается. Если говорить о процессах, то больше всего соответствует Lean-у не Scrum, а Kanban.

Несомненно, фокус отличается :) Я когда работал в последней компании, по аналогии с Toyota Production System, назвал нашу систему CompanyName Production System, которая состояла из большого набора best practices (к которым, я с лёгкой руки и отношу scrum).
Best practices, опыт, здравый смысл, желание разобраться в сути (откуда растут ноги у того же scrum) вот что должно быть положено в основу производственного процесса.
А не создавать новый фетиш, которым по сути сейчас является scrum (о чём, собственно, и говорит автор статьи).
Все привязались к переводу слова Agile — гибкий. И здесь, на мой взгляд, многие делают ошибку. Не «гибкий», но «адаптивный» — приспосабливающийся. Вот таким должен быть ваш процесс — адаптивным к проекту, команде, ситуации. Не просто scrum, но YourCompanyName Production System.

У нас такой и есть, спасибо :)

Алистер (я им уже, наверное, всех задолбал :)) о том же говорит: «there are only two rules: don’t get fired and don’t go to jail».

«ваш процесс» это я, конечно, не конкретно к Вам обращался, а больше к человечеству :) А то ещё подумайте, что я Luxsoft учить собрался :)))

Коментар порушує правила спільноти і видалений модераторами.

Привет, Юра,
Поддерживаю. Пробовали скопировать шаманство по всем канонам — не пашет. Подумали головой на тему: а что же нам надо, подкрутили, осознали — работает. Опытным путём, угу, с шишками.
Моё же скромное некомпетентное мнение состоит в том, что мы работаем не с процессами, а с людьми. С их тараканами, страхами, стремлениями. «Голова — предмет тёмный и исследованию не подлежит», так что не уверена, что когда-нибудь математика или другая идеальная абстракция предоставит формулу, применимую к любому случаю. Недавно читала о том, что уже и ограничение скорости света под вопросом. То ли действительно кварк разогнали, то ли ошибка вычислений :)
Так что поиск прекрасного, простого и элегантного решения оставляю теоретикам. Всенепременно воспользуюсь, ежели найдут. А пока буду думать. И с головой применять, искать и делать.

irinaz1983

Угу. Про работу с людьми, а не процессами — очень правильное замечание.

Только не стоит тогда говорить, что мы можем что-то «обеспечить» и «гарантировать»

Scrum TM — ценник 1800$, если не ошибаюсь.

Ошибаетесь.
Scrum TM — не продается.
Certified Scrum Master (семинар + экзамен) — $700-$800

Certified Scrum Product Owner (семинар + экзамен) — $1150

Просто экзамен на PMP стоит $550.

Ошибаетесь.
Вы всегда все буквально воспринимаете? :)
Certified Scrum Master (семинар + экзамен) — $700-$800
Certified Scrum Product Owner (семинар + экзамен) — $1150
Просто экзамен на PMP стоит $550.
а вот и прайслист
Я воспринимаю то, что написано.

Вы имели в виду что-то другое под «Scrum TM — $1800»? Пожалуйста, поделитесь.

если бы было написано «iPhone TM — ценник $800» вы бы тоже поняли это буквально как ценник прав на торговую марку?

Если команды и людей покупают, потому что они Scrum TM (как и iPhone TM), то не вижу в этом ничего плохого.

С другой стороны, не знаю ни одного заказчика или компании, которые бы переплачивали за Scrum TM. Может быть вы знаете?

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

Может быть вы знаете?

знаю

Ошибаетесь.
Scrum TM — не продается.
Какой процент не сдавших экзамен?
Ну экзамен по крайней мере есть:

www.mountaingoatsoftware.com/...crummaster_test или www.scrumalliance.org/...on_changes#exam

Процент несдавших мне неизвестен. Те, у кого есть такая информация, находятся здесь: www.scrumalliance.org

Есть подозрение что процент таки нулевой:

You cannot “fail” the assessment as you could a university course. Instead, the assessment will help you determine how well you understand Scrum and help you identify any knowledge gaps you may have.

Да, когда-то CSM таким страдал. Я например вообще никаких экзаменов не сдавал на CSM.

Но если интересно, стоит все-таки спросить у СкрамАльянса. Там черная юзервойсовская закладка Support есть справа как раз для таких вопросов.

Алистер на своем курсе достаточно ясно выразился, что завалить тест нельзя. Более того, он даже рекомендовал отвечать неправильно, чтобы еще раз почитать правильные ответы (по мнению СкрамАльянса).

Элистеру как конкуренту СкрамАльянса есть прямой резон ругать их сертификации.

Что не отменяет факта, что он похоже прав. Как всегда ))

Понятно, типичный гербалайф.

Не знаю, о каком тесте может идти речь, когда уровень вопросов ниже плинтуса и завалить, как уже тут упоминали, нельзя. Да и о какой сертификации мы можем говорить, если людям несколько дней дают теорию, проводят откровенно слабый тест и потом они выходят «типа» CSM. У меня жена так стала CSM. Глупости вся эта сертификация, если ее может пройти почти любой человек с улицы, заплатив деньги. Так что, его тоже можно допускать к боевым проектам?

Давайте называть вещи своими именами — люди просто зарабатывают деньги. Agile — да, хорошо, а вот сертификация — туфта.

Александр, а что с Вашей точки зрения нужно делать с людьми, чтобы их можно было после этого допускать к боевым (аджайл)-проектам?

Я не Александр, но попробую ответить:

То же что и в любой другой сфере деятельности — курсы, потом годик-другой джуном (смотреть но руками не трогать), потом годик-другой уже с ответственностью но под присмотром (пусть и чисто формальным), а потом самому.

Два годика смотреть, но руками не трогать? Неслабо. Что же вы такое разрабатываете?

А чему и как стоит учить такого человека, с Вашей точки зрения, чтобы как можно скорее его в бой отправить? Это я про курсы.

Цифры с потолка, если вам будет более понятно, замените «годик-два» на «некоторое время».

А чему и как стоит учить такого человека, с Вашей точки зрения, чтобы как можно скорее его в бой отправить? Это я про курсы.

Не какие курсы, универы и тд не сделают готового спеца, они должны дать базу. Возвращаясь к сертификатам, сертификат (диплом и тд) актуален только когда нечего больше «показать», то есть по факту для джуна; или в специфичных областях (типа безопасности).

Артем, как и в случае с обычными PM’ами все решает опыт человека, его готовность и т.д. Все же как-то переводят со временем разработчиков или QA, которые имеют некоторую предрасположенность и базовые навыки, в менеджеры проектов или на другие должности. Так и со Scrum Master.

Также многое зависит от текущего уровня и знаний. Например, если человек уже PM, то ему в общем-то не нужно долго учиться для того, чтобы стать SM. Прочитал книгу-две, возможно, послушал курсы, начал применять на практике. С человеком, у которого этого опыта нет, все будет не так просто. Хорошо, если он просто наломает дров, а потом научиться на своих ошибках.

Проблема не в том, что не нужно учить людей быть Scrum Master’ами или еще кем, НУЖНО, а в том, что не нужно выдавать им сертификаты и лычки без настоящего подтверждения их навыков, на базе небольшого теоретического курса и краткого теста. Это еще хуже, чем получение водительских прав. Итогом такой политики станет лишь недоверие к такой сертификации. Хотя многие и так уже понимают, что это лишь маркетинг для клиентов (на вашем проекте будет работать сертифицированный специалист) и зарабатывание денег. Доверять лычке CSM не стоит, нужно проверять практический опыт кандидата.

Я могу судить по себе: мне CSM-курс лично мне добавил много в понимании Agile и управления проектами. Я после него определенно стал лучшим ПМом, чем до.

Я тоже когда прочел несколько книг и кучу статей по Scrum, XP, Kanban, а потом еще посетил несколько докладов на разных конференциях, стал намного лучше понимать процесс разработки и то, что agile может в него привнести. И я считаю, что это правильное направление в IT, хотя и не все проекты можно и нужно делать, используя Agile-подходы, хотя некоторые тренера и коучи и пытаются доказать обратное. Если человек понимает, зачем используется та или иная практика или подход, и знает ее положительные и отрицательные стороны — тогда он может использовать ее грамотно, как и любой другой инструмент.

Наверное, не совсем правильно будет распространять сертификационный бизнес ScrumAlliance на всё Agile-сообщество ;) Ребята распиарили свой бренд, стригут на нем денежки — их право, вообщем-то. Грамотный работодатель все равно будет смотреть на опыт и знания кандидата, а не на бумажки.

В свое время, кстати, именно из-за бизнеса по «натаскиванию» на экзамены обесценились, как подтверждение знаний и умений, и Майкрософтовские сертификаты.

Кстати, СкрамАльянс — та еще контора, там уже ни Швабера, ни Сазерленда не осталось. Поэтому их «корочки» и хэндбуки — не более, чем личное мнение некоторых тренеров.

А если бы они там остались, то их корочки и хэндбуки стали бы божественным откровением?

Я этого не говорил.

я и не говорю что говорили.

Ну вот Certified Scrum Trainer и Certified Scrum Coach пока еще чего-то стоят (из-за гораздо более сложной процедуры подтверждения знаний и навыков, а также требований к практическому опыту). Но фишка в том, что ни одного CST или CSC в Украине или РФ нет ;)

Юр, у меня несколько мыслей:
1) ТоС — наукообразна??? ТоС, в основе которой высосанная из пальца метафора? Ну-ну. Хорошо хоть не научна.
2) А Теория Адизеса — недостаточно наукообразна?

3) Социология — эмпирическая псевдонаука??? Психология — эмпирическая псевдонаука????? Да там научности больше раз в 100, чем во всех менеджментах вместе взятых!

А вообще в психологии есть (псевдо)понятие психических уровней. А именно: действия — навыки — убеждения — ценности — идентичность — миссия. Меняются легче те, что слева, а влияют сильнее те, что справа. Сложно (если вообще возможно) скопировать ценности (ака манифест). Гораздо проще скопировать действия, а потом вверх по всей цепочке, добраться и до ценностей.

Поэтому логично, что мы копируем аджайл-практики.

А вообще у меня есть ощущение, что где-то все это описано где-то в 1980-х. Примерно вот тут: www.ozon.ru/...ail/id/2338486

А, и ещё у Элистера есть как раз на эту тему статья: www.maxkir.com/...onlinearRUS.htm

Артём, ушёл читать по ссылкам, спасибо... чтобы обнаружить, что эти статьи и книги я читал и уважаю :)
1. Некоторые положения ToC вполне научны. Моё математическое образование вполне позволяет свести цепочку обработки... да хоть к конечному автомату. В любом случае, утверждение, что «бутылочное горлышко» определяет производительность всей системы (да и сам вид этой зависимости) легко выражаются уравнениями.
2. Теория Адизеса именно наукообразна. Как известно, существует множество несколькофакторных способов рассмотрения личностных особенностей (вплоть до соционики). Правда, в отличие от соционики, Адизес удосужился подтвердить свою теорию наблюдениями. И она работает, что, безусловно, плюс. Хотя и не доказана строго, что, конечно же, минус — а, значит, может уйти со сцены так же, как теория эпициклов Птолемея после Коперника :)

3. Социология и психология (за исключением клинической) — на сегодняшний день — описательные науки. И естественно, их выводы представляют собой в основном эмпирики. А вот с псевдонауками ты передёргиваешь :)

Впрочем, вполне возможно, что именно возрастающая сложность наших систем не позволит строгого научного к ним подхода. И тогда SuHaRi — это всё, что нам остаётся; но всё же это подход к искусству, а не к науке...

Ну, все это, конечно, звучит очень хорошо — но куда деваться от объективного факта, что вся психология и социология именно что ползучая эмпирика и карго-культ? Так что шансов найти точное решение в одном из подразделов ровно ноль. А когда (если) эти науки перестанут быть эмпирическими... полагаю, человеческое общество изменится до такой степени, что не до скрама с эджайлом будет :))

Куда деваться? Работать над этим, вот и всё :)

Кроме ответов «как» искать ещё и ответы «почему». Вот здесь мне кстати очень Голдратт нравится.

Работать и строить-то все равно придется на зыбучем песке современной психологии и социологии. А значит в лучшем случае получится непонятно-как-стоящая башня очередного эджайла (что само по себе неплохо, но поставленной задачи не решит :))

С другой стороны, это тоже вариант.
Если признать, что управление проектами — это карго-культ, и мы не понимаем, почему нам удаётся то или иное действие — алгоритм работы тоже проясняется.

Постоянно пробуем, отслеживаем обратную связь, будучи готовы в любой момент всё поменять. Не верим без проверки никаким методикам, даже если они работают для всех вокруг, и даже если сработали для нас самих в прошлый раз. Все проекты разные; все команды неодинаковые. И вообще управление проектами есть искусство.

Юра, а что ты из Голдратта пробовал? ДТР строить? Или конфликты решать «тучами»?

Деревья строить пробовал. Несколько раз. Помогает, действительно :) В последний раз очень забавно получилось — начали смотреть, почему почти завалили релиз, а оказалось, что причина в отсутствии в команде Project Coordinator’a. «Потому что в кузнице не было гвоздя...»
Кстати, Артём, спасибо за — помнится, именно ты мне на тренинге впервые показал эти деревья :)

А вот конфликты с тучами у меня как-то не решаются.

Долой шаманство из управления проектами.

Уберем шаманство — не останется вообще ничего?

Только мне кажется что изучением теории управления айтишными командами занимаются только менеджеры с избытком свободного времени на основании опыта людей которые просто пробуют разные подходы с разными командами и не сильно заморачиваются теорией?

И, да, отдельный пункт — качество отечественных скрам коучей. Если в цивилизованном мире серьезным тренером обычно называется консультант с десятками (а то и сотнями) успешных внедрений и 10-20 годами опыта, то в случае украинского или российского рынка — это, зачастую, пресловутый «23-летний сеньор», поработавший пару лет менеджером «крупных проектов» (на 10-20 человек, в лучшем случае) и возомнивший себя крутым профи в управлении large scale enterprise projects, способным раздавать советы «космического масштаба и космической же глупости» ©

отлично!

Друзья, а что у вас за собирательный образ коуча такой? Вас кто-то лично обидел из них?

хорошо ещё если так, а то бывает заменяют «поработавший пару лет менеджером» на прочитал 5 книжек по аджайлу.

Алистер, как раз, против затыкания всех дырок одной затычкой. Он даже докторскую по этой теме защитил, да и его Crystal как раз об этом.

Проблема, как мне кажется, здесь в терминологии — многие считают (и ScrumAlliance их в этом заблуждении поддерживает), что Scrum — это методология разработки. На самом деле, это «reflective improvement framework» (сорри, что опять ссылаюсь на Коберна, но точнее не скажешь). И принципы Скрама очень простые и совершенно не навязывающие какие-то конкретные практики. Вся же шелуха типа Scrum Primer, Scrum Handbook и методичек Лармана и Книберга — это не более, чем собрание неких техник, которые успешно сработали в одном (десятке, сотне) проектов, но не факт, что сработают в вашем конкретном случае.

Собственно, основная ценность Скрама в том, что он, как зеркало, показывает неэффективные места в текущем процессе. Как этот процесс улучшать — каждый для себя решает сам, и слепое копирование чьих-то техник (тот самый карго-культ) тут не поможет.

Ага, полазил по ссылкам про Коберна и Кристал — нашёл много интересного. Похоже, что некоторые вещи лучше узнавать из первоисточников, чем из перевранных методичек. Это уже куда ближе к науке, как я её понимаю. Спасибо, буду читать Коберна и о Коберне.
Несколько смущают, правда, цитаты типа «It’s based on observations of many successful teams. You can read the surprisingly entertaining story of Alistair’s observations here. This background gives Crystal a sounder base than most competing methodologies, which typically trace their roots back to a smaller number of projects.»

Т.е. опять эмпирика. А хочется знаний и объяснений. А то, как водится, сеанс чёрной магии провели, а про разоблачения забыли :)

А хочется знаний и объяснений.
Боюсь, не доживем. Сложность задачи растет экспоненциально с ростом размера проекта и его критичности, т.к. «anything depends on everything».

Да, это похоже на правду. Придётся жить в реальном мире, без объяснений; и принимать, что управление проектами есть искусство :)

Ключевое слово заметки — сгущёнка...

Супер, поддерживаю. А то действительно у многих помешательство на модном слове скрам и многие даже и не думают а нужены ли эти все практики для конретно этого проета или команды..

А причина одна...

dilbert.com/.../1051.strip.gif

P.S. Макс, имей совесть, добавь тег img!

Хаха, у автора явный конфликт интересов, т.к. при внедренном скраме он может оказаться не нужен. Возможно поэтому и такая поверхностная статья содержащая исключительно воду.

при внедренном скраме он может оказаться не нужен.

Он просто назовет себя скрам-мастером :) как это делали все до него.

При этом потерят большую часть decision making полномочий что сделает его совсем не таким крутым перцем.

При чем тут крутизна?

Не понял вопроса. Вроде очевидно что у большого начальника детородный орган намного больше чем у скрум мастера исполняющего чисто механические обязанности и которого могут через годик коучинга заменить на ротацию.

Идите и сделайте лучше. Не можете сделать лучше? Тогда просто идите.

Для тебя эта тема я вижу тоже болезненна

Хорошо, что есть люди, способные мыслить критически... А то с кем из новых менеджеров не поговоришь, все помешались на модном нынче SCRUM, Agile, как на религии. Я не отрицаю, что они полезны во многих ситуациях и реально работают в большинстве случаев. Но это из разряда, когда есть костюм одного размера и в него пытаются одеть сначала щуплого подростка, а потом дяденьку ростом свыше 2м и весом свыше 120кг. Один влазит, но смотрится нелепо, на другом все швы трещат и движения сковывает... К чему эта аналогия и что я пытаюсь этим сказать? Вместо «серебрянной пули» и панацеи от всех бед искали бы лучше здравый смысл, что применимо в одних условиях, а что нет. Вот как-то так.

СКРАМ и прочий эджайл мне как раз нравится. Потому что — в отличие от диаграмм ганнта и прочих планов коммуникаций — эджайл обычно срабатывает.

Не нравится мне то, что это всё пытаются объявить серебряной пулей. И занимаются консультациями по внедрению, даже не пытаясь искать объяснения, что, как и почему.

Именно это я имел в виду

Юра, это пять! А я-то думал, что я один такой скептик:). Фуууух, аж полегчало:)

Предпочитаю всё же быть не скептиком, а реалистом. А реалист во мне говорит, что не всякий прибор, снабжённый электрической розеткой, является вечным двигателем. Более того, скорее он вечным двигателем не является, и в лучшем случае у него внутри аккумуляторы, а то и хреновые китайские батарейки. И то, что я успешно зарядил от него три раза айфон, совершенно не означает, что заряжу и в четвёртый. И неплохо бы научиться определять уровень заряда и подзаряжать при необходимости, например.

Так что умения применять четыре принципа и десять практик скрама мне уже мало. Хочется понимания, когда и зачем их применять (или не применять)

Делал доклад как раз на эту тему на одесском IT Jam в августе. Приятно видеть единомышленников!

А слайды от доклада или запись нигде не выложены? Было бы интересно посмотреть :)

Слайды будут, мне только нужно будет их подчистить.

Підписатись на коментарі