Здравствуйте, COFF, Вы писали:

> Но Вы же анонсировали, что изучили вопрос досконально, а в это понятие, по моему, входит и изучение конкурирующих подходов, нет?

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

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

> С моей точки зрения, было бы куда интереснее найти информацию по противостоящей доктрине, понять, чем они отличаются...
Не люблю общаться с людьми, которые указывают мне, что мне надо делать. Ищите вы, раз вам интересно. Я занимаюсь тем, что интересно мне.

> Знаете, Ваша заметка делится на две части: первая — это краткое описание Auftragstaktik, вторая — конкретные рекомендации по разработке ПО, которые якобы следуют из нее. Со второй частью спорить затруднительно...

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

У меня нет для вас времени. Всего доброго. Спорьте без меня.

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>К сожалению, за всю свою 12-летнюю карьеру разработчика я встречал очень мало грамотных менеджеров именно в техническом плане. Как правило, менеджерами становятся те люди, которые коммуникабельны, умеют хорошо говорить по-английски и которые являются очень слабыми разработчиками. Т.е. часто на первый план выходят именно презентационные навыки (чтобы продать проект), а не технические умения (чтобы этот проект завершить).

Менеджер, который не занимается кодированием, через несколько лет станет плохим программистом, даже если был раньше хорошим. И это нормально. Для того, чтобы не нарушилась связь с реальностью в цепочке менеджмента — нужны тимлиды, или аналогичные должности. Они являются "клеем" в иерархии управления.


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

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

Я это к тому, что посылка у вас в этом месте не совсем верная на мой взгляд. То, что вы приводите в пример — безусловно является доказательством ограниченности менеджеров. Но дело не в том, что они плохие программисты. Дело в том, что они у вас больше похожи на сейлзов, а не менеджеров разработки. У вас судя по всему структура управления построена криво и несбалансировано, тут отдельные лица не виноваты. Снизу такие проблемы не решаются — "рыба гниет с головы".

КЛ>К сожалению, большинство программистов (да и менеджеров) не понимают этой простой истины. Плюс присутствует большая инерция мышления, вызванная пропагандой объектного подхода. В качестве примера опять-таки сошлюсь на форум Архитектура. Большинство задач, разбираемых там, начинается со стандартной фразы: "Дан объект...". На самом деле, ни один другой инженер (не программист) не начинает проектирование с объекта. А начинает он именно с функции, т.е. с понимания того, зачем и в каких условиях эта проектируемая система будет использоваться.
КЛ>На самом деле, именно функциональное и критериальное (а не объектное) мышление является сильным.

Интересная мысль. Я тоже что-то подобное всегда чувствовал. Буду ее думать.

G>>На самом деле речь идет о большем — это leadership principle, которому подчинена вся система управления. Документ — это частность.
КЛ>Понятно. Если команда состоит из слабых специалистов, то к любому документу будут относиться достаточно формально: соблюдать лишь внешние требования, а на самом деле проектировать систему, как привыкли, а не так, как нужно. Чтобы документы, правила, методики не превратились в пустую формальность, нужно ещё создать команду — команду грамотных специалистов. Но вот создание такой команды, к сожалению, пока ещё является серьёзной архи-задачей. Очень уж мало видел я успешных примеров.

Не совсем. Даже если команда будет состоять из сильных специалистов, результат всегда можно свести на дерьмо директивным стилем руководства в сочетании с микроменеджментом. Я вам скажу — делайте вот это и вот это вот так, а зачем — вас не касается. Выполнить любой ценой. Незаменимых людей нет. Вот сделаете — будете жаловаться. И все. Этот стиль, называется Befehlstaktik или Normaltaktik, "императивная" тактика детальных приказов, который в особом представлении не нуждается, потому что его интуитивно применяет буквально каждый идиот, ставший начальником. Его тут COFF обнаружил в сети, и думает в соседней ветке, что это крутой эксклюзивный мега-метод, боагодаря которому СССР добилась победы во второй мировой .

О команде. Ну, "создать команду" звучит как заклинание — и действительно никаких методик создания команд нет. Если ставить задачу так — она заведомо невыполнима — не можете вы ее создать, она может у вас сложиться. Здесь более уместна аналогия с выращиванием растения (автор аналогии — Том ДеМарко). А именно — вы посадили растение, поливаете его, удобряете удобрениями, и вы можете надеятся, что оно может быть вырастет и принесет хорошие большие плоды, если вы конечно при этом не будете ломать ему стебель и подкапывать корни.

Так и в команде — вы должны аккуратно подбирать людей, избегать командоразрушающих факторов, и применять дружественные команде leadership principle и схемы организации работ. Тогда, возможно, пройдя серию проектов и добившись вместе успеха (это очень сильно сплачивает, и необходимо для командообразования), ваши люди превратятся в слаженную команду. Первое — зависит от вашего чутья и личных качеств, второе — в принципе что делать не надо (worst practices) — известно, а насчет третьего — вот auftragstaktik как раз об этом. Это один из таких принципов, который помимо прочего явно стимулирует командообразование. Но цель данного принципа не создание команды, он из серии "дружественных" для команды, не более того.

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

Здравствуйте, sc, Вы писали:

sc>А я вообще не понял разницы между нашим и немецким подходом. Наверное потому что в армии служил
sc>Насколько помню, нам всегда говорили что делать а не как. Как, это в учебке, на стажировке.
sc>Например в приказе "копать канаву от забора до обеда" понятно только что нужно делать, но не как. Как — это уже твои проблемы. Для чего, всегда объясняли, например, для нового кабеля, старый уже в десяти местах рвался, весь в скрутках. И творческий, нестандартный подход к делу всегда только приветствовался. Например, собрать деньги (спирт) и нанять тракториста с соседней деревни.
sc>Ну и в кино "про войну" это можно видеть повсеместно.

+3
ЗЫ: Еще есть со старых времен на флоте "... куда матроса не целуй, все равно жопа..." (в армии мотивация другая )

Здравствуйте, IT, Вы писали:

IT>Я правила изучал в Атланте много лет назад и специально искал тогда упоминание о помехе справа. Не нашёл

Может быть, конечно, позже добавили, но — открыв правила штата Georgia (если речь про Atlanta, GA, а не про другую Атланту), видим:

Yielding Right-of-Way: Always yield right-of-way to pedestrians, vehicle
operators, and bicyclists who move into the intersection before you by stopping
and remaining stopped until they have cleared the intersection.

