Публикации
Эджайл и технические коммуникации: работа с удалёнными командами (часть 1)
19.05.2014
Алисса Фокс продолжает серию статей, посвящённых эджайлу. Сегодня мы рассмотрим проблемы организации удалённой работы в команде и пути их решения.
Все чаще и чаще мы видим команды, разбросанные по всему миру. Все большее число предприятий функционируют таким образом по целому ряду причин. Всем, кто работает в эджайл-среде, полезно выяснить, как лучше решать проблемы, связанные с моделью глобальной команды.
Трудности работы с удалёнными командами
Часто в удалённой команде встречается ситуация «мы против них», особенно когда две команды собираются вместе в результате слияния. У вас вдруг оказываются большие команды по крайней мере в двух местах, и несложно забыть, что команда где-то в другом месте является частью вашей глобальной группы. Кроме того, если у команд в разных местах разные фоновые знания, различные рабочие процессы и разные культуры, трудность налаживания процесса совместной работы растет в геометрической прогрессии. Читать дальше…
Работа на несколько эджайл-команд (часть 2)
16.04.2014
Заканчиваем статью Алиссы Фокс, посвящённую одному из аспектов эджайл-процесса. Публикация заставляет задуматься, а не ввести ли эджайл-процессы в своей компании. Тем более что выбор среди возможных стратегий довольно велик.
Когда вы работаете на несколько команд, вы можете тратить 4-5 часов в неделю (или больше) на совещания для каждого назначенного проекта. Переговорите с руководителем или менеджером, чтобы распределить нагрузку таким образом, что вы можете делегировать обязательства посещений совещаний другим. Вот несколько предложений:
- Участвуйте только в совещаниях, которые относятся к самому приоритетному проекту на данный момент.
- Попросите человека, проводящего совещания, отправлять отчеты по электронной почте, чтобы помочь тем, кто не может присутствовать на каждом заседании для каждого проекта.
- Попросите руководителя или менеджера посещать некоторые важные встречи, когда вы не можете.
- Перестаньте посещать ненужные встречи. Даже если исторически сложилось, что вы присутствуете на определенного рода встречах, если вы не получаете от них достаточно, чтобы расширить свои знания о продукте или внести вклад в контент, над которым вы работаете, возможно, ваш лучше потратить это время на что-то другое.
- Всё больше и больше распределенных команд работают в эджайл-среде. Многие команды используют онлайн-инструменты для совместной работы для проведения совещаний и создания постоянных отчётов об обсуждениях. Рассмотрите возможность использования онлайн-инструментов для совместной работы для одной или нескольких ваших команд, что позволит вам, если вы пропустите встречу, проверить запись позже.
Работа на несколько эджайл-команд (часть 1)
14.04.2014
Мы продолжаем публикации на тему эджайл-разработки. Сегодня Алисса Фокс поделится опытом, как организовать одновременную работу над несколькими проектами без ущерба для качества.
Обзор
Казалось бы, клише «делать больше с меньшими затратами» в большинстве компаний сегодня является суровой реальностью. Людям надо делать больше, а времени и средств на это у них меньше. Для софтверных компаний один из способов это осуществить – частое и постоянное движение ресурсов между несколькими проектами. Когда моя команда начала использовать процессы эджайл-разработки, мы долго искали информацию о том, как использовать этот процесс при работе на несколько эджайл-команд. Мы обнаружили, что большинство писателей, занимающихся эджайл-разработкой, работали всего с одной командой разработчиков. Как у «плавающих» писателей, у нас теперь есть уникальные проблемы в эджайл-разработке.
Эджайл и технические коммуникации: командный подход (часть 3)
07.03.2014
В завершающей части статьи речь пойдёт о сворминге – что это, и чем хорош этот подход в эджайл-разработке, о работе над ошибками, а также о том, как допускать как можно меньше ошибок при командной работе и, таким образом, копить как можно меньше «технических задолженностей».
Сворминг
Чтобы командный подход стал успешным, инженерам по качеству и членам группы разработки информации нужны хорошая поддержка и обучение, которые помогут им адаптироваться к быстрому темпу эджайл-разработки. Тесное сотрудничество внутри команды может потребовать от ее членов освоения новых навыков, и действительно важно дать им время для этого. Одним из способов это осуществить является сворминг (от англ. Swarming — роение, обозначает совместную работу «всем скопом»).
Эджайл и технические коммуникации: командный подход (часть 2)
05.03.2014
Представляем вам продолжение статьи Алиссы Фокс о работе команд по эджайл-методологии. Сегодня вы узнаете, на ком лежит ответственность за результат при командном подходе, и о том, как обеспечить рациональное использование рабочего времени каждого члена команды вне зависимости от его роли и от времени выполнения своих функций представителями других ролей в команде.
Качество — это ответственность всей команды
Наряду с тем, что использование командного подхода, когда участвует вся команда целиком, даёт множество внутрикомандных преимуществ, наиболее очевидным внешним преимуществом является повышение качества продукта. Вся команда ответственна за разработку, тестирование и документирование по каждой из пользовательских историй до тех пор, пока спринт не будет окончен. Инженеры по качеству направляют эти усилия таким образом, чтобы вся команда работала над обеспечением выполнения всех этапов спринта.
Мы обнаружили, что для достижения наших целей в каждом спринте нам необходимо как можно больше автоматизировать тестирование. Автоматизированное тестирование быстрее, надежнее и менее подвержено ошибкам. Инженеры по качеству взаимодействует с группой разработки, чтобы обеспечить выполнение модульных тестов (unit tests) и повысить внимание к моментам, в которых существуют пробелы. Инженер по качеству должен также направлять усилия на разработку и автоматизацию приемочных тестов (acceptance tests), а также на выполнение исследовательских тестов (exploratory tests). Другими словами, ручное тестирование — это не самый гибкий (agile) способ получения высококачественного продукта. Для получения дополнительной информации о гибком тестировании и различных видах тестирования смотрите блог Лизы Криспин (Lisa Crispin) www.lisacrispin.com.
Эджайл и технические коммуникации: командный подход (часть 1)
03.03.2014
Продолжаем публикации из данной серии. Сегодня мы узнаем, какие ошибки можно допустить даже при введении принципов скрама в команде. Своим опытом поделилась Алисса Фокс, директор по производству информации и программному менеджменту в компании NetIQ, Хьюстон, США.
В предыдущих статьях «Эджайл и технические коммуникации» я рассказывала о преимуществах, которые эджайл-разработка даёт техническим коммуникаторам, особенно в отношении такого понятия как «скрам». В то время как «базовый» скрам поддерживает рабочий процесс и помогает синхронизироваться с остальной частью команды, командный подход к разработке в рамках скрама еще более укрепляет нашу роль в команде, всесторонне повышает эффективность коллективной работы и улучшает качество продукта и документации.
Стоимость разработки контента (часть 6)
19.02.2014
Итак, вы убедились в выгоде перехода на другие инструменты? И даже (мы вами гордимся) убедили в этом руководство? Думаете, самое сложное позади? А теперь попробуйте объявить о переменах сотрудникам. Только сначала прочитайте нашу статью, мы постараемся помочь.
Управляйте переменами
Дуглас Адамс сказал: «Перемены к лучшему. Ты оказываешься впереди».
Управление переменами является одной из самых сложных частей этого процесса. Экономическое обоснование ясно, сэкономленные деньги и затраты ясны. Что непонятно – это как изменить процессы, чтобы поддержать новую парадигму контент-разработки.
Другими словами: Как заставить людей изменить способ, которым они делают то, что они делают? Существует целая индустрия по изучению управления переменами. Мы можем призвать на помощь здравый смысл. Первый шаг для меня – это всегда выявление ожиданий.
Эджайл и технические коммуникации: 4 обязательных пункта, чтобы стать членом эджайл-команды (часть 2)
22.01.2014
Мы заканчиваем статью с советами техническому писателю, как стать полноправным членом команды. Сегодня мы узнаем, почему так важно брать на себя ответственность, что делать, чтобы остаться в проекте и почему иногда нужно спорить с разработчиками.
Участвуйте во всех областях разработки
Независимо от того, сколько раз вы это слышали или говорили, фраза «Я просто писатель» не освобождает вас от активной вовлеченности – невозможно стать одним из ключевых членов команды без полного погружения. Алан Прингл пишет об этом на сайте Scriptorium. Такой уровень участия гарантирует, что вы полностью вовлечены в проект с самого начала и знаете все требования, дизайн и что стоит за дизайном программного обеспечения. И это даёт вам дополнительное преимущество: «имидж», уважение, которое нужно, чтобы остаться в проекте.
Вы можете заработать этот имидж, выполняя несколько важных действий:
Эджайл и технические коммуникации: 4 обязательных пункта, чтобы стать членом эджайл-команды (часть 1)
20.01.2014
Мы продолжаем цикл статей, посвящённых такому понятию, как эджайл. Сегодня речь пойдёт о том, почему технический писатель должен стать частью команды и как это сделать.
Эджайл-разработка в значительной мере опирается на быструю и чёткую коммуникацию. Следовательно, может показаться, что коммуникация не будет для нас проблемой. В конце концов, мы же профессиональные коммуникаторы. Дело в том, что коммуникация эджайл-команды часто наталкивается на препятствие в виде предвзятых идей о том, что технический писатель делает или какой вклад может внести в команду. И эти предубеждения поддерживаются как техническим писателем, так и другими членами эджайл-команды. Хотя, вероятно, вы и не можете изменить устоявшиеся понятия других людей, вы можете избавиться от своих собственных. Далее — четыре обязательных пункта для любого технического писателя, стремящегося стать ключевым членом эджайл-команды.
Говорите
Звучит почти слишком просто, не так ли? Но многие технические писатели стесняются говорить в критические моменты и упускают возможности, которые могут и не повториться. Вас должны услышать, иначе вы не получите нужной информации, поэтому крайне важно, чтобы вы говорили на совещаниях и при личных встречах, связанных с каждым аспектом разработки продукта. Задавайте вопросы, много вопросов, и используйте все знания, чтобы внести свой вклад в развитие дискуссии. Говорите ради пользователей продукта. Защита интересов пользователя – роль, которую давно уже лелеют технические коммуникаторы, а это значит, что нужно говорить, пока не раскроются все проблемы и не найдутся решения. Например, если графический интерфейс трудно использовать, предложите и проведите тест на удобство пользования, чтобы непосредственно показать разработчикам борьбу, которую пользователи будут вести с текущим дизайном. Или, если вы узнали, что совещание по планированию проходит без вашего присутствия, поговорите с тем, кто его проводит, и попадите в список участников.
Эджайл и технические коммуникации: как видят скрам писатели (часть 2)
20.11.2013
Во второй части статьи о работе скрам-команд речь идёт о роли технических писателей в этих командах и о преимуществах от этого процесса для них.
Преимущества скрама для писателей
Скрам-подход подключает писателей во все области разработки продукта, и это ключевой момент для вашего успеха в команде. Когда вы участвуете с начала и знаете требования, дизайн и намерения, стоящие за дизайном программного обеспечения, вы не только получаете необходимую информацию, которая требуется для описания продукта, но и демонстрируете другим командам, отвечающим за функциональность (разработка, контроль качества), что вы настроены серьёзно изучить продукт. В результате вы получаете неоценимое уважение, какие-то хорошие отзывы и приглашение присоединиться к оркестру на следующий сезон.