Управление разработкой *

Тимлид (aka ведущий разработчик, team leader) — один из таких «специалистов», обязанности которого многие видят по-разному. Думаю, что складываются различные представления примерно так: поработал кто-то в команде под руководством тимлида, который хорошо справлялся с задачами проектирования системы, и считает теперь, что это именно то, что должен делать тимлид; в другой же команде тимлид плохо справлялся с планированием спринтов, а с другими обязанностями более или менее, и стали считать сотрудники, что планирование — не то, чем должен заниматься тимлид.

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

Сегодня мы хотим поделиться впечатлениями от участия в тренингах Certified Scrum Master и Certified Scrum Product Owner от Innovel и ProCognita, которые проходили в Варшаве 29-30 июня и 1-2 июля соответственно. Здесь мы рассмотрим наиболее интересные с нашей точки зрения инструменты и техники, представленные на обоих тренингах, которые будут полезны как тем, кто делает свои первые шаги в SCRUM, так и уже имеющим некоторый опыт в применении гибких SCRUM в своих проектах. Мы оставили оригинальные названия упражнений, чтобы упростить поиск тем, кто впоследствии пожелает найти больше информации; кроме того, статья дополнена ссылками на англоязычные статьи, поясняющие суть некоторых упражнений.

Рассмотрим основные ошибки, связанные с громким скандалом вокруг взлома сервиса Ashley Madison. Попробует проанализировать ситуацию и сделать выводы.

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

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



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

Чем грозит долгострой в разработке и с какими трудностями предстоит столкнуться на этом пути? Как бизнес-аналитик компании, которая 15 лет занимается разработкой и поддержкой одного продукта (СЭД), я решила поделиться своими мыслями и примерами из практики. Проблематика управления требованиями в любых программных продуктах с длительным периодом реализации – актуальный вопрос для аналитиков, руководителей проектов и владельцев продуктов. И, возможно, для непосредственных партнёров и заказчиков Docsvision, ожидающих выхода новых версий и заинтересованных в появлении новой функциональности.

Прочитав несколько хороших статей по организации оперативного планирования средствами Redmine (например, тут), решил поделиться опытом и написать о том, как реализовано оперативное планирование в нашей компании.

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

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

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

Небольшой экскурс: молодая и небольшая компания, успешно применяющая Agile-подходы и Scrum в частности, вела всю разработку ПО одним отделом, разбитым на несколько Scrum-команд. Каждая Scrum-команда разрабатывала свой продукт и всё было хорошо.

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

Несколько лет назад переход к электронной торговле, документообороту, CRM и ERP-системам, системам управления проектами был растущим трендом. В 2015 году – это объективная потребность большинства компаний всех секторов экономики. Корпоративное программное обеспечение прочно вошло в жизнь российского бизнеса и затронуло практически все бизнес-процессы. А как вам дышится в вашей IT-атмосфере?

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

Удивительно, но одна из основных сфер деятельности, которую обогащают и укрепляют облачные технологии — это маркетинг. Посмотрим, в что именно может дать современный подход к работе с ИТ-инфраструкторой тем, кто занимается продвижением продуктов и услуг.

Добрый день, все хабровчане!

А давайте поговорим о западном бестселлере, перевод которого почему-то прошел незамеченным.
Речь пойдет о книге Г. Лакман Макдауэлл «Карьера менеджера IT-проекта. Как устроиться на работу в ведущую технологическую компанию».

Ранее, я повторно опубликовал две свои старые статьи (оригиналы: раз, два — прим. перев.), касающиеся процесса технических собеседований. Полагаю, что мог бы описать более подробно, как провожу собеседования и на что при этом обращаю внимание.

Вот мои главные цели:

• не нанимать плохих работников;
• нанимать хороших работников;
• оставить кандидата с положительным впечатлением о компании.

Сегодня мы расскажем о нашем очередном нововведении — DNS-менеджере. Он построен на основе решения ANS и уже доступен для всех наших клиентов.

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

Двигаясь от опытного образца к серийному изделию мы попадаем в область действия “нелинейной математики” с большим количеством факторов, которые необходимо учитывать чтобы правильно рассчитать объём вложений. Данный вывод кажется очевидным, но на практике я часто сталкиваюсь с любовью к недопустимым упрощениям в расчётах. В дальнейшем приводит к серьёзным финансовым проблемам, трениям в команде, зачастую финалом становится крах проекта.

До сих пор, мое продвижение по карьерной лестнице было быстрым. В 2008 году, я начал работать на полную ставку программистом в должности Junior Developer. Там был славный босс и классные коллеги, и я получил навыки использования Java и .NET, вместе с первым полезным опытом. Поработав так пару лет, я чувствовал, что настало время двигаться дальше…

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

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

Тайм-менеджмент по сути это совокупность действий по тренировке осознанного контроля над временем, посредством которого можно существенно увеличивать свою продуктивность и эффективность.

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

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

Для начала рассмотрим основную идею тайм-менеджмента. То есть возьмем то, что не напугает разработчика.

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



Итак, несмотря на то, что сегодня мой бизнес явно зашёл в тупик, рискну таки дать несколько советов фрилансеру-электронщику. Кстати, многие из них будут полезны и в других сферах деятельности: (к сожалению, я не нашёл в интерфейсе Хабра структурированных списков, поэтому пришлось изобразить вложение как ___)