Новые темы @ it4business.ru www.it4business.ru

www.it4business.ru | Портал для IT-менеджеров

Портал для IT-менеджеров: Карьера, Персонал, Технологии

Точки влияния: места вторжения в систему

Ключевым вопросом для архитекторов и дизайнеров программного обеспечения является «где и как вводить изменения в систему для осуществления желаемых изменений». Точки влияния это те места, где микро изменения могут дать макро результаты. Коммерческое предприятие представляет собой систему, которая может быть изменена путем стратегического внедрения вычислительных технологий в соответствующих точках влияния. IT — это тоже система, которую можно изменить, сделав ключевые изменения в точках влияния. В обоих случаях необходимо вычислить точки влияния и определить тип и величину внедряемых изменений.

Точки влияния: места вторжения в систему

Донелла Мидоуз — автор книги «Thinking in Systems: A Primer», номинант премии Пулитцера, получившая награду «гения» от фонда МакАртур; ее работа «Leverage Points» до сих пор считается классическим пособием для тех, кто хочет осуществлять изменения в системе. Донелла Мидоуз умерла в 2001 году, но ее идеи о точках влияния собраны в The Solutions Journal. (дальше »)

Комментарии (0)

Конференция Agile Eastern Europe 2010 — льготные условия для читателей www.it4business.ru

8-9 октября 2010 года в Киеве состоится конференция Agile Eastern Europe!

Насыщенная программа — 2 дня, 4 потока, 40 докладов и воркшопов! Мастер-классы ключевых спикеров это прекрасный способ получить передачу опыта профессионалов и официальный сертификат Agile Alliance (для классов CSM и CSPO).

Конференция Agile Eastern Europe 2010 — льготные условия для читателей www.it4business.ru

Незабываемая атмосфера — обмен опытом, профессиональные контакты, много общения и фана в духе Agileee!

Для читателей портала www.it4business.ru, действует специальная программа — на нашем портале вы можете получить промо-код, указав который при регистрации на конференцию вы получите скидку 10%! (дальше »)

Комментарии (1)

Agile команда и контракты с фиксированной ценой

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

Agile команда и контракты с фиксированной ценой

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

Так давайте же начнем с самого контракта. (дальше »)

Комментарии (0)

Одиссея тестировщика

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

Одиссея тестировщика

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

Комментарии (0)


Вас задерживает многозадачность

В современном бизнесе принято полагаться на многозадачность, и оценка сотрудника как специалиста зависит от его способности выполнять несколько задач одновременно. IT-специалисты постоянно работают в нескольких проектах сразу. Всегда ли так было? Действительно ли многозадачность необходима? Какую реальную пользу она приносит? И есть ли ей альтернативы?

Вас задерживает многозадачность

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

Комментарии (4)

Что влияет на ценность продукта?

Agile или управление жизненным циклом

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

Что влияет на ценность продукта?

Если подойти к этой запутанной проблеме с точки зрения философии и начать задавать вопросы, то первым из них, и главным, будет вопрос: для кого производится продукт? Ответ на него прост: для пользователей. А с чем пользователи ассоциируют выгоду, полученную от использования продукта, за который они заплатили? Ответ снова прост: с номинальной ценностью продукта. Это базовое определение ценности продукта. За многие годы это определение отошло от своего первичного значения и превратилось в стремительно развивающуюся категорию, содержащую в себе понимание ценности продукта. Так происходит оттого, что само понятие ценности и ее определение претерпели ряд существенных изменений за последние 10 лет. (дальше »)

Комментарии (0)

Асхат Уразбаев: Scrum — подход к управлению сложными проектами

1 июня 2010 в рамках совместной инициативы Гильдии менеджеров программных проектов и Локальной группы по интересам «Управление проектами в ИТ и телекоммуникациях» московского отделения американского Института управления проектами (PMI) состоялся семинар Асхата Уразбаева «Scrum — подход к управлению сложными проектами».

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

Семинар провел Асхат Уразбаев, вице-президент Гильдии, евангелист Agile и Scrum, Agile Coach, совладелец компании ScrumTrek, основатель сообщества AgileRussia.

Предлагаем Вашему вниманию видеокаст выступления Асхата:


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

Участники смогут зачесть 1 PDU за этот семинар при продлении сертификации PMI PMP, PgMP. ID семинара: OSMC16.

Комментарии (0)

Основы пользовательских историй. Часть 4: Разбиение пользовательских историй

Авторы: Дин Леффингуэл (Dean Leffingwell, blog), Пит Беренс (Pete Behrence)
Перевод: Александр Якима (www.enter-agile.com)

Основы пользовательских историй

Разбиение пользовательских историй

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

Комментарии (0)

Основы пользовательских историй. Часть 3: Инвестируйте в качественные пользовательские истории

Авторы: Дин Леффингуэл (Dean Leffingwell, blog), Пит Беренс (Pete Behrence)
Перевод: Александр Якима (www.enter-agile.com)

Основы пользовательских историй

Инвестируйте в качественные пользовательские истории

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

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

Комментарии (1)

Основы пользовательских историй. Часть 2: Форма пользовательской истории

Авторы: Дин Леффингуэл (Dean Leffingwell, blog), Пит Беренс (Pete Behrence)
Перевод: Александр Якима (www.enter-agile.com)

Основы пользовательских историй

Карточка, диалог и подтверждение

Рон Джеффрис (Ron Jeffries), другой среди создателей XP, дал описание, ставшее для нас наиболее предпочтительным представлением о пользовательских историях. Он воспользовался словосочетанием: Карточка, Диалог и Подтверждение4, для описания трех элементов стори, где:

Карточка представляет собой 2-3 предложения для описания намерения стори. Карточка служит запоминающимся символом, резюмирующим намерение и представляет собой более детальное требование, дальнейшие подробности которого еще будут подлежать определению. (дальше »)

Комментарии (1)



Последние новости и пресс-релизы компаний

Статистика

  • Rambler's Top100 Рейтинг блогов хостинг от .masterhost

Исправляйте ошибки

Система Orphus

Мы рекомендуем

  • Java developers community of KPI