alexthunder: (Doctor)
Вот что ещё хотел рассказать. Я заметил за собой что рассказывать стало интересно вобщем-то об одном - о том как мы думаем и что из этого получается, и как легко мы сами себя постоянно обманываем и этот обман называем жизнедеятьельностью.... Но рассказать я хотел в этот раз об одной частной особенности нашего сознания. Я называю это - Феномен "качели".

Давным давно было изобретено простое устройство для развлекания детей. Оно представляет собой кусок бревна положенный на другой кусок бревна. "Качель" называется. Вот для иллюстрации картинка чтобы легче было представить.



Представим теперь что человек смотрит только на одну сторону качели за раз. И человек решает "Хорошо - вверх, Плохо - вниз!" Простая такая формула, правда же.

Смотрит человек на одну сторону качели и видит - "Вниз. Плохо. Надо исправить и сделать вверх." Исправляет ситуацию. Всё становится хорошо - качеля вверху.

Позже он обнаруживает для себя другую сторону качели и история повторяется. И потом ещё раз. И ещё раз. И ещё раз...

И вот так работает применимо к системным задачам подход "Решать проблемы по мере поступления, методом одну за раз." в таком вот простом "народном" его понимании. Нет в самом подходе нет никакой проблемы - всё правильно с подходом. Но вот с его применимостью не всё так просто.

Качель - устройство очень простое. Связь между двумя его сторонами очевидна даже... ну впрочем может быть что найдётся кто-то кому даже и эта связь не очевидна. Качель - это только иллюстрация. На деле устройства и системы попадаются куда сложнее и связь между двумя сторонами вот как на качеле увидеть удаётся не всегда и не каждому. Но вот что качель хорошо иллюстрирует так это различие между частью и целым.

Ходить от одного края качели к другому пытаясь устранить очевидную проблему вида "Вниз - это плохо, надо чтобы вверх!" можно бесконечно долго. И проблема не будет решена никогда. Хотя на каждом шаге будет возникать не только ясность осознания проблемы, но и очевидность применимости решения. Разница по принципу "было, стало" - очевидна. Эта разница даёт ощущение достигаемого прогресса и подтверждает правильность выбранного метода решения. "Стало лучше!" оказывается справедливым сказать буквально на каждом шаге. Если никогда не принимать во внимание систему целиком, тоесть не рассматривать обе стороны качели одновременно, то создаётся иллюзия продуктивной деятельности. Вот за эту иллюзию человечество восновном и горбатиться сегодня!

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

Стоит заметить что сложность конструкции "качели" при этом может быть любая. "Концов бревна" может быть и два и три и миллиард. И это только кажется что количество наблюдаемых индикаторов и факторов влияния принципиально что-то меняет. На самом деле - "таже самая качель" только сложнее устроенная.

Так вот, по моим наблюдениям, многие люди берущиеся за решения сложных задач на самом деле не имеют способности отличать систему от её части. Это не значит что они плохие люди или какие-то ущербные. Хорошие все люди! Просто вот кому-то эволюция дала талант композитора, а кому-то другой талант. Не все люди умудряются найти своему таланту подходящее применение и берутся за то что кажется им посильным. И бывает что ошибаются. Им кажется что у них это хорошо получается, а на самом деле - "феномен качели". Но осознать это им не позволяет всё таже самая трудность - не видят систему, видять только отдельные её детали. Одну за раз.

Попытка перехода от части к целому для многих оказывается в том что ввести себя в заблуждение оказывается есть масса способов. Так например иной "аналитик" пытаясь перенести фокус внимания от описания части к описанию целого начинает расширять описание части подробностями. Это создаёт иллюзию сложности. Ну тоесть описание проблемы обрастает такими данными как цвет бревна, его длинна, скорость движения сверху вниз, время когда было осуществлено перемещение, наличие на конце бревна мягкого сиденья, температура воздуха, матерьял, толщина бревна, порода древесины... Список можно продолжать бесконечно.

Очевидно что добавление деталей в описание наблбюдаемой проблемы с одной стороны качели никак не упрощает решения. Очевидно что и проблемы самой это никак не описывает. Очевидно что практически все такие делати лишь отвлекают от главного - от описания того свойства качели что собственно проблему создаёт изначально.

