MyPlainText

Дочитал книгу Сазерленда «SCRUM. Революционный метод управления проектами» Очень удобно, что в конце каждой главы подводятся итоги. Я решил выписать сюда те, которые больше всего приглянулись мне. Это все скорее общие принципы, а не практические советы. Кстати, практика тоже есть в этой книге, но ей отведено совсем немного внимания. В самом конце. А сама книга делает все, чтобы читатель пропитался философией SCRUM. Вот что я себе выписал: Планировать полезно. Пытаться нагнать, чтобы следовать плану – глупо.  Проверять и адаптироваться. Измениться или умереть!💀 Сомнение смерти подобно.💀  Наблюдать, ориентироваться, решать, дествовать. Великие коллективы – многофункциональные, автономные, свободные в принятии решений. Малочисленные команды работают эффективнее, чем многочисленные. 5-9 человек – идеально. Обвинять глупо. Не нужно искать дурных людей, ищите вредные системы. Демонстрируйте или умрете.💀  В конце каждого спринта должно быть что-...

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

Анализ и расстановка приоритетов рисков - это следующие после "Определения" этапы в цикле управления рисками . Сам анализ предполагает 2 этапа: Определение вероятности свершения каждого риска. Можно использовать набор величин: 10%, 25%, 50%, 75%, 90%. Вполне естественны затруднения на этом этапе даже при выборе из пяти дискретных значений. Для достижения объективной оценки вероятности свершения можно использовать такой прием: проводить оценку вероятности свершения рисков всей командой или частью команды. Сначала проводить оценку рисков индивидуально и анонимно. После чего обсуждать результаты, приходя к общему мнению.        2. Оценка воздействия на проект в случае свершения риска.В простейшем случае предлагается оценка от 1 до 5, где 1 - незначительное 2 - малозначительное 3 - среднезначительное 4 - значительное 5 - сильнозначительное. В более сложных вариациях возможны варианты оценки воздействия риска на проект по следу...

Определение рисков проекта - первый этап, с которого начинается процесс управления рисками. При определении рисков следует понимать, что есть общие риски и специфические , завязанные на конкретном проекте. Общие риски присущи практически любому проекту разработки ПО, например, изменение требований заказчика, потеря ключевого члена команды. К специфическим можно отнести те, которые зависят от сферы, в которой разрабатывается проект, от исполнителей, технологий. Также необходимо уметь выделять риски по следующим трем группам: проектные  риски, риски продукта , бизнес риски. Проектные риски - те, которые влияют на ресурсы и работу проекта. На бюджет или на команду, например. Риски продукта - те, которые влияют на конечное качество продукта Бизнес-риски - те, которые могут повлиять на соответствие продукта бизнес-требованиям и бизнес-стратегии. Далее будет приведен ряд базовых факторов, которые следует учитывать при управлении риск...

Предыстория С началом работы над крупным проектом в нашей небольшой команде встал вопрос о том, чтобы планировать итерации разработки, выбирать задачи и оценивать их объёмы. Кроме бэк-энд разработчика, пришедшего вместе со мной, никто такого опыта не имел: ни дизайнер, ни верстальщик, ни фронт-энд разработчик - отсюда и результат: 1-ая итерация клиентской разработки затянулась на 2 недели, относительно оценки. А 2 недели эти сложились очень быстро: - Сперва дизайнер что-то не учел на пару-тройку дней - Эти же пара дней сказались на работе верстальщика с дополнительным коэффициентом, ввиду того, что сверстать более трудоёмко - Ну и в завершение - Front-end разработчику приходилось ждать вёрстку  Чтобы оценить: 2 недели задержки при, скажем, 1000 руб/час это 80 000 руб. /*1000 руб/час взял условно*/ После таких  грустных расчетов я вспомнил о суперсиле риск-менеджмента! Очевидно, что стоило изначально учесть неопытность членов команды в та...