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

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 — это впечатление пользователя от вашего продукта (например, сайта). Сюда относится внешний вид, удобство расположения кнопок, ссылок и других элементов.

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

Один человек в интернете спросил меня, как я могу защитить методологии Agile.

Agile что? Не существует такой вещи, как методологии Agile.

Всё очень просто. Во-первых, парни из Agile манифеста не владели словом «Agile». Во-вторых, они не говорили сделайте то-то, сделайте это, они просто говорили о том, что мы фокусируемся не на тех вещах.
Читать полностью »

Приглашаем веб-разработчиков, особенно с опытом создания/использования userscripts, стать бета-тестерами проекта tai.st — нового способа улучшения сайтов силами пользователей.

Taist: прокачай свои интернеты

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

Давайте познакомимся с новыми инструментами планирования, появившимися в TFS 11 Beta, которые можно использовать в разработке Windows, Web, мобильных, облачных и кросс-платформенных приложений.

О гибком планировании и управлении работами в TFS 11 Beta

Так как TFS позволяет использовать несколько шаблонов процессов для поддержки разных методологий организации процесса разработки, мы сначала рассмотрим только один из них, наиболее популярный SCRUM.
Для знакомства нам могут понадобиться: образ виртуальной машины, руководства к лабораторным работам или данная статья – на выбор.

План захвата темы:
• Описание требований (Backlog)
• Планирование итерации
• Планирование работ
• Загруженность исполнителей
Читать полностью »


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