Comments 214
Как бы пока вообще не ясно .., идея вроде видна, но суть
Суть — если вы профакапили проект, то неважно, насколько прозрачно для заказчика вы это сделали.
Как создать подходящий под свой бизнес формат? Без проблем и ошибок не будет… Все равно… и этот товарищ не может не понимать, не бывает решения идеального
ЗЫ. В обратную сторону тоже работает, если у вас было всё нормально, проекты более-менее сдавались, и тут вы ввели скрам, то всё станет не особо хуже (
Жаль, в жизни таких почему-то не бывает…
Да, скрам здесь не зашёл, но это не только и не столько вопрос к СЕО — у него иные материи. Большинство из них (не все) даже не будут пытаться разобраться, в скраме ли дело — Джон за дверь, Джек теперь вместо него.
Хоть что-то в 1с работает!
Все работает, спасибо.
Но требует на это сил на порядок больше, чем любой другой софт. Порой, знаете ли, впечатление, что люди ни памятью управлять, ни с БД работать не умеют на уровне, приличном для столь популярного софта (я про саму платформу), но у них даже нет стимула прокачивать скил: купить купят любое, ответственности за качество кода ни перед кем нести, обновления — и те только за денежку можно получать… В общем, жить можно, но гордиться нечем.
Характерно, что сами разработчики на 1с называют "большими" БД и число юзеров столько небольшие (ссылаясь на саму платформу), что прямо ещё грустные делается. Я понимаю, на 1с писать Фейсбук никто не станет, но все же просить под столько клиентов воооот такую по мощности железку — кажется, об оптимизации разговора нет в принципе.
Как нет разговора ни о чем современном. Облака? Резервирование? Географически разнесенных кластер? На костылях из прошлого века такое не построить, а новее там ничего не видно. Повторюсь, я про платформу.
Про механику лицензирования можно было сказать больше и грубее, но — годами там в лучшую сторону ничего не меняется. Собственно, девиз видится так — "нужно больше золота", и только закон и угроза штрафа (а не уважение к производителю, скажем) позволяют это золото ещё получать.
Но это я так. Спасибо, что спросили!
Да, платформа у них не самая лучшая и нафига делать встроенный механизм расчета уравнений =))
«Я понимаю, на 1с писать Фейсбук никто не станет, но все же просить под столько клиентов воооот такую по мощности железку — кажется, об оптимизации разговора нет в принципе.»
на 5000 юрезов в 1С нужен что то типа супер-дома. Правда тот же DAX на 5000 пользователей стоит как 10 таких супер-домов =)))
Извините если что, это я так ответил.
Кстати, интересно, а какая тема диссертации была — работает ли agile? И какие результаты в итоге получились?
В случае, если у компании свой продукт, то проектами могут выступать эпики или проектные инициативы (стримы).
Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
Мне кажется, я могу найти соответствие между спринтом и определениями:
Проект в управленческой деятельности (соответствует англ. project от лат. projectus «брошенный вперёд, выступающий, выдающийся вперёд») — временное предприятие, направленное на создание уникального продукта, услуги или результата (см. PMBOK)[3]:3.
Управление проектами — область деятельности, в ходе которой определяются и достигаются чёткие цели проекта при балансировании между объёмом работ, ресурсами (такими как деньги, труд, материалы, энергия, пространство и другими), временем, качеством и рисками (PMBoK)
Навеяло заголовком)
Когда то очень давно (2005-2006) было увлечение UML. Предлагалась как панацея и ответ на "The Ultimate Question of Life, the Universe, and Everything".
До сих пор помню (такое не забыть) пример использования UML в бизнесе из книги (доке кажется) от Rational Software (Rational Rose).
Содержание примера (почти дословно):
Жила была семья со своим мелким бизнесом. И что что то у них не шло с бизнесом. Прочитали они учебник по UML. Купили продует Rational Rose. Нарисовали в нем диаграмму (картинка диаграммы сценариев использования на 5-6 объектов со стрелочками) и тут у них КАК ПОПЕРЛО в бизнесе!
После прочтения этой главы у меня закралось подозрение… а не дурят ли меня.
Как показало время, подозрение было обоснованным.
Так что хоть какая-то польза от Rational Rose есть.
Я видел примеры грамотного приложения UML: авиационный софт. Логика примерно такая. Есть инженер, который понимает, какие сигналы (в широком смысле этого слова) нужны для некоторого события/действия. Он ресует UML, а с этого UML генерится C код. При чем генратор протестирован и верифицирован. Т.е. гарантируется, с некоторым уровнем покрытия, что генератор работает правильно.
Собственно на этой логике огромное количество самолетов летают и по сей день.
Подозреваю, что во многих областях производства это актуально.
Конечно же, скрам тут не причем. Эти люди и так найдут с кем попить кофе и покурить. Но, ввиду того, что теперь у людей есть выбор быть на этих митингах или нет, часть группы начнет работать, потому что не все любят митинги.
Я лично ушел из Ситибанка только из-за Скрама. Потому что мне было интересно что-то делать, но большинству было интересно тереть языками в переговорках и я был обязан там сидеть.
Скрам сегодня, за редким исключением, стал карго-культом. Он мертв из-за того, что слишком требователен к дисциплине.
Если описать скрам псевдокодом, то будет как-то типа:
while (true)
{
Sleep(1day);
DiscussProblems();
}Вместо схемы:
while (true)
{
WaitForNextProblem();
SolveProblem();
}"
Как там моя задача?
Ну я Васю позавчера попросил <......>, жду!
А ты сегодня спрашивал?
А что я, девочка за ним бегать? Я жду."
Или джун реально стесняется обратиться к архитектору за решением своей проблемы по задаче. Дейли не столько процессная встреча, сколько еще и психологическая, где от твоего вопроса или требования не отмахнутся «потом, я щас страшно занят».
И, опять таки, если мне нужно api от Васи, я ставлю задачу на Васю по разработку данного api, у своей задачи выставляю is blocked by XXX и на всякий в комментах отписываю что-нибудь вроде: «Приостанавливаю работу, т.к. нужно такое-то api, которое делается в таске XXX». Далее уже все вопросы к Васе.
Ну и больше это нужно не из за озвучивания проблем, а для синхронизации. Т.е. я, например, на дейли говорю: я вот начал переделывать этот сервис. И тут Петя из моей команды: подожди, но я вот только что завязался на старую логику этого сервиса. (Пример условный, поэтому немного корявый, но суть доносит). И без ежидневных дейли Петя узнал бы об этом только после моего коммита, который бы всё ему разломал.
Или задача — опозорить Васю перед командой?
Насколько я понимаю, именно так. Точнее не опозорить, а заставить Васю работать. Так-то вы ему скажете, Вася отмахнётся, пообещает, может даже запишет где-то себе. Но он вроде как никому ничего не должен. А через неделю окажется что и вовсе забыл.
А так — максимум два дня, первый на передачу блокера Васе (Вы не можете работать над задачей пока он не даст Апи), второй на передачу задачу Вам (условно день) с готовым Апи.
Как-то так.
— что я сделал для достижения цели спринта?
— что мне мешает в достижении цели спринта?
С остальным согласен полностью, если обсуждать реальный синк о том что блокирует и кого уже разблокировал, то 5-15 минут хватает и картина становится полностью ясной.
Это вопрос культуры, как и с обычными совещаниями, на которых можно решить все важные вопросы за 20 минут, а можно убить 2 часа и уйти ни с чем.
И нет никаких защитных механизмов от бескультурья, недисциплинированности и прочих человеческих факторов.А есть ли вообще какая-то методология, которая бы имела такие защитные механизмы от человеческих факторов?
Вообще интересно что это называется «стендапом» и предлагается делать стоя, чтобы не затягивать. Но опять же нигде я такого не встречал, все сидят в переговорках в удобных креслах, прямо провоцирующих с утра подремать под унылый бубнеж коллег. Может если бы все реально стояли на ногах, воды в разговорах было бы меньше.
Может если бы все реально стояли на ногах, воды в разговорах было бы меньше.
Да. Когда мы начали стоять на стендапах, то модерировать их стало значительно легче. Теперь вся команда не даст спорить двум людям — всем хочется побыстрее закончить и сесть
Очень, очень сложно модерировать собрания чтобы уходило 15 минут.У нас в команде дейли ни разу не занимали больше 20 минут.
причем обычно пара человек о чем-то жарко спорятПросто останавливаю такие споры и создаю этим спорящим людям отдельное собрание. Так и время других не тратится и к этим встречам люди лучше готовятся и они проходят эффективнее.
Знаю ребят, которые на дейли стояли в планке) Вот что реально мотивирует побыстрее закончить! Если что, это было совместное решение всей команды)
А вот любители растекаться мыслью по древу и вещать по десять минут — они как раз и приводят к затягиванию митингов на часы. Если человеку есть что сказать больше чем на полминуты — это обычно либо какой-то узкоспециальный вопрос, по которому требуется консультация — и тогда он решается уже после собрания узким кругом заинтересованных. Либо это какая-то общая болтовня, на которую не стоит тратить время. Либо какое-то объявление для команды, которому возможно лучше посвятить отдельное время или вообще обойтись рассылкой по почте или группе в слаке или еще где.
— Работаю с Y, от Пети из соседнего отдела нет аппрува, пока временно на Z.
— Вчера сделал F,G,H, на сегодня в стеке только R и выглядит несложно, нужно больше тасков.
— О, а мне как раз нужна помощь от человека кто разбирается в R, можешь мне помочь?
ну и типа того. А обсуждать и решать проблемы нужно уже отдельно, на дейли они только озвучиваются но не обсуждаются.
Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful.
Для больших команд существуют различные способы масштабирования скрама, например Nexus — для него тоже есть гайд на scrum.org.
Так что это точно ошибка тех организаций, в которых вы работали.
7+-2, если я правильно помню
Что такого полезно в том, что все по очереди говорят «я делал то-то»?
Кому это нужно? Кому интересно? Какую пользу приносит проекту?
Только не надо заученными фразами из книги шпрехать. Расскажите про реальную пользу.
P.S. Это я еще молчу, что эти 15 мин выбивают еще на полчаса из контекста…
что бы каждый участник команды понимал, что делает другой и как это его затронет
Ну это же лукавство в общем случае. Чтобы понять как затронет работу, работа другого человека, не достаточно чтобы он сказал «я делаю сохранение документа». Там надо вникать и разбираться, что и как он делает. 15 минут «синхронизации» не хватит чтобы это всё прояснить. И опять же, «я делаю сохранение документа» никак не помогает понять прогресс. А если с задачей есть проблемы, то вменяемый разработчик не будет ждать сутки, чтобы сказать о проблеме. Он сразу скажет продакту о проблеме.
Многим не нравится, что груминг + планирование иногда может занимать весь день. Но как показывает практика (хотя бы вот и сейчас), один потраченный день экономит в последствии намного больше времени за весь спринт.
А, еще оказывается всё сделать так, чтобы каждый участник понял реализацию. Поделитесь экспресс методами обучения людей за несколько часов? Или у вас все в командах матерые профи?
Если задачу невозможно оценить за день, можно заранее взять задачу на проработку и исследование. Как оценивать задачи, если вы не можете объяснить реализацию за день ?
Оценивать просто, когда ты на конвеере делашь одно и тоже. Какие нибудь сайтики на вордпресе. А когда вообще непонятно куда идти и что делать? На сколько я вижу, скрам хорошо работает только в случае конвеера, когда всё известно и надо только планы прикинуть к команде.
Для проектов в которых нифига непонятно и каждая вторая задача на ресёрч — скрам только мешает.
Скрам как мои ботинки 45 размера, не всем подойдет.
Для проектов в которых нифига непонятно
Чтобы стало понятно что-то, необходимо провести работы — сделать понятно. Попробывать протатип, посмотреть видео итд.
Главная причина пропуска сроков в таких компаниях — это изменения в беклоге, когда по результатам работы с пользователями выясняется, что какая-то фича получилась неудачно. ГД ее переписывают, художники перерисовывают, программисты переписывают, тестеры перетещивают и вот серьёзный кусок времени выпал, по глобальным срокам уже не успеваем и понимаем это уже в этот момент.
Обычно менеджеры садятся, думают, что выкинуть или можно ли перенести сроки. Если оставляют как есть в надежде «авось прокатит», то, обычно, не прокатывает.
То есть как с этим работают. На майлстоун есть 50% обязательных фич и 50% желательных. Если майлстоун занимает два месяца, то обязательные фичи после всех подсчетов должны получатся не больше чем на месяц. Тогда будет хорошая, стремительная разработка без авралов.
Обратите внимание, у нас, на разработке игры менеджмент уже за пару месяцев понимал, с чем мы влезаем по срокам, какие риски могут сработать и, в идеале, даже имел план на такие вещи. И, уверяю вас, это совершенно не конвеер.
что бы каждый участник команды понимал, что делает другой и как это его затронет
По информации из jira, от тимлидов и менеджеров всё ясно.
Во-вторых для исправления каких-то мелких недопаниманий на лету.
Обсуждение в частном порядке или в формате мини совещания от этого спасает.
Т.е. кто-то не так понял какую-нибудь часть задачи и его тут же поправят, а не на этапе тестирования.
Это обычно от тестеров в частном порядке приходит.
В-третьих, что бы у продакта было понимание прогресса и он мог вносить корректировки.
Опять же, jira в помощь. От него исходит линейка задач, он всегда и в курсе происходящего.
Что мешает сделать всё это вне стендапа?Да ни что не мешает. Но просто то, что вы описали — это классический водопад с матричной структурой управления. И тут каждый выбирает то, что ему больше нравится.
Просто представьте, что некоторые живут без менеджеров и тимлидов. Вот им так больше нравится, самим рулить проектом.
«Задача сделать кнопку красной»
---А сегодня товарищи мы будем обсуждать вчерашнее обсуждение)))
Обычно это называется что-то вроде "ибош пока не помрёш"
Однако стоит учитывать ряд важных моментов:
1. Если есть проект и дидлайн, по которому отчитывают за SCRUM — то это вывих головного мозга. Надо лечить мозг того кто эти вещи сочетает, а не обвинять SCRUM.
2. Проекты и дидлайны бывают. Но там применяются проектные методы. Классические. Без SCRUM. SCRUM — это иная история. При определенном умении их можно сочетать. Но получается это далеко не у каждого.
3. Про консультантов — в точку. В РФ именно такие. Бегают кричат про SCRUM. А по факту просто деньги сосут и портят процессы. Но опять же это не проблема SCRUM. Это специфика русских SCRUM-консультантов.
4. Видел десятки команд в РФ которые гордо заявляли что у них уже SCRUM или что они его внедряют. Но что то похожее на настоящий SCRUM видел только у 2х команд. Реально по опыту в РФ судить о этой идеологии не стоит. Тут слишком мало тех у кого хватает ума понять что это такое и как его готовить.
5. В качестве альтернативной точки зрения стоит почитать книгу про Automattic «Год без костюма». Там про то как выглядит реальный Agile. От которого один шаг до SCRUM. Но те кто по настоящему сумел освоить силу простоты Agile — редко переходят на SCRUM.
Сам по себе SCRUM не даст крутые результаты. Скорее наоборот — станет только хуже.
Выгоду дает умение играть SCRUM. Чувствуете разницу?
Плохие результаты не потому что SCRUM плохой, а птм что люди плохо умеют играть SCRUM.
Это как обвинять гитару в том что у тебя получается плохая музыка. Но если тот кто играет — «рукожоп» — то даже лучшая гитара в мире будет давать ужасную музыку в его руках.
Коммент чисто для обозначения альтернативной точки зрения. Ну и для ссылки на книгу где описана не вымышленная, а реальная компания, с реальным опытом, которая добилась тех самых 4х-10х результатов относительно конкурентов описанных в книге про SCRUM.
если под ссылкой понимать url то можно сделать так
www.google.ru/search?ei=Say3W7X6GcjKrgSrvbWAAw&q=Automattic+%D0%93%D0%BE%D0%B4+%D0%B1%D0%B5%D0%B7+%D0%BA%D0%BE%D1%81%D1%82%D1%8E%D0%BC%D0%B0&oq=Automattic+%D0%93%D0%BE%D0%B4+%D0%B1%D0%B5%D0%B7+%D0%BA%D0%BE%D1%81%D1%82%D1%8E%D0%BC%D0%B0&gs_l=psy-ab.3...3664.3664.0.4201.1.1.0.0.0.0.63.63.1.1.0....0...1c.1.64.psy-ab..0.0.0....0.ZfhRDAdFjLk
Если упростить:
- Виноват не Скрам, а вон тот чувак.
- Виноват не Скрам, это не всем дано.
- Виноват не Скрам, а вон те чуваки.
- Виноват не Скрам, а малое количество мозгов в РФ.
- Виноват не Скрам, читайте Agile.
Таки может всё же не повара готовить не умеют, а просто блюдо специфическое и очень на любителя?
Что делать людям которые живут в скрам командах успешно ?
Спасибо, стараюсь так и поступать.
В 2013 году на тренинге по scrum, услышал вопрос который поставил меня в тупик. Он был очень простой — Если сегодня, огромный рынок разработки ПО, высокие зарплаты и мало кадров, то зачем работать в месте где вас что-то не устраивает?
С тех пор большую часть времени я проработал в scrum командах, без менеджеров и тех.лидов.
Не могу сказать что это каждый раз был идеальный scrum, но он был довольно близок к чистому без перегибов. Не хочу говорить что это серебрянная пуля, но комфортнее работать я пока не вижу возможности.
Брат жив.
«Мы живем в скрам командах успешно» и «Наша команда успешна благодаря скраму»
Это знаете ли две большие разницы.
P.S. После того, не означает в следствии того ;)
Не бывает методологий, благодаря которым ваша команда станет успешной. Равно как и не бывает методологий, из-за которых случится провал. Успешность проекта зависит от множества факторов, и методология, скорее всего, даже не в первом десятке.
по-моему, на контроль процессов, на достоверную оценку вероятности успеха или провала
Очень глупо нацеливаться на заведомо неразрешимую (с практической точки зрения) задачу.
Кроме того, мне кажется, это заявление по-просту ложно. Где в скраме, водопаде или еще какой-либо методологии, указаны конкретные способы расчетов указанной вероятности? Нету их.
Если говорить о том, зачем вообще нужны методологии — то ответ, ни за чем. Не существует некоего единственного назначения у методологий в общем. Следование какой-либо методологии вынуждает производственный процесс обладать какими-то свойствами. В зависимости от самого процесса, его участников, его назначения и других подобных вещей — те или иные свойства могут быть либо полезными в данном конкретном случае (с-но логично выбрать методологию, которая форсирует их выполнение), либо нет. Т.о. в каждой ситуации у каждой методологии есть своя функция.
Методология — это как одежда для процесса. Вы можете одеться красиво, можете — тепло, можете — дешево, можете — так чтобы не выделяться (или чтобы наоборот выделиться), можете — так, чтобы соблюсти какой-то дресскод, можете максимизировать какую-то функцию от вышеназванных параметров или еще каких-либо. Каждый раз вы будете преследовать свою собственную цель. А попытка сравнения разных методологий (вроде скрама и водопада) по обобщенному критерию — примерно то же самое, что сравнивать вечернее платье и костюм химзащиты.
Где в скраме, водопаде или еще какой-либо методологии, указаны конкретные способы расчетов указанной вероятности?Monte-Carlo Simulation? Throughput? Scatterplot?…
> Actionable Agile Metrics, 2015 — Daniel S. Vacanti
Monte-Carlo Simulation? Throughput? Scatterplot?…
Метод расчета в методологии-то где?
Actionable Agile Metrics, 2015
Следует ли из этого, что до 2015 agile не существовало?
Ну и да, судя по содержанию, никаких методов расчета вероятностей в указанной книжке нет.
Подмена понятий?
Каких?
Agile — коммуникационный фрейморк, нужны метрики — МатАнализ, привет.
То есть, ответ на вопрос: "Где в скраме, водопаде или еще какой-либо методологии, указаны конкретные способы расчетов указанной вероятности?" будет "Нигде". И, т.о., методологии не предназначены для оценки вероятности успеха или провала.
С чем вы тогда спорите?
Какую проблему вы пытаетесь решить в контексте методологий?
Вроде, я выше об этом сказал. Не существует проблем, которые бы решались при помощи методологий в общем. Каждая конкретная методология решает свой конкретный набор проблем. В зависимости от того, какие проблемы вам требуется решить — такую методологию и выбираете.
Это довольно спорное заявление. Если конкурент выпускает на вашем рынке продукт за 3 месяца а вы за 2 года, то есть большой шанс пролететь мимо.
Коль вы меня в них осуждаете, удосужтесь развить мысль и указать где вы все это увидели.
2. Вы без причины ушли в крайности. Почему 3 месяца и 2 года? А если 1 год, 3 месяца и 1 год, 4 месяца? Тогда тоже большой шанс пролететь мимо? Откуда эти цифры? 3 месяца и 2 года и как они вообще относятся к сообщению, на которое вы отвечали?
Если конкурент выпускает на вашем рынке продукт за 3 месяца а вы за 2 года, то есть большой шанс пролететь мимо.
Никакая методология вам не поможет выпустить продукт за 3 месяца вместо двух лет. Даже за полгода вместо двух месяцев — не поможет. Даже за 4 вместо 3. Эффективность перевода времени в условные фиче-тугрики — это свойство исключительно вашей команды. Все, что может дать вам методология — это сделать так, чтобы в фиче-тугрики переводилась большая или меньшая часть всего затраченного времени. Если у вас нормальная команда, которая и так непосредственно работает, например, 80% времени, то никакая методология не даст вам прироста больше 25% (и, на самом деле, даже 25% никакая не даст, потому что максимальных 100% эффективности быть не может). Если у вас команда работает <50% времени — значит, у вас работают ленивые дебилы и кусок говна вместо менеджмента, они в любом случае все провалят, как бы вы кровати в своем борделе не двигали.
Так что реальный дрейф эффективности, который можно "выжать" из смены методологии самой по себе — это 10-15%, (что, в общем, тоже может быть иногда полезно, но, еще раз обращаю внимание, — что это по сути максимально возможный показатель, достигаемый в единичных случаях, обычно он будет сильно меньше), ни о каких 2 года вс 3 месяца тут речи нет и не будет…
Методология — это не про скорость выполнения проектов, это про другие свойства производственного процесса (которые уже в свою очередь могут повлиять на эффективность, но вне зависимости от методологии). А если кто-то вроде персонажей обсуждаемого рассказа за счет смены методологии самой по себе пытается повысить эффективность, и ничего не получается — то он сам себе злобный буратина, что забивает гвозди отверткой.
Никакая методология вам не поможет выпустить продукт за 3 месяца вместо двух лет. Даже за полгода вместо двух месяцев — не поможет. Даже за 4 вместо 3. Эффективность перевода времени в условные фиче-тугрики — это свойство исключительно вашей команды.
Это может быть не тот же самый продукт. Одна методология требует спроектировать все последовательно до последней запятой, другая позволит выпустить MVP а потом посмотреть как пойдет.
Это может быть не тот же самый продукт.
Если это будет не тот же самый продукт, то что с чем вы сравниваете и при чем тут методология? Продукт от методологии не зависит, он вам дан. Точно так же как и команда вам дана. Это все входные данные, на которые нельзя повлиять заменой методологии, наоборот — это методология подгоняется под указанные входные данные.
Одна методология требует спроектировать все последовательно до последней запятой, другая позволит выпустить MVP а потом посмотреть как пойдет.
Требует и позволяет не методология, а заказчик. И уже в рамках требований заказчика вы можете выбрать методологию, которая удовлетворит этим требованиям наиболее полно.
Если же свойства производственного процесса вам диктует методология, то у вас перепутана причина со следствием, естественно, потом и скрам помрет и водопад потечет вспять.
Сперва вы выводите то, каким должен быть процесс, и уже потом выбираете методологию, которая такой процесс обеспечит. Не наоборот. Фактически, при выборе методологии особой свободы-то и нет, раз она диктуется процессом.
Требует и позволяет не методология, а заказчик. И уже в рамках требований заказчика вы можете выбрать методологию, которая удовлетворит этим требованиям наиболее полно.
Так методология требует тоже — в том смысле в котором определение квадрата требует наличия четырех углов.
Так методология требует тоже — в том смысле в котором определение квадрата требует наличия четырех углов.
Нет, не требует. Я же говорю — у вас все вывернуто наизнанку. Должно быть не "у нас квадрат, и потому будет 4 прямых угла", а "нам тут надо 4 прямых угла, так что, видимо, потребуется прямоугольник, или вовсе квадрат".
Вы просто не можете понять альтернативную формулировку.
Потому что нету никакой альтернативной формулировки. Сперва вы выясняете, что вам нужны прямые углы, а потом уже подбираете фигуру, с этими углами. Не наоборот.
Если машина требует бензина, а у вас его нет не обязаетльно добывать бензин, можно поехать на велосипеде.
Конечно, не обязательно. Но к чему вы это?
равда велосипед потребует наличия сильных здоровых ног. А еще надо на нем уметь кататься.
То есть, это то, что дано. Я об этом и говорю.
Потому что нету никакой альтернативной формулировки. Сперва вы выясняете, что вам нужны прямые углы, а потом уже подбираете фигуру, с этими углами. Не наоборот.
Конечно, не обязательно. Но к чему вы это?
К тому, что вы можете понять, что у нас с вами примерно одинаковые точки зрения.
То есть вы даже не можете сопоставить два кусочка текста
выше "методология требует X" и "машина требует бензина".
Конечно, но поскольку менеджмент ничего кроме организации процесса контролировать не может, то в итоге закачик требует именно что некоторые свойства данного процесса. И перевести "хочу бабла, быстро и с минимальными рисками" в некоторые осмысленные, выполнимые ограничения — это и есть основная задача менеджмента.
Продолжая аналогию с коммунизмом (да простят ее мне любители политики и истории), можно тоже сказать что идеология-то хорошая, просто все время тут люди не очень умные попадаются, там не очень честные, и в итоге все разваливается.
1 — вообще именно проект и его сроки первичны, скрам — вторичен. Цель — сделать продукт, а не кодить ради кодинга.
Я бы сказал так — скрам хорош для крупных компаний, где все эти «неделю жду от соседнего отдела апи» и «субординация» во всей красе, а в мелких пользы особо не будет.
С субординацией сталкивался на одной из работ — там где надо было потратить 2 недели через начальства, я напрямую всё решил за 2 часа. И получил выговор.
Прям собран весь русский опыт внедрения SCRUM
Это наднациональная проблема. Она есть во всех странах. Причем, чем южнее страна, тем более запущена проблема. В Израиле, например, с этим вообще катастрофа. Скрам сжирает города.
Это азбука, аксиома: хороший разраб – это не хороший тимлид.
А ну-ка расскажите мне, из кого тогда сделать хорошего тимлида, если не из хорошего разраба? Из плохого разраба? Из хорошего ПМ-а? Из QA? Из человека без опыта вообще?
хороший разраб – это не хороший тимлид.
Тимлида делать из разраба. Но то, что он лучший разраб, отнюдь не означает, что из него получится лучший тимлид. Иногда лучший тимлид получится из посредственного разраба (всё, правда, зависит от того, что входит в обязанности тимлида у вас).
по крайней мере, в реальной жизни многие делают именно так
Иначе, кто именно в команде будет решать путь развития в техническом смысле?
Я думаю, что идеальной правильной формы нет и все зависит от размера бизнеса.
Интересно, что получится.
Что-то получится, это точно. И, как показывает практика, получается технически идеальная хрень, для последующий работы с которой нужен менеджер уровня того самого разработчика. Более того, после эксперимента вы потеряете программиста. Представим, что заказчик не примет проект. Вы обратно к программисту — давай переделывать. А это его творение и для него оно идеально, а заказчик м… к и ничего не понимает. А Вы, как начальник, тоже м… к, не смогли отстоять "правильное" решение
Потом, после того, как каждый в команде использует свой месяц — «неудачников» можно посадить обратно на конвеер, а хорошие идеи внедрить в продукт и дать их авторам бюджет, команду, свободу.
Я согласен с вами в одном — что слишком много инструментов контроля и управления, их действительно нужно сводить к минимуму. Но, все-таки, это зависит от бизнеса и команды, например, я не приемлю в команду людей, которым нужна «игровая модель» управления и подстегивания, но я могу себе позволить выбирать, в больших «корпорациях» нехватка кадров и им приходится стимулировать разных людей и тут ваш подход о свободах не поможет )
P.S. Продолжение нужно?
Есть вопрос? Есть ответ! ))
Данный рассказ на любителя… ну или на тонко-знающего предметную часть.
Было в комментариях выше, «А как же Серега?»
Пользуясь случаем, жду продолжение циклов «Проще, чем кажется» и «Корпоративная шизофрения» )
каждый раз я возвращаюсь к тому, что ребята правы — надо фигачить и это единственное средство которое реально движет проект к цели. Как в киберспорте — если ты проседаешь по индивидуальному скиллу или по командному взаимодействию — пошел вон. Без церемоний лишних. Никто тебя на себе тащить не будет. Почему у нас не так. Выкинуть всех дармоедов к чертям. И будет норм. Какой процент дармоедов у вас в команде? У нас около 15 процентов. Те люди отсутствия которых проект вообще никак не заметит.
Мне часто думается, что радикальный подход Егора Бугаенко (zerocracy.com, xdsd.org) во многом верен. Все что нужно — это багтрекер и код.
естественный отбор давно выкосил бы команды с «дармоедами»Нет. Ведь наличие «паразита» не убивает «хозяина». Если остальные вкалывают за троих, то можно брать «дармоедов» и проекты все равно будут успешными.
Хотя он и делает оговорку, что в проектах которые имеют долгострочную направленность такой подход может и не работать.
Спасибо за очередную дозу приятных впечатлений.
Очень порадовал тимлидом, потому что в scrum нет такой роли.
Боб котрый играет во взрослого тоже очень типичен.
То, что в документах по скраму эта роль называется другим словом, не значит, что роли нет.
>играет во взрослого
Если кто-то осознал, что надо не играть в «море кода волнуется раз!», а просто писать код — он таки реально повзрослел.
То, что в документах по скраму эта роль называется другим словом, не значит, что роли нет.
а каким словом называеться тимлид в scrum документах ?
Если кто-то осознал, что надо не играть в «море кода волнуется раз!», а просто писать код — он таки реально повзрослел.
Кому за что платят, мне платят не за код а за решения проблемм бизнеса. Иногда нужно посидеть и обсудить интеграцию, иногда архитектуру порисовать, иногда в CI поковыряться, если повезло с соседней командой то и в "море волнуеться раз" поиграть.
Позиция "ваши разговоры мешают мне писать код", имеет право на существования, как и любая другая. Просто как ботинки 46 размера она не всем подходит.
Называется словом scrum-master, не?
а каким словом называеться тимлид в scrum документах ?
Если я правильно понимаю, то в гибких методология нет иерархии, т.е. там нет тимлида. Предполагается, что уровень в команде ± одинаковый и все участники команды разработки равноправны. Владелец-продукта — это не начальник, он отвечает, за набор задач и их приоритет, но вмешиваться в дела команды не имеет права. Ну а SM — это вообще наблюдатель, который хоть и является членом команды, но может только советовать/рекомендовать. А следовать его советам или нет — это уже решать остальным участникам.
Если кто-то осознал, что надо не играть в «море кода волнуется раз!», а просто писать код — он таки реально повзрослел.Опять же, чем скрам мешает писать код?
Команда здесь ни причем, они – просто разработчики, они делают то, что ты скажешь!Первая ошибка. Скрам работает только тогда, когда это нужно всей команде. И прикол в том, что вся команда должна принимать решения. Да и при такой модели тимлид то и не нужен. Все его функции должны быть чисто административные.
В четыре раза быстрее!Это только в условиях постоянно меняющегося ТЗ и по сравнению с водопадом полного цикла (написание ТЗ->Разработка->Тестирование->Внедрение) Т.е. скорость увеличивается за счёт того, что при изменение требований по результатам внедрения можно не ждать пока полностью ТЗ напишут, а сразу делать.
не хватало только еще одного просранного проекта!Т.е. у них и так всё плохо и они надеялись на какую-то волшебную методологию?
Вот вам же нравилось, что мы стали чаще и стабильнее делать релизы
Ну и прозрачность повысилась, вы же сами говорили, как удобно стало оценивать остаток работ по проекту.Т.е. плюсы они понимают.
Просто. Нормально. Работать.И вот что изменится? Что их в скраме то тормозило?
Ну т.е. на лицо явное неумение Боба руководить: благодоря скраму он прекрасно видел прогресс и прекрасно должен был понимать дату релиза. Если это дата оказывалась после дедлайна он должен был либо уменьшить число фич, либо подключить ещё одну команду. И кстати, в стиле «Просто. Нормально. Работать.» об этом бы узнали только когда уже все сроки были бы просраны. И что по итогу? Ничего из мер не было предпринято, а виноват оказался самый толковый, и скорее всего самый полезный разработчик.
как удобно стало оценивать остаток работ
То есть, я так понимаю, скрам виноват в том, что не стал серебрянной пулей, не порешал все проблемы а лишь слегка улучшил ситуацию. Не говорите директору, что его жена какает, он сделает виноватой и её!
Боб опять уставился в окно. – Я ведь тоже поверил в эту хрень. Я про скрам. Я тоже думал, что он поможет нам быстрее делать проекты.ИМХО scrum вообще не про скорость. Как раз про все остальное.
— Твоя судьба, Джон! – крикнул Боб. – В провале проекта виноват только ты! Команда здесь ни причем, они – просто разработчики, они делают то, что ты скажешь! Как ты стадо гонишь, так оно и идет, понимаешь, Джон?
— Понимаю… — сокрушенно сказал Джон и снова опустил голову.
— Ты был прекрасным разрабом, и я никогда не думал о том, чтобы сделать из тебя тимлида. – продолжал Боб на повышенных тонах. – Это азбука, аксиома: хороший разраб – это не хороший тимлид. Но ты меня… Нет, не обманул – просто запудрил мне мозги своим скрамом, и я решил – вот, вот он, тимлид нового поколения! Инициативный, вдумчивый, ищущий, не замкнутый в стереотипах! Тот, кто мне нужен! Как же я ошибся!
После вышеприведённого блока я окончательно убедился, что автор заметки не знает/понимает, что такое Scrum. Дальше читать не стал.
На Хабре тема «обсёра чего-то отдалённо напоминающего Scrum» довольно хайповая, поэтому не удивлён в количестве плюсов у данного опуса.
Просто. Нормально. Работать.
Это ведь сарказм?
Тебе надо уточнить вопрос на который он не знает ответа — пишет тут же емейл кому надо, ты еще договорить не успел. Или, ты еще не договорил, он уже набирает чей-то номер или уже пишет кому-то указания в джиру. Необходимые шаги для решения вопроса предприняты. Голова свободна.
Не делегировать не хранить задачи в списках, а напрямую решать поставленную задачу. Здесь и сейчас, самым кратчайшим путем.
Да, конечно, в этом есть что-то уникальное от самого человека. Такое стопроцентное, постоянное присутствие сознания и концентрация — не уверен, что этому можно полностью научиться. Но вот технику «питейного рога» (который нельзя отставить в сторону) — вполне можно освоить.
И мне кажетсяв именно в том чтобы «напрямую решать поставленную задачу, здесь и сейчас, самым кратчайшим путем» и заключается смысл гибкой разработки. Все остальное шелуха.
Он еще, например, против любой работы которая не улучшает напрямую конечный продукт. Как он выражается «мы не продаем %xyz%, мы продаем продукт». Все так просто. Почему это так трудно понять? Нужно делать все, что непосредственно является целью бизнеса и не делать ничего остального. В книге Голдратта, в принципе, говорится о том же.
Есть у такого подхода и недостатки. Его код, конечно, отличается решениями «в лоб». Но какую претензию ему можно предьявить, если он твой баг пофиксил еще до того как ты его нашел.
все прерывания обрабатывает по фифо. Тут же берет и решает твой вопрос. Чтобы голова всегда была свободна. Никогда не откладывает ничего «на потом».
Это не фифо, это стек. То есть он решает рабочую задачу, ты подошел он занялся твоей, ты не успел отойти, подошел Вася — он уже отложил твою и занялся Васиной.
Фифо это ты подошел со своим вопросом, а он тебе «Вон у меня стопочка, напиши свой вопрос на листочек и положи снизу».
Правильно расставлять приоритеты.
C Тимлидами происходит примерно тоже самое, что с разработчиками после курсов, если ты в IT — ты сразу модный ) и можешь часами медитировать над Agile )
Видимо, Боба как Белоснежку усыпили яблочком на пару лет, а когда его поцеловал принц, он смог-таки заехать в офис и присмотреться к отчётам о работе.
Это сказ про то, как воспитывать персонал? Слово "скрам" можно заменить любым другим, сценарий от этого не меняется.
Да элементарно: благодаря скраму они еще до факапа поняли, что будет факап. Ну и конечно в этом виноват скрам.
Все эти аджайлы и скрамы они не про скорость. Они про что угодно, но не скорость.
Предсказуемость, гибкость, понимание как изменение изначальных договоренностей изменят срок. Примерно понять какой срок будет реален. Про "мы команда" (вот кстати в РФ именно командная работа хромает: очень часто слышу не МЫ сделали плохо, а Он/ВЫ сделали плохо)
Скрам позволяет вам чётко видеть, на каком этапе вы находитесь, что сделано, а что нет, кто чем занимается и какие у кого проблемы возникают в ходе работы. Не вижу, чем скрам может быть причиной провала проекта. Причина провала проектов не в скраме. Она, скорее, либо в плохом планировании (т.е. запланировали меньше времени, чем на самом деле необходимо), либо в плохо продуманной архитектуре приложения (т.е. сами себе граблей раскидали по дороге), либо в том, что заказчик хотел пингвина, а ему сделали попугая.
Я работал в команде где скрама не было и сейчас работаю в команде, где он есть. Для меня польза скрама очевидна. Да и для начальников, насколько я вижу, тоже: каждый начальник (да и разработчик тоже) всегда хочет чётко понимать, что уже сделано, над чем идёт работа сейчас, в какой она стадии, что в рамках скрама будет сделано ещё и какие проблемы возникают в ходе работы.
— Да я понимаю, просто… — начал было Джон.
— Послушай, услышь и запомни: я уволю тебя к чертям! – перешел Боб на крик.
Боб, похоже, хамло — перебивает и кричит,.
Боб, похоже, тупой — вместо того, чтобы разобраться в чем причина провала, сразу делает выводы.
И заказчик вроде доволен был.
— Конечно доволен! Потому что до этого он вообще ничего не получал!
То есть у заказчика есть печеньки а до этого не было ничего? Если вернуть как было, от этого будет не ничего, а кусок мяса?
— А как работать? – нахмурился Джон.
— Просто. Нормально. Работать. – чеканя каждое слово, сказал Боб.
Боб, похоже, тупой — эти три слова никак не описывают как работать. У них будет какой-то процесс работы, просто не будет никакого слова, как он называется.
То, что Боб не понимает, что этих слов недостаточно, чтобы описать, что собственно он хочет, еще один признак того, что он тупой.
Мой вывод — Боб, тупое хамло практически неспособное сказать ничего по сути и заменяющее анализ и аргументацию потоком эмоций. Ответственность за организацию работы он на себя брать не хочет.
У нас скрам, но через месяц дедлайн??? Это как? Завернули итеративную разработку в фикскост и продали клиенту? Ну и м… молодцы. Я бы пожалуй ответил Бобу следующее:
- Старик, я понимаю что ты на стрессе и все такое, но давай по честному, ок? Ты как опытный менеджер почуял грядущую жопу и ищешь виноватого. Слава Богу у тебя достаточно адеквата чтобы виноватым оказался ангуляр, докер, скрам, кофемашина или на худой конец не особо ценный сотрудник из линейного менеджмента. Если тебе так легче — пусть виноватыми будут скрам и я. Но даже Дон уже понимает что проблема не там. Да, мы долбоклюи. Мы начали делать итеративную разработку внутри фикскост проекта. Мы объяснили все Дону, а он сказал "да мне пофигу, как, просто пишите код". Вот тогда нам следовало объяснить Дону что у любой методологии плюсы и минусы. Что поезд хорошо держит рельсы, а мотоцикл быстро едет и хорошо поворачивает. Возить мебель на мотоцикле или устраивать гонки на поездах это хреновые идеи. И либо ему надо отразить итеративность в отношениях с заказчиком, либо нам надо не выпендриваться а расчехлить мспроджект и поставить ПМ ов на бюджет из расчёта 1 на 5 подчинённых. Но мы ничего из этого не сделали. Мы (вообще говоря вы) продали фиксированные обязательства, выкинули весь менеджмент оверхед из оценок (у нас скрам, какие менеджеры!), тем самым занизили стоимость, забили болт на трекинг (на деме поговорим, ага) и теперь ты на меня орёшь про близящийся дедлайн. Дедлайн, Боб! Это вообще слово из другой книжки! Ты врубаешься какой это долбаный цирк! А теперь позволь предложить как клоун клоуну: давай наденем взрослые штаны и начнём решать проблему конструктивно. А почему черт подери мы не можем двинуть этот хренов дедлайн?
Вообще, если планируется работать с лидом дальше — нужен нормальный анализ ошибок проекта с выделением областей применимости вышеупомянутых инструментов и техник. А в приведенной форме это выглядит как классическая манипуляция с созданием чувства вины у выбранного стрелочника и последущим забалтыванием для затирания аргументации и закрепления чувства вины. Поэтому я и не люблю работу в офисе с коммуникацией не подразумевающей ведение истории (правда у меня значительный опыт удаленной работы аутсорсером и есть возможность сравнивать). Личностей мнящих себя непревзойденными манипуляторами (или просто очень хитрыми и умными) — множество, тратить время на борьбу с манипуляциями не очень то и продуктивно. А наличие истории общения по крайней мере сдерживает самых тупых — потому что полные идиоты выпиливаются моментально.
Мне кажется, так читать удобнее.
Не в знаках, а в авторских листах.
Это у вас? Или у меня? Или у кого?
Как там измеряют в издательстве, дело ихнее.
Про удобно или неудобно — надо знать чье-то еще мнение. Вы первый, кто обратил внимание на переносы.
— либо ругался и спорил со всеми комментаторами;
— либо бросил бы писать ниочемные тексты.
Я вроде не делаю ни того, ни другого. С вами вступил в беседу только потому, что мне показалось, она может принести пользу удобочитаемости моих текстов.
Но, к сожалению, емуНравится && емуНеудобно = 0.
Scrum is dead