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

Сегодня мы хотим поделиться впечатлениями от участия в тренингах 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, вместе с первым полезным опытом. Поработав так пару лет, я чувствовал, что настало время двигаться дальше…

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

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

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

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

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

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

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



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

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


Последняя осень?

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