Рубрика «agile» - 59

В рамках постепенного перехода процесса разработки от стихийного к вменяемому, т.е. к Agile, начал все более остро вставать вопрос рисования/изменения графиков, чартов, задач и прочего. Изначально мы думали купить маркерную или меловую доску в ближайшем офисном магазине и использовать ее, но потом появилась, разрослась и захватила власть над нами идея сделать ее своими руками, о чем данная статья и повествует.Читать полностью »

Привет!

Управление Agile проектами с YouTrack 4.0В конце прошлой недели вышел долгожданный «мажорный» релиз инновационного баг-трекера YouTrack 4.0 с возможностью управления Agile-процессами. Об этом функционале мы и хотим вам рассказать немного подробнее.

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

В YouTrack 4.0 добавлен совершенно новый, независимый модуль для управления Agile-процессами, который без проблем подстроится под особенности реализации Scrum методологии или Kanban-процесса в вашей команде. Если же вы еще только осваиваете Agile-процессы, данный модуль станет прекрасным подспорьем в ознакомлении с ними, а также позволит комбинировать наиболее удобные для вас элементы каждого процесса.
Читать полностью »

За последние полгода мне удалось побывать на двух стартап-конкурсах — DOU Mixer и Garage48. В первом команда формировалась “на лету”, что внесло определенную избыточность и путаницу ролей. Поэтому, во втором мы решили участвовать укомплектованным еще до его начала составом.

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

Хочу поделиться парой инструментов, которые помогут быстро понять кто есть кто в команде и сэкономить время некоторых командо-образующих процессов.
Читать полностью »

image
Продолжаем разговор о степени погружения в Agile начатый здесь.
Логичным продолжением предыдущей статьи будет рассмотрение Agile Evaluation Framework (сокращенно Agile:EF). Если говорить кратко, то это фреймворк детальной оценки глубины внедрения (или степени освоения) определенных практик. Ключевым словом тут является «детальный» и «фреймворк».
Читать полностью »

Да-да. Именно размышления. Я не стану перечислять по пунктам «39 вещей, которые поднимут ваши продажи на 235%». Вместо 39 и 235 можно подставить любую другую цифру. Всякий здравомыслящий человек понимает, что ограниченные в своей конечности списки «how to’s» или «хаутусов», как я их про себя называю, нисколько не помогут в конкретной ситуации. По этому поводу есть хорошее высказывание одного ученого:

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

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

Все просто: когда в конце 90х человек заканчивает лингвистический вуз, по специальности учитель английского и немецкого языка, то ясное дело, что учителем работать ну никак не хочется. И даже окончание магистратуры этому желанию не способствует. Можно было попробовать свалить куда-нибудь, к чему стремились многие однокурсники, и что некоторые сделали, но этот вариант оказался не для меня. To cut a long story short, деятельность моя в IT, начатая в качестве переводчика, плавно переросла в продажи и маркетинг.

Ситуация в то время была весьма благоприятной для людей, владеющих английским. Конец 90х -начало нулевых. В западном мире широко раскручена тема аутсорса. Толковые мозги девелоперов из постсоветского пространства востребованы весьма и весьма. Появилась кучка мелких и средних компаний, которые подвизались на аукционах проектов, или просто каким-то другим способом находили себе заказики. Некоторые особо разросшиеся, которым удалось подгрести под себя ресурсы (какое ужасное слово применительно к людям), предлагали (и до сих пор предлагают) не услуги по разработке софта на заказ, а просто мозги. Естественно, что этим компаниям были нужны менеджеры по продажам, которые могли урвать проектик на аукционе, или же успешно продавать эти самые людские ресурсы. Сразу оговорюсь, в те годы я вообще слабо себе представляла, что в IT можно делать не просто проекты на заказ и продавать разработчиков, но и делать свои (!) собственные продукты. Не спущенные на тебя клиентом, а захотеть, решить и сделать свой продукт. И еще при этом даже добиться успеха. Но я забегаю вперед. Это только с годами стало ясно, что продавать аутсорс или мозги, и делать маркетинг своего продукта – это две больших разницы, как говорил кто-то из классиков.

Поговорим немножко об аутсорсе. К чему сводились продажи:

