Мой дед, Щепотин Василий Леонтьевич, с 1935 по 1939 год служил срочную танкистом на Дальнем Востоке во 2-й механизированной бригаде, дислоцировавшейся в Усурийске. За бои на озере Хасан был награжден медалью «Зо боевые заслуги». Он был достаточно скуп на воспоминания, но среди того немного, что он рассказывал отцу была история про то, как «японцы» пробрались в расположение и «всех спящих в казарме перекололи штыками».

Долгое время я считал это байкой, поскольку нигде в источниках подтверждения данного эпизода не нашел. И вдруг недавно наткнулся на воспоминания ветерана Антона Букина:

Читать дальше →

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

А. А. Керсновский, «История Русской армии»

Селиховкин Иван (PMLead) выложил очень толковый ликбез в четырех частях.

Читать дальше →

Чем отличается опытный менеджер от неопытного? Неопытный спрашивает: «А ты сделаешь макет ко вторнику? Успеешь?» Опытный же устраивает пытку открытыми вопросами: «Когда ты пришлёшь макет?», «Когда ты пришлёшь первый черновик?», «Расскажи, с каким сложностями ты столкнулся при разработке этого макета и поэтому не успеваешь?», в середине дедлайна «Расскажи, как продвигается задача? Какая информация от меня или клиента тебе нужна?»

Люди делают классные вещи в классном состоянии. Хороший менеджер ездит в отпуск без страха провалить проект, ходит в кино и не поглядывает в телефон, вдруг пришло какое-то сообщение (вдруг по работе!). Не распространяет беспокойство. Хороший менеджер — скала. Он знает закон: все всегда будет плохо. Иначе он был бы не нужен. Когда всё начинает валиться и сыпаться, должен появиться менеджер и помочь разрулить ситуацию: ты — держи жгут, ты — делай непрямой массаж сердца, ты — звони в скорую. Появился пульс — отдал парамедикам и пошёл дальше смотреть кино.

Отсюда

В последнее время для спецификации требований все чаще используют технику пользовательских историй (User story), а не вариантов использования (Use case). Однако, это не означает, что они лучше.

Пользовательские истории — это быстрый способ документирования на повседневном языке. Требование записывается в виде одной формализованной фразы, определяющей актора, потребность и ожидаемый результат (например, «As a WHO I want WHAT so that EXPECTED OUTCOME»). Такой способ экономит ресурсы на создание и поддержание требований, но требует тесного взаимодействия между исполнителем и заказчиком системы. User Story, к сожалению, не соответствует в полном объеме таким критериям «хороших требований» как полнота, однозначность и проверяемость. Хотя с этим можно бороться определяя критерии приемки.

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

UPD:
Как писать хорошие user story

UPD 2:
См. также User story vs. Job story