man_with_dogs: (Default)
[personal profile] man_with_dogs
Нашёл в сети объяснение, почему Нокия так лихо пролетела со смартфонами.
http://www.rsdn.ru/forum/management/4315751.flat.aspx
Она, де, использовала технологию разработки scrum, которая годна для потокового производства с малыми творческими вложениями в результат, в то время как тот же Гугль позволяет работникам часть времени заниматься, чем вздумается и как им самим вздумается.


shrecher, Дата: 20.06.11 03:32
Здравствуйте, SkyDance, Вы писали:

SD>В scrum — пишутся user stories, оцениваются — и попадают в нужное место backlog'а. В зависимости от того, идет ли time-driven или scope-driven, что-то меняется (scope или time соответственно).

Это все так если разработка-фабрика: потоковое шлепанье формочек и фичек. Очевидно, что разработка программного продукта далеко не фабрика (конечно, если не аутсорс). Это исследования, творчество, сложные проблемы и пр. Да, Scrum удобен для менеджмента, но полностью душит творческое начало. Отсюда и проблемы.

Если посмотреть как работают истинно инновационные компании (dropbox, google и пр.), то там предоставлена свобода программистам самим решать как им работать (и даже "что" собственно делать). В результате он выдают новинки на гора.

Как пример, Нокия (активный апологет скрама) за последнии 10 лет так и не смогла сделать ничего инновационного, с другой стороны пришел Гугл и за три года сделал конкурента, который вышиб Нокию с рынка. Тут, конечно, не только виноват Скрам, но то, что он душит творчество это факт.


Если же вернуться к нашим баранам в высшем управлении экономикой и политикой, то там про такое наверняка даже не подозревают - что есть какие-то технологии, кроме приказ-отчёт. В таком виде и Сколково своё строить собираются. Технологии управления и работы уже где-то за горизонтом, а эти так и застряли в начале 20 века. Так и напрашиваются на сравнения с 1913 - чё хоть достигли по сравнению?

Добавлю из того же обсуждения немного контекста и местного колорита (который не только во власти, но и в конторах разработки ПО - манагеры те же самые, с теми же методами бестолковщины):

От: SkyDance
Дата: 15.06.11 03:05
Ну и верно было отмечено, что скрам нельзя просто "взять и внедрить", ничего хорошего из этого не выйдет. Нужен человек, хорошо понимающий тонкости процесса. Уже наступавший на грабли, и обязательно видевший примеры успешного и неуспешого применения. Я видел и то, и другое. И видел совсем занятный fail скрама благодаря стараниям менеджмента В общем, книжки можно писать сколь угодно большой длины, но заработает скрам только тогда, когда будет ЖЕЛАНИЕ иметь открытый и контролируемый процесс. Причем желание — со стороны менеджмента. Мой опыт показывает, что в большинстве случаев "линейному менеджменту" в России выгоднее иметь очень мутный, сложный и странный процесс разработки, по которому ничего нельзя сказать без вопросов непосредственному начальнику проекта. Поэтому любые попытки ввести прозрачный процесс (неважно, скрам или что угодно еще) будут пофейлены.

От: bkat
Дата: 15.06.11 15:54
Сам по себе скрам вполне можно юзать.
Для небольших команд (5-6 человек) вполне применим даже в том виде,
как его подают на курсах/презентациях и прочих "рекламных" акциях.

От: SkyDance
Дата: 16.06.11 03:34
Если команда является частью "чего-то бОльшего", да еще и с какой-нибудь "традиционной" (С) иерархической структурой, контролируемой по принципу "я начальник — ты дурак", то тоже ничего не выйдет.
Рамки применения SCRUM все-таки достаточно узкие. Он пойдет только в том случае, если целью является предсказуемный процесс и результат.

От: SkyDance
Дата: 16.06.11 10:17
Оценка: 2 (1)
B>На словах все процессы говорят о предсказуемых процессах и результатах.
B>Никто не декларирует своей целью хаос и банкротство.

Ага. "Но есть один нюанс" (С). Со scrum процесс действительно предсказуем — видна velocity и виден scope. Любое изменение в scope сразу же наглядно показывает съезжание сроков. Любые изменения в составе команды — аналогично. Практически realtime planning. Настоящий.

Разумеется, все (в т.ч. waterfall) методологии в теории обеспечивают то же самое. Вот только на практике всего этого добиться невозможно. Можно рассмотреть типовый примеры. Прибегает восхищенный менеджер, и говорит, что все классно, но! Надо вот там еще пимпочку, а тут — крутилку. В scrum — пишутся user stories, оцениваются — и попадают в нужное место backlog'а. В зависимости от того, идет ли time-driven или scope-driven, что-то меняется (scope или time соответственно).

