МП>>если надо скоординировать работу, то два разработчика списываются или созваниваются друг с другом,
L>Вот начинается. L>Что значит "надо скоординировать работу"? Кто решает, что нужно "скоординировать работу"? Откуда эти два разработчка вообще узнают, что им нужно координировать работу?
если это сеньёры, то сами и решают
мидлы вменяемые тоже могут это осознать
в противном случае — технический руководитель, или тот, кто даёт задачу может подсказать, что за вот этим и этим обращайся к тому-то или тому-то
если есть менеджер в команде — он тоже обратится за оценками или прочим лично к кому-то
МП>>а не слушают по расписанию всю байду которую вещает весь отдел
L>Все ясно. Рабинович напел. карго-культ.
да блин это массовая практика же (надёжный критерий истины)
весь отдел стоит и слушает что там у художников делается
везде где есть скрам там эта хрень и происходит
Re[16]: Scrum не подходит для программной разработки
Здравствуйте, Министр Промышленности, Вы писали:
МП>в противном случае — технический руководитель, или тот, кто даёт задачу может подсказать, что за вот этим и этим обращайся к тому-то или тому-то МП>если есть менеджер в команде — он тоже обратится за оценками или прочим лично к кому-то
И результат всего этого — "почти готово", но за две недели до релиза аврал и перенос сроков на полгода.
Именно отсюда скрам-то и просочился разработку софта.
Не работает это "сами и решают".
МП>>>а не слушают по расписанию всю байду которую вещает весь отдел
L>>Все ясно. Рабинович напел. карго-культ.
МП>да блин это массовая практика же (надёжный критерий истины) МП>весь отдел стоит и слушает что там у художников делается МП>везде где есть скрам там эта хрень и происходит
Это и есть карго-культ. Битлы, напетые по телефону.
Короче, выходит, что ты скрама не видел.
Твоей вины, в общем, в этом нет. Но вот оснований заявлять, что "скрам не работает" у тебя тоже нет
Здравствуйте, landerhigh, Вы писали:
МП>>да блин это массовая практика же (надёжный критерий истины) МП>>весь отдел стоит и слушает что там у художников делается МП>>везде где есть скрам там эта хрень и происходит
L>Это и есть карго-культ. Битлы, напетые по телефону. L>Короче, выходит, что ты скрама не видел. L>Твоей вины, в общем, в этом нет. Но вот оснований заявлять, что "скрам не работает" у тебя тоже нет
А это и есть основная "проблема скрама": на проектах устраивают цирк с элементами скрама типа ежедневных статус митингов на 40 человек, постоянного переноса тасков со спринта на спринт, постоянный scope creep. А потом министры на форумах рассказывают что нофига не работает.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[17]: Scrum не подходит для программной разработки
Здравствуйте, landerhigh, Вы писали:
L>Короче, выходит, что ты скрама не видел.
Ни один истинный шотландец... Каким хорошим может быть скрам, думаю, все и так знают. Проблема ж в применительной практике. И если традиционные методики выливаются в редкие авралы и перенос сроков, то "неправильный" (читай, тот, что будет в 90% компаний) скрам — ежедневый геморрой и раздражение. С точки зрения рядового исполнителя-программиста я не уверен, что второе предпочтительнее.
Re[18]: Scrum не подходит для программной разработки
L>>Короче, выходит, что ты скрама не видел. ECR>Ни один истинный шотландец... Каким хорошим может быть скрам, думаю, все и так знают. Проблема ж в применительной практике. И если традиционные методики выливаются в редкие авралы и перенос сроков, то "неправильный" (читай, тот, что будет в 90% компаний) скрам — ежедневый геморрой и раздражение. С точки зрения рядового исполнителя-программиста я не уверен, что второе предпочтительнее.
это не баг, это фича
Re[18]: Scrum не подходит для программной разработки
Здравствуйте, El Camino Real, Вы писали:
ECR>Здравствуйте, landerhigh, Вы писали:
L>>Короче, выходит, что ты скрама не видел. ECR>Ни один истинный шотландец... Каким хорошим может быть скрам, думаю, все и так знают. Проблема ж в применительной практике.
Вот именно.
Нет такой замечательной идеи, которую не испортили бы реализацией.
Здравствуйте, landerhigh, Вы писали:
IT>>Пять штук в неделю минимум. L>Ежедневная летучка на пару минут "сделал Х, буду делать У" — это ни о чем.
Ни о чём — это когда тебе по скайпу босс спросит "ну что там?", а ты ему в свободную минутку "всё норм". Это ни о чём. А в аджайле профессионалы способны из любого ни о чём раздуть ого-го.
Например, митинг назначается на 9:30 утра, чтобы все выспались и все собрались. Это означает, что до этого времени никто ничем другим заниматься не будет. Далее в течении 15-20-ти минут 10 человек рассказывают друг другу ненужные и неинтересные вещи. При этом замечено, что чем меньше чел сделал, тем больше он об этом будет говорить.
Потом разошлись, кофейку и как правило в 10:00 уже следующий митинг. Вот так "ни о чём" превращается в час дружной траты времени всей командой.
IT>>Хотя двух более чем достаточно. L>Делайте два раза в неделю, если для вас работает
Нельзя. Это ритуал. Если два раза, то это уже не аджайл. Начальство не поймёт. Да и половине команды нравится потрындеть вместо поработать.
IT>>Но ведь к этому прилагается ещё куча всего радостного. Итого в день от часа до четырёх — митинги. L>Ну, сдуру можно еще и не то сломать.
В том-то и дело, что аджайл с радостью предоставляет такие возможности. В предыдущей теме пару месяцев назад я уже говорил, что аджайл — это рай для бездельников и балаболов. А в этой теме я говорил, что если у вас в команде таких нет, то при прочих условиях аджайл может кое-как работать. Только вот зачем?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Например, митинг назначается на 9:30 утра, чтобы все выспались и все собрались. Это означает, что до этого времени никто ничем другим заниматься не будет. Далее в течении 15-20-ти минут 10 человек рассказывают друг другу ненужные и неинтересные вещи. При этом замечено, что чем меньше чел сделал, тем больше он об этом будет говорить.
Ну вот такое дело, что если "ненужные и неинтересные вещи", то это не скрам. А карго-культ.
Ну и 15-20 минут тоже уже индикатор.
IT>Потом разошлись, кофейку и как правило в 10:00 уже следующий митинг. Вот так "ни о чём" превращается в час дружной траты времени всей командой.
А откуда у вас следующие митинги? А работать когда?
IT>Нельзя. Это ретаул. Если два раза, то это уже не аджайл. Начальство не поймёт. Да и половине команды нравится потрындеть вместо поработать.
Так это, неплохо было бы определение аджайла почитать. Вообще, ежедневный скрам для аджайла совершенно не обязателен
IT>>>Но ведь к этому прилагается ещё куча всего радостного. Итого в день от часа до четырёх — митинги. L>>Ну, сдуру можно еще и не то сломать.
IT>В том-то и дело, что аджайл с радостью предоставляет такие возможности. В предыдущей теме пару месяцев назад я уже говорил, что аджайл — это рай для бездельников и балаболов. А в это теме я говорил, что если у вас в команде таких нет, то при прочих условиях аджайл может кое-как работать. Только вот зачем?
А типа вотерфол, где можно годами прятаться за "почти готово", а в момент аврала собак повесить на васю, который api модуля не совсем по спекам реализовал, не рай для балаболов, да.
Тут не кровати надо переставлять, а, гхм, сотрудников, гхм, менять.
Здравствуйте, landerhigh, Вы писали:
L>Только вот время одиночек, выдающих на-гора полезный продукт, закончилось лет 20 назад. Сегодня разработка софта — это очень сложный инженерный процесс, который нельзя отдавать на откуп индивидуальным разработчикам.
А что по-твоему делает этот сложный инженерный процесс сложным?
L>Результат такого подхода — это вотерфольное состояние продукта, который "почти готов" в течение года до релиза, но в QA в первый раз запускается и не падает сразу только в ночь перед дедлайном.
Это в большей степени проблемы менеджмента. Действительно вотерфол при плохом менеджменте скатывается в always 95% ready. Замена процесса на аджайл временно решает эту проблему, перекладывая ответственность с менеджера на девелоперов, а далее с них всех вместе взятых на заказчика. Это работает какое-то время, пока девелоперы не просекут фишку и потом это всё работает ещё медленнее, но более прогнозируемо. Всё это решается гораздо проще — заменой менеджера в самом начале.
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Scrum не подходит для программной разработки
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, landerhigh, Вы писали:
L>>Только вот время одиночек, выдающих на-гора полезный продукт, закончилось лет 20 назад. Сегодня разработка софта — это очень сложный инженерный процесс, который нельзя отдавать на откуп индивидуальным разработчикам.
IT>А что по-твоему делает этот сложный инженерный процесс сложным?
Ничего его не делает сложным.
Он такой есть. Изначально.
Если бы он был простым, уже давно вся разработка софта сводилась бы к набросу кубиков в чем-то вроде Rational Rose. Но пока все попытки упростить процесс его лишь усложняют.
L>>Результат такого подхода — это вотерфольное состояние продукта, который "почти готов" в течение года до релиза, но в QA в первый раз запускается и не падает сразу только в ночь перед дедлайном.
IT>Это в большей степени проблемы менеджмента. Действительно вотерфол при плохом менеджменте скатывается в always 95% ready. IT>Замена процесса на аджайл временно решает эту проблему, перекладывая ответственность с менеджера на девелоперов,
Что значит "перекладывая ответственность". А кто, по твоему, вообще должен отвечать за "готовность модуля"?
IT>а далее с них всех вместе взятых на заказчика.
Не перекладывает на заказчика, а вовлекает заказчика в итеративный процесс постоянного получения обратной связи.
IT>Это работает какое-то время, пока девелоперы не просекут фишку и потом это всё работает ещё медленнее, но более прогнозируемо.
Ну тут не кровати надо переставлять, а далее по тексту.
IT>Всё это решается гораздо проще — заменой менеджера в самом начале.
Ну заменил ты менеджера в самом начале. Чем это поможет?
Здравствуйте, Министр Промышленности, Вы писали:
МП>просто показателен факт, что разработчики порой предпочитают работать даже по нему, а не по скраму
Он совсем не показателен, а как раз наоборот — вполне предсказуем.
Суть и цель скрама совсем не в том чтобы нравиться разработчикам. Напротив, это способ выжать из них всё что можно.
Повышается уровень контроля за ходом выполнения задач, повышается уровень личной ответственности разработчиков, часть работы менеджеров фактически перекладывается на разработчиков. С чего бы им радоваться-то? Радоваться они могут в тех редких случаях, когда они материально заинтересованы в успешности проекта и стремятся сделать его быстрее и качественнее. Я таких случаев почти не видел.
А так-то, программисту куда комфортнее как раз "водопад" — "вы там требования уточните до деталей, зафиксируйте сроки и следующие полгода ко мне не приставайте — я буду работать над этим фиксированным списком задач". Само допущение того, что требования будут меняться и это нормально — это уже дискомфорт для разработчиков.
Как правильно сказал С.А.Д., мнение разработчиков в этом вопросе мало кого волнует.
МП>СССР не к ночи тут помянутый работал всё же не по скраму МП>но со стратегическим планированием всё было неплохо
Трудно было бы найти более неудачный пример. С планированием в СССР было очень плохо.
С уважением, Artem Korneev.
Re[4]: Scrum плоховато подходит для программной разработки
МП>>просто показателен факт, что разработчики порой предпочитают работать даже по нему, а не по скраму
AK>Он совсем не показателен, а как раз наоборот — вполне предсказуем. AK>Суть и цель скрама совсем не в том чтобы нравиться разработчикам. Напротив, это способ выжать из них всё что можно. AK>Повышается уровень контроля за ходом выполнения задач, повышается уровень личной ответственности разработчиков, часть работы менеджеров фактически перекладывается на разработчиков. С чего бы им радоваться-то? Радоваться они могут в тех редких случаях, когда они материально заинтересованы в успешности проекта и стремятся сделать его быстрее и качественнее. Я таких случаев почти не видел. AK>А так-то, программисту куда комфортнее как раз "водопад" — "вы там требования уточните до деталей, зафиксируйте сроки и следующие полгода ко мне не приставайте — я буду работать над этим фиксированным списком задач". Само допущение того, что требования будут меняться и это нормально — это уже дискомфорт для разработчиков. AK>Как правильно сказал С.А.Д., мнение разработчиков в этом вопросе мало кого волнует.
это всё принимается
водопад потому и считается регрессивным процессом
но только сильно недооценивается следующий фундаментальный фактор: моральные силы разработчика — это ценный, медленно возобновляемый ресурс
нам преподавали, что они восстанавливаются не на 8 часов продуктивной работы, а на 5-6 в день
когда я заканчивал обучение в университете (в 2005 году), пришёл к ориентировочному выводу, что процесс разработки по большому счету должен строиться вокруг этого ресурса
(за исключением острых случаев, когда на кону большое бабло)
для регулярной работы придерживаюсь этой же позиции и сейчас
соответственно, вы можете выжимать все соки из разработчика сколько душе угодно
но продуктивной работы он в среднем сделает на 5-6 часов запаса моральных сил
а если вы выжмете больше чем нужно, то рискуете тем, что разработчик не сможет восстановиться и на эти 5
тут некое усреднение имеется
сейчас я понимаю, что моральные силы тратятся на переключение и создание контекста
находясь в контексте продуктивно работать можно много и эффективно
но всё изложенное в целом верно
МП>но только сильно недооценивается следующий фундаментальный фактор: МП>моральные силы разработчика — это ценный, медленно возобновляемый ресурс МП>нам преподавали, что они восстанавливаются не на 8 часов продуктивной работы, а на 5-6 в день
Опять же, на скрам тренингах учат закладывать разумное время на продуктивную работу в день. Не более 4-6 часов в день.
AK>А так-то, программисту куда комфортнее как раз "водопад" — "вы там требования уточните до деталей, зафиксируйте сроки и следующие полгода ко мне не приставайте — я буду работать над этим фиксированным списком задач". Само допущение того, что требования будут меняться и это нормально — это уже дискомфорт для разработчиков.
Комфортность водопада заканчивается в тот самый момент, когда выясняется, что согласованный, утвержденный и принятый заказчиком фреймворк не позволяет реализовать следующую по списку фичу иначе, как стоя. В гамаке и противогазе.
Здравствуйте, Министр Промышленности, Вы писали:
МП>там проходят про моральную энергию разработчика, сбивку контекста, разные другие психологические аспекты работы и способы их оптимизации
Психология это хорошо и полезно.
А вот про собственно технологию сколько часов получилось?
МП>кто на программиста учился сам, а также на непрофильной специальности — полнотой технологии скорее всего не владеет, хотя кое-что уже и понимает сам
Можно подумать, что программиста что-то в аспекте моральной энергии отличает от художника там или ученого.
P.S. А сколько часов нынче отводят на такую дисциплину, как "Анализ сценариев отказа и их последствий"?
МП>>но только сильно недооценивается следующий фундаментальный фактор: МП>>моральные силы разработчика — это ценный, медленно возобновляемый ресурс МП>>нам преподавали, что они восстанавливаются не на 8 часов продуктивной работы, а на 5-6 в день
L>Опять же, на скрам тренингах учат закладывать разумное время на продуктивную работу в день. Не более 4-6 часов в день.
ыыыы
вообще-то продуктивная работа должна максимизироваться
соответственно, не менее 5-6 часов без сбитий контекста в свежем, не сонном состоянии
хинт: а не продуктивная не очень-то на самом деле и нужна
Re[12]: Scrum не подходит для программной разработки
Здравствуйте, Министр Промышленности, Вы писали:
L>>Опять же, на скрам тренингах учат закладывать разумное время на продуктивную работу в день. Не более 4-6 часов в день. МП>ыыыы МП>вообще-то продуктивная работа должна максимизироваться МП>соответственно, не менее 5-6 часов без сбитий контекста в свежем, не сонном состоянии
Ну удачи.
МП>хинт: а не продуктивная не очень-то на самом деле и нужна
У работников умственного труда без "не продуктивной" работы никакой особо продуктивной работы не получится. Разве вам в течение тех 68 часов об этом не рассказали?
МП>>там проходят про моральную энергию разработчика, сбивку контекста, разные другие психологические аспекты работы и способы их оптимизации
L>Психология это хорошо и полезно. L>А вот про собственно технологию сколько часов получилось?
это и есть технология
там в рамках того же курса рассказывали и про процессы и практики типа CI и т.д.
но я сейчас знания касающиеся психологических аспектов ценю больше
поскольку про CI или тестирование так или иначе научили бы на одной из работ
по процессам — одно время работал в Deutsch Telecom, у них неплохой свой процесс и структурно изложенная книга по нему, называется "SE BoOK" — в 2008 мне она показалась вменяемой
на фоне скрама кажется вменяемой и сейчас, хотя все последние годы работаю в рамках того что у кого из работодателей есть, адаптируясь по обстоятельствам
сейчас ищу работу, думаю на слова "у нас скрам" сразу буду отсеивать по ответу на вопрос "сколько у вас в среднем митингов в неделю?"
МП>>кто на программиста учился сам, а также на непрофильной специальности — полнотой технологии скорее всего не владеет, хотя кое-что уже и понимает сам
L> L>Можно подумать, что программиста что-то в аспекте моральной энергии отличает от художника там или ученого.
думаю художнику точно не нужно в голове строить сложный контекст, у него точно другая специфика
художнику для игры компьютерной думаю по скраму может работалось и хорошо
с ученым уже не уверен, но думаю их и не отвлекают
про их технологию работы я кстати не в курсе, по-хорошему должна быть
причем у разных ученых — своя
L>P.S. А сколько часов нынче отводят на такую дисциплину, как "Анализ сценариев отказа и их последствий"?
сколько нынче я не знаю, писал же закончил в 2005
что-то подобное упоминалось, но думаю не так подробно
помню проходили отличия отказа от сбоя, но там вроде так было очевидно, что просто принял к сведению
на дисциплину это не тянет
думаю сценарии последствий отказа имеет смысл специально прорабатывать в некоторых специфических проектах
у меня был один такой за 15 лет
в других проектах либо вопрос был решён без моего явного вмешательства, либо не стоял вообще
Если нам не помогут, то мы тоже никого не пощадим.
