Комментарии 30
Интересно узнать, из какого опыта была построена методология?
Потому моему опыту — либо инструмент заточен под какой-то класс задач и в них удобен, либо это мультитул, который может всё, но сильно неудобней, чем специальный инструмент.
Потому моему опыту — либо инструмент заточен под какой-то класс задач и в них удобен, либо это мультитул, который может всё, но сильно неудобней, чем специальный инструмент.
Я работал во многих компаниях в роли сотрудника или руководителя, каждый раз проводя полную ретроспективу работы компании. Кроме того, я ознакомился с источниками по известным методологиям. Лично мне удалось поработать по RUP, MSF, SCRUM, Project Management (PMBOK), ITIL, разных гибридах и без методологий, в принципе.
Конкретно тут решалась задача создать систему в которую можно вложить деньги и/или силы и получить предсказуемый результат.
Безусловно, у меня есть своя специфика проектов разработки и именно под нее все это и делалось ))
Но, думаю, этот документ все же может принести некоторые полезные идеи и другим разработчикам.
Конкретно тут решалась задача создать систему в которую можно вложить деньги и/или силы и получить предсказуемый результат.
Безусловно, у меня есть своя специфика проектов разработки и именно под нее все это и делалось ))
Но, думаю, этот документ все же может принести некоторые полезные идеи и другим разработчикам.
А есть обоснования, почему созданная методология в каком-то конкретном классе кейсов будет лучше, чем правильно выбранная для этого кейса существующая методология? И если есть, то для каких кейсов?
Сложно сказать. Я не подгонял эту задумку под конкретное семейство кейсов.
Но если ваш выбор методологий будет расширен еще потенциально одной, мне кажется, это даст вам больше информации для принятия правильных решений.
На самом деле эта идея прорабатывалась очень долго и количество разных ситуаций прогнанных через нее было огромно.
Если повезет, то проверим ее на практике ))
Но если ваш выбор методологий будет расширен еще потенциально одной, мне кажется, это даст вам больше информации для принятия правильных решений.
На самом деле эта идея прорабатывалась очень долго и количество разных ситуаций прогнанных через нее было огромно.
Если повезет, то проверим ее на практике ))
ИМХО, у вас подозрительно хорошо организована техническая команда и подозрительно плохо — продуктовая. Если бизнес не является прибыльным — совершенно не важно насколько хороша архитектура, ну а бизнес, в свою очередь, редко бывает прибыльным если все всегда делать «технически правильно».
Аджайл он не про то, что надо плохо-кодить и все делать по-быстрому, он про баланс между продуктом и техническим качеством / тех. долгом (точнее, тех. «кредитом»).
Работа технических специалистов состоит в том чтобы дать бизнесу опции и четко проговорить риски, но выбирать всё-таки должен бизнес, который платит и рискует деньгами.
p.s. Вы можете быть со мной не согласны
Продуктовая команад, по моему опыту, всегда организована плохо. Существует куча хороших книжек как ее надо организовывать, но я ни разу не видел ни одного грамотного управленца. Никогда. А я их видел много.
Эта методология не про то как сделать все технически правильно. Она про предсказуемость реализации идей и прозрачность работ.
Просто для уточнения agile — это набор принципов. Наиболее распространенная agile методология у нас это SRCUM. Я собеседовался в команду, которая следовала все его канонам буквально и я к ним не пошел, так как теперь поддержка их проекта это ад.
Вы правы что работа технических специалистов состоит в том, чтобы дать бизнесу опции. не вижу в чем бы эта методология не давала бизнесу эти опции. Сорее наоборот тут бизнес сразу работает с командой и в любой момент видит как реализуется идея и успешна ли она.
Эта методология не про то как сделать все технически правильно. Она про предсказуемость реализации идей и прозрачность работ.
Просто для уточнения agile — это набор принципов. Наиболее распространенная agile методология у нас это SRCUM. Я собеседовался в команду, которая следовала все его канонам буквально и я к ним не пошел, так как теперь поддержка их проекта это ад.
Вы правы что работа технических специалистов состоит в том, чтобы дать бизнесу опции. не вижу в чем бы эта методология не давала бизнесу эти опции. Сорее наоборот тут бизнес сразу работает с командой и в любой момент видит как реализуется идея и успешна ли она.
Все это, конечно, интересно и даже нужно, но только одна сторона медали. Здесь было бы познавательней почитать о второй стороне – какие программы собираетесь выпускать, какие идеи и технологии разработки использовать. Пожалуй, надо плясать от программы. Если вы, допустим, собираетесь делать с нуля аналог русской Виндоуз, то это будет один проект и бизнес-план. А если делать альтернативу Ютубу, то получим другой расклад (с которым пытается справится МедиаГазПром). А при желании составить конкуренцию фирме 1С и ее продуктам, выйдем на третий вариант.
Предположим, вы выберете создание собственной ERP системы, типа 1С. Тогда все рассуждения об agile’ах, SCRUM’ах, беклог'ах, DevOps'ах, багтрекенг'ах, Eptda'ах, story point'ах и т.п. уйдут, явно, на второй план. Народ сильно возбудится от одной только мысли, что кто-то покушается на «святое».
И потом для нового продукта нужны сильные и свежие идеи. Технического и технологического плата, в первую очередь, а не организационного. Кто-то из менеджеров сказал, чтобы ПО взлетело, нужно, чтобы оно содержало, как минимум, 50-60 новых идей (типа «ноу-хау»). У вас такие идеи есть?
Предположим, вы выберете создание собственной ERP системы, типа 1С. Тогда все рассуждения об agile’ах, SCRUM’ах, беклог'ах, DevOps'ах, багтрекенг'ах, Eptda'ах, story point'ах и т.п. уйдут, явно, на второй план. Народ сильно возбудится от одной только мысли, что кто-то покушается на «святое».
И потом для нового продукта нужны сильные и свежие идеи. Технического и технологического плата, в первую очередь, а не организационного. Кто-то из менеджеров сказал, чтобы ПО взлетело, нужно, чтобы оно содержало, как минимум, 50-60 новых идей (типа «ноу-хау»). У вас такие идеи есть?
Кто-то из менеджеров сказал, чтобы ПО взлетело, нужно, чтобы оно содержало, как минимум, 50-60 новых идей (типа «ноу-хау»). У вас такие идеи есть?
У меня есть, могу продать.)
Можно порассуждать какие программы можно выпускать про это методологии.
Подойдет ли эта методология, чтобы создать операционную систему, аналог Windows? Да. Она как раз и предназначена для уменьшения сложности разработки и увеличения времени поддержки проекта.
Касательно своих идей проектов, этим мало кто будет делиться.
Подойдет ли эта методология, чтобы создать операционную систему, аналог Windows? Да. Она как раз и предназначена для уменьшения сложности разработки и увеличения времени поддержки проекта.
Касательно своих идей проектов, этим мало кто будет делиться.
Подойдет ли эта методология, чтобы создать операционную систему, аналог Windows? Да. Она как раз и предназначена для уменьшения сложности разработки и увеличения времени поддержки проекта.
Предназначать можно что угодно чему угодно. Вопрос только, потянет ли? «Уменьшение сложности разработки» это слишком объемная тема, чтобы ее можно было свести только к организационным моментам, экспериментального плана.
Подобный проект, для аналога Windows, уже есть. Это «ReactOS», ныне версии 0.4.13 ( ru.wikipedia.org/wiki/ReactOS ). Это международный опенсорсный проект, который находится на стадии альфа-тестирования уже как-никак 23 года.
Вы хотите сказать, что достигли бы ее уровня быстрее и меньшими силами? Сейчас вы начнете говорить, что вам для подобной задачи нужны ресурсы: деньги, деньги и еще раз деньги. А также программисты, программисты и еще раз программисты. Ну, так они всем нужны. Вот сидит спонсор и думает, кому бы дать денег и на что? Я бы лично уже вложился в существующую команду ReactOS, а была бы возможность, и государственную поддержку организовал бы, особенно если бы основная разработка велась бы на территории России, русскими программистами.
Отсюда следует, что идти надо от обратного. Задача, ресурсы, предварительная смета, технические исследования, конкурсный набор команды и далее уже работа по какой-нибудь проверенной методике. С учетом того, что окончательная смета может быть на порядок дороже предварительной.
Касательно своих идей проектов, этим мало кто будет делиться.
Речь шла не о том, чтобы «делиться», а о том, есть ли они или их нет. Т.е., прямой вопрос – прямой ответ. Есть идеи? – Есть! Какие? – А это уже другой вопрос! Хотя количество идей вполне можно озвучить, думаю, что вы ничего не потеряете от этого.
Тем не менее, я, скажем, своими идеями вполне готов делиться. Поскольку, только любитель и меня вполне устроит, если кто-то «мою» работу сделает за меня. Но делать ее никто не хочет, что я давно понял из обсуждения на разных форумах, поэтому приходится мучатся самому. А это проект вполне доступный одному профессиональному программисту за несколько лет работы.
Речь идет об опенсорсном клоне «рабочей лошадки» 1С77. Да, есть открытый проект «2С», но он не взлетел, во-первых, потому, что использовал, давно уже непопулярный, MFC. А, во-вторых, концепция там была выбрана не слишком дружелюбная к пользователю.
Эта программа используется во многих фирмах до сих пор. И весьма эффективно, особенно на «малых и средних предприятиях». Меня самого кормит 100%-но моя конфигурация по «зарплате» уже 15 лет. Однако «семерка» не развивается с 2006 года. Часть решений у нее очень удачна, часть не очень. Поэтому, с учетом опыта использования, есть резон написать с нуля подобную программу, с поддержкой 64-х бит, SQLLite и MMF. Можно сделать ее совместимой по данным с существующими конфами 1С. Добавить систему плагинов, с открытым SDK, для бизнес логики, которые будут аналогами конфигураций. Соответственно, не надо будет писать конфигуратор, собственный скриптовый язык и отладчик. Все это уже есть в С++. Для создания интерфейса идеально подходит WTL. Сетевую работу может обеспечить аналог планов обмена, как в восьмерке. Таким образом, с учетом имеющегося опенсорса, трудоемкость создания программы для профессионала займет не 20 человеко-лет, как оригинал (10 человек писали 1С77 два года), а, думаю, примерно, пять. Что, конечно, более обозримо.
Мой предварительный опыт работы в этом направлении говорит, что самая сложная часть это создание собственного универсального контрола для формы списков, формы элементов (диалогов), табличных и печатных форм. Можно применять готовые наработки, но что-то они мне мало нравятся.
Новая методология может и нужна, но ваша не взлетит.
Главная проблема — вы слишком всё в кучу смешали. Идея взять всё лучшее из других вариантов и сварганить что-то своё не нова, но обычно получается фигня.
Да и вообще, известно же, что нет идеальных решений, устраивающих всех. Кому подойдёт ваша методология?
Явно не крупному бизнесу, где гендир не будет фокусировать внимание на отдельных командах и сотрудниках. С мелким бизнесом тоже не очевидно — там могут реально не требоваться все эти роли.
А что на счёт типов проектов/продуктов? Для инновационных у вас слишком жёсткие правила, для стадии устойчивого развития много лишнего.
Список можно продолжать.
Ну и отдельно, по мелочам:
— Гендир, подглядывающий за всеми сотрудниками, особенно в курилке? Кто ж согласится так работать, кроме самого гендира-маньяка?
— Сторипоинты в часах и прямо в календарь планировать? Может вы не знаете, зачем эти SP появились и почему в agile не меряют часами?
— Тимлид, который контролирует, как бы чего не усложнилось в проекте, игнорируя бизнес-задачи?
— Зачем вам вообще спринты, если у вас нету " times & materials"?
и т.д…
Главная проблема — вы слишком всё в кучу смешали. Идея взять всё лучшее из других вариантов и сварганить что-то своё не нова, но обычно получается фигня.
Да и вообще, известно же, что нет идеальных решений, устраивающих всех. Кому подойдёт ваша методология?
Явно не крупному бизнесу, где гендир не будет фокусировать внимание на отдельных командах и сотрудниках. С мелким бизнесом тоже не очевидно — там могут реально не требоваться все эти роли.
А что на счёт типов проектов/продуктов? Для инновационных у вас слишком жёсткие правила, для стадии устойчивого развития много лишнего.
Список можно продолжать.
Ну и отдельно, по мелочам:
— Гендир, подглядывающий за всеми сотрудниками, особенно в курилке? Кто ж согласится так работать, кроме самого гендира-маньяка?
— Сторипоинты в часах и прямо в календарь планировать? Может вы не знаете, зачем эти SP появились и почему в agile не меряют часами?
— Тимлид, который контролирует, как бы чего не усложнилось в проекте, игнорируя бизнес-задачи?
— Зачем вам вообще спринты, если у вас нету " times & materials"?
и т.д…
Низкая роль аналитики и тестирования в agile также не идет на пользу продуктам компании
Я вот всё время думал, что agile как раз про аналитику и тестирование:
— Чтобы знать куда гнуться, необходимо собирать метрики и анализировать.
— Чтобы не ломаться, когда гнёшься, надо грамтно тестировать.
Нет, в agile принципах про это не сказано. В существующих agile методологиях и их производных (XP, SCRUM, CRISTAL, Kanban) нет подробностей про аналитику и тестирование.
В реальности аналитиков просто нет в 60% софтверных компании, в частности в Москве. Нормальное тестирование я видел только в одной крупной известной компании.
В реальности аналитиков просто нет в 60% софтверных компании, в частности в Москве. Нормальное тестирование я видел только в одной крупной известной компании.
В SCRUM (agile) методологии зачастую есть Product Owner
Важные отличия от agile (SCRUM)
У меня стойкое ощущение, что для вас scrum и agile — это синонимы, и ничего другого вы не пробовали.
Ну и вы уже опробовали вашу методологию? Как работает? Что говорят аналитики по результатам её использования? Или это теоретические фантазии в вакууме?
Ну как упражнение норм. Методология это что-то более глобальное — бюджеты, риски и т.д. здесь — это больше фреймворк. Ну и большинство компаний (40% по данным, по-моему, Deloitte) используют in-house методологию — не вы первый. И да, уже заметили, что методология появляется от задач — есть методология внедрения Аксапты, например. Или в одной из компаний была методология с первыми этапами из PMI, а реализация идет в канбане, но для работы с подрядчиками использовали тоже начало PMI, а внутри реализации скрам франкенштейна со спринтами длиной в 2 месяца (кстати было удобно).
Ген.дир в эту команду должен быть из мира «розовых пони», где ресурсы нахаляву выдаются.
Отвечать за фин.показатели почти не имея инструментов влияния и рассчитывая, что ресурсов почему-то всегда будет хватать.
Отвечать за фин.показатели почти не имея инструментов влияния и рассчитывая, что ресурсов почему-то всегда будет хватать.
Если у вас нет аналитики, то у меня к вам вопросы:
Ответом на большинство вопросов было бы «мы ведем документацию». «Нужна ли эта кнопка» можно спросить в подразделении внедрения/техподдержки. Также часть задач по аналитике может быть размазана по подразделению разработки. (И это не умозрительный пример, а вполне существующий, живой и работоспособный, наблюдал своими глазами)
В целом, статья-то неплохая, видна проработка, но Вы основываете рассуждения на изначально сомнительных предпосылках.
можно спросить в подразделении внедрения/техподдержки
Обычно так и делают. Я отразил в этой статье, что необезательно так делать, это может быть дорого.
Также часть задач по аналитике может быть размазана по подразделению разработки. (И это не умозрительный пример, а вполне существующий, живой и работоспособный, наблюдал своими глазами)
Я тоже это постоянно наболюдаю. Беда в том, что у этого своя цена, и цена эта — меньше времени разработки нового функционала. Часто разработка смещена на поддержку в большую сторону, что совсем печально.
Т.е. спросить у техподдержки это дорого, а внедрить целую новую методологию, перестроить бизнес-процессы и ввести новую роль — дёшево?
Я не знаю, что Вы наблюдали, но у меня выводы совершенно другие. Будучи в курсе потребностей пользователя и нюансов поддержки, разработчику потребуется куда меньше итераций для реализации фичи. Имел в практике случаи выполнения задач за минуты против нескольких дней, пройди они через аналитика. Это и с допросом пользователя, и с тестированием, и с code review.
По моим наблюдениям, в 99% случаев аналитик выполняет роль испорченного телефона. Это не значит, что он не нужен. Это значит, что он нужен крайне редко (либо если предметная область настолько сложна, что разработчик даже за полгода азы постичь не сможет) и ставить его во главу угла — чистая авантюра и самодурство.
Я тоже это постоянно наболюдаю.
Я не знаю, что Вы наблюдали, но у меня выводы совершенно другие. Будучи в курсе потребностей пользователя и нюансов поддержки, разработчику потребуется куда меньше итераций для реализации фичи. Имел в практике случаи выполнения задач за минуты против нескольких дней, пройди они через аналитика. Это и с допросом пользователя, и с тестированием, и с code review.
По моим наблюдениям, в 99% случаев аналитик выполняет роль испорченного телефона. Это не значит, что он не нужен. Это значит, что он нужен крайне редко (либо если предметная область настолько сложна, что разработчик даже за полгода азы постичь не сможет) и ставить его во главу угла — чистая авантюра и самодурство.
Тут всё просто — аналитик нужен разрабам, не умеющим в аналитику. Если разраб умеет, то аналитик конечно будет лишним звеном.
Трудно не согласиться. Только как Вы себе представляете разраба, не умеющего в аналитику? А в кодовой базе он как разбираться будет? А в предметной области? А поиск плавающего бага как? Наверно, есть такие, но, как по мне, это не норма.
Аналитик может не разбираться в кодовой базе, может не искать плавающий баг. В предметной, области, безусловно, должен разбираться.
Если ваши разработчики не общаются с заказчиком напрямую и не ведет требования (в любом виде), при этом не отдельно, а согласуя их со всеми участниками процесса, то они не могут считаться аналитиками.
Если ваши разработчики не общаются с заказчиком напрямую и не ведет требования (в любом виде), при этом не отдельно, а согласуя их со всеми участниками процесса, то они не могут считаться аналитиками.
То есть у вас разрабочики прямо пишут документ требований, общаются с заказчиком напрямую, согласуют изменения с командой, определяют стейкхолдеров со стороны заказчика с кем общаться? Это именно то, что должен делать аналитик.
Разработчики пишут документацию и пользовательские инструкции. Соответствие последних контракту и ТЗ отслеживает РП. В каждой компании свои бизнес-процессы. Аналитик далеко не у всех согласует изменения с командой, чаще ставит перед фактом (и это беда). А контакты со стороны заказчика определять могут продажник, сопровождающий этого клиента, и группа внедрения.
Вы так уверенно и безапелляционно утверждаете, что аналитик — всенепременнейше центральная фигура (а потому необходим везде и всегда) и что ваша интерпретация его задач единственно верна, что я не уверен в плодотворности этой дискуссии.
Вы так уверенно и безапелляционно утверждаете, что аналитик — всенепременнейше центральная фигура (а потому необходим везде и всегда) и что ваша интерпретация его задач единственно верна, что я не уверен в плодотворности этой дискуссии.
Будучи в курсе потребностей пользователя и нюансов поддержки
Смотрите, деньги которые выделяются на создание нового функционала это прямые расходы бюджета. То есть я плачу деньги и получаю то, что я попросил. А затраты на поддержку косвенные, то есть я не понимаю сколько я должен заплатить за поддержку и главное зачем. Поддержка проекта идет по убыточной статье, причем ее крайне сложно прогназировать и планировать. В итоге нужно деньги выводить в более прогнозируемые статьи расходов, а непрогнозируемые, или плохо прогнозируемы, уменьшать насколько возможно, IMHO.
Есть исключения: в частности, если вы выбрали бизнес подель для компании как продажу поддержки, то чем сложнее и запутаннее ваш проект, тем лучше. В этом случае, действительно, эта методология будет сложна в использовании. В этом случае усложнение поддержки проекта придется прямо планировать.
Имел в практике случаи выполнения задач за минуты против нескольких дней, пройди они через аналитика.
Мне кажется это, скорее, «ошибка выжившего». Вам порсто повезло один раз в маленьком случае, но если брать множество кейсов, то такой подход будет разрушать проект.
И тут вопрос, если ваши разработчики брали на себя роль аналитиков, фиксировали ли они эти изменения в проекте согласовывали ли их с командой, проводили ли анализ того, что эта фича может быть реализована в рамках другого функционала. Если нет, то можно поработать в таком проекте первый год, а потом бежать с него, оставив компанию разбираться с тем что получилось.
По моим наблюдениям, в 99% случаев аналитик выполняет роль испорченного телефона. Это не значит, что он не нужен. Это значит, что он нужен крайне редко
Это также может значить, например:
- Вы наняли на роль аналитика некомпетентного человека (не читал книжки по аналитике, нет реального опыта и т. п.)
- Аналитик нормальный, но его заставляют заниматься не его работой или он перегружен, что ведет к медленной и неэффективнйо работе. Это исправляется, в том числе, введением нормальной методологии работы
То есть я плачу деньги и получаю то, что я попросил
Прямо маркер начинающего бизнесмена из палаты мер и весов. Не подумайте, я не в обиду, сам немного такого коснулся. Но под началом таких руководителей работать я зарекся.
Мне кажется это, скорее, «ошибка выжившего».
Я там проработал 5 лет. Компания живет и здравствует по сей день. Не первый десяток лет, кстати.
[промахнулся веткой]
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нужна ли новая методология разработки?