At a four-way intersection where all drivers are faced with stop signs, all drivers
must yield to pedestrians; otherwise the vehicles should proceed through the
intersection in a “first to arrive, first to proceed order.” If two vehicles reach the
intersection at approximately the same time, yield to any vehicles on your right.

http://www.dds.ga.gov/docs/forms/FullDriversManual.pdf

Здравствуйте, Gaperton, Вы писали:

G>Менеджер, который не занимается кодированием, через несколько лет станет плохим программистом, даже если был раньше хорошим. И это нормально. Для того, чтобы не нарушилась связь с реальностью в цепочке менеджмента — нужны тимлиды, или аналогичные должности. Они являются "клеем" в иерархии управления.

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

В целом же, я с Вами согласен. Человек, который перестал заниматься кодированием, через несколько лет забудет о том, как это делается. И в этом, как мне кажется, нет ничего страшного. Человек, который руководит процессом разработки, вряд ли должен писать код сам. Его ценность заключается в другом — в умении организовать работу так, чтобы сконструировать (или, если хотите, спроектировать) работоспособную и, желательно, безглючную систему, отвечающую предъявляемым к ней требованиям.

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

Между тем, чем выше занимаемая разработчиком позиция, тем меньше необходимость в т.н. "хакерских навыках" (== в знании вещей низкого уровня). На передний план выходят конструкторские навыки, умение проектировать (конструировать) сложные технические системы.

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

До недавнего времени мне казалось, что в продуктовых компаниях дела с разработкой должны обстоять лучше, т.к. задача компании — продать продукт. А если он не будет качественным, то и покупать его никто не будет. Но столкнувшись с одной брендованной компанией и узнав на практике, как там поставлена разработка, я понял, что и продуктовые компании от бардака не застрахованы.

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

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

G>Я это к тому, что посылка у вас в этом месте не совсем верная на мой взгляд. То, что вы приводите в пример — безусловно является доказательством ограниченности менеджеров. Но дело не в том, что они плохие программисты. Дело в том, что они у вас больше похожи на сейлзов, а не менеджеров разработки. У вас судя по всему структура управления построена криво и несбалансировано, тут отдельные лица не виноваты. Снизу такие проблемы не решаются — "рыба гниет с головы".

Я с этим согласен. Дело не в том, что эти менеджеры — плохие программисты. Проблема в том, что у них отсутствуют конструкторские навыки.

G>Не совсем. Даже если команда будет состоять из сильных специалистов, результат всегда можно свести на дерьмо директивным стилем руководства в сочетании с микроменеджментом. Я вам скажу — делайте вот это и вот это вот так, а зачем — вас не касается. Выполнить любой ценой. Незаменимых людей нет. Вот сделаете — будете жаловаться. И все. Этот стиль, называется Befehlstaktik или Normaltaktik, "императивная" тактика детальных приказов, который в особом представлении не нуждается, потому что его интуитивно применяет буквально каждый идиот, ставший начальником.

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

1. Выбор типов данных под переменные. Если выбран не тот тип, может произойти переполнение, потеря точности вычислений или перерасход памяти.
   
2. Выбор названий для переменных и подфункций. Если названия даны произвольно, то в написанном коде будет потом трудно разобраться.
   
3. Выбор мест (фрагментов кода), которые нужно откомментировать.
   
4. И т.д. и т.п.

Если программист не умеет решать самостоятельно такие микро-задачи, то детализация приказа не спасёт.

G>О команде. Ну, "создать команду" звучит как заклинание — и действительно никаких методик создания команд нет. Если ставить задачу так — она заведомо невыполнима — не можете вы ее создать, она может у вас сложиться. Здесь более уместна аналогия с выращиванием растения (автор аналогии — Том ДеМарко). А именно — вы посадили растение, поливаете его, удобряете удобрениями, и вы можете надеятся, что оно может быть вырастет и принесет хорошие большие плоды, если вы конечно при этом не будете ломать ему стебель и подкапывать корни.

Опять-таки согласен с Вашей метафорой про выращивание. Это очень напоминает то, как формируется отдельно взятый специалист. Квалификация растёт на задачах. Чем больше сложных и нетривиальных задач решил человек, тем больше его практический опыт, тем выше его квалификация. К сожалению, достойных публикаций на обе темы (формирование команды и формирование грамотного специалиста) не так уж много. Автором ТРИЗ Г.С. Альтшуллером на базе анализа порядка 1000 биографий творческих людей была создана ТРТЛ (теория развития творческой личности). Какую-то информацию о ней можно посмотреть здесь.

Ещё в советские времена была публикация Б.Л. Злотина по теории развития творческих коллективов. Но, к сожалению, в интернете её нет.

Думаю, что с ростом производства (особенно, наукоёмкого и высокотехнологичного) возникнет необходимость в работах по этим темам — как по выращиванию специалистов, так и по выращиванию команд.

КЛ>До недавнего времени мне казалось, что в продуктовых компаниях дела с разработкой должны обстоять лучше, т.к. задача компании — продать продукт. А если он не будет качественным, то и покупать его никто не будет. Но столкнувшись с одной брендованной компанией и узнав на практике, как там поставлена разработка, я понял, что и продуктовые компании от бардака не застрахованы.
Самое время вспомнить книгу Алана Купера "Психбольница в руках пациентов: Почему высокие технологии сводят нас с ума и как восстановить душевное равновесие"

Здравствуйте, sc, Вы писали:

sc>А я вообще не понял разницы между нашим и немецким подходом.

Поскольку в заметке, помимо статьи 40, не приводятся статьи 38 и 42 Устава внутренней службы ВС РФ, может сложиться впечатление о противопоставлении автором двух систем. Не думаю, что это так.

38. Командир (начальник) перед отдачей приказа обязан всесторонне оценить обстановку и предусмотреть меры по обеспечению его выполнения.
...
Приказ должен быть сформулирован ясно, не допускать двоякого толкования и не вызывать сомнения у подчиненного.

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

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

Процитированные статьи УВС ВС РФ в совокупности определяют принцип успешного выполнения боевых задач в ВС РФ. И, полагаю, что он никак не противоречит aftragstaktik. Более того, на мой взгляд, aftragstaktik может являться рекомендацией или частью наставления по обеспечению выполнения боевых задач.

