Комментарии 30
Потому моему опыту — либо инструмент заточен под какой-то класс задач и в них удобен, либо это мультитул, который может всё, но сильно неудобней, чем специальный инструмент.
Конкретно тут решалась задача создать систему в которую можно вложить деньги и/или силы и получить предсказуемый результат.
Безусловно, у меня есть своя специфика проектов разработки и именно под нее все это и делалось ))
Но, думаю, этот документ все же может принести некоторые полезные идеи и другим разработчикам.
Но если ваш выбор методологий будет расширен еще потенциально одной, мне кажется, это даст вам больше информации для принятия правильных решений.
На самом деле эта идея прорабатывалась очень долго и количество разных ситуаций прогнанных через нее было огромно.
Если повезет, то проверим ее на практике ))
ИМХО, у вас подозрительно хорошо организована техническая команда и подозрительно плохо — продуктовая. Если бизнес не является прибыльным — совершенно не важно насколько хороша архитектура, ну а бизнес, в свою очередь, редко бывает прибыльным если все всегда делать «технически правильно».
Аджайл он не про то, что надо плохо-кодить и все делать по-быстрому, он про баланс между продуктом и техническим качеством / тех. долгом (точнее, тех. «кредитом»).
Работа технических специалистов состоит в том чтобы дать бизнесу опции и четко проговорить риски, но выбирать всё-таки должен бизнес, который платит и рискует деньгами.
p.s. Вы можете быть со мной не согласны
Эта методология не про то как сделать все технически правильно. Она про предсказуемость реализации идей и прозрачность работ.
Просто для уточнения agile — это набор принципов. Наиболее распространенная agile методология у нас это SRCUM. Я собеседовался в команду, которая следовала все его канонам буквально и я к ним не пошел, так как теперь поддержка их проекта это ад.
Вы правы что работа технических специалистов состоит в том, чтобы дать бизнесу опции. не вижу в чем бы эта методология не давала бизнесу эти опции. Сорее наоборот тут бизнес сразу работает с командой и в любой момент видит как реализуется идея и успешна ли она.
Предположим, вы выберете создание собственной ERP системы, типа 1С. Тогда все рассуждения об agile’ах, SCRUM’ах, беклог'ах, DevOps'ах, багтрекенг'ах, Eptda'ах, story point'ах и т.п. уйдут, явно, на второй план. Народ сильно возбудится от одной только мысли, что кто-то покушается на «святое».
И потом для нового продукта нужны сильные и свежие идеи. Технического и технологического плата, в первую очередь, а не организационного. Кто-то из менеджеров сказал, чтобы ПО взлетело, нужно, чтобы оно содержало, как минимум, 50-60 новых идей (типа «ноу-хау»). У вас такие идеи есть?
Кто-то из менеджеров сказал, чтобы ПО взлетело, нужно, чтобы оно содержало, как минимум, 50-60 новых идей (типа «ноу-хау»). У вас такие идеи есть?
У меня есть, могу продать.)
Подойдет ли эта методология, чтобы создать операционную систему, аналог 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"?
и т.д…
Низкая роль аналитики и тестирования в agile также не идет на пользу продуктам компании
Я вот всё время думал, что agile как раз про аналитику и тестирование:
— Чтобы знать куда гнуться, необходимо собирать метрики и анализировать.
— Чтобы не ломаться, когда гнёшься, надо грамтно тестировать.
В реальности аналитиков просто нет в 60% софтверных компании, в частности в Москве. Нормальное тестирование я видел только в одной крупной известной компании.
В SCRUM (agile) методологии зачастую есть Product Owner
Важные отличия от agile (SCRUM)
У меня стойкое ощущение, что для вас scrum и agile — это синонимы, и ничего другого вы не пробовали.
Ну и вы уже опробовали вашу методологию? Как работает? Что говорят аналитики по результатам её использования? Или это теоретические фантазии в вакууме?
Отвечать за фин.показатели почти не имея инструментов влияния и рассчитывая, что ресурсов почему-то всегда будет хватать.
Если у вас нет аналитики, то у меня к вам вопросы:
Ответом на большинство вопросов было бы «мы ведем документацию». «Нужна ли эта кнопка» можно спросить в подразделении внедрения/техподдержки. Также часть задач по аналитике может быть размазана по подразделению разработки. (И это не умозрительный пример, а вполне существующий, живой и работоспособный, наблюдал своими глазами)
В целом, статья-то неплохая, видна проработка, но Вы основываете рассуждения на изначально сомнительных предпосылках.
можно спросить в подразделении внедрения/техподдержки
Обычно так и делают. Я отразил в этой статье, что необезательно так делать, это может быть дорого.
Также часть задач по аналитике может быть размазана по подразделению разработки. (И это не умозрительный пример, а вполне существующий, живой и работоспособный, наблюдал своими глазами)
Я тоже это постоянно наболюдаю. Беда в том, что у этого своя цена, и цена эта — меньше времени разработки нового функционала. Часто разработка смещена на поддержку в большую сторону, что совсем печально.
Я тоже это постоянно наболюдаю.
Я не знаю, что Вы наблюдали, но у меня выводы совершенно другие. Будучи в курсе потребностей пользователя и нюансов поддержки, разработчику потребуется куда меньше итераций для реализации фичи. Имел в практике случаи выполнения задач за минуты против нескольких дней, пройди они через аналитика. Это и с допросом пользователя, и с тестированием, и с code review.
По моим наблюдениям, в 99% случаев аналитик выполняет роль испорченного телефона. Это не значит, что он не нужен. Это значит, что он нужен крайне редко (либо если предметная область настолько сложна, что разработчик даже за полгода азы постичь не сможет) и ставить его во главу угла — чистая авантюра и самодурство.
Тут всё просто — аналитик нужен разрабам, не умеющим в аналитику. Если разраб умеет, то аналитик конечно будет лишним звеном.
Если ваши разработчики не общаются с заказчиком напрямую и не ведет требования (в любом виде), при этом не отдельно, а согласуя их со всеми участниками процесса, то они не могут считаться аналитиками.
Вы так уверенно и безапелляционно утверждаете, что аналитик — всенепременнейше центральная фигура (а потому необходим везде и всегда) и что ваша интерпретация его задач единственно верна, что я не уверен в плодотворности этой дискуссии.
Будучи в курсе потребностей пользователя и нюансов поддержки
Смотрите, деньги которые выделяются на создание нового функционала это прямые расходы бюджета. То есть я плачу деньги и получаю то, что я попросил. А затраты на поддержку косвенные, то есть я не понимаю сколько я должен заплатить за поддержку и главное зачем. Поддержка проекта идет по убыточной статье, причем ее крайне сложно прогназировать и планировать. В итоге нужно деньги выводить в более прогнозируемые статьи расходов, а непрогнозируемые, или плохо прогнозируемы, уменьшать насколько возможно, IMHO.
Есть исключения: в частности, если вы выбрали бизнес подель для компании как продажу поддержки, то чем сложнее и запутаннее ваш проект, тем лучше. В этом случае, действительно, эта методология будет сложна в использовании. В этом случае усложнение поддержки проекта придется прямо планировать.
Имел в практике случаи выполнения задач за минуты против нескольких дней, пройди они через аналитика.
Мне кажется это, скорее, «ошибка выжившего». Вам порсто повезло один раз в маленьком случае, но если брать множество кейсов, то такой подход будет разрушать проект.
И тут вопрос, если ваши разработчики брали на себя роль аналитиков, фиксировали ли они эти изменения в проекте согласовывали ли их с командой, проводили ли анализ того, что эта фича может быть реализована в рамках другого функционала. Если нет, то можно поработать в таком проекте первый год, а потом бежать с него, оставив компанию разбираться с тем что получилось.
По моим наблюдениям, в 99% случаев аналитик выполняет роль испорченного телефона. Это не значит, что он не нужен. Это значит, что он нужен крайне редко
Это также может значить, например:
- Вы наняли на роль аналитика некомпетентного человека (не читал книжки по аналитике, нет реального опыта и т. п.)
- Аналитик нормальный, но его заставляют заниматься не его работой или он перегружен, что ведет к медленной и неэффективнйо работе. Это исправляется, в том числе, введением нормальной методологии работы
То есть я плачу деньги и получаю то, что я попросил
Прямо маркер начинающего бизнесмена из палаты мер и весов. Не подумайте, я не в обиду, сам немного такого коснулся. Но под началом таких руководителей работать я зарекся.
Мне кажется это, скорее, «ошибка выжившего».
Я там проработал 5 лет. Компания живет и здравствует по сей день. Не первый десяток лет, кстати.
Нужна ли новая методология разработки?