1. Тусоваться на онлайн-аукционах проектов. Обещать сделать максимум всего за минимум. Эта работа очень похожа на то, что делает зазывала на восточном базаре: во все горло расхваливает товар, не стыдится приврать и пообещать больше, чем можно реально сделать. Ведь главное же урвать проект, а как там потом, и как поступать с такой страшной вещью, как «сhange requests» — это дело десятое. Как-нибудь разрулится. Иногда оно и в самом деле разруливалось, когда клиент понимал, что действительно он стал хотеть уже немножко не то, и требуется больше эфортов, а иногда нет. Опять же, в то время я никак не понимала, почему же эти клиенты с самого начала точно не знают, что им надо, и почему у них меняются требования. Звучит смешно сейчас, когда космические корабли и т.п. и когда agile стал мейнстримом.

2. Рассылки. Они же email marketing, они же direct mailing. Берутся базы каких-нибудь приблизительно подходящих prospects и оптом промыливаются. Рассылками до сих пор пользуются индусские разработческие фермы. Когда я натыкаюсь на этот спам в своем ящике, всякий раз удивляюсь: неужели же до сих пор находится кто-то, кто отзывается на такие предложения.

3. Пресловутый cold calling. Столь много воспетый в разнообразных книжуськах по продажам. Насколько я знаю, cold calling еще сколько-нибудь нормально мог работать в Европе. В USA люди настолько уже запуганы втюхиванием всего чего угодно, что до живого человека дозвониться очень сложно. Я ни разу не видела, чтобы из cold calling'а получилось что-то путное, хотя существуют мифы, что кто-то где-то якобы кого-то таким образом подцепил.

Читать полностью »

image
Существует несколько метрик, позволяющих определить глубину погружения в Agile практики вашей команды. Первым методом измерения, который мы рассмотрим, будет Shodan Adherence Metrics – Метрика соответствия уровню «Шодан» (Шодан – первый дан – первая мастерская степень в японских боевых искусствах).
Читать полностью »

Хочу поделиться опытом по организации процесса тестирования, который охватывает 3 года моей работы и создание нескольких крупных систем. Описание будет затрагивать только автоматизацию «ручного» тестирования без пересечения с другими аспектами разработки ПО.

Я думаю стоит сразу упомянуть, что на всех этапах мы использовали:

  • Модульные тесты с покрытием около 50%
  • Continuous Integration с запуском модульных тестов (в последствии и интеграционных), автоматической сборкой и выпуском релиза
  • Пересечение из гибких методологий под общим названием ScrumbanXP

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

Читать полностью »

Я ни разу не читал сравнение методов подхода к разработке сайтов. Прекрасно понимаю, насколько это будет субъективно: каждый хвалит то, что умеет делать. И всё же, я решил обобщить свой опыт и наблюдения за тем, как это делают другие. В нашей сфере существует, грубо говоря, три наиболее популярных метода: проектирование, написание «ТЗ» и Agile. Вот их-то я и сравню.

На всякий случай договоримся о терминах:

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

в 15:23, , рубрики: agile, метки:

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

В своём недавнем докладе в таллинском девклубе я поднимаю эти и другие вопросы и делюсь выводами о том, работает ли Agile на практике, или это всего лишь очередной маркетинговый булщит. Надо отметить, что я рассматриваю аджайл с сугубо практических позиций и описываю, что это означает для разработчика: что ему пришлось бы поменять в своей ежедневной работе, какой плюсы и минусы сулит ему аджайл. И конечно же, (… барабанная дробь!...) отвечаю на вопрос, в каких случаях аджайл не работает!

www.devclub.eu/2012/05/27/videoholy-agile-solncev/

Читать полностью »

Автор оригинальной идеи этой статьи — Джон Иннс, консультант в области гибких методологий IT-разработки. С первоисточником можно познакомиться здесь. Мы его немного доработали, много упростили, но теперь статью, хотя бы, можно читать :)

Делаем сплав гибкой разработки и User Experience (UX)

Итак, есть такая штука, как опыт пользовательского взаимодействия (тот самый UX, User Experience). В целом, UX — это впечатление пользователя от вашего продукта (например, сайта). Сюда относится внешний вид, удобство расположения кнопок, ссылок и других элементов.

Почему учитывать опыт взаимодействия — важно? Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js