sc>Насколько помню, нам всегда говорили что делать а не как. Как, это в учебке, на стажировке.

к сожалению, не всегда бывает так...

sc>"копать канаву от забора до обеда"

На мой взгляд, не совсем удачный пример...
Такая постановка задачи говорит о том, что начальнику важен не столько результат, сколько сам процесс, точнее длительность процесса. При такой постановке задачи, начальник занимает подчиненных делом, чтобы не сработало правило: «если солдат ничем не занят, ему в голову лезут дурные мысли».

Думаю, что более удачен следующий пример (Н — начальник, П- подчиненный):
Н: Есть ли связь со штабом?
П: Есть, но не работает...
Н: Что б через полчаса заработала!
П: Есть!

Классная статья. Очень понравилась!

Более того, человеческий фактор там значит не меньше, а возможно и гораздо больше — значимость боевого духа войск по сравнению с другими факторами оценивают как 3 к одному, и большинство специалистов оценивают его как решающий.

Это scrum и agile вообще. "Люди важнее процессов". Самомотивация и стремление к цели.

А именно — вы ставите подчиненному четкую цель, которой он должен достичь — по возможности математически точно описав критерии ее достижения, оставляя ему выбор способов ее достижения в соответствии с обстоятельствами, с которыми он столкнется при выполнении.

Это в точности scrum. Sprint goal, backlog item с информацией о том, как это показать на демо.

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

И это тоже scrum и agile. Нет смысла упираться рогом.

Это означает, что они должны знать не только ЧТО надо делать, но и понимать, ЗАЧЕМ. А именно, исполнители нижнего уровня должны хорошо понимать логику принятия решений уровня выше.

Непременно надо включить вашу замечательную статью в семинар по scrum! Все как на подбор!
Например, это — про то, как проводится planning day. Product owner рассказывает, что нужно получить и зачем это нужно в продукте.

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

Ну конечно же scrum!
Каждый backlog item имеет четкий buisiness value.

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

Опять про scrum
Менеджерские позиции в scrum'е по возможности выводятся за пределы команды. В процессе спринта команда сама решает, как делать ту или иную задачу. Кто будет ее делать, как делить работу.

Насчет agile. Отказ от управления требованиями на самом деле есть. Вы мне приводите в пример скрам, у него юзер сторисы — реально неплохая практика. Но где в скраме прописан процесс сбора, анализа и проверки этих требований? Да нигде.

А где в aftragstaktik прописан процесс формирования, анализа и проверки цели, которую командир выдает подчиненному? Что-то я не нашел

У них контроль — только в конце итерации. Которую в месяц при сложной продуктовой разработке не уложишь.

Все укладывают, и даже в меньшие итерации. Чаще всего — в двухнедельные. Месяц — это реально многовато для итерации.
Кстати, scrum не обязывает описывать требования в виде user story. Это из XP. А в scrum это может быть и в другом виде каком-то, если этот другой вид больше подходит.
Главный враг любой деятельности — это догмы.

По хорошему — в такой ситуации надо свернуть эти стори к простым элементарным операциям, ДОКАЗАТЬ, что в их терминах выразим интересующий нас класс юзер стори, после чего спокойно приступить к проектированию, имея в виду простые операции плюс несколько основных сценариев.
Это — работает, и это эффективно. При таком подходе я могу боротся со сложностью. И это — ничего общего с agile не имеет.

Это никак не противоречит scrum'у. Так и работаем.
Вот только фреймворки проектируем и рисуем не в первую очередь, опрометчиво рассчитывая на то, что у нас уже есть адекватные требования (а адекватных — нет), а когда реально увидим, например, дубляж, который может срезать фреймворк уровня проекта. Это надо делать, конечно, не слишком поздно, но и нельзя сделать слишком рано, на первых этапах. Вы еще не знаете, что у вас должен делать фреймворк. Потратите лишнее время на разработку фреймворка для гипотетического проекта. Реальный будет отличаться.

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

Замени одного подчиненного исполнителя на кроссфункциональную команду и получишь то же самое. Product owner решает, что нужно делать, и что важнее, команда решает как это делать, сколько она это будет делать и обязуется сделать. Никто не берет на себя чужой ответственности и не принимает чужих решений

Еще раз спасибо за статью!

Здравствуйте, sc, Вы писали:

sc>А я вообще не понял разницы между нашим и немецким подходом. Наверное потому что в армии служил

sc>Насколько помню, нам всегда говорили что делать а не как. Как, это в учебке, на стажировке.
sc>Например в приказе "копать канаву от забора до обеда" понятно только что нужно делать, но не как. Как — это уже твои проблемы. Для чего, всегда объясняли, например, для нового кабеля, старый уже в десяти местах рвался, весь в скрутках. И творческий, нестандартный подход к делу всегда только приветствовался. Например, собрать деньги (спирт) и нанять тракториста с соседней деревни.

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

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, sc, Вы писали:

sc>>А я вообще не понял разницы между нашим и немецким подходом. Наверное потому что в армии служил

sc>>Насколько помню, нам всегда говорили что делать а не как. Как, это в учебке, на стажировке.
sc>>Например в приказе "копать канаву от забора до обеда" понятно только что нужно делать, но не как. Как — это уже твои проблемы. Для чего, всегда объясняли, например, для нового кабеля, старый уже в десяти местах рвался, весь в скрутках. И творческий, нестандартный подход к делу всегда только приветствовался. Например, собрать деньги (спирт) и нанять тракториста с соседней деревни.

G>Как, и в немецкой тоже служил?
А подумать? Или Вам нужно расписать место моей службы в мельчайших деталях? А как же Auftragstaktik?
G>Что, и у них тоже рытье канав является важнейшей задачей армии, которую всегда приводят в пример, когда речь о тактике заходит?
После правильного ответа на первый вопрос, это станет не актуален

Здравствуйте, sc, Вы писали:

sc>А как же Auftragstaktik?
Ну, во-первых, если уж на то пошло — я гражданский, и мне таких умных штук понимать не положено . А во-вторых — что все думать да думать, могу и я постебаться немного?

Здравствуйте, Igor Trofimov, Вы писали:

iT>Классная статья. Очень понравилась!
Рад стараться . Но, как вы поняли по дискуссии в моем ЖЖ, я не могу согласиться с вашим тезисом. По пунктам покажу вам отличие agile и scrum от той реальности, в которой работает auftragstaktik:

iT>

