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

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

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



***

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

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

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

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

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

Например, совсем недавно мы рассказывали:

• о том, как Spotify масштабирует Apache Storm,
• рассматривали аппаратное обеспечение для глубокого обучения
• и бегло поговорили о примере оптимизации полосу пропускания в сетях Ethernet.

Сегодня мы расскажем о главных отличиях между PaaS и IaaS.

Хотите узнать что такое управление рисками и как с ними справляться с ловкостью ниндзи?
Тогда добро пожаловать под кат!

(В этой статье изложены мысли, навеянные творчеством Тома ДеМарко, и скорее всего статья будет неинтересна тем, кто уже знаком с его произведениями)

Управление командой по Scrum методологии приобрело широкое использование за счет своей простоты и возможности применить «из коробки». Сложнее ситуация, когда в рамках одного проекта работает несколько команд. В этом случае применяют иерархическую модель Scrum-on-Scrum. Но вот что делать, когда есть нескольких команд разработчиков и одна команда тестеров.

Сегодня мы решили обсудить заметку Кента Бека (Kent Beck), автора методологии экстремального программирования, о том, как взвесить «стоимость» вашего программиста.

Этот пост написан по мотивам мастер-класса Бориса Вольфсона (директора по развитию HeadHunter), посвященного (сюрприз!) основам Agile. Материал будет полезен всем, кто либо совсем не знаком с данной методологией разработки сложного ПО, либо имеет о ней смутное представление.

Практические кейсы, о которых мы уже рассказывали:

• ИТ-инфраструктура для высоконагруженного проекта Hotels.ru
• Переход на IaaS и масштабирование сети постаматов PickPoint
• Каким стартапам нужен IaaS: Сервисы распознавания речи
• Как бизнес работает с IaaS
• Что происходит на рынке IaaS

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

Например, совсем недавно мы рассказывали:

• о том, как Spotify масштабирует Apache Storm,
• рассматривали аппаратное обеспечение для глубокого обучения
• и бегло поговорили о примере оптимизации полосу пропускания в сетях Ethernet.

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

Если на вашем столе стоит чашка остывшего желанного кофе или чая, значит, что-то не так. Во всяком случае, так наверняка подумал бы Дэвид Аллен, автор знаменитого метода GTD (Getting Things Done). Мы хватаемся за тысячу дел, пытаясь попутно не забыть про бытовые мелочи, часто забываем о цели, но помним о неотвратимо приближающихся дедлайнах. Порой страх перед лавиной задач буквально парализует мозг и наступают апатия, прокрастинация, депрессия. Работа в такие моменты движется медленно, кажется, даже курсор мыши еле ползёт по монитору. Такая ситуация тем опаснее, чем больше человек работает в команде, особенно, если речь идёт о команде разработчиков.

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

Тимлид (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-команда разрабатывала свой продукт и всё было хорошо.