Jul. 3rd, 2011

man_with_dogs: (Default)
Нашёл в сети объяснение, почему Нокия так лихо пролетела со смартфонами.
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" сами почему-то либо молчат, либо рассказывают свои фантазии на тему (например, про то, как у них вдруг неожиданно появляется чудесный "заказчик", который всегда знает, чего хочет, и всегда официально-формально подписывает все положенные документ).


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

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

Всё идёт к тому, что потоп наступит сразу после выборов - когда всё разграбят и пустят народ по миру, как у Лукашенко в Белоруссии. Лукашенке пойти по миру хотя бы "помогли" из Кремля, а тут никто со стороны не нужен - сами всё сделают. Четверть населения уже живёт за чертой нищенства. Уже прогнозы идут по массовому сокращению потребления продуктов питания - т.к. дорого. Из-за воровства путинцев всё дорого, а у людей нет денег.

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 Sep. 25th, 2017 03:06 pm
Powered by Dreamwidth Studios