iT>Более того, человеческий фактор там значит не меньше, а возможно и гораздо больше — значимость боевого духа войск по сравнению с другими факторами оценивают как 3 к одному, и большинство специалистов оценивают его как решающий.

iT>Это scrum и agile вообще. "Люди важнее процессов". Самомотивация и стремление к цели.

"Люди важнее процессов" — это означает, что на процесс можно забить штоли? Странное акцентирование у вас в agile. Это похоже не на здравый смысл, а на подачку программистам — это распространенный миф, в который им хочется верить, наряду с мифом Крутого Хакера. Что важнее — танк или экипаж? Обе вещи важны, каждая по своему. Хорошо организованная группа людей очевидно сделает работу быстрее и эффективнее, чем неорганизованная группа очень важных людей. И ради того, чтобы получить эту организованность группы, я считаю вполне допустимым и необходимым жертвовать интересами некоторых людей.

Самомотивация — миф. От того, что вы объявите всем, что они теперь самомотивироваться должны — все типа сразу пойдет на лад, да? У военных, например, очень развитые способы поднимать мотивацию. Это целое исскуство. Пример — почитайте, как Кортес мотивировал свою банду негодяев пойти с ним в рискованную кампанию. Шедевр. Все пошли с ним. Не смотря на то, что за день до этого хотели его повязать и вернуть назад губернатору. Я не говорю, что надо делать так — я к тому, что под лежачий камень в этом деле вода не течет.

iT>

iT>А именно — вы ставите подчиненному четкую цель, которой он должен достичь — по возможности математически точно описав критерии ее достижения, оставляя ему выбор способов ее достижения в соответствии с обстоятельствами, с которыми он столкнется при выполнении.

iT>Это в точности scrum. Sprint goal, backlog item с информацией о том, как это показать на демо.

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

Еще? Вот, например: подготовить техническое задание по проекту Х, срок такой-то.

iT>

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

iT>И это тоже scrum и agile. Нет смысла упираться рогом.

Докажи.

iT>

iT>Это означает, что они должны знать не только ЧТО надо делать, но и понимать, ЗАЧЕМ. А именно, исполнители нижнего уровня должны хорошо понимать логику принятия решений уровня выше.

iT>Непременно надо включить вашу замечательную статью в семинар по scrum! Все как на подбор!
Хотите — включайте . Это не делает скрам лучше или хуже.

iT>Например, это — про то, как проводится planning day. Product owner рассказывает, что нужно получить и зачем это нужно в продукте.
Ну, рассказывает. И что? Причем здесь тема-то?

iT>

iT>То есть, они должны понимать, кто будет пользоваться их продуктом, и понимать, какую его потребность удовлетворяет их продукт.

iT>Ну конечно же scrum!
Нет, не scrum, а они должны понимать, кто будет пользоваться их продуктом. Это совершенно не одно и то же. Для этого не рассказы product owner-а нужны на planning day, а целостная маркетинговая концепция продукта.

iT>Каждый backlog item имеет четкий buisiness value.
Это как раз плохо. Следуя этому дурацкому ограничению, я не смогу применить "метод фреймворка" для сложной разработки, когда у меня несколько уровней требований, и между ними прослеживается трассировка. Зачем? Это совершенно необходимо, например, для разработки embedded софта потребительской электроники. Просто, чтобы вопиющий случай показать. Или же, это абсолютно необходимо в разработке разнообразных middleware, и прочих случаев, когда ваш потребитель не является конечным, и вы по сути продаете технологию. Или же, у вас система большая, и имеет "слоеную архитектуру". Ничего из перечисленного таким методом делать нельзя.

iT>

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

iT>Опять про scrum
iT>Менеджерские позиции в scrum'е по возможности выводятся за пределы команды.
Отвратительно. Это вносит дисбалланс в систему субординации и рвет связь между менеджментом и разработкой, делая ее неуправляемой. Сойдет с рук, если вы занимаетесь мелкой заказухой, и менеджеры ваши долдоны, и самоубийство при крупных проектах и продуктовой разработке.

Auftragstaktik — это в первую очередь механизм работы субординации.

iT>В процессе спринта команда сама решает, как делать ту или иную задачу. Кто будет ее делать, как делить работу.
Обычно новые термины (спринт) вводятся с целью запудрить мозги и замаскировать бредовость. А мне не надо, чтобы вы сами решали в процессе спринта, КАК делать фичу. Я хочу решить КАКИЕ фичи я вообще пущу в первую итерацию, с учетом информации по ее реализации и обратной связи. Менеджеров вы из команды вывели — и все, требованиями уже управлять стало невозможно. Ну просто полный autfragstaktik — разработка вслепую.

iT>

iT>Насчет agile. Отказ от управления требованиями на самом деле есть. Вы мне приводите в пример скрам, у него юзер сторисы — реально неплохая практика. Но где в скраме прописан процесс сбора, анализа и проверки этих требований? Да нигде.

iT>А где в aftragstaktik прописан процесс формирования, анализа и проверки цели, которую командир выдает подчиненному? Что-то я не нашел
1) Это leadership principle, которому подчинена вся система управления сверху донизу. А не набор процессов для работы исполнителей нижнего уровня, как ваш скрам. Смешно слушать, когда вы говорите "это скрам".
2) Выдергивать фразы из контекста и менять тему — это демагогия. Обсуждается тема, из которой вы фразу дернули — отказ от управления требованиями в скраме есть или нет? При чем тут auftragstaktik?

iT>

У них контроль — только в конце итерации. Которую в месяц при сложной продуктовой разработке не уложишь.

iT>Все укладывают, и даже в меньшие итерации. Чаще всего — в двухнедельные. Месяц — это реально многовато для итерации.
Ага. Все, кто пишет веб-сайты на PHP. А ты уложи в двухнедельную итерацию шедулер файберов для сервера базы данных. Или Фрагмент подсистемы хранения данных на диске в BTree, который делает что-то осмысленное.

iT>Главный враг любой деятельности — это догмы.
Ага. Это очень хорошо видно на примере agile. Никто не следует своим догмам настолько слепо и догматично, как сторонники agile. Ни на секунду не допускаете, что жизнь несколько сложнее. Крепка ваша вера, братья, истинно говорю . И главное ведь — fixed cost заказной делать толком не умеют, самую простую, распространенную, и лежащую на поверхности штуку, а рогом упираются, они мол пуп земли .