Очевидно кому?

Вот оказвыается что далеко не всякому это очевидно.

Попытку объясниться по существу проблемы между видящим качелю целиком и видящим только одну её сторону я называю теперь - "Феномен качели."
alexthunder: (mkrot)
Обещал поделиться ссылками на интернет-ресурсы которые были предложены в качестве дополнительных источников информации по теме SCRUM тем кто мне читал курсы.

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



1. Scrum Alliance



2. The New New Product Development Game - by Hirotaka Takeuchi, Ikujiro Nonaka

Это одно из печатных произведений давшее методике развитие. Впервые вышедшее в свет в 1986 году.

3. Страничка о самом изобретателе SCRUM - Jeff Sutherland

4. СТраничка о дядьке который сформулировал часть идей и принципов методики SCRUM в том виде как они применяются сегодня - Ken Schwaber

Остальное буду выдавать порциями по мере поступления.
alexthunder: (Default)
SCRUM - часть 1 - "Почему SCRUM?"
SCRUM - часть 2 - "Состав участников"
SCRUM - часть 3 - "Конечный продукт"
SCRUM - часть 4 - "Спринт"

Ещё одна часть методики SCRUM не рассказав о которой не стоит затевать историю про сам процесс с его ритуалами.

Product Back Log - мне хочется это по-русски назвать как План Развития Проекта. И за одно о процессе работы над ним и о том насколько это важно и почему.

Для тех кому это может быть интересно )
alexthunder: (mkrot)
Previously in SCRUM...

SCRUM - часть 1 - "Почему SCRUM?"
SCRUM - часть 2 - "Состав участников"
SCRUM - часть 3 - "Конечный продукт"

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

В этот раз я хочу подробнее рассказать о том что происходит в одном Спринте методики SCRUM.

Тем кого орагнизация коллективного производительного труда не интересует читать не обязательно )
alexthunder: (mkrot)
SCRUM - часть 1 или "Почему SCRUM?"
SCRUM - часть 2 - "Состав участников"

Основной идеей SCRUM в отношении производимого продукта является его последовательное развитие. Исходит это из предположения о том что работа штука затратная. Каждый потраченный час занятия людей чем-то обходится не дёшево и потому желательно устранить занятия которые потенциально не добавляют ценности конечному продукту или могут оказаться не нужными.

Продукт производимый методикой SCRUM после каждого короткого периода работы рассматривается как потенциально-продаваемый по сути законченный продукт.

Дальше с картинкой и подробнее )
alexthunder: (Default)
Подолжение того что начато было вот тут.

В этот раз я хочу рассказать о составе участников методики SCRUM ("Скрам").

Сразу хочу поставить ударение на том что ключевым моментом эффективности методики является СМЫСЛ того что делается и зачем. Протокол и форма предлагаемые методикой лишь являются выражением этого смысла. Тупое соблюдение протокола без преследования смысла неминуемо приведёт к профанации и потере эффективности.

Как говорят классики этого жанра - "Если вы видите что что-то не работает и надо что-то менять - меняйте свою организации, не пытайтесь менять Скрам"

Невозможность применения Скрам организацией как правило является индикатором серьёзных дизфункций в её структуре или кадровом составе. Чаще всего организации пытающиеся применять Скрам натыкаются на эти дисфункции и делают вывод что Скрам им не подходит. Большинство из таковых стремятся скорректировать протокол лишив всю методику смысла и тем самым превращают свой метод работы в "Скрам-бат". Так и говорят в таких случаях - "We are using SCRUM but..."

И так о кадровом составе методики SCRUM )
alexthunder: (mkrot)
Расскажу всёже про SCRUM. Кому интересно занимайте места поудобнее и насыпайте поп-корн. Кому не интересно - проматывайте сразу, не тратьте зря время.

Начну с того ЗАЧЕМ вообще был придуман SCRUM )

Profile

alexthunder: (Default)
alexthunder

February 2017

S M T W T F S
    1234
567 891011
12131415161718
1920212223 2425
262728    

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 24th, 2017 07:23 am
Powered by Dreamwidth Studios