На нашем сайте вы можете читать онлайн «Как хорошему разработчику не стать плохим менеджером». Эта электронная книга доступна бесплатно и представляет собой целую полную версию без сокращений. Кроме того, доступна возможность слушать аудиокнигу, скачать её через торрент в формате fb2 или ознакомиться с кратким содержанием. Жанр книги — Знания и навыки, Компьютерная литература, Программирование. Кроме того, ниже доступно описание произведения, предисловие и отзывы читателей. Регулярные обновления библиотеки и улучшения функционала делают наше сообщество идеальным местом для любителей книг.
Как хорошему разработчику не стать плохим менеджером

Дата выхода
27 февраля 2020
Краткое содержание книги Как хорошему разработчику не стать плохим менеджером, аннотация автора и описание
Прежде чем читать книгу целиком, ознакомьтесь с предисловием, аннотацией, описанием или кратким содержанием к произведению Как хорошему разработчику не стать плохим менеджером. Предисловие указано в том виде, в котором его написал автор (Константин Евгеньевич Борисов) в своем труде. Если нужная информация отсутствует, оставьте комментарий, и мы постараемся найти её для вас. Обратите внимание: Читатели могут делиться своими отзывами и обсуждениями, что поможет вам глубже понять книгу. Не забудьте и вы оставить свое впечатие о книге в комментариях внизу страницы.
Описание книги
В этой книге автор, сам прошедший путь от разработчика до менеджера в сфере IT, рассказывает неочевидные моменты, которые являются критически важными для правильного управления.
Почему разработчики увольняются после повышения зарплаты? Как делать FixedPrice проекты? Почему Scrum не упрощает менеджмент? Книга содержит ответ на эти и многие другие вопросы.
В книге есть много баек, которые показывают тяжёлую, но интересную жизнь менеджера в разработке.
Иллюстратор обложки: Ксения Ерощенко.
Иллюстрации в тексте книги авторские.
Как хорошему разработчику не стать плохим менеджером читать онлайн полную книгу - весь текст целиком бесплатно
Перед вами текст книги, разбитый на страницы для удобства чтения. Благодаря системе сохранения последней прочитанной страницы, вы можете бесплатно читать онлайн книгу Как хорошему разработчику не стать плохим менеджером без необходимости искать место, на котором остановились. А еще, у нас можно настроить шрифт и фон для комфортного чтения. Наслаждайтесь любимыми книгами в любое время и в любом месте.
Текст книги
Если в процессе разработки выяснились новые требования или выбранные технологии не подошли к задаче, то понятно, куда двигаться дальше. Вторая итерация проекта будет нацелена на исправление того, с чем не справилась первая итерация. Таким образом, провал проекта принесёт важную информацию и будет ступенькой для реализации системы.
Совсем другая ситуация, когда проект провален из-за низкой квалификации разработчиков или, ещё хуже, когда проект провален, и никто не понимает, почему. В этой ситуации провал проекта – это просто потраченные деньги.
Водопадная модель разработки
Периодически слышу от разных людей сожаление, что они используют водопадную модель разработки: “Мы бы и рады использовать Agile, но заказчик против”, “У нас водопад, мы к нему привыкли”, “Мы готовимся перейти на гибкие методологии, но пока у нас водопад”. Такие разговоры меня удивляют, так как встретить сейчас чистую водопадную модель разработки практически нереально.
Чтобы выяснить, почему так, давайте вспомним, что такое водопад как методология разработки, и как связаны разные этапы разработки:
Все этапы идут один за другим. Следующий этап начинается после полного окончания предыдущего этапа. Это очень-очень старая модель. Её название пошло из статьи Уинстона Уокера Ройса, опубликованной в 1970м году. Юмор заключается в том, что в той статье Ройс говорил об устарелости и ограниченности этой модели и о необходимости перехода на итеративные модели.
Нам сейчас даже трудно представить, как это было, но давайте попробуем. Вот у какой-то компании есть нужда в какой-то программе. Она оплачивает анализ требований какому-нибудь проектному институту. В результате получает вагон требований (буквально железнодорожный вагон документации), который принимается и подписывается. Эта документация потом направляется в другой проектный институт, который уже делает дизайн, описывает, какое оборудование и какие программы нужны для реализации задачи.






