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

Ведь, если лампочки зажигают –
значит – это кому-нибудь нужно?

Послушайте!

Кому-нибудь из тех, кто не мыслит жизни без свободы… от наличия на небе естественных светил. А ведь наши далёкие предки, в большинстве своём, безальтернативно посвящали ночное время глубокому сну. Да, чего уж там! Говорят, пока лампа Эдисона не завоевала популярность, люди спали по 10 часов в сутки. Лично я, находясь в потоке, не могу спать больше пяти. Но даже этого слишком много! Часто бывает достаточно трёх. Только без удобного и безопасного искусственного света о подобном оставалось бы лишь мечтать.

И хотя Томаса Эдисона называют королём изобретательства, идея электрической лампы накаливания принадлежит не ему. Зато ему удалось воплотить её в жизнь. Стать батарейкой, позволившей лампочке идеи зажечься. Обеспечить решающий эффект для прорывной технологии.

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

В минувшем году я окончательно пришёл к тому, что ныне склонен называть Advanced Agile Analysis. То, что помогло мне, подобно Эдисону, стать человеком-батарейкой, обеспечивая эффект технологических проектов вместо традиционного поклонения краткосрочным успехам, процессам и инструментам.

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

В то время как сторонники современных гибких методологий разработки выдумывают все новые и новые практики, их оппоненты также не стоят на месте. На фоне разнообразных XDD (FDD — Feature Driven Development, TDD — Test Driven Development, BDD — Behavior Driven Development, ATDD — Acceptance Test Driven Development) они сформулировали свою методологию — JSDD (Job Safety Driven Development). Кому интересны детали, добро пожаловать под кат.

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

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

«Идеальный» скрам: вредные советы
Читать полностью »

Бытует противоречивое мнение, что на проекте обязательно должен быть тестировщик. Но многие известные зарубежные проекты не имеют выделенных тестировщиков, особенно для привычных нашему миру задач. Как же так? Кто в этом случае будет отвечать за качество продукта? Кто будет искать и находить дефекты? Да и вообще, возможно ли такое? Если вас заинтересовали ответы на эти вопросы, то добро пожаловать под кат.

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

Темная сторона кода
«Покой — это ложь. Есть только страсть.
Через страсть я познаю силу.
Через силу я познаю могущество.
Через могущество я познаю победу.
Через победу мои оковы рвутся.
И Великая Сила освободит меня.»

— Кодекс ситов

Я хочу поговорить о темной стороне кода и о том, к чему это приводит. Что я понимаю под темной стороной кода? С моей точки зрения — это такой код, который был написан программистами, которые поддались желанию написать кое-как, исходя из своих собственных целей, а не целей продукта. Они оставили покой (размеренное написание кода согласно практикам) в угоду страсти (код ради кода). А если есть темная сторона, то есть и ее представители — Темные властелины, Дарты. Вот о них мы сегодня и поговорим.
Читать полностью »

Scrum — достаточно простая методология. Работать же по скраму не так и просто. Точно так же происходит со многими инструментами, например с покером для планирования. Практика сама по себе вполне понятная, но продуктивно её использовать в течении длительного времени затруднительно.
В этой статье я расскажу про технику, которая упрощает процесс оценок в работе скрам команды.
Итак, в чём же сложность?
Как вы знаете, story points — это относительные оценки объёма работы в истории. Нет способа оценить одну единственную историю в story points, вы всегда сравниваете историю с другими историями через story points. Покер может хорошо сработать в начале проекта, когда команды оценивает много историй в течении короткого промежутка времени.
Но позже, во время регулярной переоценки существующих историй и оценок новых историй становится значительно труднее, потому что калибровка одного story point забывается: «что такое один story point», «что-то я не уверен, что эта история действительно в 3 раза больше нашего золотого эталона», «эти две истории размером 5 не выглядят одинаковыми в размере, с моей точки зрения». Знакомые проблемы?
Читать полностью »