Поговори на эту тему с Асхатом Уразбаевым. Он организатор сообщества agile russia. Он тебе сразу скажет, что agile применим в узком классе проектов. Это простая и короткая разработка, и очень маленькие команды.

iT>

iT>По хорошему — в такой ситуации надо свернуть эти стори к простым элементарным операциям, ДОКАЗАТЬ, что в их терминах выразим интересующий нас класс юзер стори, после чего спокойно приступить к проектированию, имея в виду простые операции плюс несколько основных сценариев.
iT>Это — работает, и это эффективно. При таком подходе я могу боротся со сложностью. И это — ничего общего с agile не имеет.

iT>Это никак не противоречит scrum'у. Так и работаем.
Это в прямую противоречит скраму. Вы не можете так работать, и соблюдать скрам.

iT>Вот только фреймворки проектируем и рисуем не в первую очередь, опрометчиво рассчитывая на то, что у нас уже есть адекватные требования (а адекватных — нет),
Конечно, откуда они у вас возьмутся, если вы ими не занимаетесь. Было бы странно.

iT>а когда реально увидим, например, дубляж, который может срезать фреймворк уровня проекта. Это надо делать, конечно, не слишком поздно, но и нельзя сделать слишком рано, на первых этапах. Вы еще не знаете, что у вас должен делать фреймворк. Потратите лишнее время на разработку фреймворка для гипотетического проекта. Реальный будет отличаться.

Это вы не знаете. Я-то как раз знаю, что у меня делает фреймворк, когда закладываю его в архитектуру. Другое дело, что я не обязан его целиком писать в начале проекта. Поэтому, у меня всегда остается возможность скорректировать по ходу — это уже вопрос того, как я составляю план разработки. Вы больших планов не составляете — религия, то есть скрам не позволяет, вот у вас и не получается по другому.

iT>

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

iT>Замени одного подчиненного исполнителя на кроссфункциональную команду и получишь то же самое. Product owner решает, что нужно делать, и что важнее, команда решает как это делать, сколько она это будет делать и обязуется сделать. Никто не берет на себя чужой ответственности и не принимает чужих решений

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

Единственный реально жизнеспособный процесс у вас во всем agile — это в FDD — он эти проблемы адресует. И то, с рядом оговорок.

iT>Еще раз спасибо за статью!
Не за что. Читайте на здоровье. Главное, чтобы в прок пошло.

iT>>Классная статья. Очень понравилась!
G>Рад стараться . Но, как вы поняли по дискуссии в моем ЖЖ, я не могу согласиться с вашим тезисом.

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

G>"Люди важнее процессов" — это означает, что на процесс можно забить штоли? Странное акцентирование у вас в agile.

Это цитата. Я думал, известная. Естественно, когда про нее говорят, ее раскрывают. Раз не настолько известная, то поясню.
Естественно, процесс важен. Он упорядочивает хаос. Но если ваш процесс заставляет людей грустить и бороться с этим процессом — то нафиг такой процесс, т.к. люди важнее. Вкратце так.

G>Это похоже не на здравый смысл, а на подачку программистам — это распространенный миф, в который им хочется верить, наряду с мифом Крутого Хакера.

Можно поменьше злого сарказма?

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

Все верно. Речь о том, чтобы не пожертвовать их интересами совершенно "заздря". А в идеале — навести порядок, не жертвуя интересами.

G>Самомотивация — миф.

Нисколько. Никакие деньги не заставят человека работать с таким энтузиазмом, с каким он работает над тем, что ему интересно. Его уже пора палкой от компа отгонять, так ему хочется доделать чудо-фичу! Вот попробуй — заставь, замотивируй! Фигвам!

G>От того, что вы объявите всем, что они теперь самомотивироваться должны — все типа сразу пойдет на лад, да?

Конечно, нет. Передергиваете.
Естественно, нужно сделать так, чтобы человеку было максимально комфортно и интересно. Чтобы он захотел работать, если это есть в его природе.
Естественно, если он в принципе не хочет работать — с ним это не получится. Интересами таких людей действительно пожертвовать не жалко

G>Это не в точности скрам. Ставлю цель: .....Куда в точности скрам подевался? Какой нафиг спринт?
Никуда не подевался. Я не очень понимаю, что вы хотите продемонстрировать своей целью.
Поясняю. "Это в точности scrum" означает, что вы ставите цель, описываете критерии ее достижения, оставляя исполнителю свободу выбора пути ее достижения. Это один из основных принципов организации работы в scrum. Это почти буквально повторяет то, что вы пишете про Auftragstaktik.

iT>>И это тоже scrum и agile. Нет смысла упираться рогом.
G>Докажи.

Пожалуйста. Если в процессе спринта (скажем, в середине) вы вдруг обнаруживаете, что очень сильно отстаете, то не стоит бросаться работать по ночам или забивать на качество. Определите причины и примите решение, например, остановить спринт и перепланировать. Стандартная рекомендация.
Но, догадываюсь, что для вас это, наверное, недостаточно убедительно, и нужны какие-то более веские доказательства Мамой клянусь! Нет смысла упираться рогом! Be agile!

iT>>Например, это — про то, как проводится planning day. Product owner рассказывает, что нужно получить и зачем это нужно в продукте.
G>Ну, рассказывает. И что? Причем здесь тема-то?

Именно при том, о чем вы пишете. Т.е. буквально: "А именно, исполнители нижнего уровня должны хорошо понимать логику принятия решений уровня выше".

G>Нет, не scrum, а они должны понимать, кто будет пользоваться их продуктом. Это совершенно не одно и то же. Для этого не рассказы product owner-а нужны на planning day, а целостная маркетинговая концепция продукта.

Мне непонятно, где вы здесь видите противоречие. Да, нужно, чтобы они понимали, кто будет пользоваться их продуктом. Это scrum, scrum, и еще раз scrum. Рассказ product owner'а — это и есть изложение "маркетинговой концепции", если вам так угодно. Естественно, в приложении в первую очередь к функциональности продукта, а не к привлечению инвестиций. Кстати, если ваш продукт только и ценен, что своей "маркетинговой концепции", а реально никому и даром не нужен — то фиг вы заставите разработчика работать эффективно.

iT>>Каждый backlog item имеет четкий buisiness value.
G>Это как раз плохо. Следуя этому дурацкому ограничению, я не смогу применить "метод фреймворка" для сложной разработки