В других моделях — кто что предлагает. Но в столь любимом "военном" RUP'е надо будет проводить change request — менять (апдейтить) спецификации. Проталкивать через все стадии согласований. Я уж не говорю про то, что мегатонны спек читать невозможно (been there, done that — да, если с системой только знакомишься, удобнее читать полную доку, но если ты уже "живешь" в системе — то хочется только краткие diff'ы, апдейты).

Не буду удлиннять и без того длинный пост. Для меня разница есть лишь в одном: я видел предсказуемый процесс и результат с помощью scrum. А вот с другими метОдами — только что-то одно: результат без процессов (зачастую — вопреки "процессам"), либо "процесс", но без результата.

От: SkyDance
Дата: 20.06.11 03:28
G>Построить burn-up и burn-down chart по задачам несложно при абсолютно любом процессе, скрам для этого не нужен. Таким образом люди спокон веков выпуск maintenance release, состоящих их ошибок и доработок, отслеживают.

Можно. Только придется тогда притащить еще кое-что — в частности, гранулярность сценариев (user stories — сильно отличаются от traditional use-cases) и методы оценки в относительных величинах (да, planning poker тоже был известен до скрам).

И "утренние летучки" (stand-up) придумали газетчики-журналисты еще в XIX веке. Оценивать задачи относительно друга (а не выдавать заведомо неверные оценки — см. mythical man-month) тоже уже предлагалось. Но только в scrum эти простые практики собраны и разумным образом увязаны.

От: SkyDance
Дата: 22.06.11 03:14
А> Для средних и больших проектов scrum & agile только мешают.

Конечно, мешают. Чаще всего мешают "манагерам", которым прозрачность в проекте вовсе ни к чему. Такой процесс я тоже наблюдал: применение скрам наглядно показало, что scope проекта с существующими ресурсами ни под каким соусом не может быть выполнен в спущеные сверху сроки.

Как это выглядело до скрам: манагер рапортовал "вроде успеваем", по мере приближения очередного срока релиза оказывалось, что надо отложить, но совсем на чуть-чуть, буквально на месяц-полтора. И так в течение целого года (!!!). После реализации скрам подобный фокус тупо не прошел: было видно, сколько чего сделано, виднА реальная скорость работы (основанная на статистике работы, а не на тех оценках, которые все те же манагеры заставляли (да, именно так, — заставляли) давать. Если интересно, могу описать (хотя я уже несколько раз писал про антипаттерн lie to me).

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

A >А если будем сначала думать, а потом делать, то получим классический водопад, столь ненавидимый шарлатанами от agile.

Да нет никакой ненависти к водопаду Есть любопытство: кто же все-таки первый расскажет и покажет проект, РЕАЛЬНО подготовленный с помощью "водопада" или подобной метОдики. С полным и настоящим соблюдением правил: с реальным разделением ролей, с реальным получением approve'ов, с отсутствием правки спецификаций "задним числом". Разумеется, с соблюдением сроков и бюджетов проекта. Ну хоть кто-нибудь, расскажите же, какой реально существующий продукт хотя бы с пароу сотен инсталляций так сделан? Поделитесь же тайным знанием! Как адаптировали. Как решали проблему ответственности начальства (когда затягиваются или вовсе игнорируются запросы на формальные review созданных документов). Как решали проблему с постоянно идущими change request, когда ближе к релизу чтение первых вариантов спецификаций "доставляло не по-детски": там ВСЕ было СОВСЕМ не так, как пойдет в реальном софте.

Заметьте — я не стесняюсь рассказывать обо всем про скрам. Потому что я видел и участвовал. Но вот противники "шарлатанов от agile" сами почему-то либо молчат, либо рассказывают свои фантазии на тему (например, про то, как у них вдруг неожиданно появляется чудесный "заказчик", который всегда знает, чего хочет, и всегда официально-формально подписывает все положенные документ).


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

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

Всё идёт к тому, что потоп наступит сразу после выборов - когда всё разграбят и пустят народ по миру, как у Лукашенко в Белоруссии. Лукашенке пойти по миру хотя бы "помогли" из Кремля, а тут никто со стороны не нужен - сами всё сделают. Четверть населения уже живёт за чертой нищенства. Уже прогнозы идут по массовому сокращению потребления продуктов питания - т.к. дорого. Из-за воровства путинцев всё дорого, а у людей нет денег.
If you don't have an account you can create one now.
No Subject Icon Selected
More info about formatting

If you are unable to use this captcha for any reason, please contact us by email at support@dreamwidth.org

Profile

man_with_dogs: (Default)
man_with_dogs

December 2011

S M T W T F S
     1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 2728293031

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 21st, 2025 08:36 pm
Powered by Dreamwidth Studios