Программа AgileBaseCamp: VALUE Driven Development практически готова! В ее фокус мы взяли сближение бизнеса и девелопмента через понимание ценности продукта, нужд пользователей и приоритетов разработки. Доклады и воркшопы раскроют такие вопросы:

Алексей КривицкийАлексей КривицкийПочему проваливаются оценки и как побороть проблему сроков?  Артем СердюкАртем СердюкКак использовать Impact Mapping для наведения ясности в требованиях и приоритетах?
Наталья ТренинаНаталья ТренинаКак работать над видением продукта и вовлеченностью команды в его создание? Максим КлимишинМаксим КлимишинКак достигать состояния “done” и что для этого важно сделать на старте проекта?

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

От переводчика.
В 2009 года за рубежом возникло движение, которое назвало себя DevOps. На первый взгляд это разработчики с навыками сисадминов и сисадмины с навыками разработчиков. Но на самом деле это отнюдь не так. Данное подход имеет четкие цели, философию, инструменты и методы, которые только некоторые русскоязычные компании начинают использовать. Мне кажется, что данный подход у нас незаслуженно игнорируется и мне хотелось бы рассказать об 11 вещах, которые нужно знать о DevOps, в частности:

  • что такое DevOps
  • каковы его ценности
  • как он внедряется
  • кому он приносит пользу

Надеюсь этот текст вам понравится.
От переводчика.
Читать полностью »

Последнее время меня часто записывают в лагерь противников методологий управления проектами (чаще имея ввиду agile/scrum/kanban). Это не совсем так. Я не против методологий, а против их фанатичного применения к месту и без, а также просто мистичесой уверенности в успехе после внедрения agile.

Мне кажется, многие не понимают, зачем вообще нужна методология.

Методология — это некий контракт (договоренность) между всеми участниками процесса. Это как язык жестов, правила дорожного движения, эсперанто или математические формулы. Отличие этих примеров от aglile/scrum/kanban в том, что они не подразумевают различных трактовок. В случае с aglile/scrum/kanban — каждая компания, и даже каждая команда имеет свой «канбан», который в большинстве своем вообще ничего общего с ним не имеет.

По сути, нужно просто собраться всем участникам процесса и обговорить все нюансы. Это достаточно просто, например:Читать полностью »

Я работаю программистом более 5 лет (web), и хотел бы поделиться методикой, которая экономит силы, время и помогает автоматизировать процесс проектирования.

Методика основана на объектно-ориентированном проектировании, но несколько необычна. Зато имеет очевидные плюсы:
— в идеале, программирование по CORE сводится к описанию задачи (код близок к бизнес-логике)
— чётко разделяет систему на слабосвязанные компоненты
— легко автоматизируема, позволяет генерировать осмысленный код

Почему методика называется CORE и как это расшифровывается? Отчасти потому, что у меня тяга к красивым названиям. По буквам:
Context — контекст вычислений (что инициировало вычисления)
Object — объект, который производит вычисления
Request — действие, которое нужно совершить, чтобы объект смог продолжить вычисления
Event — событие, которое происходит с объектом

Плюсы по сравнению со стандартными способами разработки:
— ускорение стадии проектирования за счёт формализованной схемы проектирования
— ускорение стадии разработки за счёт умной генерации кода
— автоматизация создания юнит-тестов
— неглючная реализация бизнес-логики практически любой сложности
— простая поддержка кода
— простота совместного владения кодом

Минусы стандартных способов по сравнению с CORE:
— часто нельзя окинуть одним взглядом всю часть системы
— нужно самому продумывать когда и в каком месте будут вызываться обработчики тех или иных действий. CORE разруливает вызовы автоматически.
— часто вводятся дополнительные уровни абстракции, не связанные с бизнес-логикой, чтобы реализовать её особенности. в CORE это не нужно.
— программист часто совершает кучу однообразных действий, которые легко можно автоматизировать
— юнит-тестирование внедрять тяжелее

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


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