Да можете! Можете! Почитайте "Scrum and XP from the Trenches", о том, как это работает на самом деле. Пообщайтесь с людьми, реально применяющими scrum. С тем же Асхатом обсудите этот вопрос подробнее. Тут у вас явное непонимание. Вспомните, что я писал про догмы. Вот, когда по верхам прочитают чего-нибудь, то и начинают критиковать простые основные принципы, представляя их как догматы.
Естественно, будучи воспринято как догма, это правило может работать сильно во вред! Ну так, если вы это понимаете — ну скорректируйте вы процесс так, как вам надо! От этого он не перестанет быть scrum'ом Честно-честно!

G>и прочих случаев, когда ваш потребитель не является конечным, и вы по сути продаете технологию.

Ну это просто смешно. Оттого, что ваш заказчик — это другой программист, а не конечный пользователь вы уже не можете оценить, насколько для него важна та или иная возможность вашего продукта?

iT>>Менеджерские позиции в scrum'е по возможности выводятся за пределы команды.
G>Отвратительно. Это вносит дисбалланс в систему субординации и рвет связь между менеджментом и разработкой, делая ее неуправляемой. Сойдет с рук, если вы занимаетесь мелкой заказухой, и менеджеры ваши долдоны, и самоубийство при крупных проектах и продуктовой разработке.

Опять пытаетесь походя оскорбить и унизить Причем сразу весь коллектив менеджеров и организацию в целом. Ой, нехорошо.
Можно попробовать по-вашему: а докажите! Докажите, что "вносит дисбаланс" и "делает неуправляемой". Слова, слова, слова...
У меня вот есть контрпример. Скажем, длительный заказной проект с годовым бюджетом 4 млн.у.е. Я конечно, понимаю, что это для вас так, мелкая заказуха...

iT>>В процессе спринта команда сама решает, как делать ту или иную задачу. Кто будет ее делать, как делить работу.
G>Обычно новые термины (спринт) вводятся с целью запудрить мозги и замаскировать бредовость.

Я смиренно полагал, что так активно наступая на scrum вы соблаговолили хотя бы поверхностно ознакомиться с терминологией. Кварки цвета "charm" вас никогда не смущали своей бредовостью?

G>А мне не надо, чтобы вы сами решали в процессе спринта, КАК делать фичу.

Не надо?? А как же Auftragstaktik?? Цитирую с ваших слов: "оставляя ему выбор способов ее достижения в соответствии с обстоятельствами, с которыми он столкнется при выполнении."

G>Я хочу решить КАКИЕ фичи я вообще пущу в первую итерацию, с учетом информации по ее реализации и обратной связи.

Это как раз и есть забота product owner'а. Он и решает, какие фичи он пустит в первую итерацию. С учетом первичной оценки их трудоемкости.
Product owner'у для этого вовсе не нужно (необязательно, даже, скорее, нежелательно) быть членом команды, то есть самому участвовать в реализации этих фич.
Он должен знать свой продукт! Это главное. Донести цели, объяснить, зачем нужна очередная фича и почему она главнее многих других.

G>Менеджеров вы из команды вывели — и все, требованиями уже управлять стало невозможно.
Налицо некоторое непонимание. Отчего же невозможно?

G>2) Выдергивать фразы из контекста и менять тему — это демагогия. Обсуждается тема, из которой вы фразу дернули — отказ от управления требованиями в скраме есть или нет? При чем тут auftragstaktik?
Конечно же нету отказа от управления требованиями, о чем вы говорите??
В принципе Auftragstaktik, как вы его изложили (отлично изложили), так же как и в scrum'е, процесс формирования (и управления, если хотите) требованиями, очевидно, вынесен за рамки методики исполнения этих требований. Разве написано где-то в Auftragstaktik, как должны придумываться приказы, как должна определяться их приоритетность, как следует менять приказы, если что-то пошло не так, как вы планировали? Нет! Речь идет о том, как следует эти требования правильным образом отдавать на уровень исполнения.

iT>>Все укладывают, и даже в меньшие итерации. Чаще всего — в двухнедельные. Месяц — это реально многовато для итерации.
G>Ага. Все, кто пишет веб-сайты на PHP. А ты уложи в двухнедельную итерацию шедулер файберов для сервера базы данных. Или Фрагмент подсистемы хранения данных на диске в BTree, который делает что-то осмысленное.

Ну откуда столько агрессии и желания облить собеседника грязью? (простите, адепты PHP!)
Вы каждый месяц пишете шедулеры? Ну, сделайте одну итерацию длиннее. Не будьте догматиком. А лучше — все-таки найдите способ разбить задачу на несколько, поменьше.
Это правда, возможно гораздо чаще, чем кажется новичкам

iT>>Главный враг любой деятельности — это догмы.
G>Ага. Это очень хорошо видно на примере agile. Никто не следует своим догмам настолько слепо и догматично, как сторонники agile.

В эту игру можно играть вдвоем. Докажи!

G>И главное ведь — fixed cost заказной делать толком не умеют, самую простую, распространенную, и лежащую на поверхности штуку, а рогом упираются, они мол пуп земли .
Я дальше эту бессмысленную злобную ругань буду просто пропускать, ладно? Надеюсь, не будет упреков, что я замолчал тему и не швырнул банановой кожурой в качестве симметричного ответа?

G>Поговори на эту тему с Асхатом Уразбаевым. Он организатор сообщества agile russia. Он тебе сразу скажет, что agile применим в узком классе проектов. Это простая и короткая разработка, и очень маленькие команды.

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

iT>>Это никак не противоречит scrum'у. Так и работаем.
G>Это в прямую противоречит скраму. Вы не можете так работать, и соблюдать скрам.

Докажите, что не можем
И потом, а что вам важнее? Что это "не настоящий скрам", или что работа получается сделана качественно и в срок?

Не бывает "настоящего кунг-фу" и "не настоящего". Бывает сильный мастер и он может называть свое искусство "кунг-фу". У другого сильного мастера — свое кунг-фу, ничуть не хуже.
А начинают все с одних и тех же упражнений и ОФП. А вы пытаетесь по первым картинкам в книжке виртуально победить соперника: "Кунг-фу ваше — говно. Пока ты будешь вот так стоять в идиотской позе, я к тебе подойду и стукну больно". По-моему очень похоже получилось обрисовать ситуацию

