Рубрика «управление разработкой» - 128

Предлагаю перевод небольшой статьи Андерса Абеля на волнующую меня в данный момент тему — качественный и формализованный процесс подготовки задач к передаче в разработку при условии, что разработка ведется по скраму. Если у кого-то есть опыт использования описанного данным автором подхода, итересно было бы, если бы вы поделились нюансами. Оригинал статьи: «Using Kanban for Scrum Backlog Grooming».

картинка по запросу grooming:

image

***

Поддержка бэклога в скрам-проектах – это важная задача. Он очень быстро разрастается до сотен задач, находящихся на разных стадиях готовности для включения в спринт. В моём текущем проекте мы подключили Канбан-доску для помощи в поддержке бэклога и повышения эффективности груминга.
Читать полностью »

Прочитал статью коллеги Andrey2008 о добавлении, а точнее сопротивлении добавлению в проект библиотек и решил описать «чек-лист» который я использую в работе со сторонними компонентами. Пока соотношение решений в пользу готовых/написанных с нуля за последние лет 10 примерно укладывается в пресловутые 80/20, может это мне просто везет.
Читать полностью »

Пять причин не использовать своих сотрудников для перевода и локализации - 1
Переведено в Alconost Translations

Мы часто работаем с международными организациями, которые говорят: «Для перевода контента мы используем наших специалистов по продажам в каждой стране». Или: «Каждый менеджер по продукту обращается к своим контактам за языковыми услугами». За этим обычно следует замечание: «По-моему, мы теряем деньги, на все это уходит слишком много времени, и меня беспокоит вопрос защиты нашего глобального бренда».

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

Конечно, многие мультинациональные организации располагают своими командами квалифицированных языковых специалистов, что дает им огромные преимущества. Но не всем компаниям так повезло. При этом такие компании не всегда предпочитают обратиться к переводчикам и лингвистам на аутсорсе.

Итак, как организовать работы по локализации, чтобы поддержать растущие бизнес-потребности?
Читать полностью »

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

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

Читать полностью »

Горький опыт создания игровой компании - 1

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

Эта история о страстной мечте с печальным концом.

Летом 2012 я решил отдаться моей самой главной страсти – созданию компьютерных игр. У меня были средства, и я думал, что у меня есть всё необходимое для того, чтобы создать кампанию, занимающуюся разработкой игр.

Мы решили назвать её “Supersonic Parachute”.

Я не буду вдаваться в подробности, но укажу самые главные причины, которые привели нас к провалу.
Читать полностью »

Предлагаю вашему вниманию перевод небольшой статьи Гойко Аджича на тему разделения пользовательских историй от 2012 года, с иллюстрациями и примерами автора: "Splitting User Stories: The Hamburger Method" — сделал его, в первую очередь, для себя.

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

Решение: Метод гамбургера

image
Читать полностью »

Доступны записи докладов Community DevCamp - 1Стали доступны записи докладов Community DevCamp – мероприятия для разработчиков от разработчиков.Основные докладчики — признанные эксперты сообщества, которые расскали о том, как они видят, используют или планируют использовать самые последние новинки для разработчиков на .NET — .NET Native, Roslyn, кросс-платформенную разработку на ASP.NET, контейнеры Docker, Azure Service Fabric, F# — и многое другое.

Записи всех докладов доступны по ссылке:
channel9.msdn.com/Events/Community-Dev-Camp/Community-Dev-Camp-2015-Moscow

Мероприятие проводилось при поддержке сообщества MVP.
Читать полностью »

image

Под катом интересный опрос

Возможно, заголовок этой статьи покажется Вам не корректным, ”Как можно писать open-source код? И что это за код такой?” — спросите Вы.

Чем open-source код отличается от “просто-кода”? Open-source проект — это ответственность за качество кода, за покрытие его тестами, за документацию, за своевременные ответы на вопросы и реагирование на bug репорты, за обработку pull-request’ов. Ваше поведение и мысли во время написания open-source кода, который увидит мир будут другие, соответственно и код на выходе получается другой.

Open-Source проект живет своей жизнью — жизнью сообщества, которое образуется вокруг проекта. Идеи, отзывы, bug репорты, обсуждение и благодарности от других членов сообщества влияют на Вас и проект напрямую, и стимулируют написание кода — понятного, документированного и покрытого тестами.

Читать полностью »

(начало статьи здесь)

Управление рисками при инвестировании в программистские таланты

С другой стороны — этот эффект не имеет названия; возможно, его следовало бы именовать «десятикрадничеством» — плохие разработчики будут стоить вам отнюдь не незначительного ухудшения производительности труда. Нет, по целому ряду трудноуловимых причин они способны катастрофически саботировать сложную программную систему. Плохим разработчиком, построившим угрожающе полную ошибок или из рук вон плохо спроектированную систему, в её основание заложена тикающая бомба замедленного действия, и чтобы разгрести руины после того, как она рванёт, потребуются вложения, тысячекратно превосходящие сэкономленное на старте. Хуже того, работа по разбору завалов потребует привлечения усилий гораздо большего количества хороших разработчиков, и на более длительное время.

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

Читать полностью »

От переводчика

Почитывая несколько лет назад журнал «Форбс», я наткнулся на статью, которую нашёл крайне интересной. Ну, знаете как бывает — читаешь, читаешь, и на каждом абзаце воскликаешь: «О! Це ж про меня!». Не мог поверить, что я один такой, и никто не сподобится уж если не перевести, то хотя бы сослаться на неё в русскоязычной прессе. Однако за четыре года этого так и не произошло. Ну что ж, «хочешь сделать что-то правильно — сделай это сам», посему предоставляю вниманию почтенной публики первую половину статьи. (Стараюсь переводить художественно, поэтому работа двигается небыстро; размер оригинала — больше 30 килобайт, и, «земную жизнь пройдя до половины», я понял, что держаться нету больше сил.)

P.S. Так и не смог разобраться, как поставить в заголовке тег «перевод».

Восход разработчикономики

Статья Венкатеша Рао опубликована в декабре 2011 года в журнале «Форбс».

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

В последнее время я размышлял над этой идейкой в контексте человеческого богатства. Если только вы не являетесь профессиональным инвестором (а даже если и являетесь), в настоящее время находить места для хранения избытка капитала, где он бы был в безопасности и не амортизировался слишком быстро (не говоря уже о принесении дохода) становится всё сложнее и сложнее. Фондовый рынок всё чаще навевает мысли о кровавом пиршестве “медведей”. Волатильность и неожиданные кратковременные ралли делают игру с короткими позициями небезопасной. Даже хранение активов в долларах, похоже, таит свои опасности — благодаря угрозе девальвации и всяким новомодным словечкам вроде «количественного смягчения», которые мы, среднестатистические инвесторы, слышим впервые. Евро сейчас тоже не смотрится как радужная альтернатива. Решение инвестировать в золото — и вообще в любое сырьё — кажется, требует несколько апокалиптического взгляда на мир, и размышлений о том, как вы планируете получить доступ к собственно предмету владения в случае, если всё и правда полетит в тартарары (хочется отметить, что в настоящий момент не могу назвать такой взгляд на мир так уж неоправданным).

Но есть одна тихая гавань — если вы знаете, как в неё вложиться: разработчики ПО.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js