В этой статье я хочу рассказать о том, зачем мне понадобился тайм-трекер, как я его искал, почему не нашел и что из этого всего в итоге получилось.
Читать полностью »
Рубрика «управление разработкой» - 124
Кроссплатформенный Open Source Time Tracker
2016-01-23 в 11:31, admin, рубрики: open source, time tracker, ит-инфраструктура, разработка, управление разработкой, учёт рабочего времени, метки: time trackerИспользование Канбана для подготовки Скрам-бэклога
2016-01-19 в 13:32, admin, рубрики: agile, grooming, kanban, scrum, user story, перевод, управление разработкойПредлагаю перевод небольшой статьи Андерса Абеля на волнующую меня в данный момент тему — качественный и формализованный процесс подготовки задач к передаче в разработку при условии, что разработка ведется по скраму. Если у кого-то есть опыт использования описанного данным автором подхода, итересно было бы, если бы вы поделились нюансами. Оригинал статьи: «Using Kanban for Scrum Backlog Grooming».
картинка по запросу grooming:
***
Поддержка бэклога в скрам-проектах – это важная задача. Он очень быстро разрастается до сотен задач, находящихся на разных стадиях готовности для включения в спринт. В моём текущем проекте мы подключили Канбан-доску для помощи в поддержке бэклога и повышения эффективности груминга.
Читать полностью »
Как все-таки добавить в проект библиотеку
2016-01-19 в 10:44, admin, рубрики: библиотеки, Программирование, проектирование по, разработка, разработка приложений, разработка программного обеспечения, управление разработкой Прочитал статью коллеги Andrey2008 о добавлении, а точнее сопротивлении добавлению в проект библиотек и решил описать «чек-лист» который я использую в работе со сторонними компонентами. Пока соотношение решений в пользу готовых/написанных с нуля за последние лет 10 примерно укладывается в пресловутые 80/20, может это мне просто везет.
Читать полностью »
Пять причин не использовать своих сотрудников для перевода и локализации
2016-01-15 в 9:30, admin, рубрики: Alconost, cms, Crowdin, IT-стандарты, Блог компании Alconost, Inc., контент, локализация, Локализация продуктов, облачные платформы, перевод, работа над продуктом, технологии, управление разработкой 
Переведено в Alconost Translations
Мы часто работаем с международными организациями, которые говорят: «Для перевода контента мы используем наших специалистов по продажам в каждой стране». Или: «Каждый менеджер по продукту обращается к своим контактам за языковыми услугами». За этим обычно следует замечание: «По-моему, мы теряем деньги, на все это уходит слишком много времени, и меня беспокоит вопрос защиты нашего глобального бренда».
Когда интернациональные компании используют для локализации и перевода собственных сотрудников без соответствующих навыков и лингвистического образования, возникают огромные риски для качества результата, нет рычагов влияния на бюджет, а выполнение задач часто затягивается.
Конечно, многие мультинациональные организации располагают своими командами квалифицированных языковых специалистов, что дает им огромные преимущества. Но не всем компаниям так повезло. При этом такие компании не всегда предпочитают обратиться к переводчикам и лингвистам на аутсорсе.
Итак, как организовать работы по локализации, чтобы поддержать растущие бизнес-потребности?
Читать полностью »
Сопротивляйтесь добавлению в проект новых библиотек
2016-01-15 в 9:03, admin, рубрики: библиотеки, Блог компании PVS-Studio, Программирование, проектирование по, разработка, разработка приложений, разработка программного обеспечения, управление разработкой 
Итак, вам понадобилось реализовать в проекте функциональность X. Теоретики разработки программного обеспечения в этот момент говорят, что для этого нужно взять уже существующую библиотеку Y и использовать её для реализации необходимых вам вещей. Собственно, это классический подход в разработке программного обеспечения — повторное использование своих или чужих наработок (сторонних библиотек). И именно этим путём движется большинство программистов.
Однако, теоретики в статьях и книгах, забывают упомянуть, в какой ад превращается поддержка несколько десятков сторонних библиотек, живущих в вашем проекте, скажем по прошествии 10 лет.
Горький опыт создания игровой компании
2016-01-14 в 11:11, admin, рубрики: game development, iOS разработка, бизнес студии, геймдев, игровая индустрия, ошибки в бизнесе, ошибки управления, разработка под iOS, создание игр, управление разработкой 
Возможно, это и звучит странно, но для создания бизнеса недостаточно только вложений и энтузиазма. В этой статье я приведу несколько полезных советов для развития проекта, которые дались мне через горький опыт.
Эта история о страстной мечте с печальным концом.
Летом 2012 я решил отдаться моей самой главной страсти – созданию компьютерных игр. У меня были средства, и я думал, что у меня есть всё необходимое для того, чтобы создать кампанию, занимающуюся разработкой игр.
Мы решили назвать её “Supersonic Parachute”.
Я не буду вдаваться в подробности, но укажу самые главные причины, которые привели нас к провалу.
Читать полностью »
Разбиение пользовательских историй – метод гамбургера
2016-01-14 в 9:48, admin, рубрики: agile, gojko adzic, hamburger method, scrum, user story, перевод, управление разработкойПредлагаю вашему вниманию перевод небольшой статьи Гойко Аджича на тему разделения пользовательских историй от 2012 года, с иллюстрациями и примерами автора: "Splitting User Stories: The Hamburger Method" — сделал его, в первую очередь, для себя.
Проблематика: История слишком велика и процесс разбиения и оценки слишком сложен; бизнес-пользователей не устраивает ни один вариант разбивки, предложенный командой разработки; команда не имеет достаточного опыта и использует только техническое разделение историй; запущен новый проект и у команды не выходит сформулировать достаточно простые пользовательские истории.
Решение: Метод гамбургера
Доступны записи докладов Community DevCamp
2016-01-11 в 10:47, admin, рубрики: .net, .net native, alm, ASP.NET, Azue, azure ml, C#, F#, impact mapping, Microsoft Azure, roslyn, Блог компании Microsoft, управление разработкой 
Стали доступны записи докладов 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.
Читать полностью »
Почему и зачем писать open-source код?
2016-01-10 в 22:00, admin, рубрики: development, open source, открытые данные, открытый исходный код, подход к работе, подход к разработке, Программирование, процесс разработки, разработка, управление, управление разработкой 
Под катом интересный опрос
Возможно, заголовок этой статьи покажется Вам не корректным, ”Как можно писать open-source код? И что это за код такой?” — спросите Вы.
Чем open-source код отличается от “просто-кода”? Open-source проект — это ответственность за качество кода, за покрытие его тестами, за документацию, за своевременные ответы на вопросы и реагирование на bug репорты, за обработку pull-request’ов. Ваше поведение и мысли во время написания open-source кода, который увидит мир будут другие, соответственно и код на выходе получается другой.
Open-Source проект живет своей жизнью — жизнью сообщества, которое образуется вокруг проекта. Идеи, отзывы, bug репорты, обсуждение и благодарности от других членов сообщества влияют на Вас и проект напрямую, и стимулируют написание кода — понятного, документированного и покрытого тестами.
Восход разработчикономики (окончание)
2016-01-08 в 22:17, admin, рубрики: Армагеддец, бомба замедленного действия, десятикратники, перевод с английского, Программирование, программисты спасут мир, Профессиональная литература, разработка, управление разработкой, эффективность работы, эффективность труда(начало статьи здесь)
Управление рисками при инвестировании в программистские таланты
С другой стороны — этот эффект не имеет названия; возможно, его следовало бы именовать «десятикрадничеством» — плохие разработчики будут стоить вам отнюдь не незначительного ухудшения производительности труда. Нет, по целому ряду трудноуловимых причин они способны катастрофически саботировать сложную программную систему. Плохим разработчиком, построившим угрожающе полную ошибок или из рук вон плохо спроектированную систему, в её основание заложена тикающая бомба замедленного действия, и чтобы разгрести руины после того, как она рванёт, потребуются вложения, тысячекратно превосходящие сэкономленное на старте. Хуже того, работа по разбору завалов потребует привлечения усилий гораздо большего количества хороших разработчиков, и на более длительное время.
В этом моменте разработка программного обеспечения является полной противоположностью другим отраслям — скажем, аэрокосмической, — в которых некомпетентность и грубые ошибки гораздо более очевидны; их легче обнаружить и исправить на ранних этапах, пока стоимость такого исправления ещё не выросла до небес. Отсроченные кризисы (вроде конструкции самолёта, в которой в ходе реальной эксплуатации обнаружился фатальный дефект) также гораздо легче удержать от распространения, изолировать и исправить.