G>Конечно, откуда они у вас возьмутся, если вы ими не занимаетесь. Было бы странно.
Буквально парой строк выше писал, ну, повторю еще раз. Фреймворки и у нас есть. И не в один слой Налицо нежелание слушать собеседника, неверие и беспардонность.

G>Это вы не знаете. Я-то как раз знаю, что у меня делает фреймворк, когда закладываю его в архитектуру. Другое дело, что я не обязан его целиком писать в начале проекта.

Ай-ай-ай... Как это не обязан? Ну хоть спроектировать до соплей-то обязан? До последнего имени метода? Нет?? Это что ж — вы его по ходу дела будете дописывать? И может быть, начнете не с мелких утилитарных классов, а с самого главного, самого рискованного, самого нужного? Смотрите, как бы не получилось похоже на scrum

G>Вы больших планов не составляете — религия, то есть скрам не позволяет, вот у вас и не получается по другому.

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

G>Ну надо же, "команда решает" . Ты сам не замечаешь, где прокол, нет? Ты понимаешь, что оценки сложности реализации фич влияют на приоритет, нет?

А вы понимаете, что ну совсем не представляете себе роль product owner'а при планировании в scrum? И всем это воинственно демонстрируете!
Естественно, оценка сложности фич влияет на приоритет! Команда оценивает трудоемкость, PO расставляет приоритеты! Сначала без, а потом с учетом этой оценки!
RTFM.

G>Не может "команда" здесь решать Ты понимаешь, что отвечать один человек должен всегда? Где у тебя человек в скраме, который несет личную ответственности за результат целиком?
И вот тут на сцену выходит менеджер проекта! Он не ставит задачи. Он их не оценивает, и не решает! Он успокаивает заказчика и следит за тем, как идет процесс в команде. Рулит ресурсами. Он смотрит на то, как работает команда, и что в ней идет "не так". Он может уволить человека из команды, или перевести в другой проект, если видит (а scrum очень много "выметает из под дивана"!), что толку от него ноль или меньше. Команда сама это сделать не может обычно. Менеджер разрешает конфликты, как внутри команды, так и между командой и заказчиком.
Короче, RTFM.

G>Как ты это отмасштабируешь хотя бы на две команды с общим кодом? А на пять? Ну на словах-то понятно, у вас проблем никаких — типа сказал заклинание "люди важнее процессов", и все .
Интересно, какой вас устроит ответ, если ответ "на словах" не устраивает?
Ну съездите к людям, у кого scrum внедрен на общем коде не только на нескольких командах, но эти команды еще и по всему свету разбросаны. Пообщайтесь, позадавайте свои каверзные вопросы! Объясните, почему они не могут работать по scrum, и почему они все такие лохи!
Было бы желание — найти таких людей можно без труда Через того же Асхата.

G>Единственный реально жизнеспособный процесс у вас во всем agile — это в FDD — он эти проблемы адресует. И то, с рядом оговорок.
Смотрели, не понравилось.
Кстати, вам не приходило в голову, что разным людям могет больше подходить разные процессы? Мне вот только сейчас эта мысль в голову пришла.
Кто-то, например, не может работать иначе, чем из под палки.
А кому-то вынь, да положь инструкцию, где написано, во сколько он должен обедать и как часто отлучаться по нужде.
Еще одному главное, чтобы его не трогали, "он работает один!".

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

G>Не за что. Читайте на здоровье. Главное, чтобы в прок пошло.
Видимо, пока не в прок, раз трачу столько времени на ответ, который, по всей вероятности, канет в пустоту непонимания и яростного нежелания понять.
Но, чем хорош публичный форум?
Один огрызнется, второй кинет какашкой, а третьему — на пользу пойдет! Только это и мотивирует на длинные ответы.

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

Удачи в благородных начинаниях!

Здравствуйте, Igor Trofimov, Вы писали:

G>>И главное ведь — fixed cost заказной делать толком не умеют, самую простую, распространенную, и лежащую на поверхности штуку, а рогом упираются, они мол пуп земли .
iT>Я дальше эту бессмысленную злобную ругань буду просто пропускать, ладно? Надеюсь, не будет упреков, что я замолчал тему и не швырнул банановой кожурой в качестве симметричного ответа?

Ну разумеется ты замолчал тему. Сказать-то по существу тебе нечего, только банановыми кожурами швыряться остается. Это известная на весь мир дыра твоего agile, не я ее выдумал. Ну не можешь же ты в самом деле начать объяснять, каким именно образом ты будешь вести проект сроком примерно в год, когда от тебя на ранней стадии требуется порезать проект на этапы, определить требования, прикинув сроки этапов и спланировав бюджет. А по итогам первого этапа длиной в месяц-два от тебя требуется внести окончательные коррекции в ТЗ, зафиксировав требования и план.

iT>Я знаком с Асхатом довольно хорошо. Даже если вам он так и сказал (а я в этом не уверен), то я догадываюсь, почему Попробуйте догадаться сами.
Нет, мнеон такого не говорил. Мне достоверные источники рассказывали, что он это в слушателям всех своих семинаров говорит, в самом их начале. Говорит он так потому, что дорожит своей репутацией, и глупостей говорить не хочет — на бизнесе плохо сказывается.

iT>И потом, а что вам важнее? Что это "не настоящий скрам", или что работа получается сделана качественно и в срок?

А что, если я работу и так делаю качественно, и в срок — безо всякого скрама? Я наверное что-то не так делаю?

G>>Не может "команда" здесь решать Ты понимаешь, что отвечать один человек должен всегда? Где у тебя человек в скраме, который несет личную ответственности за результат целиком?
iT>И вот тут на сцену выходит менеджер проекта! Он не ставит задачи. Он их не оценивает, и не решает!
"И тут на сцену вышли клоуны, и стали показывать нумера." Не завидую вашему менеджеру. Надо же, задач не ставит, ничего не оценивает, и ничего не решает. Зато за всю вашу халабуду отвечает на полную катушку, а сам исключительно пьет валидол и заказчика успокаивает. Ответственность не подкрепленная полномочиями, зашибись. Удобно как вы устроились.

iT>Короче, RTFM.
И он мне еще после этого РТФМ-ами тыкает. Простите за солдатскую прямоту, но такие РТФМ-ы я предлагаю вам засунуть туда, где им самое место. Ну, я имею в виду, в красивую рамочку на стенку повесьте, не подумайте плохого .

