• Должен ли программист быть немножко «product manager-ом»?
    0
    Ну да. Только менеджер должен понимать кто перед ним и задачи ставить соответствующие.
    p.s. Я с безответственными и безынициативными работать так и не научился :)
  • Должен ли программист быть немножко «product manager-ом»?
    0
    В упоминаемой проблеме есть два аспекта — инициатива и ответственность. В статье разбирается только один аспект, связанный с инициативой: «Нужно ли и можно ли разработчикам проявлять инициативу?»

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

    На мой взгляд, без инициативы невозможен профессиональный рост. Но, как следствие связи инициативы и ответственности, рост происходит тогда, когда вместе с проявлением инициативы вы берете на себя и ответственность за то, что делаете. Безответственная инициатива обычно приносит больше вреда чем пользы.
  • Как не сделать «какашку»? Личный опыт создания продукта
    0
    Спасибо за статью, было интересно почитать про реальный опыт.
    Скажите, пожалуйста, какого размера была команда на этапе «Think IT», кто в неё входил?
  • Codefreeze и непрерывная поставка
    +1
    Да, на первый взгляд одно и то же, различие в деталях. В GitFlow для каждого релиза стартуют отдельную ветку, которая потом сливается с мастером. Использование release branch полезно, когда нужно релизить несколько версий одновременно, но мы предпочли сфокусироваться на коротком цикле выпуска. У нас ветка релиза всегда одна, каждый следующий планируемый релиз просто вливается в неё из dev. Ветки dev & release друг от друга по сути почти не отличаются и больше похожи на develop из GitFlow. А то что в GitFlow называется release branch у нас не прижилось. Ветки обрабатываются сервером сборки абсолютно одинаково, результаты сборки деплоятся на разных стендах. В ветке release ведется разработка также как и в dev, но границы возможных изменений в release жестко ограничены, чтобы процесс был сходящимся. Также существенная разница приоритетах усилий по тестированию и исправлению ошибок — основное внимание уделяется ветке release, dev тестируется и правится по остаточному принципу. Все усилия фокусируются на стабилизации и выпуске релиза.

  • Codefreeze и непрерывная поставка
    +1
    Почти. Мы начинали работать по GitFlow, а потом немного расширили модель, «развалив» ветку develop на две: dev и release.
  • Codefreeze и непрерывная поставка
    0
    Да, промежуточные релизы у нас выходят примерно раз в месяц
  • Codefreeze и непрерывная поставка
    +1
    1. Одновременно работают 6 разработчиков. Планируем расти.
    2. Да, проект состоит из одного (довольно большого) репозитория. На нескольких организовать управляемый процесс довольно трудно :(
    3. Каждая задача до завершения ведется в отдельной ветке и вливается в один из стволов (dev || release) только после завершения и предварительного тестирования на стенде разработчика. Я не стал пока про это писать, чтобы не усложнять. Таких веток в работе в идеальном случае — по количеству разработчиков, но иногда какие-то ProofOfConcept могут жить подольше. Могут двое работать в одной feature-ветке, например делая согласованные изменения на фронтенде и бэкенде. Вообще, стараемся делать так, чтобы эти ветки не висели долго. Делим задачи так, чтобы они делались за несколько дней и вливались в ствол. Старые ветки периодически чистим.
    4. Для поддержки старых версий есть два варианта. Первый — очень-очень осторожно сделать маленький-маленький хотфикс с последующим Sanity тестированием. Редкий кейс, стараемся избегать. Предпочитаем исправить обнаруженный баг в текущем релизе и обычным порядком выставить обновление.
  • Эволюционное управление разработкой — гарантированный путь к успеху
    +1
    Пусть и с некоторым опозданием, но хочется добавить позитива в эту ветку обсуждения.
    К сожалению, мне этот пост попался на глаза только сейчас. Полгода назад, когда всё только начиналось, я не знал слов «Эволюционное управление» и действовал скорее интуитивно. Однако, модель управления, которая в итоге получилась, очень напоминает, то что описано в статье.
    Такая модель — точно не серебряная пуля. Типовые проекты делаются по другому. Если вы точно знаете что хотите получить и влияние неопределённости на ваши планы минимально — все эти танцы неуместны.
    Совсем другая картина — когда ни вы, ни ваши заказчики точно не знаете что должно получиться в итоге, и имеете душевные силы признаться в этом себе и друг другу. Вот тут начинает в полный рост влиять используемый способ уменьшения неопределённостей. Я пришел к эволюционной идее после книг Талеба, он тоже рассказывает про «постепенное прилаживание», я адаптировал его идеи на программный код и управление требованиями.
  • Управление разработкой в проектах по созданию сложных программных систем. Опыт использования MS Project и Team Foundation Server
    0
    И еще, забыл написать почему вредно :)
    Вредно, если кратко — потому что борьба с ветряными мельницами непродуктивна. Если все засинхронизировать, все планы будут прозрачно перетекать и обновляться, то возникнет ложное ощущение того, что все под контролем. А в управлении проектом, повторюсь, задачи разработки — они даже не на втором плане по важности. Отсутствие такой прозрачной автоматизации в мелочах порождает необходимость немножко поработать головой и руками. Мозг не умеет работать с большим количеством мелких артефактов, приходится их обобщать. А это помогает расширить угол зрения.
  • Управление разработкой в проектах по созданию сложных программных систем. Опыт использования MS Project и Team Foundation Server
    0
    А вот тут ответ очень простой. Средства вполне могут быть. Но средства сами по себе никакую проблему не решают. Проблему (теоретически) смогут решить люди, которые эти средства будут использовать. Чтобы проблемы решались, эти люди должны уметь и понимать довольно много разных полезных вещей и еще больше делать. Чтобы был заметный эффект, потребуется не только система, которая что-то там умеет делать, но и реальное изменение в подходах к работе. Эти изменения коснутся не только менеджеров, но и программистов и руководителей. Людей способных и желающих провернуть подобные изменения в своих организациях слишком мало, чтобы сформировать рынок, который бы окупил создание подобной системы.
    Microsoft при первом релизе TFS запилили примитивную интеграцию TFS с Project, этим мало кто воспользовался — они и не стали развивать. Ничего личного. Просто бизнес.
  • Управление разработкой в проектах по созданию сложных программных систем. Опыт использования MS Project и Team Foundation Server
    0
    По моему опыту, сложности возникают всегда при попытке синхронизировать изменения между средством управления задачами (TFS, Jira, Redmine, Trac и т.п.) и инструментом управления проектом (как правило — Project, но может быть и Excel или даже бумажный лист). Ключевое слово — «приходится». Все эти сложности как бы намекают, что копаем не там где надо. И, хотя менеджерам, которые выросли из программистов (сам таким был) такая функция кажется очевидной, на самом деле ниоткуда не следует, что управление проектом и управление задачами работают в одних и тех же терминах.
    Даже программы мы давно уже не пишутся ассемблере, для этого используются языки высокого уровня, которые, конечно, не дают возможностей управления на уровне регистров, но внятно говорят машине чего мы от неё хотим.

    Так вот, к чему это я. Модель проекта, с которой работает менеджер и модель задач, с которой работают разработчики — это разные вещи и между ними не всегда возможна автоматическая синхронизация. Дажа, я бы сказал, она вредна. Проект включает в себя много факторов, и программирование — это только малая часть, далеко не всегда самая трудоемкая. А «интерфейс между слоями» — это совместная работа менеджера проекта, тимлида, аналитика и других заинтересованных лиц. Потому что слоёв не два, а гораздо больше.
  • Управление разработкой в проектах по созданию сложных программных систем. Опыт использования MS Project и Team Foundation Server
    +1
    Вот не поверите, только сегодня размышлял о том, что пора уже написать о том, что нужно отделять мух от котлет управление производством от управления проектами. Тогда снимается львиная доля проблем и сложностей.
  • Мыши плакали, кололись, но продолжали грызть кактус
    0
    Особенно радует «начать делать продукт качественным, удобным и т.п.» :)
    можно подумать, до этого все его специально делали плохо.
  • Мыши плакали, кололись, но продолжали грызть кактус
    0
    Боюсь, что это скорее Ваше заблуждение, по поводу количества свободного времени у менеджера.
    Если менеджер занимается делом, то у него ответственности и забот гораздо больше чем у любого разработчика, и неважно, насколько разработчик опытный. Кроме того, проблема, описанная в статье, находится в зоне ответственности менеджера. Именно потому, что у него, в отличие от разработчиков, есть доступ к информации и возможности влияния на ситуацию. Работа у него такая.
  • Любовь и ненависть к тайм-менеджменту
    0
    Спасибо за статью, очень хорошо легло на собственное мироощущение.
    К сожалению опоздал к возможности плюсовать топик :(, отыгрался на карме.
  • Управление привилегированными учетными записями
    0
    Так вся эта кухня для того и придумана. В идеальном случае человек входит в систему под личной учеткой, потом приходит на специальную веб-страничку и говорит: «дай ка мне доступ к серверу ABCDEF». И ему сразу открывается терминал в эту систему.
    Пароли в данной ситуации — это только средство предоставить ему доступ.
  • Управление привилегированными учетными записями
    0
    Так все эти «велосипеды» отчасти и придуманы для того, чтобы приладить многофакторную аутентификацию к тем системам, устройствам и т.п., которые сами этого делать не умеют. Я вижу два основных плюса от использования подобных систем:
    1. Строгая аутентификация пользователей, причем для всех систем используется один каталог пользователей.
    2. Централизованный аудит обращения ко всем системам.

    Но я ни в коем случае не буду утверждать, что эти системы нужно обязательно ставить всем и везде. Стоят они не дешево, преимущества, действительно, сходу не очевидны. Так что перед принятием решения о внедрении (или не внедрении) подобных решений, сначала нужно прийти к пониманию почему и зачем это делается.
  • Управление привилегированными учетными записями
    0
    Конечно можно :). Не хотел чтобы сочли пост рекламой в каком-либо виде.
    Из лидеров рынка я бы выделил ERPM от Lieberman Software и комплексное решение от Cyber-Ark. Есть решения от монстров рынка Identity Management — IBM и Oracle. Они не могут похвастаться большой функциональностью, это лишь дополнения к основным IdM продуктам. Есть нишевые решения, например Hytrust специализируется на защите виртуальных сред.
  • Я хочу писать тесты
    0
    Тут уже много всего было сказано, но я еще добавлю.
    На мой взгляд, неправильно воспринимать юнит и интегральные тесты как средство проверки работоспособности программы.
    Процедура тестирования — она, действительно, предназначена для того, чтобы проверить, что программа более менее работоспособна. Тесты пишутся для того, чтобы в любой момент можно было проверить работоспособность программы. А это, в свою очередь, необходимо для того, чтобы быть готовым к внесению изменений в программу.
    Понимание этой цепочки следствий приводит к следующему:
    Если вы пишете программу, развитие и изменение которой не планируется, то разработка тестов — это просто трата времени. Тестирование можно провести и вручную (оно все равно происходит).
    Но если вы используете гибкий подход к разработке, всегда готовы к появлению новых и изменению существующих требований, то тесты — это просто суровая необходимость. Без них просто невозможно обеспечить необходимую скорость внесения изменений.
  • Профессия «Руководитель». Или «Руководятел»? Давайте разберемся!
    0
    Спасибо за статью. Отлично изложено.
    Опоздал ставить плюс за статью, придется плюсовать карму :)
  • Обзор свежих материалов, июль-сентябрь 2012
    0
    Большое спасибо, шикарная подборка.
  • Мой велосипед для сниппетов
    +1
    Начинание правильное, сервис мог бы быть полезным для меня, ЕСЛИ БЫ:
    1. Была возможность интеграция в среду разработки. Без этого — проще пользоваться сторонними средствами.
    2. Была возможность подстановки значений. Я использую сниппеты не столько как сокровенное знание об алгоритмахх, сколько уменьшение рутинной писанины. Часто случается, когда одну и ту же строчку нужно написать много раз(например название свойства — его использует геттер, сеттер и поле для хранения значения)
  • Динамическая интерпретация метамоделей
    +1
    Тогда (из своего опыта) рекомендую включить в примеры задачи управления документами вообще и документооборота в частности (которые в статье почему-то упомянуты как не нуждающиеся в метамодели). Я много лет занимался вопросами как раз обобщенных решений для работы с документами, так что могу с уверенностью утверждать, что описываемый Вами подход в этих задачах вполне применим.
  • Динамическая интерпретация метамоделей
    +1
    ага, а еще эти методы позволяют аргументировано и безрезультатно проедать бюджет в течение весьма длительного времени. Потому как для того чтобы команда успешно реализовала метамодель, пригодную для практического применения, сначала нужно лет несколько успешно порешать практические задачи на прикладном уровне. А без этого почему-то получается очередной многофункциональный, очень полезный, но неповоротливый комбайн, который никто не понимает как использовать в конкретной задаче. :-(
  • Динамическая интерпретация метамоделей
    +1
    Вот такие примеры, как веб браузеры, (а вместе с ними — СУБД, и другие подобные решения, реализующие метамодели) очень надо включить непосредственно в статью. По опыту, человеку, далекому от понятия метамодели, объяснить что это такое и зачем нужно почти невозможно без живых, понятных ему примеров. В результате получается, что статья реально доступна только тем, кто уже и так понимает что такое метаподход. А для этой аудитории, честно говоря, ничего интересного не прозвучало :-(.
  • Будьте добры к программистам
    +4
    Ой, да ладно, можно подумать кто-то устроен по другому, от пекаря, до ракетостроителя!
    Банальное нытье эгоиста, думающего, что он самый разнесчастный. (специально утрирую, чтобы показать абсурд)

    image
  • Будьте добры к программистам
    +2
    Странный тезис.
    Программист всего лишь старается сделать мир лучше, исправляя его самые худшие проявления. При чем тут негатив?
  • Критика современных систем управления проектами
    0
    Скрестить ничего не мешает, как видите, это даже кто-то уже сделал.
    Только толку от этого, к сожалению, немного :-(.
    Если Jira вообще не является системой планирования, то MS Project, конечно, пытается это делать, но до того туманным способом… Вспоминается цитата из Р.Хайнлайна — «Демократия плохая система. Её единственное достоинство — она в 8 раз лучше любой другой.» Т.е. большинство достоинств Project кроются в недостатках других систем, он лучше их. Но не становится от этого хорошей системой.
  • Как два программиста хлеб пекли
    0
    Небольшой вывод — применение любых методологий просто ради их применения в легкую может привести совсем не туда, куда ожидалось. Любые методологии, шаблоны и прочий Фаулер придуманы для того, чтобы решать конкретные задачи. Но есть большой соблазн вляпаться в них до появления самих задач. Вот и получается такая, с позволения сказать, хлебопечка.
  • Критика современных систем управления проектами
    0
    Ну, поделитесь ;-) посмеемся вместе (в хорошем смысле).
  • Критика современных систем управления проектами
    +1
    Вы знаете, а я не хочу создавать систему управления проектами. Есть куча систем, которые с этой задачей справляются. Мне хочется создать инструмент планирования, который позволит создать приемлемый план, а потом скормить задачи из полученного плана в какой-нибудь issue-tracker типа Jira и отслеживать их выполнение. Мне кажется, что это в несколько раз проще, чем делать очередную систему управления проектами, и при этом даст заметный эффект.
  • Критика современных систем управления проектами
    0
    MS Project вполне можно использовать как систему управления проектом. Его сложно рассматривать как систему управления задачами, это верно. Тут уже можно обходиться личным общением или использовать TFS, Jira или любой другой трэкер.
  • Критика современных систем управления проектами
    0
    На самом деле, важно смотреть не только на то как мы оценивали задачи, а смотреть в динамике на изменение планируемого срока окончания работ. Пока у нас нет таких данных мы ни о чем не можем говорить, но у меня есть устойчивое ощущение, что скорость движения планируемого «хвоста» проекта (т.е. даты окончания) — величина достаточно стабильная. В частности, подобные наблюдения были сделаны в процессе анализа множества проектов, управляемых по методике освоенного объема. Было замечено, что коэффициент эффективности вложений (по сути отношение фактического результата к планируемым затратам) сильно не меняется после отметки 20% завершения. Это позволяет использовать эту величину для корректирования планируемого срока. Но беда это методики в том, что она требует очень точного расчета всех затрат, что почти невозможно когда проекты не очень большие и их много. Мне кажется, что оценка скорости движения хвоста проекта приведет к тем же результатам при существенно меньших затратах на получение этой оценки.
  • Критика современных систем управления проектами
    0
    Если команда под управлением менеджера становится в позу, то это означает только одно — надо гнать в шею либо команду, либо менеджера. А контроль — это не цель. Это лишь один из инструментов управления.
  • Критика современных систем управления проектами
    +1
    близко имел дело с:
    MS Project (+MS Project Server)
    Jira
    TFS
    Basecamp
    Trac
    Asana

    Издалека смотрел на Redmine, Мегаплан, LiquidPlanner.

    Много читал про разные другие системы (конкретных названий уже не скажу, все смешалось, уж больно они все похожи).
    Не упоминаю разнообразные персональные органайзеры, которые претендуют на управление проектами.
  • Критика современных систем управления проектами
    +1
    Интересная мысль… Я вообще больше думал в сторону автоматизации способа мышления, а это движение в сторону применения для планирования социальных инструментов — очень в духе времени :-)
  • Критика современных систем управления проектами
    +2
    Мне очень грустно развеивать Ваши заблуждения, но управление на самом деле бывает. Действительно, специалисты решают конкретные технические задачи, а менеджеры контролируют их деятельность. Но кроме них еще существуют руководители, которые весь этот бардак пытаются вести в некотором направлении. И при отсутствии управления все почему-то очень быстро превращается в иллюстрацию к басне «Лебедь, рак и щука». Случается, конечно, такое чудо, как самоуправляемые команды, но это очень большая редкость.
  • Gantt против Backlog
    0
    Несколько запоздало влезаю в дискуссию :-) Но уж очень интересна показалась тема.
    Прошло уже 2 года с поста, скажите, были ли реализованы какие-то интересные решения по скрещиванию ганта со скрамом?
    Я сейчас работаю над близкой тематикой, интересуюсь, кто что придумал.

    В качестве комментария хочу добавить, что, на мой взгляд, неправильно относиться к диаграмме ганта как к чему-то статическому и неизменному. Это лишь способ показать на шкале времени информацию о фактически выполненных и запланированных задачах. В начале итерации это только планируемые задачи, в конце итерации — все должно быть выполнено. И это логично приводит нас к утвверждению, что да, действительно, диаграмма Ганта каждый день должна быть новой. В идеальном случае (когда все идет по плану) она отличается от исходной только процентами выполнения задач. Но в реальности все не так и я не вижу смысле так цепляться за неизменность диаграммы Ганта. Это же не какая-то священная корова, а всего лишь инструмент визуализации.
  • Красной таблетки не существует
    0
    я уверен, что они неочевидны и даже после этого. Но это не говорит о том, что методология бесполезна.
    Она полезна, поскольку несет в себе бесценный опыт людей, которые её придумали. Очень важно понимать ПОЧЕМУ и ЗАЧЕМ создана эта методология. Но это совершенно не означает, что она всем поможет и всех спасет.
  • Красной таблетки не существует
    +5
    Автор сделал очень верное наблюдение — методологии (управления, проектирования, разработки — можете продолжить список) не приносят ожидаемой от них пользы. Но при этом он делает совершенно неправильный вывод — что эти методологии не нужны. Да, бесспорно, люди важны. Опыт бесценен и незаменим. Но нельзя же строить опыт на пустом месте?

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

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

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

    А вот кого стоит реально побить палкой — так это армию маркетологов, которые используют хорошие начинания вроде Agile для банального сбора денег. По факту на флаг выносится идея — «Вот мы вас щас научим и у вас наступит счастье». Грамотный маркетинг приводит к тому, что куча организаций под барабану несет свои деньги консультантам. И методологии становятся просто товаром. Очень многие покупают методологию, поскольку продавцы говорят, что успех прилагается бесплатно.

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