Есть два правила, которые соблюдать необходимо, чтобы система управления работала. ЛЮБАЯ система.
1) Личная ответственность. Отвечать должен один человек. Отвечает несколько — не отвечает никто.
2) Ответственность должна быть обязательно подкреплена полномочиями. Человек не может отвечать за те факторы, над которыми не имеет контроля.

G>>Как ты это отмасштабируешь хотя бы на две команды с общим кодом? А на пять? Ну на словах-то понятно, у вас проблем никаких — типа сказал заклинание "люди важнее процессов", и все .
iT>Интересно, какой вас устроит ответ, если ответ "на словах" не устраивает?
iT>Ну съездите к людям, у кого scrum внедрен на общем коде не только на нескольких командах, но эти команды еще и по всему свету разбросаны. Пообщайтесь, позадавайте свои каверзные вопросы! Объясните, почему они не могут работать по scrum, и почему они все такие лохи!

Ну зачем мне разъезжать по незнакомым мне людям, и объяснять им, какие они лохи. Оставив в стороне экстравагантность вашего предложения, коллега — пусть остаются какие есть. Бизнес — это война. И с этой точки зрения вовсе не так плохо, что многие компании теряют компетенции в успешном ведении контрактов fixed cost. А следуя правилам "исскуства войны" Сунь Цзы — мне никак не следует к ним ездить. Потому, что "если вы сильны — враг должен думать, что вы слабы". А я правила старика Сунь Цзы чту, так что нипочем не поеду. Кстати, я вижу, что агилисты тоже вольно или невольно следуют советам Сунь Цзы. Потому, что дальше он сказал — "а если вы слабы, то враг должен быть уверен, что вы сильны".

Ну а Time boxing применить при планировании, к чему сводится на самом деле ВЕСЬ ваш скрам, и я смогу, когда это реально потребуется — было бы о чем говорить, это самый тупой и простейший прием. Просто удивительно, сколько всего можно высосать из пальца вокруг одного единственного приема планирования.

G>>Единственный реально жизнеспособный процесс у вас во всем agile — это в FDD — он эти проблемы адресует. И то, с рядом оговорок.
iT>Смотрели, не понравилось.
iT>Кстати, вам не приходило в голову, что разным людям могет больше подходить разные процессы? Мне вот только сейчас эта мысль в голову пришла.
Вовремя вам эта мысль пришла, однако. Столько пикселов исписать успели. Не людям, а организациям. Scrum хорош, если вы делаете веб-сайты на заказ, и прочие проекты, где вы своих технологий не изобретаете, а комбинируете существующие, и вся фишка в юзабилити. И которые слишком короткие, чтобы полномасштабный процесс оправдать. Короче, любой проект, где быстрее сделать и показать, чем с требованиями и спеками возится (это подразумевает "легкие" технологии вроде скриптовых языков), и которые не надо потом поддерживать. Еще одна индустрия, где скрам скорее полезен, чем вреден — это компьютерные игры. Хотя уже здесь скрамом можно проект зафакапить в два счета.

И не путайте свой скрам с нашими прототипами. Прототипы люди умели делать задолго до вашего скрама — для этого никакой особой методологии не нужно.

iT>За сим разрешите откланяться, извините, если где был груб, эмоции захлестнули.
А вы спокойнее будьте. Если человек по настоящему уверен в том, что он говорит — он может позволить себе оставаться спокойным. Эмоции захлестывают тогда, когда вы вовсе не уверены в своей правоте, и в том что вы можете ее доказать. Вот тут-то эмоции и захлестывают.

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

Здравствуйте, Gaperton, Вы писали:

G>Помните здесь были дискуссии про военные методы в разработке ПО? Последнее время я очень плотно интересуюсь военными методами управления. И обнаружил массу интересного. У меня для вас есть кое-что — я написал небольшую заметку про немецкий принцип Auftragstaktik. Совершенно великолепный принцип. ЭТО и есть квинтэссенция управления. Постоянно нарушаемая на местах многими "гражданскими" людьми, очень умными, с высшим образованием полученном в неплохих ВУЗах, и, когда доходит до реального руководства людьми — являющихся почему-то классическими образчиками ментальности "сапогов" из начала 19 века.
G>Чему это может научить современного менеджера в разработки ПО? Многому, уважаемые коллеги. Мы раскроем суть этого принципа.
Дык для начала — напишите устав. Потом примите присягу. А потом уж и требуйте по уставу.
А без устава и присяги на верность — какой же дурак будет следовать приказам?!

Здравствуйте, LaptevVV, Вы писали:

LVV>Дык для начала — напишите устав. Потом примите присягу. А потом уж и требуйте по уставу.
LVV>А без устава и присяги на верность — какой же дурак будет следовать приказам?!

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

Здравствуйте, Gaperton, Вы писали:

G>Еще одна индустрия, где скрам скорее полезен, чем вреден — это компьютерные игры. Хотя уже здесь скрамом можно проект зафакапить в два счета.
Нет, только не скрам! При написании игры, если речь не идёт о простой Java-игрушке для мобильника, приходится проводить много НИОКР. Поэтому лёгкие методологии не подойдут. Можно загубить проект.

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Здравствуйте, Gaperton, Вы писали:

G>>Еще одна индустрия, где скрам скорее полезен, чем вреден — это компьютерные игры. Хотя уже здесь скрамом можно проект зафакапить в два счета.
КЛ>Нет, только не скрам! При написании игры, если речь не идёт о простой Java-игрушке для мобильника, приходится проводить много НИОКР. Поэтому лёгкие методологии не подойдут. Можно загубить проект.

Знаешь, насчет игр я только предполагаю — сам в их разработке не участвовал. Предполагаю потому, что обычно
1) Там относительно небольшая команда разработчиков (насколько я слышал).
2) Там надо много экспериментировать с "играбельностью" на живых прототипах (мне так кажется) — это может радикально сказаться на результате.
3) Есть много публикаций о применении скрамоподобных штук в game development.

Но на самом деле — насчет игр я не уверен совершенно, опыта нет.

Здравствуйте, Gaperton, Вы писали:

G>Помните здесь были дискуссии про военные методы в разработке ПО? Последнее время я очень плотно интересуюсь военными методами управления. И обнаружил массу интересного.

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

есть одна книга, посвященная этому вопросу
написана психологом, оказавшимся в одном из таких лагерей